Boot ROM is a piece ofread-only memory (ROM) that is used forbooting a computer system.[1] It containsinstructions that are run after theCPU is reset to thereset vector, and it typically loads abootloader. There are two types of boot ROM: amask boot ROM that cannot be changed afterwards, and a writable boot ROM such as anEEPROM or aflash memory chip.
Upon power up, hardware usually starts uninitialized. To continue booting, the system may need to read abootloader from someperipheral device, usually adata storage device. It is often easier to implementroutines for reading from external storage devices in software than in hardware. A boot ROM provides a place to store this initial loading code, at a fixed location immediately available to the processor when execution starts.
 | This sectionneeds additional citations forverification. Please helpimprove this article byadding citations to reliable sources in this section. Unsourced material may be challenged and removed.(October 2022) (Learn how and when to remove this message) |
The boot ROM is mapped into memory at a fixed location, and the processor is designed to start executing from this location after reset, according to the processor's reset vector. The boot ROM is either placed on the same die as the CPU or is an externalROM chip. On modern systems, the boot ROM (whether integrated into CPU or external ROM chip) usually usesNOR flash, which supportsexecute in place.
The boot ROM will then initialize the hardwarebusses and peripherals needed to boot. In some cases, the boot ROM is capable of initializingDRAM, and in other cases it is up to thebootloader to do that.[citation needed] On some modern ARM CPUs, the boot ROM integrated in CPU will initialize DRAM and then load abootloader; but after a bootloader (such asDas U-Boot) is loaded, the bootloader may reinitialize DRAM, to fix bugs and reduce cost.[citation needed]
At the end of the hardware initialization, the boot ROM will try to load a bootloader from external peripheral(s) (such as ahard disk drive orsolid-state drive, aneMMC oreUFS card, amicroSD card, an external EEPROM, and so on) or through specific protocol(s) on a communications port (such as aserial port orEthernet, etc.).
In manysystems on a chip (SoC), the peripherals or buses from which the boot ROM tries to load the bootloader, and the order in which they are loaded, can be configured. This configuration can be done by blowing someelectronic fuses inside the system on a chip to encode that information, or by having specific pins or jumpers of the system on a chip high or low.
Some boot ROMs are capable of checking thedigital signature of the bootloader and will refuse to run the bootloader and stop the boot if the signature is not valid or has not been signed with an authorized key. With some boot ROMs, thehash of the public key needed to verify the signatures is encoded inOTPelectronic fuses inside the SoC. Some systems on a chip boot ROMs also support apublic key infrastructure and the hash of thecertificate authority (CA) public key is encoded in the electronic fuses instead, and the boot ROM will then be able to check if the bootloader is signed by an authorized key by verifying that key with the CA public key (whose hash is encoded in the electronic fuses).[2][3]
That feature can then be used to implement security features or used as a hardwareroot of trust in achain of trust, but once configured, users are denied the freedom to replace the bootloader with the one they want without the use of boot ROMexploits. Because of this, the feature has raised strong concerns from the free software community.[4]
Just before jumping to the bootloader, some systems on a chip also remove the boot ROM from thememory mapping, while others do not, making it possible to dump the boot ROM for lateranalysis.[3] If the boot ROM is still accessible, bootloaders can also call the code of the boot ROM (which is sometimes documented).
When asystem on a chip (SoC) enterssuspend-to-RAM mode, in many cases, the processor is completely off while the RAM is put in self-refresh mode. At resume, the boot ROM is executed again and many boot ROMs are able to detect that the SoC was in suspend-to-RAM mode and can resume by jumping directly to thekernel which then takes care of powering on again the peripherals which were off and restoring the state that the computer was in before.
On many Allwinnersystems on a chip (A10, A20, A64), the boot ROM either waits for abootloader to be loaded through USB (if a specific PIN is high) or tries to boot on several peripherals in a fixed order.[5]
Some Allwinner systems on a chip can verify the signature of the booloaders.[6] But most devices being manufactured are not configured for that. This has enabledfree and open-source software to add support for many Allwinner systems on a chip and devices using them inbootloaders likeU-Boot.[7]
OniPhone,iPad,Apple Watch,iPod Touch, andApple TV devices, the boot ROM is called "SecureROM"[8] It is a stripped-down version ofiBoot. It provides aDevice Firmware Upgrade (DFU) mechanism, which can be activated using a special button combination.[9]
The boot ROM of NXPsystems on a chip (SOCs) support configuring the peripherals through specific pins of the system on a chip. On the i.MX6 family it also supports configuring the boot order througheFuses.
The boot ROM of several NXP SoCs have many ways to load the first stagebootloader (from eMMC, microSD, USB, etc.).
Several NXP SoCs can be configured to verify the signature of the bootloaders. Many devices with such SoCs were sold without that verification configured and on those devices users can install the bootloader they want, including severalfree and open-source softwarebootloaders likeDas U-Boot[10] andBarebox.
The boot ROMs of several Texas Instrumentssystems on a chip support configuring the peripherals through specific pins of the system on a chip. They have many ways to load the first stagebootloader (which is called MLO in the systems on a chip reference manuals):
On the OMAP36xx system on a chip, the boot ROM looks for the first stage bootloader at the sectors 0x0 and 0x20000 (128KB),[11] and on the AM3358system on a chip,[12] it additionally looks at 0x40000 (256KiB) and 0x60000 (384KiB). In both cases its maximum size is 128KiB. This is because the (first stage) bootloader is loaded in anSRAM that is inside the system on a chip.
The OMAP and AM335x systems on a chip can be configured to verify the signature of the bootloaders. Many devices with such system on a chip were sold without verification configured and on those devices users can install the bootloader they want, including severalfree and open-source software bootloaders likeDas U-Boot[13] andCoreboot[14] andBarebox.
STMicroelectronicsSTM32 familymicrocontrollers have embedded ROM (also referred as "on-chip ROM") calledsystem memory[15] to facilitate empty system flashing. Certain pin combinations or sometimes efuses and/or empty flash checks force the chip to boot from ROM instead of the firmware in main flash. This allows empty chips to be flashed without resorting to hardware programming interfaces. Technically this ROM is stored in a dedicated area of the flash array and programmed by ST during production. Most STM32 microcontrollers can at least be flashed over UART, some support USB and eventually other interfaces like e.g.I2C,SPI, orCAN. TheCortex-M core normally fetches vectors from the well-known addresses 0x00000000 (initialstack pointer value) and 0x00000004 (initialprogram counter value). However pins and/or fuses define which memory is mapped at these addresses. System memory is one of the mapping options, another would typically be main firmware in flash. In this case, firmware is supposed to do all the jobs boot ROMs do; part of the firmware could act as a bootloader similar to ST's boot ROM. Hardware could provide read-only enforcement on the boot area, turning it into a user-provided version of boot ROM.
On devices runningiOS, boot ROM exploits (like the limera1n,[16] alloc8,[17] and checkm8[8][16] exploits) are sometimes used foriOS jailbreaking. The advantage for people wanting to jailbreak their devices over exploits that affectiOS is that since the boot ROM cannot be modified—and that devices runningiOS do not have fuses to append code to the boot ROM, Apple cannot fix the vulnerability on existing devices.
The boot ROM of theTegra SoC ofNvidia (used by theNintendo Switch) contained a vulnerability which made it possible for users to run thebootloader they want.[18][19]
| Processes |  | ||||||
|---|---|---|---|---|---|---|---|
| Bootingfirmware |
| ||||||
| Hybrid firmware bootloader | |||||||
| Bootloaders |
| ||||||
| Partition layouts | |||||||
| Partitions | |||||||
| Utilities |
| ||||||
| Network boot | |||||||
| ROM variants | |||||||
| Related | |||||||