It is often easier to implement routines 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.
[citation needed] At the end of the hardware initialization, the boot ROM will try to load a bootloader from external peripheral(s) (such as a hard disk drive or solid-state drive, an eMMC or eUFS card, a microSD card, an external EEPROM, and so on) or through specific protocol(s) on a communications port (such as a serial port or Ethernet, etc.).
With some boot ROMs the hash of the public key needed to verify the signatures is encoded in electronic fuses inside the system on a chip.
At resume, the boot ROM is executed again and many boot ROMs are able to detect that the SoC was in suspend to RAM and can resume by jumping directly to the kernel which then takes care of powering on again the peripherals which were off and restoring the state that the computer was in before.
This has enabled free and open-source software to add support for many Allwinner systems on a chip and devices using them in bootloaders like U-Boot.
It provides a Device Firmware Upgrade (DFU) mechanism, which can be activated using a special button combination.
The boot ROM of several NXP SoCs have many ways to load the first stage bootloader (from eMMC, microSD, USB, etc.).
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 several free and open-source software bootloaders like Das U-Boot[13] and Coreboot[14] and Barebox.
Technically this ROM is stored in a dedicated area of the flash array and programmed by ST during production.
The boot ROM of the Tegra SoC of Nvidia (used by the Nintendo Switch) contained a vulnerability which made it possible for users to run the bootloader they want.