This needs to be compile-time decided in coreboot. We've been through this before and wasted a bunch of time on code that needed to be reverted in the end... I can dig up the bug if you want. The gist is that it takes a non-trivial amount of code to get SPI flash working on Arm devices, and we definitely want to have a UART available to be able to get debug output from that code. You have a chicken-and-egg problem if you want to put the flag deciding whether to enable serial output on SPI flash.

For all later pieces (e.g. depthcharge, Arm TF) the decision is already made at runtime by parsing the coreboot tables. Some of the legacy payloads (e.g. SeaBIOS, apparently) may not be using that, but the information is available, the payload just needs to parse it. Of course someone would need to write that code and the maintainers of that payload would need to be convinced to take it.

There is a GBB flag allocated for this, but as Julius notes it ran into some issues and we had to revert..

I've reallocated the flag a while ago, actually, it's used to skip the BROKEN screen now: https://chromium-review.googlesource.com/976660

Oops I remember that now, guess I should have said there _was_ a flag.

OK, so we cannot put it in a separate file in CBFS because ARM systems need to start their SF driver before they can decide if serial is available?

So is it OK to add a GBB flag?

Or do we need to add a simple run-time config option to coreboot so we can build the serial value into it?

GBB is stored in flash too so it has the same issue.

OK, so maybe I need to try to get some run-time config in coreboot. It was rejected some years ago.

> maybe I need to try to get some run-time config in coreboot

Not really sure what you mean by this. I don't think there's a way to solve this the way you want, it's a fundamental problem. Some platforms just don't have any persistent storage other than SPI flash available where you could store something like this. Decisions that need to be made before SPI flash is accessible need to be made at build time, I think there's just no real way around that. (I also don't think it's a big enough problem that it would require bending over backwards to fix tbh.)

The idea is to store the config actually in coreboot - e.g. at minimum a simple binary flag to indicate serial or not. Would that be acceptable?

> The idea is to store the config actually in coreboot - e.g. at minimum a simple binary flag to indicate serial or not. Would that be acceptable?

Sorry, I still don't understand what you're trying to achieve. Storing a flag on flash will not work for the reasons mentioned above. We want to have the console available before the point where we can access the flash. Compiling the decision into the code is really the only way to achieve that.

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.