[Skiboot] [RFC PATCH 00/13] Rework flash TOC generation

[Cyril Bur]

On Mon, 2017-12-04 at 13:53 +1100, Stewart Smith wrote:
> Cyril Bur <cyril.bur at au1.ibm.com> writes:
> > Currently the ability within libffs to prove an api to generate TOCs
> > is a bit experimental/developmental and it needs work. The original
> > version tried to abstract too much which mean needless complexity
> > within the library.
> > 
> > I've ripped quite a lot of the complexity out of the libffs in favour
> > of some added (but overall less) complexity in ffspart.
> > 
> > Unfortunately this does change libffs just a tad, hopefully none of
> > the functions have been used by anyone outside of skiboot, and the
> > input file to ffspart had to change a bit too, but I haven't heard of
> > anyone actually using it.
> > 
> > Feedback very much welcome,
> 
> how close is this to being able to produce a binary identical FFS image
> to the existing tooling?
> 

I'm pretty sure that at time of posting, it was identical to what I
could wget from openpower.xyz as build pnors. In previous iterations of
this patch it was also true, and things magically changed... 

Definitely worth a recheck - perhaps I could add it as part of a test.
Bit of a wget and diff situation, that might be fragile because the XML
would need to be converted

> We have a different CSV format for FFS in phosphor-mboxd too, perhaps
> Adriana can chime in if it's possible/plausible to move to just one
> representation, as this could help simplify our PNOR building process.
> 

Hmm I remember thinking that the phosphor-mbox CSV was pretty close. Of
course its possible that the one here grew a bit in complexity.

> I'd *really* like to rip out openpower-ffs and other related crap from
> the op-build process and just replace it with this, largely because this
> has a remote chance of being maintained and a remote chance of not
> bringing in 13,000 lines of useless junk with it.
> 

Strong ack!

> In theory at least, ffspart ond the openbmc image building utility could
> just take the same input and output a different image.
>