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:[EMAIL PROTECTED] http://www.amd.com/embeddedprocessors -- coreboot mailing list [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
