[coreboot] RFC: Allow CBFS to read from multiple arbitrary source media.

[Hung-Te Lin]

On Tue, Jan 29, 2013 at 6:46 PM, Patrick Georgi <patrick at georgi-clan.de>wrote:

>     CBFS used to work only on memory-mapped ROM (all x86). For
>> platforms like ARM, the ROM may come from USB, UART, or SPI -- any
>> serial devices and not available for memory mapping.
>>
>>     The idea is to allow (1) using CBFS on platforms without
>> memory-mapped ROM (ex, ARM), and (2) reading CBFS from multiple source
>> at the same time (ex, receive updates from USB or UART cable).
>>
> I can understand other memory types (and there are some weird access
> patterns, we had that on some gigabyte board already).
> I'm not quite as sure about UART as CBFS source.


    ARM SoC like Exynos or OMAP can boot from multiple source - SD Card,
eMMC, flash, ... etc, and they may even support booting from a downloaded
ROM (just for development) from a USB cable or UART port.

I'm quite opposed against "live" updates.
>

    Oh, it's not for regular use. Just a feature for development -  so you
can test firmware without flashing it to a real EEPROM.
    Booting a small portion from flash chip and then read the remaining
part from other media (ex, downloaded from USB). Maybe I should not call
this "update".
    I totally agree with you that coreboot should not make this as part of
official design, but if some developers want to play with that  (feature
provided by SoC vendors) it would be nice if he only needs to make minimal
changes for that.


> Any use case I can envision (for updates or UART loading) is better
> implemented as payload specific function (and totally separate from CBFS),
> but maybe I just lack creativity.

So, what's your use case?


    The main use case is for booting and loading ROM stage file on ARM --
and that's why we can't have it as payload function.

    On X86, most boards just need few lines of code to enable memory
mapping of whole flash ROM, execute-in-place in bootblock and ROM stage
file, initialize RAM and load ram stage / payload from CBFS. But for ARM,
there's no memory mapping. The SoC will load a very small portion (16~32k
for example) into SRAM, and that part is responsible for load more content
(ROM stage) from flash.

    So, we need the initialization and and CBFS code even in bootblock (to
load ROM stage) and ROM stage. There's also very few SRAM so we can't
preload whole ROM content -- and that's why we need a load-on-demand style
CBFS.

    Hmmm, I forgot to explain the design and change behind API prototype
changes; sorry for that.

    In this CL, CBFS functions are now virtualized and leaving all I/O low
level stuff in a "media" (media->open, media->read, media->map,
media->close). In this way, a board / architecture can implement its own
media source. For X86, it's as simple as using memory pointers. For ARM, it
may be a complex procedure of initializing clock, SPI driver, reading from
specific address, finding memory to cache and map data, ... etc. That's why
we need a param as "media source".

    CBFS functions then changed I/O method from (take get_file search loop
for example)
        while ((data < dataend - 1) && (data >= origdata)) {   // all void*
pointers, must pre-load whole ROM
    to
        while (offset < romsize && media->read(media, &file, ...) == xxx)
// allow reading from any kinds of media on demand.

    Without this, we will have to write different CBFS code for different
platforms, and maybe even more variants for different stages (bootblock,
ROM stage, RAM stage) -- just like x86's assembly version cbfs_walk. By
having I/O abstracted we can always have same CBFS interface, with only
difference in I/O backend.

Regards,
Hung-Te
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20130129/931c1f0c/attachment.html>