[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 <
> 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
> 
> 
>