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.
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?
Dec 19, 2023 at 10:15 by james@nurealm.net:
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.
On 19.12.23 19:11, Martin Roth via coreboot wrote:
Worth to mention that the flash console driver never erases. When it's full, it's full, the user needs to erase it manually.
Nico
Geminilake devices use the FSP PEI GOP driver for display init, so the display backlight will come on during ramstage (when FSP-S runs), but the platform does not currently support any output / proof of life prior to the payload, other than maybe an early boot splash screen (you'd have to look if GLK supports that).
The truth is though, if your device doesn't boot to the OS, you're going to need to debug it, and having an indication that it failed in coreboot vs the payload isn't all that useful when simply connecting the debug cable and flashing a serial output enabled build will tell you the same thing
On Tue, Dec 19, 2023 at 11:15 AM James Feeney james@nurealm.net wrote: