Am 21.11.2013 12:50, schrieb Laurent Lesage:
So I understood that, indeed, a very quick boot is possible. That's fine. So, the POST may be done when "cold start" is done. It's only when I want to make a reboot that I need it to be as fast as possible. When you say " shallow warm restart
it speaks well to me, though I've still no idea of how to do it. ... if I google those words "shallow warm restart + coreboot" .... I just find this email thread in first position!!! Can you give more tips on haow to go in this direction?
You can reduce the time for initializing RAM by assuming that the configuration didn't change (typically a given on embedded hardware). This is implemented in coreboot for current AMD and Intel chipsets.
You can also postpone some hardware initialization to a later stage, but that's a bit more involved.
And then there's the option that you essentially keep the system in suspend-to-ram mode, so "power up" equates "wake up" (which is _really_ fast, and you can jump into a prepared OS state, too). I suspect that this is what Zoran is alluding to. It depends on your application if that is an option or not...
All of these options depend on some trusted hardware configuration (part of which is in flash), so that might or might not be acceptable for your use case.
I also saw that it was possible to flash coreboot + payload on the chip
If your software is simple (and in particular: small) enough, it can serve as a payload. We have libpayload (part of the coreboot source tree) to provide common libc functions and a bunch of drivers.
In theory you could run everything from ROM, but coreboot isn't prepared for that (we unpack the later stage to RAM), so you'd need to adapt that for your use case. You'll also have to be careful not to kill performance. Caching the ROM might help - we do that, but probably not good enough for such a scenario
Is UEFI and EDK necessary? I read that UEFI support was not yet complete.
The UEFI payload for coreboot isn't yet complete.
EDK is the tool provided by SAGE, I think : is it GPL too? At this time we do not have budget to hire anyone... MAybe in the future if we can set this experiment which has never been done.
EDK is also the "EFI development kit" - it's unclear what Zoran meant, given that he also brought UEFI into the debate.
About the test board : At this point, my idea is to use coreboot + Qemu to put my hands on coreboot and try to do what I described.
That's a great idea since it teaches you about the coreboot build process and its architecture. However since Qemu takes a couple of shortcuts, it's limited in what hardware behaviour you can model.
I suppose (am I right?) that if it works that way, it would be possible to use what I learned to put it quite easily on a "real" board?
AMD's SimNow provides a more complete emulation, and it models "real" hardware, so the same image (sans workarounds for emulation bugs) can be used on the corresponding hardware. However it's non-free and its learning curve is a bit steep.
Is Intel or AMD more suited to those needs? What do you think?
Intel chipsets come with the management engine, which sometimes interferes in the boot process. AMD has less of that stuff, so I guess you have more control over the platform characteristics.
Patrick