it's quiet on these changes and this list. I am going to try to finish testing myle's stuff this weekend and hope to try your romfs next week. I realize we're on a deadline here. Overall I think we need these changes.
ron
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
-
Jordan Crouse -
Peter Stuge -
ron minnich