[coreboot] [PATCH] Table code cleanup
Patrick Georgi
patrick at georgi-clan.de
Thu May 14 17:15:15 CEST 2009
Am 14.05.2009 16:04, schrieb Myles Watson:
>> + smp_write_floating_table_physaddr(low_table_end, mpc_start);
>> crashes some linux versions that expect the MP table to directly follow
>> the floating table, I think.
>
> ? I must have misunderstood. How can we put MP table in the high tables
> area if the floating table has to be in low memory to be found, if they have
> to be adjacent?
The high table versions are (mostly) used to allow SeaBIOS to copy them
down. SeaBIOS copies the entire MP table into low memory precisely
because certain linux version can't cope with a different layout.
The best outcome in my opinion is to default to
HAVE_LOW_TABLES == HAVE_HIGH_TABLES == 1. Maybe even drop the config
flags and #ifs, unless there's a good reason to keep them
However I think we're not there yet.
>> Also your change seems to create _only_ a high ACPI table if
>> HAVE_HIGH_TABLES is activated, which is less than optimal because ACPI
>> tables there aren't found automatically but require the payload to
>> create a low mem RSDP - which the code that you removed already does.
>
> Yes. I think it should go into the ACPI code. I'll add it if you'll test.
I don't have a clear idea on how to approach this right now. I'll
happily test a patch.
If you boot Linux on a board with ACPI, it's easy to see for yourself.
Early in the boot process (line 12 or so of the boot log), Linux figures
out the ACPI tables (some example I copied from the 'net):
<6>ACPI: RSDP (v000 GBT ) @0x000f6a00
<6>ACPI: RSDT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x00000000) @0x13ff3000
<6>ACPI: FADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x00000000) @0x13ff3040
<6>ACPI: DSDT (v001 GBT AWRDACPI 0x00001000 MSFT 0x0100000c) @0x00000000
As you can see here, RSDP is in low mem (@0x000f6a00), while the other
stuff is somewhere else (@0x13ff3000) (no idea what's up with the DST here)
> I wasn't unhappy with the behavior, just the maintainability. I think the
> code flow was too complex.
I'm not too happy with it either, and improvements are welcome - as long
as they're not regressions, which is why I chimed in.
Patrick
More information about the coreboot
mailing list