[coreboot] Rettungsboot

[ron minnich]

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": [
"/$ARCH/include/cflags.json"
],
"Oflags": [
"-static"
],
"Post": [
"rm -f *.o"
],
"Pre": [
"rm -f *.o *.tag.*"
]
}
}

On Mon, Nov 28, 2016 at 1:15 PM David Hendricks via coreboot <
coreboot at coreboot.org> wrote:

> On Mon, Nov 28, 2016 at 12:40 PM, Peter Stuge <peter at stuge.se> wrote:
>
> David Hendricks via coreboot wrote:
> > On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminnich at 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):
> {"employees":[
>     {"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 at coreboot.org
> https://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161128/3cbb4bbb/attachment.html>