We've been kind of holding off on this, but, fact is, coreboot has followed the well trod path of firmware everywhere and become a small kernel. It started as little more than memcpy with a frisson of I2C packet IO thown in, but thanks to the generous ideas of hardware designers everywhere, with ever-increasing needs for block IO devices, little on-chip packet networks, and so forth, here we are: YAFOS (Yet Another Firmware OS).
LinuxBIOS/coreboot was intentionally not designed to be a kernel or become a kernel, and the strain is starting to show as we find ourselves needing to be more of what a kernel is. Alex points out that "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."
I've been feeling the same way. Adding specific APIs for specific device types is very old school design (and I mean REALLY old school, like OSes from the 60s). That was always a major objection I had to EFI -- it looked like the guys who designed it had never heard of Unix.
There's not much point in fighting the tide here. The idea of linux-as-bios was nice, but we have come to the point where linux-as-bios requires a small firmware kernel just to load it.
I think we need to step back from the small problems just a bit (i.e. generic block device interface) and think about generic device interfaces. It's doable: see Unix. We don't have as broad a range of devices as Unix had to contend with (no paper tape). And we've got tons of different examples to draw from.
But should this device abstraction be a driver or a device? And, in this new world, would the driver/device distinction in coreboot disappear?
ron