原文地址 ： http://omappedia.org/wiki/Bootloader_Project
SYSBOOT Pins
The internal ROM Code can attempt to boot from several different peripheral and memory devices, including, but not limited to: Serial (UART3), SD Card, eMMC, NAND, and USB. The order in which these devices are searched for a valid first-stage booting image (x-loader) is determine by a set of GPIO configuration pins referred to as SYSBOOT. The TRM includes a table that shows the booting device list that each combination of the SYSBOOT pins refers to.
The SYSBOOT value can be read from physical address 0x480022f0, either using JTAG, or if you have linux running, use devmem2:
固化在芯片的程序可以從多種介質上啓動，配置SYSBOOT Pins修改啓動順序。First Stage Boot
For example, the SYSBOOT pins could be set such that booting device list consists of 1) serial (UART3), 2) SD card (MMC1), and 3) NAND flash. In this case, the ROM code would first look for a valid x-loader over the serial port, then in the SD card, then in the NAND flash. Whenever it finds a valid x-loader, it proceeds with execution of that binary.
Serial Boot
For serial boot, a simple ID is written out of the serial port. If the host responds correctly within a short window of time, the ROM will read from the serial port and transfer the data to the internal SRAM. Control is passed to the start of SDRAM if no errors are detected. UART3 is the only uart for which the ROM will attempt to load from.
SD Card Boot
If MMC is included in the booting device list, the ROM looks for an SD Card on the first MMC controller. If a card is found, the ROM then looks for the first FAT32 partition within the partition table. Once the partition is found, the root directory is scanned for a special signed file called "MLO" (which is the x-loader binary with a header containing the memory location to load the file to and the size of the file). Assuming all is well with the file, it is transfered into the internal SRAM and control is passed to it. Both MMC1 and MMC2 can be used for booting.
如果MMC在啓動設備列表中，ROM 通過1號MMC控制器尋找SD卡，如何識別到SD卡，在SD卡的第一個FAT32分區上尋租MLO文件，如果MLO文件存在，將其複製到內部SRAM中並啓動MLO程序。
NAND / eMMC Boot
If NAND is included in the booting device list, the ROM attempts to load the first sector of NAND. If the sector is bad, corrupt, or blank, the ROM will try the next sector (up to 4) before exiting. Once a good sector is found, the ROM transfers the contents to SRAM and transfers control to it. (The same steps are performed for eMMC if eMMC is included in the booting device list instead of NAND.)
x-loader
The x-loader is a small first stage bootloader derived from the u-boot base code. It is loaded into the internal static RAM by the OMAP ROM code. Due to the small size of the internal static RAM, the x-loader is stripped down to the essentials. The x-loader configures the pin muxing, clocks, DDR, and serial console, so that it can access and load the second stage bootloader (u-boot) into the DDR. This figure shows the code flow in the x-loader, beginning in start.S.x-loader是一個運行在內部SRAM的程序，它負責外部pin、DDR、串口等設備的初始化，並將二級引導程序（例如u boot）複製到DDR中執行。
u-boot
The u-boot is a second stage bootloader that is loaded by the x-loader into DDR. It comes from Das U-Boot. The u-boot can perform CPU dependent and board dependent initialization and configuration not done in the x-loader. The u-boot also includes fastboot functionality for partitioning and flashing the eMMC. The u-boot runs on the Master CPU (CPU ID 0), which is responsible for the initialization and booting; at the same time, the Slave CPU (CPU ID 1) is held in the “wait for event” state. This figure shows the code flow in the u-boot, beginning in start.S.U boot是二級引導程序，它運行在主CPU（CPU ID 爲0）上，從CPU（CPU ID 爲1）被掛起。
編譯x-loader 和 U boot
http://omappedia.org/wiki/Android_Panda_Build_Source#Building_the_kernel_from_source
git clone git://git.linaro.org/boot/u-boot-linaro-stable.git
cd u-boot-linaro-stable.git
make CROSS_COMPILE=arm-none-linux-gnueabi- omap4_panda
# Replace the CROSS_COMPILE with the name of your compiler（將MLO u-boot.bin複製到SD 的第一個FAT32分區,我的pandaboard是 Pandaboard ES Rev B1,使用上訴方法可以正常引導linux kernel）