-
Notifications
You must be signed in to change notification settings - Fork 37
Known SoC Boot Behaviour
Note
This page is obsolete and kept for convenience.
This page is a rollup of various SoCs' boot behaviour. Many SoCs can load firmware from an SD, eMMC, or USB storage device, but the behaviour may be hard coded in masked ROM and be incompatible with standard MBR or GUID partitioning, requiring special care if the storage is used to load both firmware and the target OS.
Note: The scope of this document is for systems that load firmware from some kind of primary boot media with a role similar to the primary SSD in a laptop (eMMC/UFS where this is fitted, SD for RPi, etc). The special partitioning of removable recovery media (where the boot ROM boots directly from removable/secondary media) is out of scope for EBBR since when the primary media is functional the firmware will be loaded as normal and becomes responsible for booting secondary media.
Masked ROM looks for first MBR partition formatted as FAT (partition type 0x0C) and loads bootcode.bin. bootcode.bin loads and runs start.elf, which in turn loads config.txt, cmdline.txt, and an executable (defaults to kernel*.img).
Supposedly newer Raspberry Pis can handle GUID Partition Tables, but haven't found any information as to which.
https://github.com/raspberrypi/noobs/wiki/Standalone-partitioning-explained
GUID Partition Table with firmware loaded from specific partitions: hyp (512KB), rpm (512KB), sbl1 (512KB on 410, 2MB on 820), tz (1MB on 410, 2MB on 820), aboot (1MB), and cdt (1KB). The size mentioned are the one typically used. On 820 based based it is possible to use eMMC or UFS. When using UFS the partition/LUNs scheme is slightly more complicated...
GUID Partition Table on eMMC. Native partitioning on UFS. Firmware loaded from specific partitions: xloader, fastboot, nvme, fw_lpm3, trustfirmware.
MBR partition table, boot ROM copies first 1MB from eMMC to DDR but data from 0x0 to 0x3000 can be arbitrary (forces MBR or undersize GPT partitioning). Uses a protective partition to protect SPL.
These families (such as i.MX6, i.MX7) load firmware found at the one kilobyte offset of an SD or eMMC device.
These families (both 32 and 64bit) load firmware found at the 8 kilobyte offset of an SD or eMMC device.
If SoCs load from SD or eMMC, they do so from sector 64 (32KB).
QorIQ family SOCs (such as LS1046, LS2088) has firmware (UEFI or u-boot) from block number 0x808 onward on SD card.
ROM:
Many TI ARMv7 SOCs have a similar boot ROM. This includes the AM335x SOCs used in the BeagleBone family of boards, the AM57xx SOCs used in the BeagleBoard-X15, and the AM3530 and AM3730 used in the original BeagleBoard and BeagleBoard-xM.
When booting from SD/MMC (including eMMC) the boot ROM supports raw block mode or FAT file mode. On each boot the ROM checks for the RAW mode and then, if not found, attempts the FAT file mode. When booting from eMMC all the SOCs mentioned above ignore the boot partitions and use only the user area just as if it were an SD card. A few existing TI devices support booting from eMMC boot partitions.
The raw block mode assumes 512 byte blocks and reads from blocks 0, 256, and on later devices 512, and 768. The first location with a valid header is used.
The FAT file mode looks for a bootable FAT12 (0x01), FAT16 (0x04, 0x06, 0x0E), or FAT32 (0x0B, 0x0C) partition type in the MBR. The ROM then reads, verifies, and runs a file named "MLO" in the root directory of that partition. (The ROM also supports direct boot of FAT images w/o an MBR but this is not deemed useful.)
Early boot ROMs were quite picky about the MBR, the contents of sector 256, and the presence of long file names in the root directory of the FAT. The ROM on AM335x and later devices is much more forgiving.
The SOC boot ROM supports other boot devices including UART, [Q]SPI, NAND, NOR, USB device mode, and most support direct BOOTP/TFTP boot from Ethernet if the board meets specific constraints. Other TI ARMv7 SOCs support I2C boot, SATA boot, and PCI EP slave boot.
Selection of bootmode is controlled via strapping of the SYSBOOT pins on power-on-reset. Many TI SOCs, including the ones mentioned above, try a number of boot methods for a given strapping of the SYSBOOT pins.
Boards:
BeagleBone Black starts ROM boot from the on board eMMC by default but will start with the uSD slot if a button is held while powering up the board. Other ROM bootmodes can be configured via pull-ups and pull-downs on the SYSBOOT pins available on the expansion header. Boards without eMMC like the original BeagleBone or the PocketBeagle start boot from the uSD.
Existing firmware:
The images from BeagleBoard.org switched to using raw block mode a number of years ago. These images embedded the u-boot SPL and u-boot image in the space between the MBR and the first LBA of the first partition.