I'm also ok with text protobufs. My only request is that we do not use binary blobs or XML.

Here's one .json from Harvey, defining rules for libraries. It has some arrays, and shows the use of structure. Seems simple enough to me.

My assumption is that this would be parsed by a user level program, not firmware or kernel.

If you're going to pick a format, pick a simple one with lots of parser implementations in lots of languages and which is easy to read (I find this easy to read).

"Libs": {
"Include": [
"Oflags": [
"Post": [
"rm -f *.o"
"Pre": [
"rm -f *.o *.tag.*"

On Mon, Nov 28, 2016 at 1:15 PM David Hendricks via coreboot <coreboot@coreboot.org> wrote:
On Mon, Nov 28, 2016 at 12:40 PM, Peter Stuge <peter@stuge.se> wrote:
David Hendricks via coreboot wrote:
> On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminnich@gmail.com> wrote:
> > I like the idea of JSON file
> Now we're talkin' - A standardized data format that is human
> readable/writeable that can be easily parsed and generated using
> small libraries.

I agree with the concept as described by David, but strongly disagree
with choosing JSON. I think we can and should do better than that.

That was my initial reaction as well. But if you check out some examples it really doesn't seem bad especially if we restrict ourselves to a subset of JSON. Here's a simple example using key:value pairs (from http://www.w3schools.com/js/js_json_intro.asp):
    {"firstName":"John", "lastName":"Doe"},
    {"firstName":"Anna", "lastName":"Smith"},
    {"firstName":"Peter", "lastName":"Jones"}

The page for jsmn notes that it explicitly does not support "advanced" functionality that does not map well to C. I'm not sure exactly what this implies (presumably the above example is OK), but it seems worth investigating if it suits our needs and enables us to use existing standards and libraries.

Ron - If you get a chance, can you post a sample JSON file from u-root?

> given that CMOS might not exist on a particular platform
> (especially in the non-x86 world)

Maybe no NVRAM, but surely there will be persistent storage on board?

Implementation-defined. I'm sure it exists on some designs, but in general non-x86 board vendors don't add additional nonvolatile storage unless they really have a specific purpose for it. Even if they add a serial EEPROM or some such, it's not necessarily trivial to access like CMOS on x86 platforms. IMO the only persistent storage we can depend upon is the persistent storage that coreboot resides on. Everything else is nice to have but should not be a hard requirement.

I suppose this could be another parameter exposed in the config file in CBFS. For example, if a key "nonvolatile-storage" has value "cmos" then the tools know we need to look at cmos.layout and write boot device priority using CMOS-methods. We currently do something similar to this on ChromeOS devices to tell where verified boot data is stored (CMOS, embedded controller, SPI ROM, etc).

David Hendricks (dhendrix)
Systems Software Engineer, Google Inc.
coreboot mailing list: coreboot@coreboot.org