[coreboot] patch: add romfs to V2

[ron minnich]

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.


> 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