On Fri, Mar 14, 2014 at 08:58:01AM -0500, Aaron Durbin wrote: > On Thu, Mar 13, 2014 at 10:15 PM, mrnuke <[email protected]> wrote: > > I'm glad you brought that up. I ran into several problems, most of which > > were > > a result of CBFS's x86-centric design rather than the shortage of SRAM. A > > lot > > of CBFS callers love to generate map() calls, which means we as the backend > > need to provide the cache where to map that. When I get a map() call to map > > 20+ KiB of romstage into an area of SRAM I must provide, which must not > > overlap the final destination of romstage, I am wasting SRAM. If I only got > > a > > call to read(), with the destination being the resting place of romstage, > > that > > would eliminate the SRAM pressure a bit. > > CBFS is definitely not friendly to environments that can't map() the > storage area of the CBFS itself. Beyond that in-storage format with > metadata tightly coupled to the data itself leads to needing to stream > large amounts of data through the working set just to locate the piece > that is desired.
CBFS is a neat system for accessing flash that can be linearly mapped into memory. If one has a flash device that can't be mapped into memory, I don't understand why one would want to use CBFS. Trying to adapt CBFS to block devices is going to complicate the CBFS code, and it still isn't going to be a good solution for those block devices. There are a number of filesystems already developed for block devices - why not just use one of them? The coreboot code's interaction with the "filesystem" after memory init (should) largely boil down to load_file(char *name, void *address, int maxsize). Why not just end the abstraction there (ie, on these arm devices, implement a completely different "load_file" function). -Kevin -- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
