On Thursday, March 13, 2014 04:29:06 PM David Hendricks wrote:
On Tue, Mar 11, 2014 at 7:55 AM, Naman Govil namangov@gmail.com wrote:
Hi!
Hi!
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 media.
The problem is not that CBFS is not easily extendable to incorporate MMC; that's a 100 liner [1]. 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 the code.
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 [2]. 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.
Alex
[1] https://github.com/mrnuke/coreboot/blob/369998920685852246dcae4c3e88b268c1c9... [2] https://github.com/mrnuke/coreboot/commits/cubie_mmc