|
From: Martin P. <Mar...@ia...> - 2009-08-18 15:03:48
Attachments:
tboot_DQ45CB.cap
|
Hi list.... Trying tboot on a Intel DQ45CB, SENTER fails with - see attached log. What does the LT.ERRORCODE want to tell me? Any hints appreciated :-) Martin |
|
From: Hal F. <hal...@gm...> - 2009-08-18 15:35:26
|
Hi Martin. The error from your log is:
TBOOT: LT.ERRORCODE=c0002cd1
TBOOT: AC module error : acm_type=1, progress=0d, error=b
Progress 0xd, error 0xb is:
1011 TPM NV RAM is unlocked
I'm surprised it cares about this. The nonvolatile memory in the TPM
is shipped in a rather permissive, "unlocked" state. At some point it
is supposed to be "locked" after which time a degree of authentication
is necessary for certain instructions. Sounds like SINIT wants the TPM
to have been converted to the locked state.
The lcptools directory in tboot contains a command nvlock which will
lock the TPM. As the Readme.txt warns:
"Warning
The tools can only run on the machine with TPM 1.2 Device. And
be careful on using the nvlock command, because after the tpm device
is locked, it could not be unlocked again."
But I don't think there's probably any harm. I think you can still add
NV areas, like if you want to define a policy someday as to which
versions of tboot can load, etc. Maybe someone else can confirm that
(A) locking the NV RAM is necessary for the SINIT to run; and (B)
locking it won't cause any trouble with future things you might want
to do with the TPM.
Hal Finney
On Tue, Aug 18, 2009 at 8:03 AM, Martin
Pirker<Mar...@ia...> wrote:
> Hi list....
>
> Trying tboot on a Intel DQ45CB,
> SENTER fails with - see attached log.
> What does the LT.ERRORCODE want to tell me?
>
> Any hints appreciated :-)
> Martin
|
|
From: Martin P. <Mar...@ia...> - 2009-08-19 10:03:43
Attachments:
brick.log
|
Hal Finney wrote: > TBOOT: LT.ERRORCODE=c0002cd1 > TBOOT: AC module error : acm_type=1, progress=0d, error=b > > Progress 0xd, error 0xb is: > 1011 TPM NV RAM is unlocked Yes, I remembered there is a list somewhere - I looked into the TXT docs, the chipset docs - but not into the SINIT package... I locked the NV ram. Then, SINIT complained about a pre-production AC module, as the platform default policy does not allow one. Then I wrote a user policy which allows a pre-production module. I tboot-ed again and it stucks at GETSEC[SENTER]. Hardware reboot -> box does not boot anymore. Lights come up, fan starts for a sec, lights go off, fan too. Neverending cycle. Hmm.... kinda looks like Hal's problem? I now have a box which is a brick :-((((( (Removing CMOS battery to clear TPM NV does not help) FYI (AFAIR): Intel DQ45CB, BIOS version 0085 TBoot f332236d7183 bootlog before crash captured from serial console attached Martin PS: Intel, if you want to debug this bricked DQ45CB - send me a new one? |
|
From: Martin P. <Mar...@ia...> - 2009-09-18 12:54:15
|
Hi list... Martin Pirker wrote: > I now have a box which is a brick :-((((( > (Removing CMOS battery to clear TPM NV does not help) > > FYI (AFAIR): > Intel DQ45CB, BIOS version 0085 > TBoot f332236d7183 > bootlog before crash captured from serial console attached We got a replacement board under warranty. Updated to BIOS version 0093. Updated TBoot to latest da3ebacc9b6d. Result: Good news: The board is still working.... ;-) Bad news: Executing TBoot, it gets stuck at TBOOT: executing GETSEC[SENTER]... This happens every time, whenever control is transfered from TBoot to SINIT AC, control appears to never get back to TBoot. After reset (by reset switch) we get: LT.ERRORCODE=c0000001 This is valid error/software error/SINIT 00/0000 -> SINIT Exit Point Martin |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-22 20:26:27
Attachments:
carter.tboot.success.0-20090922.txt
|
Hi Shane, cc list, I'm experimenting with SENTER on an HP 8530p with the newest BIOS. tboot works without issue. However, when I run my own code, the laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I am doing wrong based solely on that error message. Attached is the log for the successful tboot run. I'm trying to figure out what might be unusual about this platform that causes it to fail, as my code does work on another system that I have here. This line is interesting: TBOOT: SINIT does not support launch with MLE pagetable in ECX And there's a chance I'm doing something wrong with the MTRRs, but the error message does not seem to relate to either of these. Any ideas? Thanks, -Jon |
|
From: Wang, S. <sha...@in...> - 2009-09-23 06:15:04
|
Jonathan M. McCune wrote: > Hi Shane, cc list, > > I'm experimenting with SENTER on an HP 8530p with the newest BIOS. > tboot works without issue. However, when I run my own code, the > laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated > with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I am > doing wrong based solely on that error message. > > Attached is the log for the successful tboot run. I'm trying to > figure out what might be unusual about this platform that causes it > to fail, as my code does work on another system that I have here. please check: do you set the return entry in your code? another system? you mean hardware or software? do you use the correct sinit? can you run tboot on the system your system you mentioned? can you compare with tboot code what your code hasn't done? > > This line is interesting: > > TBOOT: SINIT does not support launch with MLE pagetable in ECX It is printed by me. SINIT will support this but now it is not ready. > > And there's a chance I'm doing something wrong with the MTRRs, but the > error message does not seem to relate to either of these. Any ideas? > > Thanks, > -Jon |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-23 17:17:07
|
Hi Shane, Thanks for your reply. Wang, Shane wrote: >> I'm experimenting with SENTER on an HP 8530p with the newest BIOS. >> tboot works without issue. However, when I run my own code, the >> laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated >> with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I am >> doing wrong based solely on that error message. > please check: > do you set the return entry in your code? I'm not sure what you mean by this. > another system? you mean hardware or software? do you use the correct sinit? I mean hardware, and I believe I am using the correct sinit, as I use the same sinit that allows tboot to work on each machine in question. My code works on an HP dc7800 with Q35_SINIT_16.BIN, and it works on a Lenovo T400 with GM45_PM45_SINIT_19.BIN. > can you run tboot on the system your system you mentioned? Yes, tboot works perfectly on the HP 8530p. > can you compare with tboot code what your code hasn't done? I can and will if I must but I am mostly just seeking to understand a little more about what the "SINIT Exit Point" error means. Is this related to the "return entry" you mention above? Thanks, -Jon |
|
From: Cihula, J. <jos...@in...> - 2009-12-02 08:07:28
|
> From: Martin Pirker [mailto:Mar...@ia...] > Sent: Monday, November 23, 2009 2:32 AM > To: tbo...@li... > > Hi.... > > another BIOS update, another try.... > > Intel DQ45CB, bios rev 103(20091104) > TBoot e57acd4d1460 > > Good news: > board does not turn into a brick > > Bad news: > executing TBoot, it still gets stuck at > TBOOT: executing GETSEC[SENTER]... > > > ...so, will TXT work sometime on Intel's own mainboard? :-/ This BIOS is one of those that has usable RAM both below and above its ACPI reserved regions. It is also one of the BIOSes that gets hung in SMM when the legacy USB buffers (in those ACPI reserved regions) are DMA protected. The work around is to disable legacy USB support. Meanwhile, I will be fixing tboot to not DMA protect these regions when it finds such a case (the current code will not DMA protect reserved regions as long as there is no RAM after them). This is a non-trivial fix, so it may take a little while. Joe |
|
From: Martin P. <Mar...@ia...> - 2009-12-03 16:50:21
|
Cihula, Joseph wrote: >> From: Martin Pirker [mailto:Mar...@ia...] >> another BIOS update, another try.... >> >> Intel DQ45CB, bios rev 103(20091104) >> TBoot e57acd4d1460 > The work around is to disable legacy USB support. Indeed, that's the trick, thank you! I can confirm successful tboot, done with LCP "any" and "hashonly" policy. - as this disables the keyboard one has to control GRUB menu by serial console - for some reason GRUB only likes serial speed 9600, so tboot needs to be set to 9600, too - booted with a 2.6.30 kernel with TXT + Intel TPM patches - all TPM NV + TXT LCP stuff done solely with jTpmTools - I can also confirm a successful tboot on a HP dc7900 with vanilla 2.6.32 No TXT patching necessary :-) One board nailed - what about the others? - Is there a way to identify the BIOSs which seemingly do contain some bad code which turns the boards to bricks upon SINIT? I don't like the trial and error strategy... - Can anybody report tboot experiences with other Q45 boards, e.g. Asus P5Q-EM DO/P5Q-VM DO (Intel TPM) Fujitsu D2831-S/D2836-S (IFX TPM) Gigabyte GA-EQ45M-S2 (IFX TPM) ...and laptops? Best regards, Martin |
|
From: Cihula, J. <jos...@in...> - 2010-05-19 22:09:37
|
> From: Martin Pirker [mailto:Mar...@ia...] > Sent: Monday, April 19, 2010 4:17 AM > > Cihula, Joseph wrote: > > The work around is to disable legacy USB support. Meanwhile, I will > > be fixing tboot to not DMA protect these regions when it finds such a > > case (the current code will not DMA protect reserved regions as long as > > there is no RAM after them). This is a non-trivial fix, so it may > > take a little while. > > Any news on this? It took a while, but c/s 203 fixes this issue. Joe |
|
From: Wang, S. <sha...@in...> - 2009-09-22 02:57:39
|
Martin, Error 0xc0000001 is fine. Anyway, you can reset and get the machine work;-) Can you send me the log if convenient? Make sure you enabled TXT, TPM and VT-d in BIOS, get the correct SINIT for the board. Thanks. Shane Martin Pirker wrote: > Hi list... > > Martin Pirker wrote: >> I now have a box which is a brick :-((((( >> (Removing CMOS battery to clear TPM NV does not help) >> >> FYI (AFAIR): >> Intel DQ45CB, BIOS version 0085 >> TBoot f332236d7183 >> bootlog before crash captured from serial console attached > > We got a replacement board under warranty. > Updated to BIOS version 0093. > Updated TBoot to latest da3ebacc9b6d. > > Result: > Good news: The board is still working.... ;-) > > Bad news: > Executing TBoot, it gets stuck at > TBOOT: executing GETSEC[SENTER]... > > This happens every time, whenever control is transfered from > TBoot to SINIT AC, control appears to never get back to TBoot. > > After reset (by reset switch) we get: > LT.ERRORCODE=c0000001 > > This is > valid error/software error/SINIT > 00/0000 -> SINIT Exit Point > > > Martin > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your developing skills, take BlackBerry mobile applications to market > and stay ahead of the curve. Join us from November 9-12, 2009. > Register now! http://p.sf.net/sfu/devconf > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Martin P. <Mar...@ia...> - 2009-09-22 07:54:38
Attachments:
tboot_martin_try2.cap
|
Wang, Shane wrote: > Error 0xc0000001 is fine. Anyway, you can reset and get the machine work;-) > Can you send me the log if convenient? > > Make sure you enabled TXT, TPM and VT-d in BIOS, get the correct SINIT for the board. attached Note that this is the identical setup/kernel which tboots on the HP box just fine - we moved the harddisk.... Thanks, Martin |
|
From: Jonathan M. M. <jon...@cm...> - 2009-09-23 19:53:23
|
Hi Shane, cc list, Jonathan M. McCune wrote: >>> I'm experimenting with SENTER on an HP 8530p with the newest BIOS. >>> tboot works without issue. However, when I run my own code, the >>> laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated >>> with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I am >>> doing wrong based solely on that error message. This laptop contained 4GB of physical memory in two 2GB DIMMs. I removed one of them, leaving the system with only 2GB of physical memory. This enables my code to execute successfully. I realized this when I noticed that despite having CONFIG_HIGHMEM4G=y in the kernel config, the system only sees 3GB of memory. I then took a closer look at the value read from TXTCR_SINIT_BASE. The value is 0x7be00000 with 2GB of RAM in the system, but it changes to 0xbfe00000 with 4GB in the system. However, 0xbfe00000 is much closer to 3GB than 4GB. tboot will execute successfully with either amount of memory in the system, and also sees 0xbfe00000 in TXTCR_SINIT_BASE with 4GB of RAM in the system. Thus, I'm still not exactly sure what causes my code to fail. However, I discovered that the chipset in this laptop has an issue with making all 4GB of RAM available despite CONFIG_HIGHMEM4G=y, and instead requires PAE support to see more than 3GB of RAM (I did verify that with CONFIG_HIGHMEM64G=y all 4GB are visible to Linux). Here's a thread that discusses this unexpected need for PAE: http://lkml.indiana.edu/hypermail/linux/kernel/0607.3/1787.html I'm not sure if these issues are related yet. Suggestions / comments / questions welcomed by all. Thanks, -Jon |
|
From: Wang, S. <sha...@in...> - 2009-09-24 08:52:01
|
OK. So, it should not be the problem of entry point. Originally what I mean is the entry point in tboot header structure. (see init_txt_heap()) CONFIG_HIGHMEM4G should be kernel config. When you get "reset" in GETSEC[SENTER], kernel is not running. So, I don't think the problem is related to any of kernel configs. Can you check your PMR setting for 4G? vtd_pmr_lo_base/size and vtd_pmr_hi_base/size. This is what I can think related to memory. PS: is it convenient for you to send me your serial log of your code? Shane Jonathan M. McCune wrote: > Hi Shane, cc list, > > Jonathan M. McCune wrote: >>>> I'm experimenting with SENTER on an HP 8530p with the newest BIOS. >>>> tboot works without issue. However, when I run my own code, the >>>> laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated >>>> with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I >>>> am doing wrong based solely on that error message. > > This laptop contained 4GB of physical memory in two 2GB DIMMs. I > removed one of them, leaving the system with only 2GB of physical > memory. This enables my code to execute successfully. > > I realized this when I noticed that despite having CONFIG_HIGHMEM4G=y > in the kernel config, the system only sees 3GB of memory. I then > took a closer look at the value read from TXTCR_SINIT_BASE. The > value is 0x7be00000 with 2GB of RAM in the system, but it changes to > 0xbfe00000 with 4GB in the system. However, 0xbfe00000 is much closer > to 3GB than 4GB. > > tboot will execute successfully with either amount of memory in the > system, and also sees 0xbfe00000 in TXTCR_SINIT_BASE with 4GB of RAM > in the system. > > Thus, I'm still not exactly sure what causes my code to fail. > > However, I discovered that the chipset in this laptop has an issue > with making all 4GB of RAM available despite CONFIG_HIGHMEM4G=y, and > instead requires PAE support to see more than 3GB of RAM (I did > verify that with CONFIG_HIGHMEM64G=y all 4GB are visible to Linux). > Here's a thread that discusses this unexpected need for PAE: > > http://lkml.indiana.edu/hypermail/linux/kernel/0607.3/1787.html > > I'm not sure if these issues are related yet. Suggestions / comments > / questions welcomed by all. > > Thanks, > -Jon |
|
From: Cihula, J. <jos...@in...> - 2009-09-30 23:41:41
|
Error code 0xc0000001 isn't really an error code, but rather an indication that SINIT has finished successfully. SINIT writes this (almost) just before it transitions to the MLE entry point as a way of indicating that it has gotten that far. There is a small window of code that executes after this is written and before the actual jump to the MLE. Are you are confident that your code never executes (hence Shane's suggestion of making sure that you set the entry point correctly)? Can you post the serial log of your code's execution on the 4GB config? Also, is this a 2 core or 4 core CPU? Joe > From: Wang, Shane [mailto:sha...@in...] > Sent: Thursday, September 24, 2009 1:51 AM > To: Jonathan M. McCune > Cc: tbo...@li... > Subject: Re: [tboot-devel] SINIT Exit Point > > OK. > > So, it should not be the problem of entry point. Originally what I mean is the entry point in > tboot header structure. (see init_txt_heap()) > CONFIG_HIGHMEM4G should be kernel config. When you get "reset" in GETSEC[SENTER], kernel is > not running. So, I don't think the problem is related to any of kernel configs. > > Can you check your PMR setting for 4G? vtd_pmr_lo_base/size and vtd_pmr_hi_base/size. > > This is what I can think related to memory. > > PS: is it convenient for you to send me your serial log of your code? > > Shane > > Jonathan M. McCune wrote: > > Hi Shane, cc list, > > > > Jonathan M. McCune wrote: > >>>> I'm experimenting with SENTER on an HP 8530p with the newest BIOS. > >>>> tboot works without issue. However, when I run my own code, the > >>>> laptop reboots upon invoking SENTER, and LT.ERRORCODE is populated > >>>> with 0xc0000001, or "SINIT Exit Point". I'm at a loss for what I > >>>> am doing wrong based solely on that error message. > > > > This laptop contained 4GB of physical memory in two 2GB DIMMs. I > > removed one of them, leaving the system with only 2GB of physical > > memory. This enables my code to execute successfully. > > > > I realized this when I noticed that despite having CONFIG_HIGHMEM4G=y > > in the kernel config, the system only sees 3GB of memory. I then > > took a closer look at the value read from TXTCR_SINIT_BASE. The > > value is 0x7be00000 with 2GB of RAM in the system, but it changes to > > 0xbfe00000 with 4GB in the system. However, 0xbfe00000 is much closer > > to 3GB than 4GB. > > > > tboot will execute successfully with either amount of memory in the > > system, and also sees 0xbfe00000 in TXTCR_SINIT_BASE with 4GB of RAM > > in the system. > > > > Thus, I'm still not exactly sure what causes my code to fail. > > > > However, I discovered that the chipset in this laptop has an issue > > with making all 4GB of RAM available despite CONFIG_HIGHMEM4G=y, and > > instead requires PAE support to see more than 3GB of RAM (I did > > verify that with CONFIG_HIGHMEM64G=y all 4GB are visible to Linux). > > Here's a thread that discusses this unexpected need for PAE: > > > > http://lkml.indiana.edu/hypermail/linux/kernel/0607.3/1787.html > > > > I'm not sure if these issues are related yet. Suggestions / comments > > / questions welcomed by all. > > > > Thanks, > > -Jon > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9-12, 2009. Register now! > http://p.sf.net/sfu/devconf > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel |
|
From: Martin P. <Mar...@ia...> - 2009-11-23 10:32:25
Attachments:
smime.p7s
|
Hi.... another BIOS update, another try.... Intel DQ45CB, bios rev 103(20091104) TBoot e57acd4d1460 Good news: board does not turn into a brick Bad news: executing TBoot, it still gets stuck at TBOOT: executing GETSEC[SENTER]... ...so, will TXT work sometime on Intel's own mainboard? :-/ Martin |
|
From: Martin P. <Mar...@ia...> - 2010-04-19 11:17:03
|
Cihula, Joseph wrote: > The work around is to disable legacy USB support. Meanwhile, I will > be fixing tboot to not DMA protect these regions when it finds such a > case (the current code will not DMA protect reserved regions as long as > there is no RAM after them). This is a non-trivial fix, so it may > take a little while. Any news on this? Thanks, Martin |
|
From: Martin P. <Mar...@ia...> - 2010-05-20 14:52:16
Attachments:
smime.p7s
|
Cihula, Joseph wrote: > It took a while, but c/s 203 fixes this issue. ...verified fixed with BIOS rev. 121 and TBoot 816ca Thank you! Martin |
|
From: Corrion, B. W <bra...@in...> - 2010-05-20 21:37:25
|
I too was able to verify the fix on my DQ45CB board. Thanks! Brad Brad Corrion Platform Architect Embedded & Communications Group 480-552-3366 -----Original Message----- From: Martin Pirker [mailto:Mar...@ia...] Sent: Thursday, May 20, 2010 7:52 AM To: Cihula, Joseph Cc: tbo...@li... Subject: Re: [tboot-devel] TBoot+Intel DQ45CB, update Cihula, Joseph wrote: > It took a while, but c/s 203 fixes this issue. ...verified fixed with BIOS rev. 121 and TBoot 816ca Thank you! Martin |