There were three parts to that #2, repeated below for reference.
2. It presents a whole new set of problems that need to be addressed. For
example, how do we load different stages of the boot process from a media
that
is not memory-mapped? How do we handle devices with limited amounts of
Cache-
as-RAM (SRAM in this case)? How do we adjust our payload ecosystem to
accommodate loading the OS kernel?
Hung-Te, an engineer at Google, has reworked the CBFS infrastructure so
that you can plug different media into it which know how to load things
for that platform. On x86 platforms it's just memory mapped. On all the ARM
platforms I mentioned except for beaglebone, the SPI driver is plugged in
which will load stages, CBFS meta data, etc., on request. The SOC in a
beaglebone can load the non-masked firmware from lots of places including
downloading it over the network, but on the beaglebone its wired up either
to get it from either the eMMC or the SD card. I played a trick which
avoided having to have an eMMC driver in the bootblock by making the masked
ROM load enough of CBFS into SRAM so that the media could just adjust the
ROM stage in place slightly and run it from there. I wasn't able to work on
beaglebone much after that, but to flesh it out it would need an eMMC/SD
driver and that would need to be interfaced with CBFS as a type of media.
The CBFS support is for the whole tree, and the media support is per
board or maybe SOC.
That's how to load things off of non-memory mapped media. As far as how to
work in limited pre-memory storage that hasn't really been a problem. There
isn't a lot of space, but it's generally not been that hard to fit in the
limits of the chips we've worked with so far. In my in depth but relatively
short experience with U-Boot over the last few years it tends to be pretty
monolithic and large comparatively, and so I don't think we would have too
much trouble fitting in their footprint.
As far as payloads, that needs some work. We've focused on the depthcharge
payload since we've been developing for chromebooks. I have no interest in
turning depthcharge into a general purpose bootloader, and I think people
would be better served by having something like a grub for ARM anyway.
There are several complications here, though.
1. There is much less you can count on hardware wise on ARM. There's
basically no legacy hardware or interfaces you can fall back to to make a
bootloader that should work on most machines like you can on x86. You have
to have real drivers for the SOCs in question, and perhaps even have info
about each particular board in some cases. A lot of ARM stuff is
non-discoverable too, so you need some sort of configuration database to
tell you were things are. The kernel uses a device tree (not like
coreboot's) which has its own issues.
2. Booting a kernel on ARM is complicated. There are a couple different
kernel boot protocols (ATAGS, device tree), and if the kernel uses device
tree you may be expected to load it and fix it up. The information itself
and which information it is is board specific. There may even be a need to
bridge between things the firmware proper did and the kernel, for instance
telling the kernel where magical blobs of resident firmware code are.
Payloads can't actually even count on memory being in the same place in the
address space which makes finding the coreboot tables somewhat tricky and
which is a bit hacky as implemented right now. What we do for the existing
boards is we have to staticlly tell libpayload where to look on that
platform. A better solution would be pass a pointer to the coreboot tables
in a register when the payload starts. Then libpayload and other payloads
can be a little more generic.
I think I've basically addressed your question at this point, but I also
want to mention somethings that I think could be improved in our SPI/CBFS
stack.
Currently our SPI drivers are, I think, based on the U-Boot API. This is
actually a fairly reasonable interface which has a start, stop, and xfer
function. The start function asserts CS, the stop function deasserts it,
and the xfer function does either a simplex or duplex transfer to the
device. One problem with it, though, is that it does everything in terms of
bits. That means all the call sights multiply the size by eight, and all
the drivers divide by eight and probably check for remainder bits and flag
an error. It's wasteful and doesn't really make any sense since we don't
care about single bits of data. The size of the incoming and outgoing
arrays are also independently controlled which complicates the driver logic
considerably.
Then, we have the CBFS media support. This was unfortunately built into the
drivers themselves and comes with its own set of functions which are built
more around a memory mapping sort of interface. Those functions are
implemented directly by the driver and make controlling the device more
complicated. What I want to do to fix that up is to pull all the
