New subject: GSoC-2014 Project for Coreboot

15 Mar 2014


      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@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

Re: [coreboot] GSoC-2014 Project for Coreboot