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
