[coreboot] [RFC] SMM handling and resident coreboot
Marc.Jones at amd.com
Mon Jul 28 21:22:17 CEST 2008
Stefan Reinauer wrote:
> 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.
Senior Firmware Engineer
(970) 226-9684 Office
mailto:Marc.Jones at amd.com
More information about the coreboot