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