Android源码编译（四）----------->Beagleboard-xm — Initialization & x-load (DM3730 process)

1, General boot process and device

The initialization process for OMAP Dm37x beagleboard:

• Preinitialization
• Power/clock/reset ramp sequence
• Boot ROM
• Boot Loader
• OS/application

Six external pins(sys_boot[5:0]) are used to select interfaces or devices for booting. The interfaces are GPMC, MMC1, MMC2, USB and UART.

The ROM code has two booting functions: peripheral booting and memory booting:

• In peripheral booting, the ROM code pools a selected communication interface such as UART or USB, downloads the executable code over the interface, and execute it in internal SRAM. Downloaded software from an external host can be used to program flash memories connected to the device.
• In memory booting, the ROM code finds bootstrap in permanent memories such as flash memory or memory cards and executes it. The process is normally performed after cold or warm device reset.

Overall boot sequence is as follows:

Following is 32K SRAM memory map of GP device, which is used only during the booting process.

Beagleboard-xm is OMAP3, so use 64K SRAM which range is 40200000-4020FFFF.

2, Boot from MMC/SD card

In general, beagleboard-xm uses memory booting from MMC/SD card, because this board does not have NAND device. There are some limitations as follows:

• Supports MMC/SD cards compliant with the Multimedia Card System Specification v4.2 from the MMCA Technical Committee and the SD I/O Card Specification v2.0 from the SD Association. Includes high-capacity (size >2GB) cards: HC-SD and HC MMC
• 3-V power supply, 3-V I/O and 1.8-V I/O voltages on port 1
• Supports eMMC/eSD (1.8-V I/O voltage and 3.0-V Core voltage) on port 2. The external transceiver mode on port 2 is not supported.
• Initial 1-bit MMC mode, 4-bit SD mode
• Clock frequency:
              –   Identification mode: 400 kHz
              –   Data transfer mode: 20 MHz
• Only one card connected to the bus 
• Raw mode, image data read directly from card sectors 
• FAT12/16/32 support, with or without a master boot record (MBR). 
• For a FAT (12/16/32)-formatted memory card, the booting file must not exceed 128 KB.
• For a raw-mode memory card, the booting image must not exceed 128 KB.  

The image used by the booting procedure is taken from a booting file named MLO. This file must be in the root directory on an active primary partition of type FAT12/16 or FAT32.

An MMC/SD card can be configured as floppy-like or hard-drive-like:

• When acting like a floppy, the content of the card is a single FAT12/16/32 file system without an MBR holding a partition table.
• When acting like a hard drive, an MBR is present in the first sector of the card. This MBR holds a table of partitions, one of which must be FAT12/16/32, primary, and active.

3, MLO image format

For a GP device, the image is simple and must contain a small header having the size of the software to load and the destination address of where to store it when a booting device is other than XIP. The XIP device image is even simpler and starts with executable code.



4, x-load

4.1 Why uses x-load

As above mentioned, the SRAM in beagleboard-xm is very tiny as 64K, the u-boot image size is almost 196K, so beagleboard-xm can not use u-boot as MLO. The x-load is used here, which can be considered as u-boot loader, and it’s size is around 24K.

4.2 How to build x-load

• Get mainline x-load source code from

git clone git://gitorious.org/x-load-omap3/mainline.git

• Get/Install ARM compiler from http://www.codesourcery.com/sgpp/lite/arm/portal/subscription?@template=lite
• Build

make CROSS_COMPILE=arm-none-linux-gnueabi- omap3530beagle_config

make CROSS_COMPILE=arm-none-linux-gnueabi-
       Although beagleboard-xm use DM3735 process, there is updated config file in x-load mainline’s tree. So it is ok for reuse omap3530beagle_config file.

• Generate MLO file

After building, x-load.bin is generated as raw executable binary. As above mentioned about non-XIP image format, the size and address should be added at image’s first 16 bytes. So use signGP scipt to do it. The source code of signGP ishttp://beagleboard.googlecode.com/files/signGP.c

