[coreboot] [RFC] SMM handling and resident coreboot

[Marc Jones]

Stefan Reinauer wrote:
> Hi,
...
> 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.

I think you need to consider keeping the runtime smm code 
self-contained. Executing code from SMM that is outside the SMM 
protected memory region could be risky. prink is a conveniet way to 
debug SMM but it shouldn't be used runtime in a normal system since 
Linux could be using the serial port. PCI read/write functions are not 
so duplication shouldn't be too bad. The device tree might be 
interesting but I don't know that SMM really needs it.


> In the case of the SMM handler, this would also confine us, because the
> actual SMI# handling code (written in C) would not be shared between
> CPUs but has to be duplicated for every CPU core. However, my current
> approach only keeps a very small amount of code per CPU, that is just
> enough to enter gcc compiled functions and return from them, cleanly.
> 

I didn't really understand this comment. You are saying that there would 
be generic routines for entering SMM, PCIr/w etc and that there is a 
small section of processor specific code? I think that the processors 
and platform specific stuff will be the majority of the code not the 
other way around. It would be similar to coreboot in that way.


> One of the questions in my mind is: where should we put the coreboot
> image, if we want to keep it around?
...

> Since we know how big our RAM is when we copy coreboot to RAM, I suggest
> that we copy coreboot to the end of memory and run it from there. It is
> a pretty good assumption that no payload will require that space. During
> memory map creation, we just reserve 256k at the upper end, and we're good.

The end of memory is an ok place but you could also consider the legacy 
locations at 0xE0000-0xFFFFF since Linux and other OS tend to avoid that 
area and look for ACPI and other table (or pointers to table) there.

Marc



-- 
Marc Jones
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
http://www.amd.com/embeddedprocessors