Unlike simple processors where the user's code executes immediately at power on, the AM335x processors feature an internal ROM to offer a variety of choices to start the system. At power on, the internal ROM starts running and looks at the SYSBOOT signals connected to the processor to decide whether to load the user code and to configure the device containing the user code appropriately. The BBB exposes a subset of the available options; this subset can be selected by the user button.
Note that the user button is only checked on power up (not reset!). In the following image, the user button is highlighted. Since the BBW does not have an onboard flash, there is no user button.
Bootloader is the part of the system responsible for loading the operating system. This is similar to the concept of BIOS on desktop systems. By default, if the user button is not depressed, the processor will attempt to boot from the onboard flash on the BBB. The processor will configure the flash to access and look for a special file called MLO on the first partition. The MLO file contains a first stage bootloader along with a checksum to let the ROM know that it is valid code. If the checksum is valid, the contents are copied to the internal memory and the processor will attempt to execute from there. The first stage bootloader's size is limited by the size of the internal memory.
The job of the first stage bootloader is to configure the external (DDR2/DDR3) memory and read in the second stage bootloader into the external memory and pass control. On a standard BBB system, this will load u-boot.img from the same location as MLO. The
u-boot.img file is the main code for U-Boot—the main bootloader.
Once U-Boot is running, it will configure additional hardware as needed. On a standard system, it will attempt to load a configuration defined by u-env.txt in the same partition as the rest. Using that information, it will attempt to load and start Linux from the specified media such as the onboard flash. The standard U-Boot (as shipped) will check for an external microSD card. If present, it will load the Linux kernel from there instead of the internal flash. The following flowchart shows the boot process and how it is changed by the user button:
The internal flash memory is normally divided into two partitions:
The first partition contains the
MLO,u-env.txt, andu-boot.imgfiles, and sometimes the Linux kernelThe second partition contains the Linux filesystem
For a lot of projects, the second partition is the only part that is typically modified and is the partition that is most likely to be corrupted due to user errors. The first partition is not often corrupted due to user errors. From a recovery standpoint, this can be addressed as simply as inserting a configured microSD card and allowing the system to boot! For the microSD card, such as on the BBW, things are analogous as the flash memory used on the BBB is embedded MMC (eMMC). eMMC is basically the same microSD card permanently mounted on the board.
On a standard system, the onboard LEDs have a pattern to indicate whether things have got as far as loading the Linux kernel. This is a function of the U-Boot configuration.
If the user button is pressed again when power is applied, the BBB will look for the same MLO file on the external microSD card. If the file is found and the checksum matches, it will attempt the same boot process as explained earlier but using the external SD card. This is useful if the bootloader itself is corrupted.
A more advanced booting method is possible if the user button is pressed at power on. The BBB is capable of downloading a bootloader over the serial port or the USB device port.