[coreboot] [PATCH] Table code cleanup

Myles Watson mylesgw at gmail.com
Thu May 14 17:33:09 CEST 2009



> -----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
> 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.

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):
PIRQ
MPTABLE (with floating table)
ACPI bulk

0x7fff0000 (high_tables):
PIRQ
MPTABLE
ACPI bulk

We could also do it in terms of the patch I sent:

You could tell me what things I should[n't] have included in write_table,
and what I missed.

> 
> >> 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've only been booting into Linux with SeaBIOS.

> 
> > 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.
And why I specifically asked for your input :)  Thanks for the explanations.
I'll try again.

Thanks,
Myles





More information about the coreboot mailing list