Bootloader Project
Bootloader Project
From OMAPpedia
Jump to: navigation, search
[edit] OMAP Bootloader Overview
There are several stages of bootloaders that perform different levels of initialization on an OMAP platform, in order to eventually load and run the filesystem. This figure shows the booting sequence of the ROM code, x-loader, u-boot,
and kernel, with each stage performing enough configuration in order to load and execute the next.
The Bootloader Project covers specifically the x-loader and the u-boot: a code overview, and how to obtain and build the code.
Why are there two bootloaders? The first bootloader, x-loader, is a stripped-down version of the u-boot, designed to run in OMAP's small on-chip SRAM. It initializes the main off-chip memory of the system and other necessary device
drivers, and then loads the larger bootloader for Linux, u-boot.
[edit] OMAP Boot Sequence
Detailed documentation on the OMAP boot sequence is available in the OMAP TRM, Initialization chapter. The TRMs for multiple OMAP platforms (OMAP4430, OMAP4460, OMAP34xx, etc) are available here:
http://www.ti.com/general/docs/wtbu/wtbudocumentcenter.tsp?templateId=6123&navigationId=12037
[edit] 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:
# devmem2 0x480022f0 b /dev/mem opened. Memory mapped at address 0x40020000. Value at address 0x480022F0 (0x400202f0): 0x2F
For OMAP34xx, there is also a tool to show the boot order:
omap34xx-boot-order
[edit] 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.
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.)
[edit] Second Stage Boot
It is the job of the x-loader to transfer the 2nd stage loader into main memory, which we call the u-boot. Typically both the x-loader and u-boot come from the same storage medium. For example, typically if the x-loader is transferred
via USB, the u-boot will also be transferred via USB, and if the x-loader is transferred via SD card, the u-boot will also be transferred via SD card. However, this is not required. For example, you could flash the serial x-loader into the NAND. The ROM code
will load the x-loader from NAND and transfer control to the x-loader, which will wait for the u-boot to be downloaded from the serial port.
Serial Boot
In the case of loading both the u-boot over the serial port, the x-loader waits for the host to initiate a kermit connection to reliably transfer large files into main memory. Once the file transfer is completed successfully, control
is transfered.
SD Card Boot
In the case of loading the u-boot via the SD card, the SD card x-loader looks for a FAT32 partition on the first MMC controller and scans the top level directory for a file named "u-boot.bin". It then transfers the file into main
memory and transfers control to it.
NAND / eMMC Boot
In the case of a u-boot stored in NAND, the x-loader expects the u-boot to be located at the 5th sector (offset 0x00800000). It transfers the image from NAND into main memory and transfers control to it. In the case of a u-boot stored
in eMMC, the x-loader expects the u-boot to be located at the offset 0x200.
[edit] x-loader overview
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.
[edit] u-boot overview
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.
[edit] Building the Bootloaders
The following steps will build the x-loader and u-boot.
Note: In order to build the x-loader or u-boot, it is recommended that you use the omappedia Release Notes page corresponding to the platform you are using (Blaze, Blaze Tablet, Panda, or Zoom) and follow the instructions for that
release: http://www.omappedia.com/wiki/Release_Notes In general, the instructions will be very similar with the following exceptions:
The commit ID used to pull the code from the u-boot and x-loader git trees varies based on the release. It is recommended that you use the correct commit ID corresponding to your release, as this is how the validation is performed.
The config file used to setup the configuration when building the u-boot and x-loader varies based on the platform you are using. See the tables below.
Also, ensure that you have installed the pre-requisite packages for building the bootloaders, namely Git and the CodeSourcery ARM Compiler. These instructions are included in the omappedia Release Notes corresponding to your release.
You can also find the information here:
Git is available for download at git-scm.com. For more details on installing and using git please see this wiki page.
For the CodeSourcery ARM Compiler, visit Support_Tools/Cross_Compilers for further information.
[edit] u-boot
[edit] Downloading u-boot source
Clone the u-boot git tree and checkout the source code corresponding to this release:
# mkdir u-boot # cd u-boot # git clone git://git.omapzoom.org/repo/u-boot.git # git checkout <<commit_ID_for_uboot_in_this_release>>
[edit] Building u-boot
Make the u-boot source code using the correct config file depending on your platform:
# cd u-boot # make distclean # make CROSS_COMPILE=arm-none-linux-gnueabi- <<config_file_depending_on_your_platform>> # make CROSS_COMPILE=arm-none-linux-gnueabi-
u-boot config files
Board | config file |
44xx Blaze Tablet | omap44XXtablet_config |
44xx Blaze | omap4430sdp_config |
3430SDP | omap3430sdp_config |
3630SDP | omap3630sdp_config |
3430LDP | omap3430labrador_config |
Zoom2 | omap3430zoom2_config |
Zoom3 | omap3630zoom3_config |
2430sdp | omap2430sdp_config |
2420h4 | omap2420h4_config |
The resulting u-boot.bin is located in the top-level of your u-boot directory.
[edit] x-loader
[edit] Accessing x-loader source
Clone the x-loader git tree and checkout the source code corresponding to this release:
# cd x-loader # git clone git://git.omapzoom.org/repo/x-loader.git # git checkout <<commit_ID_for_xloader_in_this_release>>
[edit] Building x-loader
Make the x-loader source code using the correct config file depending on your platform:
# cd x-loader # make distclean # make CROSS_COMPILE=arm-none-linux-gnueabi- <<config_file_depending_on_your_platform>> # make CROSS_COMPILE=arm-none-linux-gnueabi- ift
x-loader config files
Board | config file |
44xx Blaze Tablet | omap44XXtablet_config |
44xx Blaze | omap4430sdp_config |
3430SDP | omap3430sdp_config |
3630SDP | omap3630sdp_config |
3630SDP 1GB | omap3630sdp_1G_config |
3430LDP | omap3430labrador_config |
Zoom2 | omap3430zoom2_config |
Zoom3 | omap3630zoom3_config |
2430sdp | omap2430sdp_config |
2420h4 | omap2420h4_config |
To build x-loader to boot over a serial connection for OMAP3, use "omap3430labradordownload_config"
The resulting MLO is located in the top-level of your x-loader directory.
Note: If you are using an HS (High Security) OMAP device, an extra step is required. First, build x-load.bin using the steps above. Then, download the MShield signing tool and use the commands below. Contact your TI representative
to get access to this tool.
# cd mshield-dk-root-folder # ./generate_MLO <<OMAP type>> x-load.bin
For example, for an ES2.3 OMAP4430 device, use the command:
# ./generate_MLO OMAP4430 ES2.3 x-load.bin
The resulting MLO is located in the top-level of your mshield-dk directory.
[edit] Flashing
Refer to Android_Fastboot to review flashing methods for Blaze and Blaze Tablet using Fastboot.
Refer to Zoom Flashing to review flashing methods for Zoom1/Zoom2/Zoom3.
Refer to 3630SDP Flashing to review flashing methods for 3630SDP board.
Refer to eMMC Boot to review flashing and boot methods from eMMC device.
Refer to [[1]] for a USB downloader for PandaBoard.
[edit] Upstreaming U-boot
U-boot upstreaming is being carried out as a separate project. Please refer to the following link for more details.
Bootloader Project的更多相关文章
- QEMU 模拟运行 VxWorks 6.6
QEMU 模拟运行 VxWorks 6.6 项目简介 本项目是在 Windows 系统编译运行 X86 平台 VxWorks 6.6 系统,使用的模拟软件是 qemu for Windows Host ...
- make 实例 二 V56
######################################################################### # # Makefile used for buil ...
- make 实例 一 3463
######################################################################### # # Makefile used for buil ...
- 嵌入式Linux系统Bootloader启动调试技术(回想)
嵌入式系统搭建过程中,对于系统平台搭建project师最初的一步一般是移植Bootloader ,当然移植有几个级别,通常最常见的是參考的EVM 的硬件有了改动(如更改了FLASH ,更改了SDRAM ...
- 智能家居项目(2):项目project框架的搭建
项目管理器: Linux中的项目管理器"make"有些类似于windows中的Visual C++里的"project",它是一种控制编译或者反复编译软件的工具 ...
- AVR之BOOTLOADER技术详解(转)
源:http://blog.csdn.net/zhenhua10/article/details/6442412 ATmega128具备引导加载支持的用户程序自编程功能(In-System Progr ...
- 豹哥嵌入式讲堂:ARM开发之文件详解(3)- project文件
大家好,我是豹哥,猎豹的豹,犀利哥的哥.今天豹哥给大家讲的是嵌入式开发里的project文件. 前面两节课里,豹哥分别给大家介绍了嵌入式开发中的两种典型input文件:source文件.linker文 ...
- 高通平台的bootloader过程【转】
====================基本知识=======================LK是(L)ittle (K)ernel的缩写.高通平台android普遍采用LK作为其bootloade ...
- [国嵌笔记][028][Bootloader设计蓝图]
Bootloader的作用就是启动Linux内核 U-Boot简介 1.U-Boot是用于多种嵌入式CPU(ARM.x86.MIPS等)的bootloader程序,U-Boot不仅支持嵌入式Linux ...
随机推荐
- c# 对象 & 类
类定义中可以使用的访问修饰符组合 none or internal 类只能在当前工程中访问 public 类可以在任何地方访问 abstract or internal abstract 类只能在当前 ...
- JVM类加载机制---类加载器
一.概念 "通过一个类的全限定名来获取描述此类的二进制字节流",实现这个动作的代码模块成为 类加载器. 二.分类 从java开发人员的角度出发,系统提供的类加载器大致分为如下3类: ...
- 51Nod 欢乐手速场1 B 序列变换[容斥原理 莫比乌斯函数]
序列变换 alpq654321 (命题人) 基准时间限制:1 秒 空间限制:131072 KB 分值: 40 lyk有两序列a和b. lyk想知道存在多少对x,y,满足以下两个条件. 1:gcd( ...
- verilog实验3:AD转换后串口输出到PC端
一.实验任务 通过tcl549AD转换芯片将模拟电压信号转换为数字信号,并通过串口显示到电脑上.此AD转换芯片为串行转换芯片,且转换速率要和串口选择的速率匹配.等待串口发送完后,再进行下一次AD转换. ...
- 读论文系列:Object Detection SPP-net
本文为您解读SPP-net: Spatial Pyramid Pooling in Deep Convolutional Networks for Visual Recognition Motivat ...
- 对JavaScript中的静态属性和原型属性的理解
首先是在访问上的区别,当访问实例对象的某个属性但它本身没有时,它就会到原型中去查找,但不会去查找静态属性. // 实例对象不会去查找静态属性 function Foo(){} Foo.a = 1; v ...
- JavaScript之父谈JavaScript
本文翻译自popularity,为了更好的阅读我把部分内容进行了增删改,如果你英语比较好,建议直接阅读原文,因为这篇文章是我通过google翻译再进行修改的. 貌似(根据一位精神导师的说法)JavaS ...
- 怎样在VS2010-2017中使用LightningChart绘图控件?
为了方便开发人员能更快速的使用开发工具,下面给大家提供LightningChart® Ultimate SDK v.8 使用手册: 1. 安装软件 - 运行 setup.exe ...
- GIT_服务器与本地环境构建
linux安装git包 很多yum源上自动安装的git版本为1.7,这里手动编译重新安装1:安装依赖包yum install curl-devel expat-devel gettext-devel ...
- Nginx Rewrite规则详解
Rewrite规则含义就是某个URL重写成特定的URL,从某种意义上说为了美观或者对搜索引擎友好,提高收录量及排名等. Rewrite规则的最后一项参数为flag标记,支持的flag标记主要有以下几种 ...