[coreboot] GSoC-2014 Project for Coreboot

[Kevin O'Connor]

On Fri, Mar 14, 2014 at 08:58:01AM -0500, Aaron Durbin wrote:
> On Thu, Mar 13, 2014 at 10:15 PM, mrnuke <mr.nuke.me at gmail.com> 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