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 -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
