<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 28, 2016 at 12:40 PM, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se" target="_blank">peter@stuge.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-3100000294629224675gmail-">David Hendricks via coreboot wrote:<br>
> On Sun, Nov 27, 2016 at 8:28 PM, ron minnich <<a href="mailto:rminnich@gmail.com" target="_blank">rminnich@gmail.com</a>> wrote:<br>
</span><span class="m_-3100000294629224675gmail-">> > I like the idea of JSON file<br>
><br>
</span><span class="m_-3100000294629224675gmail-">> Now we're talkin' - A standardized data format that is human<br>
> readable/writeable that can be easily parsed and generated using<br>
> small libraries.<br>
<br>
</span>I agree with the concept as described by David, but strongly disagree<br>
with choosing JSON. I think we can and should do better than that.<br></blockquote><div><br></div><div>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 <a href="http://www.w3schools.com/js/js_json_intro.asp" target="_blank">http://www.w3schools.com/js/<wbr>js_json_intro.asp</a>):</div><font face="monospace, monospace">{"employees":[<br>    {"firstName":"John", "lastName":"Doe"},<br>    {"firstName":"Anna", "lastName":"Smith"},<br>    {"firstName":"Peter", "lastName":"Jones"}<br>]}</font><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Ron - If you get a chance, can you post a sample JSON file from u-root?</div><div class="gmail_quote"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-3100000294629224675gmail-">> given that CMOS might not exist on a particular platform<br>
> (especially in the non-x86 world)<br>
<br>
</span>Maybe no NVRAM, but surely there will be persistent storage on board?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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).</div></div><div><br></div>-- <br><div class="m_-3100000294629224675gmail_signature">David Hendricks (dhendrix)<br>Systems Software Engineer, Google Inc.</div>
</div></div>