It's essential for some ARM SoCs. Allwinner chips like the MMC as their first boot source, and people are very happy with having their firmware and linux on micro SD. It makes the system unbrickable.
For coreboot, this presents a whole new set of challenges. First off, MMC, NAND and friends are block devices. Unlike SPI, which is easily integrateable as an alternate CBFS driver, block devices are a whole new beast.
First, there's the potential of code reuse, or excessive duplication, depending on how you look at it. uboot has a 1500+ LOC driver for MMC/SD handling. Beynod that, low-level operations are passed to device-specific drivers. I'm not happy with the details of the uboot code, and have tried to adapt it for coreboot [1]. The result is a complete mess. This is part of a larger effort to bring Allwinner support to coreboot[2].
We need block device and MMC/SD support (at least for Allwinner at the moment), and we need to do it coreboot style. That means high quality, readable code, and most of all modular. We need an API on which to build things. I'm not happy with the uboot model here: it's not clear what belongs where.
So, how do we handle block devices, then MMC/SD, and potentially NAND? I can adapt the existing code to a specification, but I am disqualified to write that spec, as I have been brainwashed by working with the uboot code[2]. It works, but we need a coreboot-centric approach.
Any takers?
Alex
[1] http://review.coreboot.org/4631 [2] https://github.com/mrnuke/coreboot cubie_mmc branch
you don't want to follow the EFI path of a separate API for each device type. That's pre-unix thinking. It's also a path we're on, because coreboot was never intended to have drivers, and now we're getting them, and we have not really thought it out.
You do want to create a reasonable abstraction layer. I'd suggest looking at one of the embedded OSes that don't have user mode (Inferno being my favorite) to see how they did it.
ron
On Thu, Jan 09, 2014 at 01:46:19AM -0600, mrnuke wrote:
It's essential for some ARM SoCs. Allwinner chips like the MMC as their first boot source, and people are very happy with having their firmware and linux on micro SD. It makes the system unbrickable.
Can you expand on this requirement? Do these machines have a regular flash/rom with code that reads the rest of the firmware from the block device, or is some portion of the block device mapped by hardware at startup and that portion is tasked with reading the rest of the firmware off the block device? If so, how big is the initial mapped area?
-Kevin
On 01/10/2014 12:39 PM, Kevin O'Connor wrote:
On Thu, Jan 09, 2014 at 01:46:19AM -0600, mrnuke wrote:
It's essential for some ARM SoCs. Allwinner chips like the MMC as their first boot source, and people are very happy with having their firmware and linux on micro SD. It makes the system unbrickable.
Can you expand on this requirement? Do these machines have a regular flash/rom with code that reads the rest of the firmware from the block device, or is some portion of the block device mapped by hardware at startup and that portion is tasked with reading the rest of the firmware off the block device? If so, how big is the initial mapped area?
A blob built-in the SoC reads in some of the firmware (from SD, MMC or SPI, load to SRAM @ 0x0, branch to 0x0). 24 KiB on A10, a little different on A13 and so on. Think of it as the coreboot bootblock. That's all the free ride that you get. romstage and others you have to load manually.
It really depends on how that blob built into the SOC works. On the Tegra chips and on the SOC in the Beaglebone, the amount that's loaded depends on a data structure bundled in with the firmware. On the Beaglebone I told it to load enough of CBFS that it could get the ROM stage out of SRAM without having to talk to the boot media again. Anything beyond that, though, would require talking to the media. On Exynos the blob on the SOC loads another fixed size Samsung provided blob from the boot media which then loads the actual firmware. There it depends on how that blob works. Sometimes the blob loads a fixed size chunk, and sometimes it loads a variably sized blob which is described in a small header. I think the blobs we have in the coreboot repository are one of each, fixed size for the 5250 and variably sized for the 5420.
Gabe
On Fri, Jan 10, 2014 at 11:03 AM, mrnuke mr.nuke.me@gmail.com wrote:
On 01/10/2014 12:39 PM, Kevin O'Connor wrote:
On Thu, Jan 09, 2014 at 01:46:19AM -0600, mrnuke wrote:
It's essential for some ARM SoCs. Allwinner chips like the MMC as their first boot source, and people are very happy with having their firmware and linux on micro SD. It makes the system unbrickable.
Can you expand on this requirement? Do these machines have a regular flash/rom with code that reads the rest of the firmware from the block device, or is some portion of the block device mapped by hardware at startup and that portion is tasked with reading the rest of the firmware off the block device? If so, how big is the initial mapped area?
A blob built-in the SoC reads in some of the firmware (from SD, MMC or SPI, load to SRAM @ 0x0, branch to 0x0). 24 KiB on A10, a little different on A13 and so on. Think of it as the coreboot bootblock. That's all the free ride that you get. romstage and others you have to load manually.
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Gabe Black -
Kevin O'Connor -
mrnuke -
ron minnich