Am 2013-01-29 11:08, schrieb Hung-Te Lin:
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. I'm quite opposed against "live" updates.
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?
Patrick
On Tue, Jan 29, 2013 at 6:46 PM, Patrick Georgi patrick@georgi-clan.dewrote:
CBFS used to work only on memory-mapped ROM (all x86). Forplatforms 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 withoutmemory-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
-
Hung-Te Lin -
Patrick Georgi