This patch adds Jordan's ROMFS utility to v2.
ron
On 31.03.2009 00:52, ron minnich wrote:
This patch adds Jordan's ROMFS utility to v2.
This patch adds Jordan's romtool support for v2. There are a few changes. The 20K bootblock size restriction is gone.
ROMFS has been tested and works on v2 with qemu and kontron. Once this patch is in, those patches will follow.
Signed-off-by: Ronald G. Minnich rminnich@gmail.com
IIRC this was posted in December and did not get any reviews.
I do agree that v2 benefits from a ROM management scheme, considering how many problems people have with payload handling in v2.
This is not even near a complete review, but I wanted to get some comments on the code out there. AFAICS the proposed ROMFS code will break on the Gigabyte GA-M57SLI-S4 v2.x. Since the M57SLI is one of the best supported recent boards out there, I'd like to make supporting or not supporting one of its variants an explicit rather than an implicit choice. Short summary of the issue: ROMs larger than 512 kB or so can only be accessed in 3 byte chunks. That means you have to read every header in chunks. Direct comparisons in memory are not possible. Besides that, I agree with Peter on naming when he wrote:
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.
And finally, I'd like to make sure we don't try to support multiple ROM management schemes. That would be madness. If ROMFS is the future, can we please use it in v3 as well?
The "pointer to romfs_header at the end of the ROM" idea was rejected twice when I tried to get that in in v3. I still believe it is a good idea. struct romfs_header is missing a struct member containing the lowest accessible ROM address so you can switch to accessor functions for lower addresses. This is needed if we ever want to support the M57SLI v2.x with ROMFS. romfs_header.version does not have to be endian-independent. If you can read the magic correctly as a number, you got the endianness right. No point in working around problems which do not exist. "'pad' rounds the header to 32 bits and reserves a little room for later use." Actually, that should read "32 bytes". Can we use some magic other than "ORBC"?
Sorry for not giving a more complete review. I'm working against a deadline for a paper and an unrelated presentation. I'll try to get back to this sometime later.
Regards, Carl-Daniel
On Mon, Mar 30, 2009 at 5:36 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
AFAICS the proposed ROMFS code will break on the Gigabyte GA-M57SLI-S4 v2.x. Since the M57SLI is one of the best supported recent boards out there, I'd like to make supporting or not supporting one of its variants an explicit rather than an implicit choice. Short summary of the issue: ROMs larger than 512 kB or so can only be accessed in 3 byte chunks. That means you have to read every header in chunks. Direct comparisons in memory are not possible.
Actually, the code should work fine with the streams. I will rewrite the coreboot part to use them.
Besides that, I agree with Peter on naming when he wrote:
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.
I welcome another name, but I won't accept a reject unless it comes with another name :-)
And finally, I'd like to make sure we don't try to support multiple ROM management schemes. That would be madness. If ROMFS is the future, can we please use it in v3 as well?
let's get it working first.
The "pointer to romfs_header at the end of the ROM" idea was rejected twice when I tried to get that in in v3. I still believe it is a good idea.
It is.
struct romfs_header is missing a struct member containing the lowest accessible ROM address so you can switch to accessor functions for lower addresses. This is needed if we ever want to support the M57SLI v2.x with ROMFS.
That's an interesting idea. Or, we can just always use the stream model for ROMs. That's a bit more uniform, albeit slower.
romfs_header.version does not have to be endian-independent. If you can read the magic correctly as a number, you got the endianness right. No point in working around problems which do not exist.
There's another reason to do that. '1' is a common constants. 0x31313131 is not. I like to make important constants have complex values that can be caught from (e.g.) a JTAG memory dump.
"'pad' rounds the header to 32 bits and reserves a little room for later use." Actually, that should read "32 bytes".
yep.
Can we use some magic other than "ORBC"?
I don't see the problem, but I'll take a suggestion.
ron
On 31.03.2009 03:11, ron minnich wrote:
On Mon, Mar 30, 2009 at 5:36 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
AFAICS the proposed ROMFS code will break on the Gigabyte GA-M57SLI-S4 v2.x. Since the M57SLI is one of the best supported recent boards out there, I'd like to make supporting or not supporting one of its variants an explicit rather than an implicit choice. Short summary of the issue: ROMs larger than 512 kB or so can only be accessed in 3 byte chunks. That means you have to read every header in chunks. Direct comparisons in memory are not possible.
Actually, the code should work fine with the streams. I will rewrite the coreboot part to use them.
The other question is whether we want to use streams unconditionally. I'd prefer to use such streams only in emergencies (crappy hardware).
Besides that, I agree with Peter on naming when he wrote:
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.
I welcome another name, but I won't accept a reject unless it comes with another name :-)
LAR2 or maybe LLAR (Lightweight LinuxBIOS ARchive) or LCAR (Lightweight Coreboot ARchive). OK, the last one may be misunderstood as a Star Trek reference.
And finally, I'd like to make sure we don't try to support multiple ROM management schemes. That would be madness. If ROMFS is the future, can we please use it in v3 as well?
let's get it working first.
I don't understand this comment. If it does not work, why would we commit it to the v2 tree? Since v3 already has LAR, any replacement has to demonstrate that is an improvement over LAR while not introducing additional limitations/problems. (And no, bugs/misfeatures in the userspace tool do not count. If nobody has bothered to tackle them, nobody will bother to tackle similar problems with new userspace either.)
Don't get me wrong. Substantial parts of the ROMFS design are really worth having (and overlap with the LAR design), but I hope the LAR->ROMFS move is not brownian motion motivated by the intrinsic coolness of a new tool. And if someone designs LAR-NG as part of GSoC, will we switch (again)?
The "pointer to romfs_header at the end of the ROM" idea was rejected twice when I tried to get that in in v3. I still believe it is a good idea.
It is.
Can we separate the "pointer to something" patch out and handle/commit it before ROMFS? I can dig up my ancient v3 patch for this.
struct romfs_header is missing a struct member containing the lowest accessible ROM address so you can switch to accessor functions for lower addresses. This is needed if we ever want to support the M57SLI v2.x with ROMFS.
That's an interesting idea. Or, we can just always use the stream model for ROMs. That's a bit more uniform, albeit slower.
I can see roughly a factor of 20 slowdown. That's a bit excessive for my taste.
romfs_header.version does not have to be endian-independent. If you can read the magic correctly as a number, you got the endianness right. No point in working around problems which do not exist.
There's another reason to do that. '1' is a common constants. 0x31313131 is not. I like to make important constants have complex values that can be caught from (e.g.) a JTAG memory dump.
What about 0x4c415232 instead? That's "LAR2".
Can we use some magic other than "ORBC"?
I don't see the problem, but I'll take a suggestion.
"LAR2" maybe? "ORBC" in a hex dump looks like something went really wrong with endianness.
We need a policy for future romfs_header variants, too. Should they be backwards compatible? Do we want ext2-style read/write feature flags?
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
There's another reason to do that. '1' is a common constants. 0x31313131 is not. I like to make important constants have complex values that can be caught from (e.g.) a JTAG memory dump.
What about 0x4c415232 instead? That's "LAR2".
Can we use some magic other than "ORBC"?
I don't see the problem, but I'll take a suggestion.
Let's start with working out the name. :)
//Peter
On 31.03.2009 4:18 Uhr, Peter Stuge wrote:
Carl-Daniel Hailfinger wrote:
There's another reason to do that. '1' is a common constants. 0x31313131 is not. I like to make important constants have complex values that can be caught from (e.g.) a JTAG memory dump.
What about 0x4c415232 instead? That's "LAR2".
Can we use some magic other than "ORBC"?
I don't see the problem, but I'll take a suggestion.
Let's start with working out the name. :)
Yeah, bikesheds first. Then the deed!
Stefan
On Tue, Mar 31, 2009 at 04:12:53AM +0200, Carl-Daniel Hailfinger wrote:
LAR2 or maybe LLAR (Lightweight LinuxBIOS ARchive) or LCAR (Lightweight Coreboot ARchive). OK, the last one may be misunderstood as a Star Trek reference.
I vote LCAR. Totally :)
Thanks, Ward.
On Mon, Mar 30, 2009 at 7:12 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
The other question is whether we want to use streams unconditionally. I'd prefer to use such streams only in emergencies (crappy hardware).
great! how much crappy hardware is there. Is it only a part of the past or will we see it in future.
If it is only misdesign for past boards then there is an easy solution.
let's get it working first.
I don't understand this comment. If it does not work, why would we commit it to the v2 tree?
OK, first, it's working in my tree.
It's a huge improvement over LAR. It's 10 times huge over what v2 does now. I've got a patch that lets us use the old way and LCAR. (I like the name).
Since v3 already has LAR, any replacement has to demonstrate that is an improvement over LAR while not introducing additional limitations/problems.
This is a huge improvement over LAR.
Also, the code to come is design so that it is 100% backwards compatible and LCAR is by default *off*. You only use it if you want it. Hopefully, over time, 100% of us want it.
Don't get me wrong. Substantial parts of the ROMFS design are really worth having (and overlap with the LAR design), but I hope the LAR->ROMFS move is not brownian motion motivated by the intrinsic coolness of a new tool. And if someone designs LAR-NG as part of GSoC, will we switch (again)?
It's worth having. It's why I did not back-port LAR to v2.
Can we separate the "pointer to something" patch out and handle/commit it before ROMFS? I can dig up my ancient v3 patch for this.
I am not doing this for v3. This is a v2 patch.
I can see roughly a factor of 20 slowdown. That's a bit excessive for my taste.
Again, is this stupid hardware design something we only see on one bad board or might we see it again? Would be nice to know :-)
What about 0x4c415232 instead? That's "LAR2".
harder to remember but I can entertain it.
We need a policy for future romfs_header variants, too. Should they be backwards compatible? Do we want ext2-style read/write feature flags?
no. no. no. no. no. no. no. no. I'm not even that big a fan of versioning in the current design, but there you are. :-)
ron
ron minnich wrote:
great! how much crappy hardware is there. Is it only a part of the past or will we see it in future.
If it is only misdesign for past boards then there is an easy solution.
Completely agree.
But I think it is difficult to say at this point. Personally I don't see far enough into any vendor's roadmap about flash chip access. I'm not sure anyone even cares?
What is the key limiting factor on the m57sli? Decode window IIRC, but mpc55 or superio?
SPI is kind of new still.. If we look at the SB600 it has a really nice SPI master with no semblance of these limits.
But Winbond SPI masters continue to only support 1Mbyte. There is no workaround. We can't fix that of course but maybe it's some sign of where things are at the moment.
//Peter
so the substantive comments that I can see so far: 1. ROMFS->LCAR 2. ORBC->LAR2 2.5 version number 31313131 to something else, I don't care, just name it. 3. consider stupid hardware design which makes most of ROM non-memory-accessible but at the same time don't do that because it is really slow. You all confused me now :-) 4. make expansion roms compressed. Well, this is ok by me; are we going to expand them to c0000? That works for me.
I'd like to say, this is the 3rd or 4th attempt to fix this. Jordan did this twice, we did it once before him, and this is actually Jordan's last piece of code. I am thinking we need to stop arguing this code to death.
Nothing is going to be perfect, but I have been using LCAR2 for a week and it's way better than what v2 has now. I think it's the right direction.
Let's not make this a file system. It's just a set of managed pointers to data. We don't need ext2 extended headers.
Compression is possible on expansion roms. There is nothing that says we can't do it.
ron
ron minnich wrote:
- ROMFS->LCAR
Let's not make this a file system.
Hmm, I remember Jordan didn't like the archive concept, and ISTR he prefered fs, as suggested by the romfs name too. I think an *fs name makes sense when there is a master structure like here.
It's just a set of managed pointers to data. We don't need ext2 extended headers.
I agree, but datablobs is not a great name either.. :)
- ORBC->LAR2
Shouldn't 1. and 2. be in sync somehow?
- consider stupid hardware design which makes most of ROM
non-memory-accessible but at the same time don't do that because it is really slow. You all confused me now :-)
Yeah. I don't know. :\ It depends on how early in the stack this problem is relevant. For coreboot+SeaBIOS it will never become an issue. Want to make use of more stuff - then maybe you need better hardware. Does that seem fair?
I do however think it would suck to intentionally regress on m57sli, or any other board.
Nothing is going to be perfect,
As for the name I can not stress enough how important it is to come as close as possible to something unique, especially when there is a unique purpose (and noone has publically standardized firmware flash chip content before), and this particular area is a very confusing minefield for newcomers already. We lose way more by ignoring that and making things worse than we can ever gain from the best technical storage solution. :\
Even if we can't find the perfect name we will suffer for sure if we have a name which can be confused or misunderstood in any way.
A good name alone lowers the knowledge barrier for many.
but I have been using LCAR2 for a week and it's way better than what v2 has now. I think it's the right direction.
Sounds great!
//Peter
On Mon, Mar 30, 2009 at 9:36 PM, Peter Stuge peter@stuge.se wrote:
Hmm, I remember Jordan didn't like the archive concept, and ISTR he prefered fs, as suggested by the romfs name too. I think an *fs name makes sense when there is a master structure like here.
I don't want it to become ext2. Sure, we can make it complicated, but that's a mistake.
- ORBC->LAR2
Shouldn't 1. and 2. be in sync somehow?
Sure. Suggest something! :-)
Yeah. I don't know. :\ It depends on how early in the stack this problem is relevant. For coreboot+SeaBIOS it will never become an issue. Want to make use of more stuff - then maybe you need better hardware. Does that seem fair?
Yes. I think we ought to be willing, when confronted with stupid hardware, to say "Sorry, your hardware is too stupid to run coreboot". We just can't cover every single piece of hardware -- right now we don't cover much at all, and diverting huge effort for bad hardware doesn't make sense to me.
look, long term, if EFI happens, or if bigger BIOS happens, ROM will be memory addressable.
I don't think stupid hardware designs will continue to be the rule. I hope not.
I do however think it would suck to intentionally regress on m57sli, or any other board.
I should mention that the patch I will submit (once this one goes through) won't regress anything. The old way continues to work fine (tested). The new way works too. You pick which one you want in either the target or mainboard file. The default is CONFIG_ROMFS=0.
I.e. it is quite backward compatible (abuild tested; tested with ROMFS^H^H^H^H^HLCAR on qemu and kontron). It only builds an LCAR image if CONFIG_ROMFS^H^H^H^H^HLCAR is 1.
This is designed to be a very painless transition.
OK, this is going to be a question. Why am I suddenly back on v2? The reason is simple. We've been baking v3 for 30 months and ... we're not there except on a very few boards. Most vendors are still doing v2 for the most part. V2 has grown tremendously since Oct. 2006 when we designed v3. The development on v2 has been so good, in fact, that in many feature areas v2 is now far ahead of v3: ACPI, SMM, S3 resume, etc. etc.
To put it simply, I think we have to use v3 as the "good ideas and lessons learned" testbed, and bring ideas we learned from there back into v2. And that is what I am doing. LCAR is the first step.
I don't plan to put LCAR into v3. In fact I think I am done with v3. It was a beautiful thing but it is time to move forward and bring the good parts of v3 into v2 ... and realize that a lot of very fine work has been done on v2, and it's simply not possible at this point to move all that work to v3. We have to evolve, now, and do so in a way that merges the best ideas of v3 back into v2.
I don't think v3 will end. It is the definitive Geode platform, in my view. But the geode will end someday.
So I'm back.
As for the name I can not stress enough how important it is to come as close as possible to something unique, especially when there is a unique purpose (and noone has publically standardized firmware flash chip content before), and this particular area is a very confusing minefield for newcomers already. We lose way more by ignoring that and making things worse than we can ever gain from the best technical storage solution. :\
The thing is, I use a lot more than linux, so this naming thing doesn't bother me that much. I use several different OSes that have a rom or ram or whatever fs.
But if you want a name that is evocative of coreboot .... we can do the "core" thing in the name (corefs?) or we can just go with LCAR (wow, that is hard to say in many places! -- can we possibly put a few more vowels in there?) or we can try to pick a good name in the next few days. But I don't want to hold this new stuff up forever while we debate on a name.
ron
On 31.03.2009 07:09, ron minnich wrote:
OK, this is going to be a question. Why am I suddenly back on v2? The reason is simple. We've been baking v3 for 30 months and ... we're not there except on a very few boards. Most vendors are still doing v2 for the most part. V2 has grown tremendously since Oct. 2006 when we designed v3. The development on v2 has been so good, in fact, that in many feature areas v2 is now far ahead of v3: ACPI, SMM, S3 resume, etc. etc.
To put it simply, I think we have to use v3 as the "good ideas and lessons learned" testbed, and bring ideas we learned from there back into v2. And that is what I am doing. LCAR is the first step.
I don't plan to put LCAR into v3. In fact I think I am done with v3. It was a beautiful thing but it is time to move forward and bring the good parts of v3 into v2 ... and realize that a lot of very fine work has been done on v2, and it's simply not possible at this point to move all that work to v3. We have to evolve, now, and do so in a way that merges the best ideas of v3 back into v2.
I don't think v3 will end. It is the definitive Geode platform, in my view. But the geode will end someday.
So I'm back.
I'm very sad to hear this. Sure, I've seen that v3 didn't improve at the rate it used to. But although I've been active in coreboot for 3 years: - I still do not understand the v2 build system. - I still do not understand the v2 device model. - I still do not understand the v2 Config.lb/Option.lb system. - I still do not understand the v2 fallback/normal/failover model. - I still do not understand the v2 design. - I still do not understand how v2 CAR and normal code interact. Every time I work on v2, I feel utterly incompetent. I just try to hack on it unintelligibly in the hope it doesn't explode in my face again and again. v2 is my personal motivation killer. Every time I work on v3, I feel I understand everything. Working on it is a pleasure and tracking down bugs is rather easy because of the clear structure.
Now if we can make v2 use the v3 device model, DTS, config system, build system, stage design, LAR, CAR, startup code, global variables, struct device and printk buffer, v2 will become bearable. But then v2 will essentially be transformed into what v3 is now with additional ports.
Bringing v3 concepts, but not code to v2 removes all implementation experience we have with those concepts. If we already built and reinvented the wheel multiple times and the last one works rather well, rebuilding and partly reinventing it again feels really futile.
I'm all for transforming the v2 codebase into v3 for easier transplantation if we reuse v3 code.
Regards, Carl-Daniel
Am 31.03.2009 12:52, schrieb Carl-Daniel Hailfinger:
I'm very sad to hear this. Sure, I've seen that v3 didn't improve at the rate it used to. But although I've been active in coreboot for 3 years:
- I still do not understand the v2 build system.
- I still do not understand the v2 device model.
- I still do not understand the v2 Config.lb/Option.lb system.
- I still do not understand the v2 fallback/normal/failover model.
- I still do not understand the v2 design.
- I still do not understand how v2 CAR and normal code interact.
Every time I work on v2, I feel utterly incompetent. I just try to hack on it unintelligibly in the hope it doesn't explode in my face again and again. v2 is my personal motivation killer. Every time I work on v3, I feel I understand everything. Working on it is a pleasure and tracking down bugs is rather easy because of the clear structure.
Now if we can make v2 use the v3 device model, DTS, config system, build system, stage design, LAR, CAR, startup code, global variables, struct device and printk buffer, v2 will become bearable. But then v2 will essentially be transformed into what v3 is now with additional ports.
Yes, but what's easier: porting 200-or-so mainboards and chips with all their hidden workarounds to v3 or porting some design work in a comparably small kernel of generic code?
Bringing v3 concepts, but not code to v2 removes all implementation experience we have with those concepts. If we already built and reinvented the wheel multiple times and the last one works rather well, rebuilding and partly reinventing it again feels really futile.
LAR worked so well that there was a need to create ROMFS.
I'm all for transforming the v2 codebase into v3 for easier transplantation if we reuse v3 code.
And that's the idea. Just that in this case, there was some fix to shortcomings in LAR already (romfs was first proposed for v3, after all). This is only the first step in a longer plan of incremential improvements. And it's supposed to fix most of your issues above.
Patrick
On 31.03.2009 12:52 Uhr, Carl-Daniel Hailfinger wrote:
I'm very sad to hear this. Sure, I've seen that v3 didn't improve at the rate it used to. But although I've been active in coreboot for 3 years:
- I still do not understand the v2 build system.
- I still do not understand the v2 device model.
- I still do not understand the v2 Config.lb/Option.lb system.
- I still do not understand the v2 fallback/normal/failover model.
- I still do not understand the v2 design.
- I still do not understand how v2 CAR and normal code interact.
We are all fighting with "smart conceptions" in version 2. But, I also believe the reason we're not getting anywhere with v3 is that we refused to get a decent understanding of what happens in v2. Starting out with a clean room implementation like v3 helps to grasp many of the issues. Now it is time for a "lessons learned".
Every time I work on v2, I feel utterly incompetent. I just try to hack on it unintelligibly in the hope it doesn't explode in my face again and again.
Which is exactly why we started to improve v2.
Every time I work on v3, I feel I understand everything. Working on it is a pleasure and tracking down bugs is rather easy because of the clear structure.
Except for the idiosyncratic implementation of some features, v2 is very similar to v3. Don't let the few rough parts in v2 delude you into thinking v3 were something completely different. Yes, v3 is simpler. And yes, a lot of that is due to the fact that v3 lacks a lot of functionality that we have in v2. A bike is more comfortable than a car, if you have to carry it. Things change as soon as it's supposed to carry you.
Now if we can make v2 use the v3 device model, DTS, config system, build system, stage design, LAR, CAR, startup code, global variables, struct device and printk buffer, v2 will become bearable. But then v2 will essentially be transformed into what v3 is now with additional ports.
I still think DTS isn't all that helpful, and a lot more complex than what we have in v2 without any additional gain. For the rest, I agree. We developed a lot of fine features in our experimental tree, and it's about time we port those over so that people can actually use them.
Bringing v3 concepts, but not code to v2 removes all implementation experience we have with those concepts.
Why is that? We don't suddenly become oblivious, will we?
If we already built and reinvented the wheel multiple times and the last one works rather well, rebuilding and partly reinventing it again feels really futile.
We have a pretty large stock pile of tires around here, but now it's getting spring, and we want to mount a new set of tires. :-)
Stefan
Am 31.03.2009 05:23, schrieb ron minnich:
so the substantive comments that I can see so far:
- ROMFS->LCAR
- ORBC->LAR2
LCAR, so magic and name match (request by Peter)
2.5 version number 31313131 to something else, I don't care, just name it.
"VeR1" (as good as any, and it doesn't look like a failed memory test)
- consider stupid hardware design which makes most of ROM
non-memory-accessible but at the same time don't do that because it is really slow. You all confused me now :-)
That shouldn't stop integration. With the code integrated, we can start porting boards over to whatever-it-is-called-now (wiicn), and fix issues as we encounter them. And if some boards require special access to wiicn, we'll have to allow them to redirect wiicn access through functions pointers - that's not hard, and doesn't change the design as far as I see it, merely some implementation bits.
- make expansion roms compressed. Well, this is ok by me; are we
going to expand them to c0000? That works for me.
Expansion roms are not on the roadmap yet (the buildsystem doesn't even cover them), and this is something that can be modified at build time at will (romtool add-whatever filename [compression flag]) once we support it. No change in wiicn design, no significance for the patch in question, no need to debate it now.
Regards, Patrick
On 31.03.2009 4:12 Uhr, Carl-Daniel Hailfinger wrote:
On 31.03.2009 03:11, ron minnich wrote:
Actually, the code should work fine with the streams. I will rewrite the coreboot part to use them.
The other question is whether we want to use streams unconditionally. I'd prefer to use such streams only in emergencies (crappy hardware).
The question is: Has anyone written a streaming decompressor of lzma yet? I think the current code performs quite badly when trying to make the visibility window one word wide.
Stefan
ron minnich wrote:
Besides that, I agree with Peter on naming when he wrote:
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.
I welcome another name, but I won't accept a reject unless it comes with another name :-)
Some -fs names I would like much better: cfs compfs componentfs fwfs firmwarefs cbfs corbfs topfs
I want to avoid anything with RAM, ROM, BIOS, boot or flash because those terms are extremely overloaded.
//Peter
On Mon, Mar 30, 2009 at 03:52:20PM -0700, ron minnich wrote:
This patch adds Jordan's ROMFS utility to v2.
ron
Hi Ron,
I think it would be great to backport a LAR like flash structure to coreboot v2.
However, I'm a bit confused by the move to include ROMFS in v2 - at least while v3 still has LAR. As payloads become more advanced, I think they're going to need to peek into the flash, and having to support both LAR and ROMFS in external code is going to be a big pain.
I hope this doesn't come across as too critical to ROMFS, but I have some concerns.
From an outside point of view, LAR seems to work okay - what's the
driving reason to do a wholesale replacement? I think incremental patches would make more sense here.
Some thoughts on the format -
I do like how ROMFS simplifies the "file header". However, I think the use of a file type is a mistake. I think type info can be more appropriately conveyed in the file name. (As a "straw man" argument, consider ROMFS allocates four bytes for a file type; one could instead use a four byte suffix on file names (eg, ".xip", ".exe", ".rom").)
ROMFS is essentially a collection of binary blobs. One of these file types (payloads) is also effectively a collection of binary blobs. I preferred the way LAR had one abstraction for storing blobs. Unfortunately, LAR achieved this by adding info to the file header. However, I think there is a "middle ground" here - for example, one could put the ROMFS header into a file, and then every section into its own file.
It's not clear to me how XIP code (eg, raminit in v3) would be stored in ROMFS.
The description states that option roms would not be compressed. Given how bloated option roms seem to be, I think compression is desirable.
There are some improvements that I think would make LAR more useful that I don't see in ROMFS. One really useful feature would be to support building a LAR from a directory of files and vice-versa. This would simplify the build process and make it easier for users to add/modify payloads, option roms, etc..
Also, it would be useful to come up with some way for payloads to reliably access the LAR even when files are compressed. For example, I would like to add support in SeaBIOS to extract option roms from the LAR, but to do so would require supporting lzma, nrv2b, etc. in SeaBIOS. I think having every payload know about every compression scheme is too much. (Of course, not compressing option roms would solve this, but I still think compressing them makes sense given how small and slow flash tends to be.)
-Kevin
Am 31.03.2009 00:52, schrieb ron minnich:
This patch adds Jordan's ROMFS utility to v2.
It has no effect except creating a new directory. Not hooked up anywhere, not capable of doing any harm. Let's get it in: Acked-by: Patrick Georgi patrick.georgi@coresystems.de
Patrick
Am 31.03.2009 13:57, schrieb Patrick Georgi:
It has no effect except creating a new directory. Not hooked up anywhere, not capable of doing any harm. Let's get it in:
r4032. Without any changes to magic numbers or other stuff. Keep bikeshedding on this as long as you please, these numbers aren't part of any stable contract yet, so whoever uses romtool and binaries from different revisions is on his own, and rightfully so.
Patrick
-
Carl-Daniel Hailfinger -
Kevin O'Connor -
Patrick Georgi -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Ward Vandewege