ARM 开发板SD卡和NAND的启动过程

DM365启动模式介绍

BOOT MODES

  The ARM ROM boot loader(RBL) executes when teh BTSEL[2:0] pins indicate a condition other than the normal ARM EMIF boot.

1. Asynchronous EMIF boot mode(NOR or OneNAND). This mode is handled by hardware control and does not involve the ROM. In the case of OneNAND, the user is responsible for putting any necessary boot code in the OneNAND's boot page. This code shall configure the AEMIF module for the OneNAND device. After the AEMIF module is configured, booting will continue immediately after the OneNAND's boot page with the AEMIF module managing pages thereafter.

2.The RBL supports 7 distinct boot modes:

   (1)NAND Boot mode

   (2)MMC0/SD0 Boot mode

   (3)UART0 Boot mode

   (4)USB Boot mode

   (5)SPI0 Boot mode

   (6)EMAC Boot mode

   (7)HPI Boot mode

其中，启动顺序如下面所示：

If NAND boot fails, then MMC/SD mode is tried.

If MMC/SD boot fails, then MMC/SD boot is tried again.

If UART boot fails, then UART boot is tried again.

If USB boot fails, then USB boot is tried again.

If SPI boot fails, then SPI boot is tried again.

If EMAC boot fails, thenEMAC boot is tried again.

If HPI boot fails, thenHPI boot is tried again.

NOTE:上面只有NAND启动一次，失败后，直接转入MMC/SD，其他模式进入都需要自动启动一次。

RBL shall update boot status (PASS/FAIL) in MISC register bits 8 and 9 in System control module.

下面介绍ARM ROM 启动 --NAND 模式 (仅对NAND和MMC/SD模式介绍)

ARM ROM Boot - NAND Mode

1.No support for a full firmware boot. Instead, copies a second stage User Boot Loader (UBL) from NAND flash to ARM internal RAM (AIM) and transfers control to the user-defined UBL.

2.Support for NAND with page sizes up to 4096 bytes (2M).

3.Support for magic number error detection and retry (up to 24 times) when loading UBL

4.Optional, user-selectable, support for use of DMA and I-cache during RBL execution (i.e, while loading UBL)

5.Supports booting from 8-bit NAND devices (16-bit NAND devices are not supported)

6.Supports NAND flash that requires chip select to stay low during the tR read time

ARM ROM Boot - MMC/SD Mode

1.No support for a full firmware boot. Instead, copies a second stage User Boot Loader (UBL) from MMC/SD to ARM Internal RAM (AIM) and transfers control to the user software.

2.Support for MMC/SD Native protocol (MMC/SD SPI protocol is not supported)

3.Support for descriptor error detection and retry (up to 24 times) when loading UBL

4.Support for up to 30KB UBL (32KB ~2KB for RBL stack)

5.SDHC boot supported by RBL

开发板一上电就会先地址映射，启动原理如下：

(1)pc被置为0,0地址被映射到IROM的起始位置；

(2)此时将开始执行，pc会跳转到SD卡启动的代码处；

(3)将SD卡的前8K代码放到IRAM(SRAM的一种，6410中物理地址0x0c000000~0x0c002000-1,共8K)中；

(4)pc指向IRAM的起始地址0x0c000000,开始执行bootloader；

启动步骤如下：

1.初始化SP，SP=0x0c002000

2.映射外设端口，即，告诉程序数据该走那个端口，地址该走哪个端口；6410外设和内存统一编址，分界线是0x70000000,低地址为内存，高地址为外设

3.关掉看门狗(WDT)，否则，系统会定时重启

4.初始化DDRC(内存控制器)

5.调用movi-read函数，将SD内256K空间存的代码督导内存中0x57e00000(u-boot的链接地址，在编译u-boot的时候可改)

---------------------------------------------第一阶段的代码结束--------------------------------------------------

6.跳转到movi-read函数的下一个函数，比如说a函数(这里执行的a函数就是内存中的a函数了)

7.UART(串口)初始化

NAND启动：

启动原理：

(1)通过stepping stone controller(IRAM控制器)，去读NAND中前8K的代码(这样的方法已经基本不用了，如今通过NAND控制器去读取NAND中前8K的代码)

(2)将NAND的前8K代码放到IRAM中

(3)PC被置为0，此时的0地址被映射到IRAM的起始地址，开始执行代码

启动步骤(大致思路和SD卡相同)

