[coreboot] GSoC-2014 Project for Coreboot
mr.nuke.me at gmail.com
Fri Mar 14 04:15:47 CET 2014
On Thursday, March 13, 2014 04:29:06 PM David Hendricks wrote:
> On Tue, Mar 11, 2014 at 7:55 AM, Naman Govil <namangov at gmail.com> wrote:
> > Hi!
> > a generic interface for
> > accessing block devices on ARM SoCs so that coreboot could launch its
> > stages from the block devices (an MMC for example).
> Seems interesting, but I am a little bit worried that the project is too
> narrow. We updated CBFS about a year ago to allow CBFS content to come from
> any media. This was required for the earlier ARM-based platforms which use
> SPI ROM since the content was not memory mapped as it is on x86 platforms.
> It should be reasonably easy to follow that model using MMC as a backing
The problem is not that CBFS is not easily extendable to incorporate MMC;
that's a 100 liner . The problem is creating yet another API for accessing
stuff, besides which we'll add an MTD and NAND API, etc. etc. etc. This would
make us EFI-ish.
> IIRC Alexandru ran into issues with adapting the A10's MMC driver from
> u-boot to coreboot and making it fit into the bootblock, which was
> constrained by the amount of SRAM available on the A10. I am worried that
> you will end up fighting implementation-specific problems on the platform
> you choose instead of doing more interesting infrastructure work.
I'm glad you brought that up. I ran into several problems, most of which were
a result of CBFS's x86-centric design rather than the shortage of SRAM. A lot
of CBFS callers love to generate map() calls, which means we as the backend
need to provide the cache where to map that. When I get a map() call to map
20+ KiB of romstage into an area of SRAM I must provide, which must not
overlap the final destination of romstage, I am wasting SRAM. If I only got a
call to read(), with the destination being the resting place of romstage, that
would eliminate the SRAM pressure a bit.
My first solution was to make the CBFS cache and the romstage destination
overlap. That needed a trivial change in CBFS, but that patch dropped the soap
for various reasons. The alternate_cbfs implementation for that was also
clumsy and difficult to read.
Another problem I almost had was caused by problem #1. Since I needed a ton of
RAM for the CBFS cache, I had to initialize RAM in the bootblock. Adding that
code almost caused overgrowing the maximum bootblock size. I was getting close
to the 24KiB limit with the MMC driver in there as well. I moved a bunch of
non-essential stuff to romstage, and optimized the code layout a bit to not
compile big bloat in bootblock. If I nuke the MMC debug messages, the
bootblock goes under 13KiB, with MMC and raminit. Seems like there's also room
for an MTD/NAND driver.
So, I hope I killed any worries about "fighting implementation-specific
problems on the platform", which brings me back to the awkward design of CBFS.
If we go the way of separate API for every possible bootblock media, you can
have a Kconfig to select which to boot from.
If, on the other hand, you have a well designed, unified block dev API, you
can select your block device based on some some heuristic to decide which
media to boot from. Make it a GPIO.
Why is this better? You don't need two implementations of alternate_cbfs,
which are extra code size, extra code, and generally look ugly and complicate
I hope I convinced both of you that this is not an easy, trivial problem, and
will take a big chunk of GSoC time, as well as tons of dedication to get done
right. The purpose is not to hack something together to boot. I already did
that in my github branch . The purpose is to Do It Right (TM).
Naman, that means that if you pull this off, you'll need to be completely
involved with the community for the twelve or so weeks of coding. You'll need
to have patches up on gerrit early, take feedback, and involve in lots of
discussion about the design. You will often be rewriting patches in the
afternoon, in order to conform to the new design ideologies you discussed in
the morning. You will repeat this process many times. You'll have to get
intimate with the coding standards and ideologies of coreboot. I suggest you
demonstrate a profound understanding of the foundation of our coding standards
in your application, by correctly formatting any example code included
therein. Your goal must be to have your work merged in coreboot master, and
your board booting from MMC/SD with that code, by the pencils down date.
More information about the coreboot