I continue to believe that this is not a good idea and would add a lot of complication (and another competing system for something we already have many solutions for) without sufficient benefit to justify it. Manipulating variables in a bootblock image would add yet more complexity to the already stretched cbfstool, require more magic numbers (a CBFS attribute is not a solution because not all bootblocks are CBFS files), may cause issues with verification or compression, etc.

If we want easier control of serial loglevel, the obvious solution is to integrate into any of the existing configuration mechanisms that have already been mentioned rather than invent a new one. I mean we already have that implemented today through the option backend (CMOS), after all. We also already had a proposal to implement this as a CBFS file two years ago (https://review.coreboot.org/54385) which we seemed to have general consensus on and started implementing, they were just never finished because Patrick moved on to work on other things (https://review.coreboot.org/56210, https://review.coreboot.org/45208, https://review.coreboot.org/55397). We could also tie into the FW_CONFIG system that was added since then, if we do that we basically get both CBFS file support and ChromeOS CBI support automatically while tying into an existing, widely-used system. Really, anything would be so much better than inventing something completely new and yet again different, which doesn't come with a convenient solution to have the information available in later stages and requires cbfstool to make yet more complicated bootblock surgery.

The only real reason you have to reject all of those other options is so that this can capture the serial output from the very first few bootblock lines, but where is the pressing use case for that which justifies ignoring all these other concerns? Does anyone really ever have a situation where they're running an image they didn't build themselves (so they can't quickly change the Kconfig and rebuild), but suddenly something in the very early bootblock starts to break and they need to be able to debug it without recompiling? The bootblock has the least interaction with any outside components that could induce a sudden change in behavior or a rare flake, and thus is the most stable piece of coreboot. You usually debug bootblock issues early on when working with a new SoC, at a point where you have the console enabled through Kconfig anyway. And then once you get it working it tends to stay working. We're just talking about a tiny piece of coreboot with hardly any dependencies here which only tends to break on the developer's desk right after they wrote some new code, not randomly on someone else's machine (like e.g. memory training or PCI init or all the more complicated pieces that could be served perfectly fine by a CBFS file based solution). In fact, on x86 devices CBFS is basically available right away so this only really makes a difference on non-x86 devices to begin with, and on those we're taking about half of a small stage.