4.3 x-load’s research

4.3.1 memory map

In beagleboard-xm, ROM code will load x-load binary into SRAM (0×4020000 ~ 0x4020FFFF) 64K range. The range is allocated as follows:

Runtime stack: 0×4020000 ~ 0x40207FFF

MLO                : 0×4020800 ~ 0x4020FFFF

please reference board\omap3530beagle\config.mk for TEXT_BASE setting:

   1: # For XIP in 64K of SRAM or debug (GP device has it all availabe)

   2: # SRAM 40200000-4020FFFF base

   3: # initial stack at 0x4020fffc used in s_init (below xloader).

   4: # The run time stack is (above xloader, 2k below)

   5: # If any globals exist there needs to be room for them also

   6: TEXT_BASE = 0x40200800

Please reference cpu\omap3\start.S for stack pointer setting:

   1: /* Set up the stack  */

   2: stack_setup:

   3:     ldr    r0, _TEXT_BASE        /* upper 128 KiB: relocated uboot   */

   4:     sub    sp, r0, #128        /* leave 32 words for abort-stack   */

   5:     and    sp, sp, #~7        /* 8 byte alinged for (ldr/str)d    */

Because the x-load is non-XIP code, so TEXT_BASE is passed to compiler:

arm-none-linux-gnueabi-gcc -Wa,-gstabs -D__ASSEMBLY__ -g  -Os   -fno-strict-aliasing  -fno-common -ffixed-r8  -D__KERNEL__ -DTEXT_BASE=0×40200800 -I/home/ken/bb/x-load/mainline/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/i486-linux-gnu/4.4.3/include -pipe  -DCONFIG_ARM -D__ARM__ -march=armv7-a  -c -o cpu/omap3/start.o /home/ken/bb/x-load/mainline/cpu/omap3/start.S

 

4.3.2 startup process

1. The boot is started from cpu\omap3\start.S and the first instruction is reset vector.
2. set cpu mode to Supervisor (SVC) 32 bit mode.
3. Copy vectors to indirect address 0x4020F800 (SRAM_OFFSET0 + SRAM_OFFSET1 + SRAM_OFFSET2)
4. relocates clock code into SRAM where its safer to execute
5. Initialize CPU
   1. Invalidate instruction, L2 cache, and invalidate TLBs, disable MMU
   2. Initialize SRAM stack at 0x4020FFFC, so can use C code now.
   3. In C code s_init do some early initialization such watchdog,  configure SDRAM.
6. Relocate code section
7. Set runtime stack
8. Clear bss section for uninitialization value.
9. Jump to C code start_armboot().
   1. Initialize the serial device
   2. print version information like

      Texas Instruments X-Loader 1.4.4ss

   3. Initialize I2C which base address is 0×48070000 in L4 core.
   4. reading GPIO173, 172, 171 to determin the version of beagleboard then print it, for beagleboard-xm board, the value should be 0, 0, 0
   5. Initialize MMC card and load u-boot.bin from MMC card into pop SDRAM 0×80008000
      1. If no MMC found, try to boot from onenand or nand, but beagleboard-xm does not has these devices
      2. try to boot from serial ……
   6. Jump to 0×80008000, over for x-load.

4.3.3 x-load vs EFI’s SEC phase

So we can see the x-load is very like SEC phase in UEFI specification, in Intel’s tiano implementation, the SEC phase mainly:

• Enter protect mode
• Prepare early C stack in CAR, the CAR is instruction cache in process for temporary stack/heap, just like Omap’s internal SRAM for boot phase. Unlike SRAM, the CAR will be disabled/destroyed after SEC phase.
• Initialize CPU such as MTRR for flash range.
• Initialize early ACPI timer for performance collection.
• Find the PeiCore from flash and shadow into CAR for PEI phase.

5, Reference
=======
1) DM37x Multimedia Device Silicon Revision 1.x