[coreboot] GSoC-2014 Project for Coreboot

[mrnuke]

On Saturday, March 15, 2014 05:15:12 PM Kevin O'Connor wrote:
> Did you mean to send this only to me?  I'm only sending to you and not
> the list, but I'd prefer the discussion to be on list.
> 
OOPS! I blame it on KMail's shitty "Reply" interface.

> On Sat, Mar 15, 2014 at 01:54:47PM -0500, mrnuke wrote:
>> On Saturday, March 15, 2014 01:02:22 PM you wrote:
>>> On Fri, Mar 14, 2014 at 08:58:01AM -0500, Aaron Durbin wrote:
>>>> 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.
>> 
>> Last I checked, CBFS stood for "CoreBoot File System". I think that might
>> mean it's the filesystem used by coreboot, but I'll have to double check
>> and get back to you on that.
> 
> I don't think that's a great way to look at it.  The CBFS system is
> clearly designed to delineate a linearly mapped area of memory.  I
> wouldn't recommend using it for something else solely because it
> starts with "CB".
> 
>>> 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?
>> 
>> And how exactly is this going to complicate CBFS code? And how would
>> adding
>> another filesystem parser into coreboot simplify things?
> 
> The code has a bunch of media->open(), ->close(), ->read(),
> etc. operations that are unnecessary for basic linear memory mapped
> accesses.  As you've already cited, even with these "media" accessors
> the system still doesn't work well for not mapped flash chips.
> 
> By moving the abstraction up a layer, I posit that the CBFS code could
> be simpler, and the ARM code could be more capable.
> 
>>> The coreboot code's interaction with the "filesystem" after memory
>>> init
>> 
>> Aye, there's the rub: the assumption of "after memory init".
> 
> Before memory init everything is different on these non-mapped flash
> systems anyway.  In past conversations I've been told the hardware (or
> builtin firmware) on these systems extracts a preset block from the
> flash and places it into sram, and this is how the bootblock/romstage
> is done on these systems.  Thus the execute in place nature of
> bootblock/romstage in CBFS has no added value for these platforms.
> 
>>> (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).
>> 
>> Did you have a look at our CBFS backending, by any chance?
> 
> Yes.
> 
>> I'm sorry to be dismissive of your comments, Kevin, but it seems to me you
>> do not fully understand the issue and its implications. I suggest you
>> fully read this thread and "CBFS bullfart (forked from GSoC-2014 Project
>> for Coreboot)" to get an idea of the problem and its subtleties.
> 
> I have read the thread.  I concur that I do not understand.
> 
> -Kevin