>From Googling, it seems BAR is a general PCI concept. The VT-d spec mentions it in "8.3.6 Implications with Provisioning PCI BAR Resources" (just next to the DRHD section) but doesn't give an obvious clue to this error message (seems to be more of a recommendation).
Could it be that the register base/range in the table is somehow in conflict with what SINIT can see by other means of PCI enumeration? Maybe the table is now incomplete (since the error occurred after an apparent simplification in the table, and with an error code that seems to relate to an earlier check than before?). Perhaps you could send a dump from lspci - it would be interesting to cross-reference it with the values in the DMAR. Best regards, Martin Thiim On Fri, Jul 31, 2009 at 7:31 PM, Hal Finney<hal.fin...@gmail.com> wrote: > I did another experiment, disabling USB and also audio in BIOS, and > trying tboot. It hung again in GETSEC[SENTER] as before. Upon > restarting it, it dumped the error code register, which was different > this time: Progress 0ah, error 6. That is: > > "BARs in VT-d DMAR DRHD struct mismatch" > > I am attaching the log of the two boot attempts (the first which hangs > in SENTER, followed by the reboot which displays the error code). Here > is the output of Ross's dmardump program in this state with USB > disabled: > > DMAR dump utility - reading memory > DMA Remapping Reporting Structure > ================================================== > Signature: DMAR > Length: 0x000000a0 > Revision: 0x01 > Checksum: 0xb0 > OEMID: COMPAQ > OEM Table ID: BEARLAKE > OEM Revision: 0x00000001 > Creator ID: > Creator Revision: 0x00000000 > HAW: 0x23 > Flags: 0x00 > Reserved[10]: 00 00 00 00 00 00 00 00 00 00 > > Remapping Structures... > > DMA Remapping Hardware Unit Definition (DRHD) Structure #1 > Type: 0x0000 (ACPI_DMAR_DRHD) > Length: 0x0018 > Flags: 0x00 -- INCLUDE_ALL = no > Reserved: 0x00 > Segment Number: 0x0000 > Register Base: 0xfed91000 > Device Scope Structure #1 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x02 Function: 0x00 > > DMA Remapping Hardware Unit Definition (DRHD) Structure #2 > Type: 0x0000 (ACPI_DMAR_DRHD) > Length: 0x0028 > Flags: 0x00 -- INCLUDE_ALL = no > Reserved: 0x00 > Segment Number: 0x0000 > Register Base: 0xfed92000 > Device Scope Structure #1 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x03 Function: 0x00 > Device Scope Structure #2 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x03 Function: 0x02 > Device Scope Structure #3 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x03 Function: 0x03 > > DMA Remapping Hardware Unit Definition (DRHD) Structure #3 > Type: 0x0000 (ACPI_DMAR_DRHD) > Length: 0x0010 > Flags: 0x01 -- INCLUDE_ALL = yes > Reserved: 0x00 > Segment Number: 0x0000 > Register Base: 0xfed93000 > > Reserved Memory Region Reporting (RMRR) Structure #1 > Type: 0x0001 (ACPI_DMAR_RMRR) > Length: 0x0020 > Reserved: 0x0000 > Segment Number: 0x0000 > Base Address: 0x3e600000 > End Address: 0x3effffff > Device Scope Structure #1 > ========================== > Type: 0x01 (ACPI_DEV_ENDPOINT) > Length: 0x08 > Reserved: 00 00 > Enumeration ID: 0x00 - Reserved > Start Bus Num: 0x00 > Path Depth = 1, Path Entries: > -- Device: 0x02 Function: 0x00 > > ================================================== > End DMAR > > > A couple of differences: there is one fewer DRHD structure, 3 instead > of 4, and there is only one RMRR structure instead of several. This > one also avoids the potential problem Martin pointed out, that the > device scopes under the RMRR's don't explicitly match any of the ones > under the DRHD's. In this one, the only RMRR is device 2, function 0, > which is covered explicitly under the first DRHD. I do agree with Ross > that the full DMAR struct I posted earlier is kosher because of the > INCLUDE_ALL DRHD which should cover all devices in PCI segment 0000, > but just because we read the spec this way, that doesn't mean the > SINIT author read it that way. > > (The frustrating thing is, SINIT doesn't actually seem to do anything > with this DMAR data. It just copies it to the SinitMleData struct, for > use by the MLE. SINIT wants to put the data into the TXT heap so it is > protected. It is apparently just doing some sanity checks on the data > structures before doing the copy, and obviously the SINIT author and > the HP BIOS author were not on the same page. This happens a lot in > implementing specs. But for me it means that we have two opaque pieces > of code which are incompatible, and both only get updated a couple of > times a year at best.) > > Anyway, back to the SINIT error, "BARs in Vt-d DMAR DRHD struct > mismatch". It's like a Zen koan, what is the sound of one hand > clapping. You have to try to puzzle out what on earth this could mean. > First, what's a BAR? The closest thing I can see in the table is > Register Base Address, which maybe could be called Base Address > Register or BAR. Then, we have a complaint about a mismatch. Mismatch? > What is it supposed to match against? It's just an address. > > The base addresses in the 3 DRHD structs are 0xfed91000, 0xfed92000, > and 0xfed93000. Is that a problem? They seem reasonable enough to me. > I can't figure out what it means to complain about a mismatch. > > This error code, 6, is less than the earlier error code with USB > enabled, 8. I'm guessing that SINIT applies all these sanity checks to > the DMAR data in order, and errors out when it doesn't like one. This > suggests that it is not getting as far as it got earlier, so I don't > know whether it still would have hit error code 8 or not (which was > device scope invalid). > > The one other unusual aspect of my machine is that it has only 1 gig > of memory. I was cheap when I ordered it, and it's run fine for what > I've used it for. Conceivably the SINIT authors may have accidentally > assumed a larger memory configuration would have been in use, in > sanity checking some addresses. I suppose I could add a second gig and > see if that makes a difference, but it seems like a long shot. > > At this point I will wait and hope to hear something from the SINIT > group, if they have any ideas. I would of course be happy to run an > experimental SINIT with additional debugging outputs or error codes if > that would help. I'll also try reverting the BIOS version and see if > that makes a difference. > > Thanks for all your help - > > 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
