Editing Booting (section)

== SoCs, embedded systems, microcontrollers, and FPGAs ==
{{Anchor|SPL}}
[[File:Bootloader Android HTC Pico.JPG|right|thumb|An [[unlocked bootloader]] of an [[Android (operating system)|Android]] device, showing additional available options]]

Many modern CPUs, SoCs and microcontrollers (for example, [[Texas Instruments|TI]] [[OMAP]]) or sometimes even [[digital signal processors]] (DSPs) may have a boot ROM integrated directly into their silicon, so such a processor can perform a simple boot sequence on its own and load boot programs (firmware or software) from boot sources such as NAND flash or eMMC. It is difficult to hardwire all the required logic for handling such devices, so an integrated boot ROM is used instead in such scenarios. Also, a boot ROM may be able to load a boot loader or diagnostic program via serial interfaces like [[UART]], [[Serial Peripheral Interface Bus|SPI]], [[USB]] and so on. This feature is often used for system recovery purposes, or it could also be used for initial non-volatile memory programming when there is no software available in the non-volatile memory yet. Many modern microcontrollers (e.g. flash memory controller on [[USB flash drive]]s) have firmware ROM integrated directly into their silicon.

Some [[embedded system]] designs may also include an intermediary boot sequence step. For example, [[Das U-Boot]] may be split into two stages: the platform would load a small SPL (Secondary Program Loader), which is a stripped-down version of U-Boot, and the SPL would do some initial hardware configuration (e.g. [[DRAM]] initialization using CPU cache as RAM) and load the larger, fully featured version of U-Boot.<ref>{{cite web |url=http://processors.wiki.ti.com/index.php/The_Boot_Process |title=Overview – The four bootloader stages |date=2013-12-05 |access-date=2015-01-25 |publisher=[[Texas Instruments]] |website=ti.com |archive-date=2014-12-23 |archive-url=https://web.archive.org/web/20141223025158/http://processors.wiki.ti.com/index.php/The_Boot_Process |url-status=live}}</ref> Some CPUs and SoCs may not use CPU cache as RAM on boot process, they use an integrated boot processor to do some hardware configuration, to reduce cost.<ref>{{cite web |url=https://rxos.readthedocs.io/en/develop/how_it_works/boot.html |title=The boot process rxos 1.0rc1 documentation |access-date=2015-10-25 }}</ref>

It is also possible to take control of a system by using a hardware debug interface such as [[JTAG]]. Such an interface may be used to write the boot loader program into bootable non-volatile memory (e.g. flash) by instructing the processor core to perform the necessary actions to program non-volatile memory. Alternatively, the debug interface may be used to upload some diagnostic or boot code into RAM, and then to start the processor core and instruct it to execute the uploaded code. This allows, for example, the recovery of embedded systems where no software remains on any supported boot device, and where the processor does not have any integrated boot ROM. JTAG is a standard and popular interface; many CPUs, microcontrollers and other devices are manufactured with JTAG interfaces ({{as of|2009|lc=true}}).{{citation needed|date=September 2023}}

Some microcontrollers provide special hardware interfaces which cannot be used to take arbitrary control of a system or directly run code, but instead they allow the insertion of boot code into bootable non-volatile memory (like flash memory) via simple protocols. Then at the manufacturing phase, such interfaces are used to inject boot code (and possibly other code) into non-volatile memory. After system reset, the microcontroller begins to execute code programmed into its non-volatile memory, just like usual processors are using ROMs for booting. Most notably this technique is used by [[Atmel AVR]] microcontrollers, and by others as well. In many cases such interfaces are implemented by hardwired logic. In other cases such interfaces could be created by software running in integrated on-chip boot ROM from [[GPIO]] pins.

Most DSPs have a serial mode boot, and a parallel mode boot, such as the host port interface (HPI boot).

In case of DSPs there is often a second microprocessor or microcontroller present in the system design, and this is responsible for overall system behavior, interrupt handling, dealing with external events, user interface, etc. while the DSP is dedicated to signal processing tasks only. In such systems the DSP could be booted by another processor which is sometimes referred as the ''host processor'' (giving name to a Host Port). Such a processor is also sometimes referred as the ''master'', since it usually boots first from its own memories and then controls overall system behavior, including booting of the DSP, and then further controlling the DSP's behavior. The DSP often lacks its own boot memories and relies on the host processor to supply the required code instead. The most notable systems with such a design are cell phones, modems, audio and video players and so on, where a DSP and a CPU/microcontroller are co-existing.

Many [[FPGA]] chips load their configuration from an external configuration ROM, typically a serial EEPROM, on power-up.