Dec 19, 2023 at 10:15 by james@nurealm.net:
On 12/18/2023 1:00 PM MST Matt DeVillier matt.devillier@gmail.com wrote: ...
Thanks for all that, Matt. A little perspective helps me a lot!
I'm wondering, with MrChrombox coreboot will anything normally show on a chromebook screen at ramstage, before payload? Or, if not, can anything be *made* to show on the screen, like status or debug info? I'm thinking, if a payload fails, at least something on the screen from coreboot ramstage would indicate that coreboot executed up through ramstage, without needing to connect a debug cable - and sort of geek eye-candy.
coreboot generally initializes the display in ramstage, if at all. Some chips could be initialized earlier, but this is a chip-by-chip thing, not coreboot-wide.
Most platforms will support a coreboot splash screen - Intel better than others thanks to libgfxinit, so if you just want to verify that coreboot got that far, you can enable that.
coreboot might not even be able to help with what you want, since after we jump to the payload, coreboot's done. It would be up to the payload to display or log any issues.
Also, it looks like there is a way to save coreboot debug messages to a file. But, does that use CAR, or would messages be repeatedly written to the ROM with every boot? Maybe cache is too small to use for debug messages - geminilake? Or repeatedly writing to ROM reduces its life?
Lots to respond to in this paragraph.
"file" is only true in the Unix sense where everything is a file. coreboot saves the console output to memory and to any other output you have enabled in Kconfig. coreboot doesn't communicate with a file system at all - that's the payload's responsibility. You can enable the option to write the console to the ROM with CONSOLE_SPI_FLASH (and adding a CONSOLE area to FMAP), but this would be more of a debug option than anything else. It's not enabled by default.
The console does get written to cache for early stages on any platform that supports cache-as-ram, but I don't think this helps you. And yes, when writing the console to ROM it would get written out on every boot, otherwise it wouldn't be super useful. Additionally, as I mentioned, having coreboot write the console log to ROM generally wouldn't help if there's a problem in the payload.
The ROM does have a limited write capacity, but it's typically 100K erase/write cycles at this point, which should be enough for anyone. Erase cycles take a long time though, and writing to ROM is slower than to RAM.
Would a live Q/A session help? I'd be happy to host something.