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