On Mon, Mar 30, 2009 at 5:36 PM, Carl-Daniel Hailfinger <[email protected]> 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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
