[coreboot] [PATCH] Table code cleanup
mylesgw at gmail.com
Thu May 14 18:46:58 CEST 2009
On Thu, May 14, 2009 at 9:33 AM, Myles Watson <mylesgw at gmail.com> wrote:
>> -----Original Message-----
>> From: Patrick Georgi [mailto:patrick at georgi-clan.de]
>> Sent: Thursday, May 14, 2009 9:15 AM
>> To: Myles Watson
>> Cc: 'coreboot'
>> Subject: Re: [coreboot] [PATCH] Table code cleanup
>> 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
>> > area if the floating table has to be in low memory to be found, if they
>> > 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.
> Sorry to be dense. Could we do this in terms of which tables we want in
> each place?
> Page0 (low_table_start):
> COREBOOT TABLE
> 0xf0000 (rom_table):
> MPTABLE (with floating table)
> ACPI bulk
> 0x7fff0000 (high_tables):
> ACPI bulk
That was less than clear :)
A problem that I see with the code right now is that it depends on the
implementation of acpi_write_tables, which is per-mainboard right now.
If someone decides to align their rsdp at 64 bytes instead of 16, it
You also end up with two rsdp structures, one in 0xf0000 and one in
high_tables. Is that really what we want?
More information about the coreboot