Re: [coreboot] Rettungsboot

[Nico Huber]

On 28.11.2016 22:38, ron minnich wrote:
> I'm also ok with text protobufs. My only request is that we do not use
> binary blobs or XML.

Interesting, I think almost everyone would agree to never use XML for
anything ;)

I've been looking at protobufs, the text-representation looks nice. I
like it more than JSON. But I totally agree with Peter, don't hurry!
Before we decide about our favorite data format, we should define what
we're going to store in it.

At the moment, I don't see a reason for a most human readable format,
like syslinux or legacy GRUB did it. If we can write a parser for it
in 30~50 loc, I'd prefer that over any more standardized format.

Anyway, back to what to store: With multiboot in mind, there is

o the path to the binary,
  o optional list of arguments to the binary,
  o optional list of paths to modules

1st, is this everything we _need_? are there other standards to load a
kernel that don't fit in this (and we'd want to support).

2nd, is this everything we _want_? how about multiple options to choose
from?
> 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.

The idea is to specify something that can be adopted by any bootloader.
> 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.*"
> ]
> }
> }

Well, actually this shouts at me: It didn't boot because I missed a clo-
sing bracket? WTF! no, this is not human readable.

Nico
> On Mon, Nov 28, 2016 at 1:15 PM David Hendricks via coreboot <
> [e-mail]> wrote:
> > On Mon, Nov 28, 2016 at 12:40 PM, Peter Stuge  wrote:
> >
> > David Hendricks via coreboot wrote:
> > > On Sun, Nov 27, 2016 at 8:28 PM, ron minnich  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).