[coreboot] [RFC] SMM handling and resident coreboot

[Carl-Daniel Hailfinger]

On 27.07.2008 16:36, Stefan Reinauer wrote:
> I have been working on an SMM handler for coreboot in the last week, so
> we can support laptops and mainboards with power management features
> that are hard or impossible to support in the near future.
>   

Great!

> The SMM handler I wrote switches to 32bit protected mode and all SMI#
> handling is written in C code, compiled with normal gcc without the
> gcc16 hack or similar nasty things. Thus it is just another exception
> handler, like the ones we have in coreboot already.
>   

I like that approach.

> One difference is that the SMM handler stays operational once the OS is
> loaded. The SMM stub living at 0xa8000 currently jumps to the C handler
> in normal coreboot code in ram, which starts at _RAMBASE. So in order to
> be able to use the SMM handler, that memory (code, data, bss, and heap;
> not the stack) needs to stay in place and untouched for the current
> scenario to work.
>
> Now, memory consumption of the ram part of coreboot is quite tough:
>
> On an example mainboard, I get these values:
>
> code: 102464
> data: 53088
> bss: 10248
> stack: 32768
> heap: 32768
> ------------------
> total: 231336
>
> Usually code starts at 0x4000 (_RAMBASE) and, in the above example,
> reaches up to 0x3e000, occupying almost 4 64k "segments" (0x3a000/237568
> bytes)
>
> My first thought was: we could add that memory as reserved in the
> coreboot table / e820. coreboot keeps a lot of information in memory
> already, and expects the OS / payload to take care it is not overwritten:
>
> - mptable
> - pirq
> - dsdt, and the other ACPI tables
> - DMI (required for ACPI on 32bit systems with newer Linux kernels)
> - i remember some ebda issues in the last few days on this list, too
> - last but not least of course the coreboot table.
>
> So far, coreboot has been "tricking around" to put these in places that
> don't hurt and where the OS is going to find them. This worked in a
> rough-and-ready manner but will fail us in the future, at least make us
> stay quick'n'dirty fixing after every occurence of a problem.
>
> But to conclude, keeping (parts of) coreboot resident in memory is
> nothing that SMM would introduce. We have been doing this for many years.
>
> Another alternative to keeping full coreboot around, would be to make
> the SMM handler self contained. This would mean, the SMM handler could
> not use coreboot's functions like printk_debug, pci_read_config32, it
> could not use the device tree, and it would become more complex, because
> for some information we have to reprobe the hardware, or parse the
> coreboot table.
>