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