1.初始化栈，SP=0x2000

2.映射外设端口，即，告诉程序该走哪个端口，地址该走哪个端口；6410外设和内存统一编址，分界线是0x70000000,低地址为内存，高地址为外设

3.关闭看门狗(WDT)，默认WDT会定时启动系统

4.中断初始化<这步骤可有可无，如果缩写的bootloader的第一阶段代码用到中断，就必须初始化>

5.初始化时钟(colok)，DDR在使用之前必须配置好时钟

6.初始化DDR

7.初始化NAND

8.调用nand-read函数，将全部代码放入到内存中

---------------------------------------------第一阶段的代码结束--------------------------------------------------

9.跳转

10.初始化串口(UART),打印shell

DM365的视屏采集设备输入接口VPSS介绍

Video Processing Subsystem (VPSS)

  The device contains a Video Processing Subsystem (VPSS) that provides an input interface (Video Processing Front End or VPFE) for external imaging peripherals such as image sensors, video decoders, etc, and an output interface (Video Processing Back End or VPBE) for display devices, such as analog SDTV/HDTV displays, digital LCD panels, etc.

 In addition to these peripherals, there is a set of common buffer memory and DMA control to ensure effcient use of the DDR2/mDDR burst bandwidth. The shared buffer logic/memory is a unique block that is tailored for seamlessly integrating the VPSS into an image/video processing system. It acts as the primary source or sink to all the VPFE and VPBE modules that are either requesting or transferring data from/to DDR2/mDDR. In order to efficiently utilize the external DDR2/mDDR bandwidth, the shared buffer logic/memory also interfaces with all the VPFE and VPBE modules via a 128-bit wide bus. The shared buffer logic/memory (divided into the read & write buffers and arbitration logic) is capable of performing the following functions. It is imperatice that the VPSS utilize DDR2/mDDR bandwidth efficiently due to both its large bandwidth requirements and the real-time requirements of teh VPSS modules. Because it is possible to configure the VPSS modules in such a way that DDR2/mDDR bandwidth is exceeded, a set of user accessible register is provided to monitor overflows or failures in data transfers.

Video Processing Front-End (VPFE)

  The VPFE or Video Processing Front-End block is comprised of the Image Sensor Interface (ISIF), Image Pipe (IPIPE), Image Pipe Interface (IPIPEIF), Hardware 3A Statistic Generator(H3A), and a Hardware Face Detect Engine. 

  Image Sensor Interface (ISIF)

  The ISIF is responsible for accepting raw (unprocessed) image/video data from a sensor (CMOS or CCD). In addition, the ISIF can accept YUV video data in numerous formats, typically from so-called video decoder devices. In case of raw inputs, the ISIF output requires additional image processing to transform the raw input image to the final processed image. This processing can be done either on-the-fly in IPIPE or in software on the ARM and MPEG/JPEG and HD Video Image coprocessor subsystems. In parallel, raw data input to the ISIF can also used for computing various statistics (3A, Histogram) to eventually control the image/video tuning parameters. The ISIF is programmed via control and parameter registers.

 

 The Image Pipe Interface (IPIPEIF)

  The IPIPEIF is data and sync signals interface module for ISIF and IPIPE. Data source of this module is sensor parallel port, ISIF or SDRAM and the selected data is output to ISIF and IPIPE. This module also outputs black frame subtraction (two-way) data which is generated by subtracting SDRAM data from sensor parallel port or ISIF data and vice versa. Depending on the functions performed, it may also readjust the HD, VD, and PCLK timing to the IPIPE and/or ISIF input.

  

Image Pipe - Hardware Image Signal Processor (IPIPE)

  The Image Pipe (IPIPE) is a programmable hardware image processing module that generates image data in YCbCr-4:2:2 or YCbCr-4:2:0 formats from raw CCD/CMOS data. An image resizer is also fully integrated within this module. The IPIPE can also be configured to operate in a resize-only mode, which allows YCbCr-4:2:2 or YCbCr-4:2:0 to be resized without processing every module in the IPIPE.

Hardware 3A (H3A)

  The H3A module is designed to support the control loops for Auto Focus, Auto White Balance and Auto Exposure by collecting metrics about the imaging/video data. The metrics are to adjust the various parameters for processing the imaging/video data. There are 2 main blocks in the H3A module:

(1) Auto Focus (AF) engine

(2) Auto Exposure (AE) Auto White Balance (AWB) engine