[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