Well, I tried lots of BIOS versions. v1.24 gives me a Microcode Error 1801 (unrelated to TXT) and runs the fans at full speed, so I didn't get very far with it. v1.26 hangs with the BIOS screen displayed after rebooting immediately upon executing SENTER (again sounds consistent with what Hal was reporting with his 'older' BIOS -- I'm guessing that was v1.26). v1.28's behavior is indistinguishable from that of v1.27's, which was the version that has been on my machine for months or possibly years.
I tried disabling basically everything non-essential in BIOS (left enabled a single serial port, single SATA port, Ethernet, and video; disabled USB, firewire, parallel port, floppy, CD-ROM, audio, ...). No change. Just toggles between the two TXT.ERRORCODES (0xC00020A1 or 0xC00018A1). This really has me confused. I've successfully used this machine for tboot/Flicker countless times in the past, and I really have no idea what would have changed that suddenly caused it to behave the way Hal previously described things. Could adding or removing PCI cards make a difference? It may have previously had two NICs, and now only has one (can't remember for sure). It has 4GB of RAM, which I believe it has always had. I can always try removing some... Any ideas? Thanks, -Jon On Thu, Jul 22, 2010 at 5:02 PM, Jonathan McCune <jonmcc...@cmu.edu> wrote: > Hi Hal, Martin, list, > > Any progress on this front? I've just run into this same issue (error > codes 0xC00020A1 or 0xC00018A1 depending on whether USB/floppy/1394 > are enabled -- suspect USB is what's meaningful but haven't dissected > it) on a dc7800 with tboot-20100427 (w/ Q35 SINIT modules v18, 17,and > 16) and tboot-20090330 (w/ Q35 SINIT module v16). I hope to continue > experimenting with interesting combinations, but when I last used this > machine, I don't recall ever having this problem. > > My system has BIOS version 1.27 installed. I can see that there's a > 1.28 available from HP's web page. Hal, you said that reverting BIOS > versions helped you out. Do you happen to know which version you > used? If it's younger than 1.27, do you happen to have the installer > for it? > > I'll post a follow-up if I figure out anything interesting. > > Thanks, > -Jon > > > On Sat, Aug 1, 2009 at 6:54 AM, Martin Thiim <mar...@thiim.net> wrote: >> Hi >> >> Great. However, I'm still curious about what caused it to fail. I hope >> in the future more info will be released on what SINIT actually does. >> >> As my last posts indicated, it probably isn't/wasn't an inconsistency >> in the tables themselves, but rather an inconsistency with the tables >> and something outside the tables, such as either the PCI device BAR >> registers, or perhaps the register base of the DMA units that are off >> (i.e. maybe these registers don't actually point to a DMA unit). >> >> Best regards, >> >> Martin Thiim >> >> On Sat, Aug 1, 2009 at 8:40 AM, Hal Finney<hal.fin...@gmail.com> wrote: >>> As an update, I successfully rolled back my BIOS to an earlier >>> version. With this change, tboot works again! GETSEC[SENTER] executes >>> with no errors and I get into the secure state. So it is definitely >>> some problem relating to the new BIOS. >>> >>> Interestingly, I dumped the DMAR tables created by the working BIOS >>> and they are byte for byte identical to what they were with the >>> non-working BIOS. So clearly there is no point in going over those >>> tables with a fine tooth comb to figure out what SINIT doesn't like >>> about them. Something else must be different. I'd say the SINIT error >>> codes are not particularly informative about what is going wrong in >>> this case. >>> >>> I hope the SINIT team will still look into this. I can easily go back >>> to the newer BIOS in order to reproduce the failing state. The new >>> BIOS has the advantage that I can reboot after an SINIT failure and >>> read the errorcode register. With the old BIOS, attempts to reboot >>> hang in the BIOS and it's not possible to read the errorcodes, which >>> made debugging TXT almost impossible. >>> >>> So I can either use the new BIOS which would allow some debugging but >>> which unfortunately doesn't work with SINIT; or I can use the old BIOS >>> which works with SINIT but reveals nothing when there is a failure. >>> Neither is a great alternative. >>> >>> Hal Finney >>> >> >> ------------------------------------------------------------------------------ >> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day >> trial. Simplify your report design, integration and deployment - and focus on >> what you do best, core application coding. Discover what's new with >> Crystal Reports now. http://p.sf.net/sfu/bobj-july >> _______________________________________________ >> tboot-devel mailing list >> tboot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/tboot-devel >> >> > ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ tboot-devel mailing list tboot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tboot-devel
