nico.h at gmx.de
Tue Nov 29 00:27:18 CET 2016
On 28.11.2016 20:26, David Hendricks via coreboot wrote:
> On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <rminnich at gmail.com> wrote:
>> yeah, david and nico both make very good points. I like the idea of JSON
>> file, and further we're working on a Go program
>> on the u-root project that would parse said file (trivial in Go to parse
>> JSON, it's one statement and blam! your Go struct is all
>> filled in) and then decide what to configure/what to download/how to
>> validate (we have a gpgv command written in Go by
>> Eric Grosse) and then how to kexec it.
>> I think what we're doing might be useful?
> Now we're talkin' - A standardized data format that is human
> readable/writeable that can be easily parsed and generated using small
> libraries. It looks like Go can already handle it easily, for C we could
> maybe use JSMN (http://zserge.com/jsmn.html) or something similar. I think
> that addresses Nico's first point.
> For the other points, I imagine we'd have two varieties of the JSON file.
> One would be generated along with the payload and included as a CBFS file
> to specify things like capabilities and bootable device priority*. The
> other would be on the bootable media and specify things like the kernel
> path and parameters. A tool which is used to generate the latter would
> verify the capabilities and warn the user if their coreboot payload lacks
> support for something.
A tool like that might have to see the whole bootable medium. You can't
tell from the configuration file in which type of filesystem it's stored
for example. But I really like the idea. Such a tool could tell if a
boot medium only needs capabilities that are mandatory in the spec,
thus, should always boot ;)
> *Stuff like boot device priority might need some more thought since CMOS
> may be a preferable way of controlling something like that. However given
> that CMOS might not exist on a particular platform (especially in the
> non-x86 world) replacing the config file in CBFS file might not be a bad
> way to go.
I'd like to keep that out of scope (for the moment). Let's just start
with what happens when the bootloader has found the configuration.
More information about the coreboot