[coreboot] ROMFS

[Peter Stuge]

Jordan Crouse wrote:
> This presents what I call ROMFS

It absolutely must get a different name. Several file systems exist
in Linux already with names that are similar enough to cause a lot of
unneccessary confusion.


> - the next generation LAR for next generation Coreboot.

I've digested it over the last days, and I'm sorry to say that I
don't have a strong feeling either way. :\

Could you also talk about the LAR issues that these changes solve?


> The master header provides all the information LAR needs

What information does LAR need and why? What does LAR mean here? Is
it the producing utility or the consuming code in coreboot or .. ?


> plus the magic number information flashrom needs.

I don't think flashrom needs any information. I really want to change
flashrom to disregard content completely.


> Each "file" (or component, as I style them) now has a type
> associated with it.

The lasting impression from your proposal is that it defines more
clear layering of the .rom file, and that seems like a good idea to
me.


> The header on each "file" (or component, as I like to style them)
> has been simplified - We now only store the length, the type, the
> checksum, and the offset to the data.

What was (re)moved?


> The components are arranged in the ROM aligned along the specified
> alignment from the master header - this is to facilitate partial
> re-write.

Alignment needs some temporal consideration. It is only relevant when
the file has been written to a flash chip. So it would be the job of
flashrom to fix up the alignment if it's wrong for the flash chip
being written. This is not to say that the producing tool should
leave it unset, quite the opposite, it would be nice to have sector
size expertise both in the .rom producing tool and in flashrom.


> I hope that somebody will embrace this code and take it the rest of
> the way, otherwise it will die a pretty short death.

Well embrace.. I don't know. I do like the suggested changes that I
understand and the others are probably good too, but I would like us
to keep the lar product and name. romtool seems to do much of what
lar does, just slightly differently. I would like a patch better.

A nice bonus would be if the tremendous usability bug of not being
able to replace a file/component in a larball/.rom was addressed. :)


> I realize that this will start an awesome flamewar,

Hopefully not so bad. I am generally positive but request some more
input. I hope you'll find a chance to comment even though holidays
are looming.


> Thanks for listening to me over the years

Thanks for helping! I have always appreciated discussing with you,
even when it got heated.


> When you all make a million dollars, send me a few bucks, will you?

If that happens, you have my word. :)


Jordan Crouse wrote:
> This is the userland component for creating ROMs:
..
> add [FILE] [NAME] [TYPE]	Add a component
> add-payload [FILE] [NAME] [OPTIONS]	Add a payload to the ROM
> add-stage [FILE] [NAME] [OPTIONS]	Add a stage to the ROM

Where are they added? Can I control the location? Do I need to?


ron minnich wrote:
> I realize we're on a deadline here.

I could not disagree any more. I don't think deadlines of individual
developers should be of any consequence whatsoever to the project as
a whole.


//Peter