Embedded Linux - Booting phases

I would like to systematize my U-Boot/linux knowledge. Is it true that minimum 2 bootloader phases are needed in each embedded platform? Or can following process vary?

1. 1st-stage b开发者_JAVA技巧ootloader (can be U-Boot) is stored in internal the processor's ROM and can't be updated. It will run from internal cache memory. This U-Boot needs to (at least): initialize RAM, initialize external flash, initialize serial console, read and run 2nd-stage bootloader.

2. 2nd-stage bootloader (can be U-Boot) is stored in RW flash memory. It will handle ethernet, flash RW functions, etc. This U-Boot can be customized and overwritten. Main task is to load linux kernel into RAM and run it.

3. linux kernel startup.

Is 1st-stage bootloader always Read-Only?

Where, how that first bootloader is is heavily system dependent. You might have some sort of usb bootable device that enumerates and downloads firmware to ram all in hardware then the processor boots from that ram.

Normally yes the first boot is some sort of flash. It is a good idea to have that first bootloader uber simple, essentially 100% bug free and durable and reliable with perhaps a serial or other way to get in so that you can use it to replace the second/real bootloader.

Ideally the second bootloader wants to be flash as well, the second bootloader would want to do the bulk of the work, initializing ddr, setting up ethernet if it wants to have some sort of ethernet based debugging or transferring of files, bootp, etc. Being significantly larger and more complicated it is expected to both have bugs and need to be upgraded more often than the primary bootloader. The primary is hopefully protected from being overwritten, so that you can comfortably replace the second bootloader without bricking the system.

Do all systems use the above? No, some/many may only use a single bootloader, with there perhaps being a pause very early so that a keystroke on a serial port can interrupt the bootloader taking you to a place where you can re-load the bootloader. Allowing for bootloader development with fewer chances at bricking but still a chance if you mess up that first bit before and including the keystroke and serial flash loader thing. Here again that serial loader thing is not always present, just a convenience for the bootloader developers. Often the fallback will be jtag, or a removable prom or some other system way to get in and reprogram the prom when you brick it (also, sometimes the same way you program it the first time in system when the board is produced, some designs are brickable to save on cost and use pre-programmed flashes during manufacturing so the first boot works).

A linux bootloader does not require any/all of this, a very very minimal, setup ram, prep the command line or atags or whatever and branch to linux.

It is a loaded question as the answer is heavily dependent on your system, processor, design engineers (including you). Traditionally processors boot from flash and the bootloader gets memory and some other things up so the next bit of code can run. That next bit of code can come from many places, usb, disk, flash/rom, ethernet/bootp/tftp, pcie, mdio, spi, i2c, etc. And there can be as many layers between power on reset and linux starting as the design desires or requires.

The first-stage bootloader doesn't have to be read-only - but putting a read-only bootloader in ROM with some recovery mode is helpful in case you corrupt the read-write parts of flash; otherwise you'll need to physically attach a programmer to the flash chip in order to recover.

If you are using U-Boot, the 2nd stage bootloader can be skipped to speed up the boot time. In other words, the first stage bootloader (SPL) will load the Linux kernel directly, skipping the second stage bootloader (u-boot). In U-Boot, this is called the Falcon Mode.