Overview of Embedded ROM Flashing Processes and Online Programming Techniques

The article begins by defining common terms in embedded development: upgrade refers to post‑sale ROM system software updates via the product’s own upgrade function; burning (or programming) is the earliest concept, originating from one‑time programmable PROM where voltage‑fuse devices were used; flashing is a mobile‑industry term meaning to replace or modify the phone’s existing operating system, i.e., reinstalling the system. In daily communication, burning and flashing have become nearly synonymous.

Factory production line burning is divided into two methods: burner burning and online burning. Burner burning occurs before SMT, using a chip programmer to write software into Flash, eMMC or UFS chips. Manual programmers allow adapter changes for different ROM types and interfaces, suitable for engineering verification or small‑batch production; automatic programmers enable parallel programming for higher efficiency. This approach uses the chip interface directly, offering fast speed and high stability, but requires costly programmers and adapters, plus development of specific drivers (e.g., NAND Flash ECC OOB data, bad‑block management). Online burning, also called board‑level burning, programs the chip after it is soldered onto the PCB via SMT, using a host machine connected through USB, network cable or UART. It is flexible, suited for frequent software iterations, low‑cost, and easy to scale; most phone manufacturers adopt online burning on their production lines.

The online burning process relies on a burning program sent from the host to the embedded target. The host transfers the burning program, which then receives the burning image and writes it to ROM. Prior to this, the article explains related boot concepts: BootRom (on‑chip, immutable after chip manufacture) executes first after power‑on; SPL (Secondary Program Loader) initializes DRAM and relocates the Bootloader to DRAM for execution; Bootloader consists of two stages, the first running in SOC SRAM (SPL) and the second in external DRAM. The typical sequence is BootRom → SPL → Bootloader.

The phone’s online flashing procedure is outlined: (1) SOC powers on, executes BootRom, detects an empty ROM, enumerates the USB port and attempts to receive data; (2) BootRom receives the burning program via USB and loads it into on‑chip SRAM for execution; (3) The burning program receives the burning image via USB and writes it into ROM.

Most SOC vendors integrate the burning program into the Bootloader. For example, Qualcomm’s Firehose runs in SPL (limited by SRAM size), while MediaTek’s DA is similar to U‑Boot and executes in the second Bootloader stage in DDR. The article then analyzes U‑Boot’s implementation: the linker script defines internal SRAM and external DDR memory regions; the start.o .text section is placed first, making _start the SPL entry point. Key steps include setting the exception register (vbar_elx), disabling IRQ/FIQ, low‑level initialization (setting SP to SRAM), board_init_f (clock, DRAM init, BSS clearing, copying U‑Boot to DRAM), and board_init_r (running in external DRAM, further ROM initialization, building a dynamic memory pool, entering an instruction loop that performs ROM chip burning). U‑Boot provides burning commands such as sf (SPI Flash), mmc (eMMC), ufs and scsi (UFS).

Because the burning program requires BootRom guidance, only SOCs with integrated on‑chip BootRom support online burning. Early SOCs lacked BootRom and needed external NOR Flash for boot, increasing hardware and software costs; later SOCs integrated on‑chip BootRom as NAND Flash, eMMC and UFS became prevalent.

The article discusses security measures to prevent unauthorized system tampering. Vendors provide secure boot solutions; burning program security mirrors Bootloader security, commonly using RSA or ECDSA signatures. Mobile SOCs mostly adopt ECDSA for its speed and higher security. The burning program signature process involves hashing (MD5, SHA‑256) and encryption (RSA/ECC). Before shipment, the SOC burns efuse and a root key; BootRom checks efuse configuration, uses the root key to verify the public‑key certificate, then validates the image signature with the public key.

Integrity of the burning process is ensured by hash verification. The burning step is early in the production line; to maintain efficiency and prevent tampering, the written image is compared with the expected image via hash checks.

Common problems in online burning are examined: (1) Burning program fails to load/run – causes include SecureBoot rejecting unsigned programs (USB returns a signature error packet), SPL size exceeding allocated memory (no USB response after receiving the program), or hardware faults (SOC, DDR) that prevent any USB traffic; diagnostics use USB sniffers (Bus Hound, Wireshark). (2) Intermittent USB port disconnection during production – causes include worn USB cables, over‑current protection triggering when many devices draw high current simultaneously. Mitigation: replace cables, test USB current changes before mass production, disable battery charging during burning, use external fixtures to power the PCB, thereby reducing USB current spikes.

The evolution of embedded ROM is traced from the 1956 invention of PROM by engineer Wenjun Zhou to modern UFS, capacity growing from a few kilobytes to hundreds of gigabytes. For XIP (execute‑in‑place) programs, NOR Flash is required; otherwise NAND Flash suffices. Both use MOS transistors as storage cells; NOR Flash cells are parallel‑connected to the bit line allowing random access, while NAND Flash cells are series‑connected, requiring whole‑page reads into RAM before CPU execution. eMMC and UFS are built on NAND Flash with integrated controllers. eMMC uses an MMC bus interface and partitions into Boot Area (Bootloader), RPMB (Replay Protected Memory Block for sensitive data like passwords, fingerprints, IMEI), and User Data Area. UFS employs a MIPI interface, supports SCSI command sets, and divides internal storage into independent Logical Units each with its own address space.

Conclusion: Online flashing is favored by phone manufacturers for its low cost and suitability for mass production. Burning speed and stability are key production concerns; speed is limited by the interface (e.g., USB 2.0 < 35 MB/s) and can be improved via DMA, data‑summarization optimizations, or image compression/decompression on the phone side. Stability is affected by SMT quality, fixtures, cable wear, and host‑machine USB controller stability; power‑surge mitigation via proper power‑supply design and host‑side burning‑state monitoring with rapid reset/re‑flash reduces manual intervention and boosts efficiency.