[coreboot] patch: add romfs to V2
c-d.hailfinger.devel.2006 at gmx.net
Tue Mar 31 04:12:53 CEST 2009
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 at 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
>> 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
>> 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?
More information about the coreboot