Question about rsdp test?

[Dong, Eric]

> A warning can work for me, although a medium failure has suggested
> this is not a must-fix for most of recent systems.
> 
> However, I still want to know why this needs to be changed and whether
> there are real world examples.
> 
> Eric,
> 
> On the system you have failed this test, can you provide the
> information as below:
> 
> 1. whether the data pointed by RSDT and XSDT are different

Yes. 

> 2. whether XSDT is not addressable by 4 bytes

Yes. UEFI bios image need to support different OS (different OS may support different ACPI versions) with same image, so it report RSDT and XSDT at the same time. And the table nest in the RSDT and XSDT (nest in the Entry section) are same. Although the XSDT is 8 byte for each entry, in order to share same table in XSDT and RSDT, the address for these tables is addressable by 4 bytes.

> 
> I think fwts-live also dumps acpi tables. You can use acpidump on
> Linux or use r/w everything on Windows for extract related field.
> 
> On Fri, Jul 22, 2016 at 1:15 AM, Al Stone <al.stone at linaro.org> wrote:
> > On 07/21/2016 07:25 AM, Colin Ian King wrote:
> >> On 21/07/16 02:34, Dong, Eric wrote:
> >>>> On 07/20/2016 01:02 AM, Dong, Eric wrote:
> >>>>> Hi Alex,
> >>>>>
> >>>>> We are using the UEFI code. In UEFI code, it uses both Rsdt and Xsdt. I check the ACPI spec and found below info: (Excerpt from
> ACPI
> >>>> spec 6.0 page 113)
> >>>>>    Platforms provide the RSDT to enable compatibility with ACPI 1.0 operating systems. The XSDT, described in the next section,
> >>>> supersedes RSDT functionality.
> >>>>>
> >>>>> So base on this, I think UEFI code is ok and Fwts should not do such check.
> >>>>
> >>>> Right.  That is what the spec says.  I think Alex's question was different,
> >>>> though, and something the spec does not address.
> >>>>
> >>>
> >>> I think if the spec not has clear description, the Fwts tool should not add such check base on some of the current implementation.
> >
> > We'll have to disagree, then.  I see FWTS as a tool to help me make sure that
> > my firmware and my OS can work together properly.  If that means that we have
> > to adapt to what actually gets shipped, or de facto standards that are not
> > part of the spec, that's just reality.
> >
> >>>> The test being referred to below is saying that the RSDT and XSDT addresses
> >>>> are different.  It is okay to use both addresses.  But, if they are different,
> >>>> which one is the correct one for the OS?  There is no way to know, and the
> >>>> spec does not tell us, so this is an error.
> >>>>
> >>>
> >>> I think it depend on what ACPI version this OS support. If the OS supports ACPI 1.0 version, it can use the RSDT, else it use XSDT.
> >>>
> >>> For the UEFI code, I think it just wants to support different OS with same image. So it use RSDT and XSDT both with different value.  If
> the OS supports ACPI 1.0, it can use RSDT, else it can use XSDT. I think the UEFI solution is correct and make sense.
> >
> > Again, the test is not saying you cannot use RSDT.  The test is saying you
> > can use RSDT, or you can use XSDT, or you can use both, but I expect the
> > addresses to be consistent.  If they are not, this often presents a really
> > big problem for the OS.
> >
> > The firmware that I have seen that works properly has a 32-bit address in
> > RSDT and the same address in XSDT, even though it is 64-bit.  When the OS
> > sees this, it can use either pointer since they both point to exactly the
> > same ACPI table data.
> >
> > The firmware that I have seen that is broken is when RSDT != XSDT.  In those
> > cases, the 32-bit ACPI tables had different content from the 64-bit tables,
> > and in one case, the 32-bit data had never been tested.  What's more, the
> > tables were written saying they only needed ACPI 1.0, which was a slightly
> > different mistake since parts of the DSDT used ACPI 5.0 features.  So, this
> > test was written so the OS would not have to workaround buggy firmware that
> > is known to exist -- which is what I thought was the point of using FWTS.
> >
> > I still have to disagree; I believe the UEFI implementation is not quite right
> > and creating tables that can or will cause trouble with an OS later on.
> >
> >> Given the case we have some ambiguity here, I think the way forward is
> >> to remove the failure mode from the test and replace it with some
> >> warning and NOT report an error, e.g. something like:
> >>
> >> fwts_log_warning(fw, "Note: The RSDT and XSDT are both defined. An "
> >>       "OS supporting ACPI 1.0 should use the RSDT, otherwise the "
> >>       "OS will use the XSDT. RSDT = 0x%" PRIu32 "x, "
> >>       "XSDT = 0x%" PRIu64,
> >>       rsdp->rsdt_address, rsdp->xsdt_address);
> >>
> >> If that sounds sane I'll send a patch.
> >>
> >> Colin
> >>
> >
> > WFM.  I disagree that it's ambiguous :), but I can live with it if
> > there's at least this warning.  Thanks, Colin.
> >
> > --
> > ciao,
> > al
> > -----------------------------------
> > Al Stone
> > Software Engineer
> > Linaro Enterprise Group
> > al.stone at linaro.org
> > -----------------------------------
> 
> 
> 
> --
> Cheers,
> Alex Hung