MX51 Boot Block Guide 1.3

System Boot
Chapter 1 System Boot

1.1 Introduction
The AP processor on i.MX51 start booting from a power on reset. The boot ROM supports features such as booting from various external memory devices, support for downloading code through a ROM bootloader, capability for device configuration and secure boot. The boot ROM is responsible for reading inputs such as the boot pins and efuses to determine the behavior of the boot flow. The i.MX51 out-of-reset boot sequence, make use of the High Assurance Boot (HAB) library to provide a secure boot environment. A High Assurance Boot is a combination of hardware and software, with the use of a PKI (Public Key Infrastructure) protocol to protect the system from executing unauthorized images or programs. In order for the HAB to allow user code to run, the code must be signed by the private key holder which matches with the public key on i.MX51 . The HAB library in the i.MX51 boot ROM, also provide a number of API functions to allow the user to authenticate any defined region and signature at run-time. The i.MX51 also supports a HAB-bypass mode or direct external boot in which the processors can boot directly to external memory, such as a traditional microprocessor would do.The ROM also provides a mechanism to download and flash new code via a serial connection. Typically a downloader application is downloaded to RAM which facilitates the flash programming. The download is over either on a High speed USB in Non-stream mode or UART connection.The boot capabilities are substantially different on i.MX51 packages depending on the HAB type security configuration. Full flexibility is supported in the development (or engineering) configuration, but significant limitations are imposed on the production (or secure) configuration. The remainder of this chapter provides the details for booting i.MX51 in of each of the available modes.
1.2
Hardware Blocks
There are various hardware modules which are activated and play a vital role in the boot flow. The MCU configure and use the following peripherals during boot: SCC v2 RTICv3 SAHARA v4 LT CSU SRTC EMI (WEIM/NFCv2/ESDCTLv2) - used for boot from external memory IIM - contains the e-fuses UART and USB - used for serial download IOMUX GPIO - used to choose tests in FSL Test Mode WDOG PLL
ELVIS IC Users Guide, Rev .1.3Freescale Semiconductor 1-1 NDA Required / Preliminary Freescale Confidential
Proprietary
System Boot
CCM I2C HS-I2C eCSPI eSDHCv2 SRC - stores the value of the BMOD pins
ELVIS IC Users Guide, Rev .1.3 1-2
Freescale Confidential Proprietary

NDA Required / Preliminary
Freescale Semiconductor
System Boot
1.3
iROM and iRAM memory map

0x00000000 U S B B u ff e r ( 2 K B ) 0x00000048 D C D B u f fe r ( 1 K B ) Within First 8KB E r r o r L o g g in g 0x000000B 0 H A B d a ta 16KB 0x1FFE 0800 0x1FFE0C 00 0x1FFE 0000
R eset and E x c e p tio n v e c to r T a b le C o p y R ig h t a n d R O M v e r s io n H A B A P I V e c to r T a b le
0x00000090
R O M B o o ts tr a p BSS
DATA 0x1FFE 2000 0x00003FFF
IR A M f r e e s p a c e (1 1 2 K B ) 112KB
0x00404000
0x1FFFE000
Approx 8KB
STACK R O M B o o t s tr a p 20KB E x c e p tio n V e c to r T a b le 0x00408FFF
0x1FFFFFB 8 0x48 0x1FFFFFFF
V a r ia b le A d d r e s s F ix e d A d d r e s s
Figure 1-1. iROM and iRAM memory map

Proprietary
System Boot
1.4
1.4.1
Boot Options
Boot options and E-fuse settings
The boot sequence in i.MX51 is determined and controlled by: 1)BMOD[1:0] 2)GPIO_BT_SEL BMOD[1:0] -Type of boot is controlled by the boot mode pins (BOOTMOD[1:0]) value, sampled at exit of reset(stored in SRC Boot Mode Register - SBMR register of the System Reset Controller - SRC module). Options are: Internal, FSL Test mode, Internal boot with fuses and serial boot via USB/UART. Refer to Table 1-1 below for details.
Table 1-1. Boot Mode Options BMOD[1:0]
00 01 10 11
Boot Type
Internal Boot FSL Test Mode
Internal boot with fuses

Serial Boot Loader
GPIO_BT_SEL- Additional boot option selection is passed on to the processor, via either programmable e-fuses or pins value sampled at POR de-assertion(applicable only when BMOD=00). The select between the two options, is done based on the value of GPIO_BT_SEL fuse, as follow: a) In the case GPIO_BT_SEL is blown - all boot options are configured by e-fuses, as detailed in Table 1-2 below. Boot ROM software may read the values from the SBMR, or from the e-fuses, via the IIM module.It is the recommended configuration for deployed products and the GPIO mode is essentially for testing purposes. b) In the case GPIO_BT_SEL is left un-blown - the various boot options are determined by sample of dedicated pins at the exit of reset. Every e-fuse option is associated with a dedicated pin(s), such that same functionality is available for both boot options. See Table 1-5 below for boot option pins. For this case, regardless of fuse values, Boot ROM code must read the options values from SBMR register of the SRC module.
Table 1-2 describes the fuses that affect the boot flow.

System Boot
Table 1-2. Fuse Descriptions Fuse

DIR_BT_DIS
Configured by
Settings: Definition
Direct External Memory Boot Disable. Intact reads as 0 Blown reads as 1 0 = Direct boot to external memory is allowed 1 = Direct boot to external memory is not allowed
OEM
BT_MEM_CTL[1:0]
OEM
Boot Memory Control Type used to select EIM(NOR,oneNAND), NAND flash or expansion devices like SD/MMC, EEPROM Flexibility is provided to OEM to select any kind of bootable device to be used in their hardware. NAND Flash Page Size. This field is used in conjunction with the BT_MEM_CTL[1:0] setting to set page size of NAND flash device
00 - WEIM 01 - NAND Flash 10 - Reserved 11 - Expansion Device (SD/MMC, support high storage, EEPROMs. See BT_MEM_TYPE[1:0] settings for details). If BT_MEM_CTL = NAND Flash then 00 - 512 bytes 01 - 2K bytes 10 - 4K bytes 11 - Reserved 0 = 128 bytes spare (Samsung) 1 = 218 bytes spare (Micron, Toshiba) Note:Applicable to 4KB page size only If the bootable device is SD then: 0 - "FAST_BOOT" bit 29 in ACMD41 argument is 0 1 - "FAST_BOOT" bit 29 in ACMD41 argument is 1
BT_PAGE_SIZE[1:0]
OEM
BT_SPARE_SIZE
OEM
Specifies the size of spare bytes for 4KB page size NAND Flash devices. Note: 512B page devices have 16 bytes spare area size,2KB page devices have 64 bytes spare area size. OEM can choose between 128 byte spare or 218 spare bytes by using this fuse. Also used as a fast boot mode indication for eSD 2.10 protocol. NAND/NOR Bus Width. Note: OneNAND has only 16 bits,
BT_BUS_WIDTH[1:0]
OEM
BT_MEM_CTL[1:0] = NAND Flash 00 = 8 bit 01 = 16 bit BT_MEM_CTL[1:0] = WEIM (NOR) 0 = 16 bit data bus 1 = 32 bit data bus BT_MEM_CTL[1:0] = Expansion Device (SPI) 0 = 2-Address word SPI device (16-bit) 1 = 3-Address word SPI device (24-bit)
Proprietary
ELVIS IC Users Guide, Rev .1.3Freescale Semiconductor 1-5 NDA Required / Preliminary
Freescale Confidential
System Boot
Table 1-2. Fuse Descriptions (continued) Fuse

BT_MEM_TYPE[1:0]
Configured by
Boot Memory Type. Interpreted by boot ROM SW according to BT_MEM_CTL setting. Signals could also be interpreted by HW to alter delays and timing in support of direct boot. Intact reads as 0 Blown reads as 1 If BT_MEM_CTL = WEIM then 00 - NOR 01 - Reserved 10 - OneNand 11 - Reserved If BT_MEM_CTL = NAND Flash 00 - 3 address cycles 01 - 4 address cycles 10 - 5 address cycles 11 - reserved If BT_MEM_CTL = Expansion Card Device 00 - SD/MMC/eMMC/eSD 01 - Reserved 10 = Serial ROM via I2C 11 = Serial ROM via SPI If BT_MEM_CTL[1:0]==11 (Expansion card device) && BT_MEM_TYPE[1:0]=00 (SD/MMC/eMMC/eSD) then 00 - eSDHC-1 01 - eSDHC-2 10 - eSDHC-3 11 - eSDHC-4
OEM
BT_SRC[1:0]
OEM
Fuse is used to select following devices depending on value of BT_MEM_CTL[1:0] 1)esdhc1-4 2)I2C1-2,HS-I2C 3)CSPI,eCSPI1-2
(eMMC4.3 fastboot is supported in eSDHC3-4)

If BT_MEM_CTL[1:0]==11 (Expansion card device) && BT_MEM_TYPE[1:0]=10 (Serial ROM via I2C) then 00 - I2C-1 01 - I2C-2 10 - HS-I2C 11 - Reserved If BT_MEM_CTL[1:0]==11 (Expansion card device) && BT_MEM_TYPE[1:0]=11 (Serial ROM via SPI) then 00 - eCSPI-1 01 - eCSPI-2 10 - CSPI 11 - Reserved

System Boot

BT_WEIM_MUXED[1:0]
Configured by
Selects WEIM muxed mode. Have a corresponded GPIO pin. Intact reads as 0 Blown reads as 1 For BT_MEM_CTL[1:0] = WEIM (Nor) 00 = Not muxed, not multiplexed with NAND, 16-bit data (high half) NOR interface. 01 = Muxed, not multiplexed with NAND, 16-bit data (low half) NOR interface. 10 = muxed, multiplexed with NAND data bus, 16-bit data (low half) NOR interface, . 11 = Muxed, multiplexed with NAND data bus, 32-bit data NOR interface. 00 - UART-1 01 - UART-2 10 - UART-3 11 - Reserved If BT_MEM_CTL[1:0] == NAND 0-SLC nand device 1-MLC nand device If BT_MEM_CTL[1:0] == Expansion Device && BT_MEM_TYPE[1:0]=00 If the bootable device is MMC then: 0 - Don't use eMMC fast boot mode. 1 - Use eMMC fast boot mode. 0= Use EEPROM DCD 1 = Dont use EEPROM DCD
OEM
BT_UART_SRC[1:0]
OEM
Choosing the specific UART controller for serial downloading .Have a corresponded GPIO pin.
BT_MLC_SEL
OEM
SLC/MLC nand device or FAST BOOT enable/dissable for eMMC device (Due to Hardware issue, this feature of eMMC is not supported)
BT_EEPROM_CFG
OEM
Selects whether EEPROM device is used for load of configuration DCD data, prior to boot from other devices (not applicable when using EEPROM as boot device) USB phy selection is based on this fuse. CKIH Frequency Select. It is used by boot code for PLL programming. Have a corresponded GPIO pin. GPIO Boot Select. Determines, whether certain boot fuse values will be controlled from GPIO pins or IIM Note: Applicable only for BMOD=00
BT_USB_SRC
OEM
0 = USB OTG Internal PHY(UTMI) 1 = USB OTG External ULPI PHY 00 - CKIH Frequency is 26 MHz 01 - CKIH Frequency is 19.2 MHz 10 - CKIH Frequency is 27 MHz 11 - CKIH Frequency is 24 MHz 0=Certain bits of SBMR is updated by GPIOs. 1=Certain bits of SBMR is updated by IIM fuses.
OSC_FREQ_SEL[1:0]
OEM
GPIO_BT_SEL
Freescale
Proprietary
System Boot

HAB_TYPE[2:0]
Configured by
Security Types as defined in Section 1.6.1.1 Note:In Engineering mode if CSF and SRK is not provided it must set to NULL in app header. Most significant byte of 256-bit hash value of super root key (SRK_HASH) HAB Customer Code Selects customer code, as input to HAB. Device Unique ID, 64-bit UID. Intact reads as 0 Blown reads as 1 001 - Engineering (allows any code to be flashed and executed, even if it has no valid signature) 100 - Security Disabled (For internal/testing use) Others - Production (Security On) Varies - used by HAB
OEM
SRK_HASH[255:0]
OEM
HAB_CUS[7:0] DIE-X-CORDINATE[7:0] DIE-Y-CORDINATE[7:0] WAFER_NO[4:0] LOT_NO_ENC[42:40] LOT_NO_ENC[39:32] LOT_NO_ENC[31:24] LOT_NO_ENC[23:16] LOT_NO_ENC[15:8] LOT_NO_ENC[7:0] SRTC_SECMODE[1:0]
OEM Freescale
Varies - used by HAB Varies - used by HAB
OEM
Security Mode for Secure RTC. Determines the level of security for Secure Real Time Clock (SRTC) module LPB ARM core frequency
00 - Low Security 01 - Medium Security 10 - High Security 11 - Reserved 000-192 MHz (Default,Out of Reset,Refer Sec 1.6.1.2) 001-133 Mhz 010-55.33 MHz 011-200 MHz 100-220 MHz 101-166 MHz 110-266 MHz 111-Normal boot frequency(400 MHz) 0 - BOOT area is virgin. Boot flow jumps to UART/USB boot loader, in case of BOOT_MODE[1:0]==10. 1 - BOOT area is not virgin. Regular boot flow is performed. 00 - LPB disabled 01 - Generic PMIC and one GPIO input (Low battery) 10 - Generic PMIC and two GPIO inputs (Low battery and Charger detect) 11 - Atlas AP Power Management IC.
BT_LPB_FREQ[2:0]
OEM
BT_VIRGIN
OEM
Indication that BOOT area was not burnt yet
BT_LPB[1:0]
OEM
Options for Low Power Boot mode.

System Boot
The settings required for a secure and non-secure devices during production and engineering development phases are shown in Table 1-3
Table 1-3. Required fuse settings
Fuse name HAB_CUS[7:0] HAB_TYPE[2:0] SRK_HASH[0:247] Non-secure device production/engineering) Not required 100(Security Disabled) Not required Secure device (engineering) Not required 001(Engineering) As instructed by freescale 0(External boot is allowed) Secure device (production) As instructed by freescale Other (Production) As instructed by freescale 1(External boot is not allowed)
DIR_BT_DISABLE 0(External boot is allowed)
NOTE:Table 1-3 is for FSL internal use only Setting of Page Per Block values In general, the Page Per Block setting, may not have a one to one relation to block size. However, most devices used, are following the relations listed in Table 1-4
Table 1-4. Page Per Block settings
Page Size 512 Bytes 2K Bytes SLC 2K Bytes MLC 4K Bytes Page per Block 32 64 128 128
1.4.2
Boot Option fuses and associated Pins
Table 1-5 below provides listing of boot options fuse values and associated pins, where applicable. Several input pins, are also sampled at boot, and can be used to override fuse values, depending on the value of GPIO_BT_SEL fuse. The boot option pins are in effect, when GPIO_BT_SEL is 0 (cleared - case for un-blown fuse.) Also listed are boot mode pins and functionality of other boot related fuses and pins.
Proprietary
System Boot
Table 1-5. Fuses and associated pins used for boot

Pin BOOT_MODE[1:0] Direction at Boot INPUT NA E-Fuse Name Details Boot Mode selection Boot option pins and also used in FSL Test mode for test selection Boot Options, Pin value overrides fuse settings for GPIO_BT_SEL = 0
DISP1_DAT[21:20]
INPUT
BT_MEM_TYPE[1:0]
DISP1_DAT[19:18] DISP1_DAT[17:16] DISP1_DAT[15] DISP1_DAT[14:13] DISP1_DAT[12] DISP1_DAT[10] DISP1_DAT[9:8] DISP1_DAT [7] DISP1_DAT [6] EIM_A[21:20] EIM_A[19:18] EIM_A[17:16] NANDF_RDY_INT[22] Output
BT_WEIM_MUXED[1:0] BT_PAGE_SIZE[1:0] BT_BUS_WIDTH BT_MEM_CTL[1:0] BT_MLC_SEL BT_SPARE_SIZE BT_ SRC[1:0] BT_EEPROM_CFG BT_USB_SRC[1:0] BT_UART_SRC[1:0] BT_TBD23 OSC_FREQ_SEL[1:0] NA
Pulse Indication on finish of internal system reset(Also indicates exit of ALT7 IOMUX mode),by visibility of any any_pu_rst signal. This indication should be enabled by JTAG first.
1.5
Boot Sequence
Figure 1-2 shows the High Level MCU ROM code flow followed in Elvis..

System Boot
Reset
ELVIS MCU ROM Code High Level Bootflow
Boot pins and fuses are sampled
KEY Low Power Boot Boot Pins E- Fuses Hardware
LPB
No
FSL TEST MODE(BMOD=1) && DIR_BT_DIS=0
Yes Sleep mode
Wait mode No Yes Yes USB/UART Bootloader(BMOD=3 || (BMOD=2 && BT_VIRGIN =0)) No Enter Debug Mode TEST Selection SCC To failure GPIO1[4:6] FSL Test Mode (Test Executive)
Security HW test (SCC key Check)
Infinite SCC_RAM test No INTERNAL Bootloader(BMOD=0 || (BMOD=2 && DIR_BT_DIS=1))
FSL Test Mode
Infinite GMEM test
Yes
BT_MEM_ CTL == EIM and BT_MEM_TYPE == NOR No
Yes
WEIM MUX mode selection BT_WEIM_MUXE D[1:0]
Basic Config and Obtain base addr Of boot device
HAB checks
BT_MEM_ CTL == EIM and BT_MEM_TYPE == OneNand No
Yes
ConfigureWEIM (CS0) interface and Copy initial 1kB of data to ONENAND RAM
HAB check image is verified ? Code Barker Valid? Yes No
yes
Yes BT_MEM_CTL == NAND No BT_MEM_CTL == Expansion Card Device(SD/MMC / eMMC/eSD/) No Yes
Configure NFC controller and copy initial 4k of data to NFC Buffer
No
Configure eSDHC1-esdhc4 controller and read initial 2k of data to IRAM
HAB_TYPE?
ENG
Execute Image
PROD
Boot Mem ctrl SPI/I2C
yes
Configure SPI/I2C And download initial 2k data to iRAM
NO
BootLoader flow
(A)
HAB check and Execution Flow
From B
Proprietary
System Boot
NO
BT_EEPROM_CFG Blown
Configure I2C Read ADR/DATA pairs To iRAM
yes
Execute code (Check address validity)
B
HAB checks Configure IOMUX and PHY
UART UART/USB Secure Download? (Wait for activity on one of devices)
Initialize UART BT_UART_SR C[1: 0]
Initialize RAM
USB Start WDOG timer
Download image
Initialize USB Driver
Watchdog Asserted
Issue Reset to PMIC
Figure 1-2. Boot Flow
Note: The size of image for any boot device is not limited to 4kB/2KB size

System Boot
1.6
Boot Modes
There are four unique boot modes for the MCU boot ROM. The modes are selected by setting the boot mode pins to one of the combinations listed in Table 1-1 with the path of the MCU boot illustrated in Figure 1-2.
1.6.1
Internal Boot mode (BMOD[1:0] = 00)
Internal boot is selected by driving value of 00 on the BMOD[1:0] pins, at device power up. In this mode core boots from internal ROM. The boot code performs HW initialization, application image validation using the HAB library and then jumps to an address derived from the application image. If any error occurs during internal boot the boot code jumps to the UART/USB secure download. Internal boot mode is the only mode in which a secure boot of the i.MX51 is possible.
1.6.1.1
Security Settings
External boot modes are considered as non-secure by definition: the software in Flash is executed regardless of its authenticity, and the SCC is automatically put into Non-Secure state so that it cannot be used to decrypt information with the device-unique secret key. Internal boot modes can have one of two security levels: Production: This level is intended for use with shipping products. All HAB functions are executed and security hardware is initialized (the SCC enters Secure state), DCD is processed if present, and software in Flash or downloaded to RAM is authenticated by HAB prior to its execution. First error detected will be logged, and the boot flow is aborted with control passing to the download mode. With this level, execution does not leave the internal ROM unless the target executable image has been authenticated. Engineering: This level is intended for use during the development phases of a product. All HAB functions are executed as for a production device. security hardware is initialized (except the SCC is left in Non-Secure state), DCD is processed if present, and software in Flash or downloaded to RAM is authenticated by HAB prior to its execution. First error detected will be logged, but have no influence on the boot flow.CSF must be present in this mode even if it could be a wrong one.Therefore, with this level, it is possible to develop software without requiring that each build be signed for HAB authentication, since the device will boot even if the code signatures are missing.
1.6.1.2
Basic Initialization
On reset MCU core has access of all shared peripherals. On reset by default all peripheral clocks are enabled and boot ROM will not change any of the peripheral clock enables. NORMAL mode: In normal mode the following frequencies are available as input clock to PLL1-3 modules. Selection of these frequencies is done as follows. The CLKSS is read and if OSC is selected then further input clock selection is based on the fuse OSC_FREQ_SEL[1:0](Refer to Table 1-6).
Proprietary
System Boot
If the CLKSS is FPM, then 32KHz is selected as input to PLL1-3 module. Table 1-6. OSC_FREQ_SEL[1:0] values and corresponding frequencies OSC_FREQ_SEL[1:0]
00 01 10 11 Frequency 26 MHz 19.2 MHz 27 MHz 24 MHz
Table 1-7. PLL Configuration

Clock PLL1 PLL2 PLL3 Frequency(MH z) 400 600 216
Table 1-8. Normal Frequency Clocks Configuration

Clock ARM core clock EMI NFCv2 AHB IPG AXI_A AXI_B USB UART eSDHC CCM signal arm_clk_root emi_slow_clk_root enfc_clk_root ahb_clk_root ipg_clk_root axi_a axi_b usboh3_clk_root uart_clk_root esdhc1_clk_root esdhc2_clk_root esdhc3_clk_root ecspi_clk_root Source PLL1 PLL2 PLL2 PLL2 PLL2 PLL2 PLL2 PLL2 PLL3 PLL3 Frequency(MH z) 400 100 20 120 60 150 75 60 21.6 54
CSPI
PLL3
54
Table 1-7 shows the different PLLS used and Table 1-8 shows the various clocks used thier clock sources

System Boot
Beside these clocks PERCLK_ROOT is getting generated from lp_apm source of value 50MHz and CSPI_CLOCK_ROOT is getting generated from IPG_ROOT(60MHz). Low Power Boot Mode: In Low power boot(LPB) mode, PLL1 is configured at 266MHz/166MHz and used as source of ARM core clock, serial buses clock (i2c,cspi,esdhc,uart etc), IPG, perclk_root , AHB, AXI bus clocks. PLL2 and PLL3 are disabled in low power boot mode. ROM configures ARM core frequency value based on fuse BT_LPB_FREQ[2:0]. ARM core frequencies in low power boot mode: 0=192 MHz (Default,out of reset) Note :- This value gets changed based on the OSC_FREQ_SEL[1:0] fuse values as follows:Table 1-9. Normal Frequency Clocks Configuration OSC_FREQ_SEL[1:0]
Oscillator Frequency
LPB Frequency at
BT_LPB_FREQ[2:0] = 0
00 01 10 11
26 19.2 27 24
208 153.2 216 192
1=133 MHz 2=55.33 MHz 3=200 MHz 4=220 MHz 5=166 MHz 6=266 MHz 7=normal boot frequency(400MHz) Table 1-9 lists the various LPB frequancies(In MHz) used by diifferent clock based on the BT_LPB_FREQ[2:0] value.
Proprietary
System Boot
Table 1-10. LPB Clock Configurations

BT_LPB_FREQ[2:0] PLL1 frequency 0 192* 1 266 2 166 3 200 4 220 5 166 6 266 7 400
ARM frequency
192*
133
55.3333 3 41.5 20.75 33.2
200
220
166
266
400
axi_a(div by 4) axi_b(div by 8) emi_slow_clk_root(div by 5) enfc_clk_root(div by 5) ahb_clk_root(div by 5) ipg_clk_root(div by 2) perclk_root(div by 12) uart_clk_root(div by 12) esdhc_clk_root(div by 12) cspi_clk_root(div by 18)
48* 24* 38.4*
66.5 33.25 53.2
50 25 40
55 27.5 44
41.5 20.75 33.2
66.5 33.25 53.2
100 50 80
7.68* 38.4* 19.2* 16* 16* 16* 10.6667 * 16*
10.64 53.2 26.6 22.1666 22.1666 22.1666 14.7777
6.64 33.2 16.6 13.8333 13.8333 13.8333 9.22222
8 40 20 16.6666 16.6666 16.6666 11.1111
8.8 44 22 18.3333 18.3333 18.3333 12.2222
6.64 33.2 16.6 13.8333 13.8333 13.8333 9.22222
10.64 53.2 26.6 22.1666 22.1666 22.1666 14.7777
16 80 40 22.2222 13.3333 13.3333 13.3333
i2c_clk_root(div by 12)
22.1666
13.8333
16.6666
18.3333
13.8333
22.1666
33.3333
* This frequency depends on the oscillator frequency selected based on OSC_FREQ_SEL[1:0] fuse, please refer to Table 1-9 for
corresponding frequency values.
1.6.1.3
External Device Selection
The i.MX51 will support the following boot flash devices: NOR flash with WEIM Interface, located on CS0, Bus width of 32 and 16 bits NOR flash devices. OneNAND flash with WEIM interface, located on CS0, Bus width of only16 bit OneNAND flash devices. MLC Nand , SLC Nand and LBA Nand Flash via NFC interface. Page sizes of 512 bytes, 2KB or 4KB, bus width of 8 bit or 16 bit, 4/8-bit ECC (Error Checking) SD/MMC/eMMC and eSD via eSDHC interface, supporting high capacity cards. eMMC-4.3 boot mode (FAST BOOT) via eSDHC-3 and eSDHC-4 interface. eSD FAST BOOT mode via all the eSDHC ports.

System Boot
EEPROM boot via SPI (serial flash) and I2C/HS-I2C (via CSPI, HS-I2C and I2C modules respectively) The selection of external flash device type is determined by BT_MEM_CTL[1:0] and BT_MEM_TYPE[1:0] efuses. See Table 1-2 for more details. NOTE: eMMC Boot Mode (FAST BOOT) has been implemented in ROM but due to hardware bug this feature is not supported. 1.6.1.3.1 NOR Flash via WEIM interface
Boot from the WEIM NOR Flash interface is supported for debug purposes. It should be used on special cases only. The NOR FLASH interface will work in the asynchronous mode, and supports either muxed. Address/Data, or non muxed scheme, based on fuse settings, see Table 1-2 for details. 1.6.1.3.2 NAND Flash Support
A number of MLC/SLC NAND flash devices from different vendors and LBA Nand Flash are supported by the boot ROM. The Error Correction and Control (ECC) module is used to detect the errors. Boot ROM determines the configuration of external NAND flash by following parameters, either provided by e-fuse, or sampled on IO pins, during boot: PAGE_SIZE[1:0] - 512B/2KB/4KB BUS_WIDTH - 8-bit/16-bit BT_SPARE_SIZE[1:0] - 128 byte / 218 byte BT_MEM_TYPE[1:0] - 3/4/5 address cycles BT_MLC_SEL - SLC/MLC flash To decide page size,bus width,address cycle and ECC select of external NAND device ROM read PAGE_SIZE[1:0],BUS_WIDTH,BT_MEM_TYPE and BT_MLC_SEL bit fields from SBMR register of SRC module.For more details see the Table 1-2.For more details on NAND address cycle section please refer to Appendix-A. On device power on, the copy of first boot block data from NAND flash device to NFC buffer is done by boot ROM. Since in NAND flash devices there are possibility of getting errors while reading first 4k boot data from first block(NAND device Block-0), the user is required to duplicate the first 4k boot code to subsequent block(NAND flash Block-1), to serve as a 2nd copy option. The boot ROM code, takes advantage of the duplicate boot code, by the following flow: If no ECC errors are detected in first 4K boot data from NAND device block-0, dcd is performed and downloaded 4KB image as well as rest of the image is copied to application destination pointer embedded into image(iRAM) and secure boot is performed. If ECC Error is detected in first 4k boot data from Block-0, the boot ROM code shall copy the duplicated 4k boot data from the NAND flash block-1. If an error is detected in the subsequent boot block, boot ROM code will log an error and jumps to USB/UART bootloader. The logged error can be queried via the serial protocol. If there is no error in data copy then boot ROM will perform the secure internal boot.
Proprietary
System Boot
NOTE:The application image length and destination pointer should be specified in image as BootROM reads application image length as well as application destination pointer from image. 1.6.1.3.3 OneNand-Flash Boot Operation
The OneNAND flash devices are available only with 16 bit interface. ROM OneNAND flash driver will get the device page size by issuing a software command to device and collecting the response from device. At system power-up, OneNAND automatically copies 1 Kb data from start of flash array (sector 0 and sector 1, page 0, block 0) to its *Boot RAM i.e. Boot RAM contains the OneNAND flash header. Boot ROM will copy the 1Kb OneNAND *BootRAM contents to application destination pointer (located in the app_dest_ptr entry of application header) and decrement length of the image to be read from OneNAND by 1 K. *Boot RAM area is memory mapped and copying operation will be simple memory copying operation. The length of image to be read from OneNAND device is specified in flash header structure described in Figure 1-8.Any failure of loading data from OneNAND flash for any reason would force MCU Boot ROM to switch to serial download. At system power-up, the voltage detector in the device detects the rising edge of Vcc and releases internal power-up reset signal which triggers bootcode loading. Bootcode loading means that the boot loader in the OneNAND copies designated sized data(1KB) from the beginning of memory to the *BootRAM. Bootcode copy operation starts 400us later than POR activation and 1K bytes Bootcode copy takes 70us(estimated) from sector0 and sector1/page0/block0 of NAND Flash array to BootRAM. INT bit of Interrupt status register goes Low to High on the condition of Bootcode-copy done and RP rising edge. Boot ROM Implements this in 2 stages:1. Put GPT timer to introduce a delay of around 500 Micro seconds. 2. Wait for INT bit of Interrupt status register to go High. Once INT bit of interrupt status register is set to High, Boot ROM proceeds with OneNAND initialization. NOTE:* oneNAND internal RAM NOTE:The application image length and destination pointer should be specified in image as BootROM reads application image length as well as application destination pointer from image. 1.6.1.3.4 Expansion Device Support
Boot procedure is enabled from MMC/eMMC and SD/eSD compliant devices. SD/MMC/eSD/eMMC boot can be performed via either eSDHC-1, eSDHC-2, eSDHC-3 or eSDHC-4 devices, based on BT_SRC fuse value, or its associated input pin value at boot. For eMMC-4.3 with BOOT ACK support boot mode, only eSDHC-3 or eSDHC-4 can be used. Refer to Table 1-2 for details. Boot code supports following standards. MMCv4.3 or less

System Boot
eMMCv4.3 or less SDv2.0 or less eSDv2.10 rev-0.9, with or without FAST_BOOT.
MMC/SD/eSD/eMMC can be connected to any of eSDHC1-4 module and booting can be done by copying 2KB of data from MMC/SD/eSD/eMMC device to iRAM. After checking barker value(0x000000B1) from boot image, ROM perform DCD check. After successful DCD extraction, rom code extracts destination pointer and length of image to be copied to RAM device from where code execution occurs.
Table 1-11. SD/MMC Frequencies
Frequency NORMAL 0 IDENTIFICATION(KHz) OPERATING (MHz) 1 115.41 5.54 2 72.03 3.45 LPB BT_LPB_FREQ[2:0] 3 86.80 4.16 4 95.48 4.58 5 72.03 3.45 6 115.41 5.54 7 69.44 3.33
210.937
13.5
83.30 4.00
NOTE: The application image length and destination pointer should be specified in image as BootROM reads application image length as well as application destination pointer from image. 1.6.1.3.5 MMC and eMMC
MMC frequency is set to 210.937KHz for the identification phase in Normal boot mode. During identification phase MMC card voltage validation is performed. During voltage validation, boot code checks with high voltage settings and capacity of card is checked. Boot code supports both high capacity and low capacity MMC/eMMC cards. After initialisation phase is over, boot code switch to a higher frequency, 13.5MHz in Normal boot mode. eMMC is also interfaced via eSDHC and follows same flow as does by MMC. Boot partition can be selected for eMMC-4.3 card after the card initialization has been done. ROM reads the BOOT_PARTITION_ENABLE field in the Ext_CSD[179] to get the boot partition to be set. If there is no boot partition mentioned in BOOT_PARTITION_ENABLE field or the user partition has been mentioned, ROM boots from the user partition. eMMC-4.3 device support special Boot mode, which can be initiated by pulling the CMD line low. If BOOT ACK is enabled, the eMMC-4.3 device sends the BOOT ACK via DATA0 and ROM can read the BOOT ACK [S010E] to identify the eMMC-4.3 device. eMMC-4.3 device with Boot mode feature can only be supported via eSDHC-3 and eSDHC-4 and with BOOT ACK enabled. ROM waits for 50ms to get the BOOT ACK and if BOOT ACK is received by ROM, then only eMMC-4.3 is booted in Boot mode, otherwise eMMC-4.3 boots as a normal MMC card from the selected boot partition. This boot mode can be selected by BT_MCL_SEL fuse. Only 1-bit bus width is used in ROM.
Proprietary
System Boot
M M C /S D B oot E ntry P oint
C heck B T _S D M M C _ S R C fuse for eS D H C port. A ccordingly do the IO M U X config eS D H C S oftw are R eset, S et R S T A S et Identification frequency (A pprox 400 K H Z )
eS D H C in it
C heck for eM M C -4.3 boot m ode support
B T _M LC _ S E L = = 1? Y es
No
eM M C -4.3 boot m ode is not selected
C onfigure C M D line as G P IO C onfigure operating frequency ~ 20 M H z S et C M D line low Issue virtual read (C M D 17 ) com m and (50 m s tim eout, B C = 4 , W M L = 1) to get the B O O T A C K S 010E Y es G ot eM M C boot A C K ? No eM M C B O O T A C K S et Identification frequency (A pprox 400 K H Z ) R eset the D A T A line by setting R S T D R eset the C M D line by setting R S T C R elease C M D line to eS D H C
eM M C -4 .3
B oot O peration M ode
eM M C B o o t M o d e is n o t s u p p o rte d
C onfigure G P T for 1 s tim eout
B C = 0xF F F F W M L = 128 , B C E N = 0, M S B S E L = 1
Issue virtual read (C M D 18 ) com m and to initiate infinite block xfer
W ait for block of boot data to com e in eS D H C buffer by polling the B R R bit (tim eout = 1 s)
R ead 2 K data from eS D H C buffer to IR A M
G ot the first block of data
Y es
B R R set? No
No
G P T tim er expires ?
Y es
R elease C M D line to eS D H C
eM M C d ata read

System Boot
1
Set INITA to send 80 SDCLK to card Card S/W Reset(CMD0)
Command Successful ? Yes Issue CMD 8 with HV (3.3V) Command Successful ? Yes Card is HC/LC HV SD ver 2.x Set ACMD41 ARG to HV and HC
No
No
Issue CMD 8 with LV (1.8V) Set ACMD41 ARG to LV and HC FAST_BOOT Yes selected? No Set ACMD41 ARG bit 29 for FAST BOOT Start GPT delay of 1s for ACMD41 Issue CMD55 Command Successful ? Yes No
Command Successful ? Yes Card is HC/LC LV SD ver 2.x
No
Card is LC SD ver 1.x
Set ACMD41 ARG to HV and LC
Yes
NOTE: eSD FAST BOOT support is selected by BT_SPARE_SIZE fuse: 0 - "FAST_BOOT" bit 29 in ACMD41 argument is 0 1 - "FAST_BOOT" bit 29 in ACMD41 argument is 1
Issue ACMD41 Command Successful ? Yes Busy Bit == 1 No No
No
Loop Cntr < 3000 and looping period < 1s Increment loop counter
Yes
SD Boot
Yes Card is HC SD
Voltage Validation
Card is LC SD
No
Is Response OCR for HC
Device Initialization Command Yes Successful ? No Get RCA (Issue CMD3) Command Successful ? No Yes
SD Boot
Get CID from card (Issue CMD2) Set operating frequency upto 20 MHz Put card in data Transfer Mode (Issue CMD 7) No Command Successful ?
5
No Card State == TRANS?
Yes
Send CMD13 to read status
Yes
Send CMD43 to select partition 1 Command Successful ? Yes Card is eSD
Partition1 set FAILED No
Yes Yes Card State == TRANS? Yes No CMD13 poll timeout? No
Partition1 got selected No
Command Successful ? Send CMD13 to read status
Boot Partition Set
SD Boot
FAST_BOOT selected? Yes
No
Set CMD13 poll timeout to 15ms Set CMD13 poll timeout to 1S
Proprietary
System Boot
Set Strong pull-up for CMD line
Start GPT with 1s delay for CMD1
MMC Boot
Voltage Validation Increment loop counter No
Get MMC card CSD (Issue CMD9) Set Weak pull-up for CMD line Yes Command Successful ? No
Set operating frequency to 20 MHz
MMC Boot
Device Init
Issue CMD1 with HV
Put card in data Transfer Mode (Issue CMD7)
Command Successful ? Yes Busy Bit == 1 No
5 No
No Yes Set RCA (Issue CMD3) Yes Command Successful ? Get CID from card (Issue CMD2) No
Yes
Command Successful ? Yes
Loop Cntr < 3000 and looping period < 1s
Is Response OCR for HC No
Yes
Card is HC MMC
No
Card State == TRANS? Yes
Card is LC MMC No
Spec ver >= 4.0? Yes Send CMD8 to get Ext_CSD
Partition set FAILED Yes CMD13 poll timeout? No No Card State == TRANS? Yes Yes Partition got selected No Card is eMMC-4.3 Set CMD13 poll timeout to 100ms
User or no partition set
Extract the boot partition to set No Got valid partition? Yes
No
Command Successful ? Yes
Command Successful ?
Send CMD6 to select partition
MMC Boot
Boot Partition Set

System Boot
Card read data
Read 512 bytes of data from MMC/SD/eSD/ eMMC Card (CMD17) and copy to IRAM
USB/UART flow (Serial boot)
6
Yes
No 2K Data Read ?
Check for barker
Braker present?
No
Execute the Image

Jump to application code jump vector
Yes Check for security type Yes
Security dissabled? No
Do HAB verification
Parse valid address range
Copy rest of image data from SD/MMC/ eSD/eMMC to SDRAM
Address range is valid? Yes
No
Copy 2k data image data from IRAM to SDRAM Yes
Configure the device using DCD
Device configuration pass?
No
1.6.1.3.6
SD and eSD
SD and eSD frequency is set to 210.937KHz for the identification phase in Normal boot mode. During identification phase SD and eSD card voltage validation is performed. During voltage validation, boot code first checks with high voltage settings and if it fails it checks with low voltage settings. Capacity of card is also checked. Boot code supports high capacity and low capacity SD and eSD cards. After voltage validation card initialisation is done. During card initialisation boot, code tries to set boot partition for both SD and eSD device. If it fails, boot code assumes card as normal SD card otherwise as eSD card. After initialisation phase is over, boot code would switch to a higher frequency, 13.5MHz in Normal boot mode. ROM also support FAST_BOOT mode booting from eSD card. This mode can be selected by BT_SPARE_SIZE fuse. The BootROM uses 1-bit access to card. Application code can switch to 4/8-bit mode
Proprietary
System Boot
1.6.1.3.7
Serial ROM support via SPI, I2C and HS-I2C
The i.MX51 supports boot from serial memory devices, such as EEPROM, and Serial Flash via the SPI (CSPI, at chip select #1), HS-I2C(fast mode only) and I2C (I2C-1 and I2C2) interfaces. Boot ROM determines the type of device, by the following parameters, either provided by e-fuse, or sampled on IO pins, during boot(See Table 1-5 for details): BT_MEM_TYPE[1:0] - SPI/I2C select. BT_SRC[1:0] - I2C1, I2C or HS-I2C select. BT_SPI_TYPE - defines the type of SPI device (EEPROM / Serial Flash) The I2C-1/I2C-2/HS-I2C module can be used as boot device using I2C/HS-I2C interface, for serial ROM boot. I2C/HS-I2C interface is configured at speed of 312.5Kbps. I2C/HS-I2C Boot BootROM code reads from fuses HAPI_BT_EEPROM_CONFIG and HAPI_BT_MEM_TYPE to detect EEPROM device. BootROM copies 2K data from EEPROM device to internal RAM. ROM code copies intial 2KB data as well as rest of image directly to application destination extracted from application image. If DCD verification fails ROM code execution log error and jumps to serial downloader. The i.MX51 attempt to boot from EEPROM, using the following Device Select Code / Device Address:
Table 1-12. EEPROM via I2C Device Select Code
Bits 7 Device Select Code 1
Device Type Identifier 6 5 0 1 0
Chip Enable Address1 2
RW 0 RW
These address bits, should be configured at the memory device, to match this 000 value.

System Boot
I2C Flow chart
Internal Boot
Check the BT_MEM_CTL and BT_MEM_TYPE No I2C device? Yes I2C init Check the BT_SRC fuse Yes HS-I2C selected? No
Continue internal booting
HS-I2C init
I2C init
Check the BT_SRC fuse HS-I2C selected? I2C read No I2C read Yes
HS-I2C read
I2C/Hs-I2C boot
IOMUX configuration, Set the data rate, enable I2C Set xfer mode to trnasmit Send start Send slave address Send MSB of source address Send LSB of source address Send repeat start Send Slave ADDR with read mode enalbed Set xfer mode to receive Read data NOTE: 1. Failure to any of the steps will abort the boot and jump to serial boot flow 2. This is the very high level flow diagram of I2C/HS-I2C boot for detail, please see the HS-I2C/I2C module description
Proprietary
System Boot
CSPI Boot CSPI interface is configured in Master mode.EEPROM device is connected to CSPI interface as slave. BootROM copies 2K data from EEPROM device to internal RAM.If DCD verification is successful ROM code copies initial 2KB data as well as rest of image directly to application destination extracted from application image.If DCD verification fails ROM code execution log error and jumps to serial downloader.CSPI can read data from EEPROM in 2 or 3 byte addressing and its burst length is 32Bytes. NOTE The Serial ROM is required to reside on Chip Select #1 of the CSPI module. Using SPI as boot device, the i.MX51 supports boot from both Serial EEPROMS, and Serial Flash devices. The boot code should distinguishing between the two, by read of fuse / signal value at boot(See Table 1-5 for details).
Figure 1-3. CSPI Flow chart
Start
END
no
Configure CSPI clock divider==success yes EEPROM Read data NO
Set instruction length address cycle according to fuses If read data length greater than( burst length- instruction length) Assign MSB as read instruction(0x03) and other 2/3 byte dest address in data pointer Send read instruction to read burst length of data
If read data length > 0
Assign MSB as read instruction(0x03) and other 2/3 byte dest address in data pointer
NO
Send read instruction to read remaining length of data
If read instruction status is CSPI_SUCCESS
If read instruction status is CSPI_SUCCESS yes Read burst length of data and copy to destination pointer Increment destination pointer and reduce length of data read
yes Read remaining length of data and copy to destination pointer yes
B
NO
B
Disable CSPI
END

System Boot
1.6.1.4
Flash Header
The flash header is a data structure that the MCU ROM reads from flash which provides information about the application. The location of the flash header must be located at a known fixed address depending on the type of external flash device connected to i.MX51. The required offsets of the flash header for each device type are mentioned in Table 1-13.
Table 1-13. Flash header offset
Flash Type NOR NAND OneNAND SD/MMC/eSD/eMMC I2C/HS-I2C/SPI EEPROM Offset from the base address 4 kbyte = 0x1000 bytes 1 kbyte = 0x400 bytes 256 bytes = 0x100 bytes 1 kbyte = 0x400 bytes 1 kbyte = 0x400 bytes
Figure 1-4. Flash Header Example for Devices Other than NOR Flash
Flash Memory
Flash base Dest. Memory
Flash Header offset
*app_code_jump_vector app_code_barker *app_code_csf **dcd_ptr_ptr *super_root_key *dcd_ptr *app_dest_ptr
Flash Header offset
*app_code_jump_vector app_code_barker *app_code_csf **dcd_ptr_ptr *super_root_key *dcd_ptr *app_dest_ptr
application device configuration data External Flash hdr super root key certificates and csf data
application device configuration data External Flash hdr super root key certificates and csf data
The flash header must follow the structure defined below:

typedef struct { UINT32 UINT32 *app_code_jump_vector; app_code_barker;
Proprietary
System Boot
UINT32 DCD_T hab_rsa_public_key DCD_T UINT32 } FLASH_HDR_T;
*app_code_csf; **dcd_ptr_ptr; *super_root_key; *dcd_ptr; *app_dest_ptr;
where: UINT32 is a 32 bit unsigned integer DCD_T is a structure that defines the device configuration table (see below for details) hab_rsa_public_key is a structure defines the super root key
app_code_jump_vector pointer: Points to the address of the first instruction of the application app_code_barker: A value that the ROM uses to determine that the flash device has been programmed. For i.MX51 the app_code_barker value must be set to 0x000000B1. app_code_csf pointer: Points to the certificate and command sequence file data. This data is used by High Assurance Boot library included in the ROM to verify that the application is authentic. See Section 1.9 for further details. dcd_ptr_ptr double pointer: This pointer must be set to point to the dcd_ptr also contained in the flash header structure super_root_key: Pointer to the super root key data. The super root key data should conform to the following structure:
typedef struct { UINT8 rsa_exponent[MAX_EXP_SIZE]; UINT8 *rsa_modulus; UINT16 exponent_size; UINT16 modulus_size; BOOLEAN init_flag; } hab_rsa_public_key; /* /* /* /* /* RSA public exponent */ RSA modulus pointer */ Exponent size in bytes */ Modulus size in bytes */ Indicates if key initialized */
where: UINT8 is an 8 bit unsigned integer UINT16 is a 16 bit unsigned integer BOOLEAN is an 8 bit flag indicating TRUE or FALSE
rsa_exponent: Exponent of the RSA key. The maximum exponent size is 4. rsa_modulus: Pointer to the RSA key modulus. exponent size: Exponent size in bytes. Must be less than or equal to the maximum exponent size. modulus size: Modulus size in bytes. Must be greater than or equal to 128 and less than or equal to 256. dcd_ptr: Points to the Device Configuration Table (DCD) data. See Section 1.4.1.1.5 for further details on the DCD table. app_dest_ptr: Is used by the ROM for NAND/MMC/SD/OneNand/I2C/HS-I2C/SPI EEPROM boot. During boot the ROM copies the application data from boot flash memory to destination RAM. This pointer defines the location of destination memory where the ROM will copy the application.

System Boot
Flash Header for NAND Boot devices In case of NAND boot case, an additional flash header must be defined as shown in flash header Figure below. The flash header must be located immediately after the DCD table and contains the length of the data to be read from boot device.
/* Flash Header Structure */ typedef struct { UINT32 length; /* Length of data to be read from nand flash */ } FLASH_CFG_PARMS_T; where: UINT32 is a 32 bit unsigned integer.
length: This parameter is required to determine the length of image to copy to RAM. Address Cycle Values for NAND Boot Devices In the case of NAND boot, there will be no software look up table in boot ROM to determine the address cycle value; this value will be determined by the efuses. The various NAND flash configuration parameters are obtained from efuses as described in Table 1-2. Error Correction and Error Detection NFC automatically generates ECC code for both main and spare data during NFC data loading/reading to/from NAND Flash, and NFC updates ECC in the ECC status Register. NFC performs error detection and error correction.If ECC errors are not more than allowable limit(For 4 bit ECC,allowable limit is 4 and for 8 bit ecc it is 8) NFC will correct those errors. On device power on, the copy of first 4k boot data from NAND flash device Block-0 to NFC buffer is done by boot ROM. Since in NAND flash devices there are possibility of getting errors while reading first 4k boot data from first block(NAND device Block-0), the user is required to duplicate the first 4k boot code to subsequent Block-1(NAND device block), to serve as a 2nd copy option. The boot ROM code, takes advantage of the duplicate boot code, by the following flow: If no ECC errors are detected in first boot block, boot execution will perform the secure internal boot. If ECC Error is detected in first 4K boot data from Block-0(NAND device block), the boot ROM code would copy the 4k boot data from the block-1(NAND device block): If no error detected, boot flow will continue performing the secure internal boot. If an error is detected in the subsequent boot block, boot ROM code will log an error and jumps to USB/UART bootloader. The logged error can be queried via the serial protocol.
Proprietary
System Boot
First 4k Boot Data starts from Block 0 Rest of Image Copy of First 4k Boot Data from Block 1
BLOCK 0 of NAND
BLOCK 1 Copy of Rest of Image Block 1 of NAND
BLOCK 2- n
Figure 1-5. Representation of data in NAND flash device
1.6.1.4.1
Flash Header for SD/eSD/MMC/eMMC Boot devices
In case of SD/MMC/eMMC boot case, an additional header must be defined (similar to that mentioned for NAND) as shown in Figure 1-6 The header must be located immediately after the DCD table and contains the length of the data to be read from boot device. eSDHC automatically generates CRC code during eSDHC data write /read to/from SD/MMC/eMMC, and eSDHC updates CRC in the CRC status Register. Boot-software will perform following operations: 1) Copy the 2k boot block data into IRAM. 2)Check the error using CRC. If no error, jump to address (base address plus the offset mentioned in Table 1-13 for SD/MMC/eMMC) of IRAM to authenticate the application if required. If error occurs, boot ROM code will log an error and jumps to USB/UART bootloader. The logged error can be queried via the serial protocol.

System Boot
Note: Boot block mentioned here is different from the SD/MMC block.Boot block size is fixed to 2kB.
2K Boot Block Data Starts from BLOCK 0
Rest of Image
Figure 1-6. Representation of data in SD/MMC card
Proprietary
System Boot
1.6.1.4.2
Flash Header for I2C/HS-I2C/CSPI EEPROM Boot devices
In case of I2C/HS-I2C/CSPI EEPROM boot case, an additional header must be defined (similar to that mentioned for NAND) as shown in Figure 1-4. The header must be located immediately after the DCD table and contains the length of the data to be read from boot device. Representation of image data in I2C/HS-I2C/CSPI EEPROM would be as shown in Figure 1-7. Boot-software will perform following operations: 1) Copy the 2k boot block data into IRAM. 2)Check the error using barker value. If no error, jump to address (base address plus the offset mentioned in Table 1-13 for I2C/HS-I2C/CSPI EEPROM) of IRAM to authenticate the application if required. If error occurs, boot ROM code will log an error and jumps to USB/UART bootloader. The logged error can be queried via the serial protocol. Note: Boot block mentioned here is different from the I2C/HS-I2C/CSPI EEPROM block.Boot block size is fixed to 2kB.
Rest of Image
Figure 1-7. Representation of data in I2C/CSPI EEPROM
1.6.1.4.3
Flash Header for OneNand Boot device
In case of OneNand boot case, an additional header must be defined (similar to that mentioned for NAND) as shown in Figure 1-4. The header must be located immediately after the DCD table and contains the length of the data to be read from boot device.At system power-up, OneNAND automatically copies 1 Kb data from start of flash array (sector 0 and sector 1, page 0, block 0) to its Boot RAM i.e. Boot RAM contains the OneNAND flash header.Boot ROM will copy the 1Kb OneNAND boot RAM contents to

System Boot
destination address (located in the app_dest_ptr entry of application header) and decrement length of the image to be read from OneNAND by 1 K. Boot RAM area is memory mapped and copying operation will be simple memory copying operation. The length of image to be read from OneNAND device is specified in flash header structure described in Figure 1-8 below.Any failure of loading data from OneNAND flash for any reason would force MCU Boot ROM to switch to serial download.
Rest of Image
Figure 1-8. Representation of data in OneNand Flash
1.6.1.4.4
Device Configuration Data (DCD)
Some peripherals need to be configured before making use/ efficient use of it. The corresponding device specific configuration data is termed as DCD. Upon reset, the i.MX51 uses the default register values for all peripherals in the system. These settings typically are not ideal for achieving optimal system performance. For example, the EIM default settings allow core to interface to a NOR flash device immediately out of reset. This allows to interface with any NOR flash device, but has the cost of slow performance. Besides some peripherals like SDRAM etc. might require some sequence of register programming as part of configuration before its ready to be used. It is assumed that EIM registers and ESDCTL registers will be set up via DCD. ROM bootstrap has a provision for accommodating solutions to above scenarios. To allow users to configure for better performance, the ROM reads a DCD table from the flash device. The ROM determines the location of the DCD table based on information located in the flash header shown in Figure 1-4 above. This DCD table is an array of (access type, address and value) pairs preceded by a barker code and length field. The number of DCD entries is limited to 60.
Table 1-14. DCD block
Proprietary
System Boot
Field Name DCD-barker DCD-block-length
Description Barker for sanity check The total length in bytes of theDCD block (excluding this length field as well as the barker code) Followed by an array of structures with following fields Type of pointer (byte, halfword, word, wait/read) in the following field The absolute address of the register to be programmed The value to be programmed at above address
Size (bytes) 4 4
Value
0xE91972B1
DCD-address-type DCD-address DCD-value
4 4 4
Note: The DCD is read as 32-bit words, and must therefore be aligned on a word boundary. The set of registers programmable with DCD must be restricted for security. Since the device configuration block is only post-authenticated (i.e. after it has already been used), the restriction has to be very tight. ROM bootstrap performs boundary checking of DCD-address in the device configuration block against the valid range of addresses. The allowed register sets by the device configuration block are defined in the table below:
Table 1-15. DCD valid modules Valid list of modules Clock Controller Module Universal Asynchronous Receiver/Transmitter-1/2/3 Universal Synchronous Bus(USBOH3) IOMUX (only for pad drive strength registers SW_PAD_CTL) PLL(1,2,3) Registers Watchdog(1) NAND Flash Controller(NFC) Enhanced Synchronous Dynamic RAM Controller Wireless External Interface Module Enhanced SD Host Controller(eSDHC1,2,3,4) External Interface Module Inter IC 1/2, HS-I2C Multi Master Memory Interface module enhanced Configurable serial peripheral interface 1/2 Chip Select 0 - Chip Select 4 CSD0 - CSD1
ROM bootstrap maintains an array of lower and upper addresses for each module allowed to be programmable through DCD. This array is utilized for verifying any attempt to configure a register other than that are allowed. ROM bootstrap determines the size of the block by reading DCD-block-length and copies it into IRAM. It is considered to be an error if Any register address is outside the pre-defined range.

System Boot
The length of the DCD exceeds the maximum acceptable size. That is MAX_HW_CFG_SIZE (in bytes). Assuming maximum of sixty elements for the array it amounts to seven hundred and twenty bytes. Any other failure.
If successful, it configures the HW registers and failure would lead to non-initialization of intended modules. DCD error (e.g. writing to a non-supported address say like ROMPATCH) causes the ROM boot code to enter the boot loader (serial download). The DCD table must follow the structure below:
typedef struct { DCD_PREAMBLE_T preamble; /* Preamble */ /* Type / Address / data elements */ DCD_TYPE_ADDR_DATA_T type_addr_data[count]; /*where count would be some hardcoded value less than 60*/ } DCD_T;
Where:
typedef struct { UINT32 barker; /* Barker for sanity check */ UINT32 length; /* Device configuration structure length (not including preamble) */ } DCD_PREAMBLE_T;
typedef struct { UINT32 type; /* Type of pointer (byte, halfword, word, wait/read) */ UINT32 *addr; /* Address to write to */ UINT32 data; /* Data to write */ } DCD_TYPE_ADDR_DATA_T;
DCD_T typically contains the configuration data for Watchdog, SDRAM, and EIM etc.
Proprietary
System Boot
Example code:
DCD_T device_config_data = { { IROM_DCD_BARKER, // assuming this is pre-defined as macro (18 * sizeof(DCD_TYPE_ADDR_DATA_T)) },
{ {0x00000002, (UINT32 *)0x53fdc000, 0x00003F7E}, /* WDOG WCR */ {0x00000002, (UINT32 *)0x53fdc004, 0x00005555}, /* WDOG WSR */ {0x00000002, (UINT32 *)0x53fdc004, 0x0000aaaa}, /* WDOG WSR */ {0x00000004, (UINT32 *)0xb8002000, 0x14110802}, /* EIM CTL H 0x11134722 */ {0x00000004, (UINT32 *)0xb8002004, 0x80330d01}, /* EIM CTL L -0x50331D01- 16 Bit */ {0x00000004, (UINT32 *)0xb8002008, 0x00000800}, /* EIM CTL A */ {0x00000002, (UINT32 *)0xa0002394, 0x00000060}, /* EIM CS0 -6F0C- 16 Bit */ {0x00000002, (UINT32 *)0xa0002394, 0x00000003}, /* EIM CS0 -6F0C- 16 Bit */ {0x00000002, (UINT32 *)0xa0000000, 0x000000ff}, /* EIM CS0 - R/A - 16 Bit */ {0x00000004, (UINT32 *)0xb8001004, 0x000ac7a8}, /* SDRAM CS0 CFG0 - Timing */ {0x00000004, (UINT32 *)0xb8001000, 0x92110080}, /* SDRAM CS0 CTL0 - Enable */ {0x00000004, (UINT32 *)0x80000400, 0x00000000}, /* SDRAM CS0 - Precharge */ {0x00000004, (UINT32 *)0xB8001000, 0xa2110080}, /* SDRAM CS0 - Refresh */ {0x00000004, (UINT32 *)0x80000000, 0x00000000}, /* SDRAM CS0 - Refresh */ {0x00000004, (UINT32 *)0x80000000, 0x00000000}, /* SDRAM CS0 - Refresh */ {0x00000004, (UINT32 *)0xB8001000, 0xb2110080}, /* SDRAM CS0 - Load Mode */ {0x00000001, (UINT32 *)0x80000033, 0x00000000}, /* SDRAM CS0 - Load Mode */ {0x00000004, (UINT32 *)0xB8001000, 0x82114c80}, /* SDRAM CS0 - Norm Mode */ } };
Above code is based on following table.

Table 1-16. Valid DCD address range
Address range CCM register set CSD0 memory CSD1 memory WEIM register set NANDFC register set CS0 memory CS1 memory CS2 memory CS3 memory CS4 memory CS5 memory Start address 0x43FD4000 0x90000000 0xA0000000 0x83FDA000 0x83FDB000 0xB0000000 0xB8000000 0xC0000000 0xC8000000 0xCC000000 0xCE000000 Length (in bytes) 0x00004000 0x10000000 0x10000000 0x00001000 0x00000F00 0x08000000 0x08000000 0x08000000 0x04000000 0x02000000 0x01FF0000

System Boot
Address range USB OH3 memory IOMUXC registers UART 1 register UART 2 register I2C1 register WDOG register PLL1 register PLL2 register PLL3 register ESDHC1 register ESDHC2 register ESDHC3 register ESDHC4 register EMI register ESD RAM controller register M4IF register
Start address 0x73F80000 0x73F8A000 0x73FBC000 0x73FC0000 0x83FC4000 0x73F98000 0x83F80000 0x83F84000 0x83F88000 0x70004000 0x70008000 0x70020000 0x70024000 0x83FD8000 0x83FD9000 0x83FD8000
Length (in bytes) 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00004000 0x00001000 0x00001000
In boot flow the DCD data is used prior to being verified.The DCD data must be included as part of memory regions verified indicated in one of the HAB CSF commands.
1.6.2
Serial Downloader (BMOD[1:0] = 11)
Serial downloader is invoked when the external flash device is not programmed or when a failure is encountered during the boot flow process. It is invoked in any of the following condition BMOD=11 BMOD=10 && BT_VIRGIN =0 BMOD=00 /10 and no valid image in Flash ROM is in internal boot and none of the fuses for external flash are satisfied. Security hardware failure Run time exception occurs Error returned by the HAB functions in Production Mode.
Proprietary
System Boot
To determine the active serial port either UART or USB, MCU ROM polls UART and USB status register for about 32 seconds. If there is no activity on either port within predefined polling loop time then ROM will power down the phone using WDOG. In USB/UART bootloader valid case the WDOG will be serviced periodically. If the communication between the Host and ELVIS IC hangs for more than 32 sec or processor goes into and endless loop then WDOG will expire and power down the device. If UART is selected as the communication path then UART1/2/3 is configured for baud rate 115.2 kbps, parity disable, 1 stop bit and 8- bit TX-RX character length and data is downloaded using the Serial protocol (Section 1.11). Else if USB is selected then USB core and the external transceiver or Internal transceiver(Selected based on the BT_USB_SRC fuse) is configured. The USB/UART Boot flow is shown in Figure 1-9.
Figure 1-9. USB/UART Boot flow
Configure USBOTG, UART1, program WDOG(MCU) for 32 sec timer No Poll USB/UART activity
Yes
No
USB/UART ? 32 timer over USB Complete the High Speed USB enumeration process in NonStream Mode
UART
Yes
Ready for serial download
PowerDown Device

System Boot
1.6.2.1
USB
The i.MX51 USB support is composed of the USBOH3 (USB OTG core controller, compliant with the USB 2.0 specification and three additional USB hosts) and the USBPHY (HS USB transceiver). USB OTG port is the bootable USB device. Additional USB hosts are intended for the intraplatform communication and not bootable. To enumerate the ROM boot USB function the host PC needs a compatible windows driver and a specific application ADS Tool kit. Once enumerated, the USB boot device uses a specific protocol Download protocol to download an application, DCD block or CSF and launch the application. For USB boot, the USBOH3 controller is used, with either the integrated PHY (typical use), or via ULPI interface to an auxiliary PHY. Selection between the two PHYs, is determined by either is done by BT_USB_SRC fuse or the corresponded GPIO pin, Table 1-18 shows the possible fuse values and their corresponding feature enabled. The Boot ROM USB driver configures the USB controller to function in High Speed non-stream bulk mode with 512B maximal packet size. The control endpoints EP0IN and EP0OUT are configured for control transfer and for data transfer in bulk mode EP1OUT and EP2IN are configured as IN and OUT transactions respectively. The supported transceivers are in Table 1-17.
Table 1-17. Supported USB Transceivers
Transceiver Internal PHY Speed High Speed (HS) Interface UTMI USB Controller Mode High Speed(HS) non-stream bulk mode with a maximal packet size 512B High Speed(HS) non-stream bulk mode with a maximal packet size 512B
External PHY1
HS
ULPI
1USB External Phy was tested on Philips1504 and SMSC3300/3311 only
USB configuration details A High speed(HS for UTMI, ULPI )Non-stream mode with maximal packet size 512B low level USBOTG function device driver is supported. Following are the type of supported USB transceivers. USB ULPI interface. USB UTMI interface.
Proprietary
System Boot
Table 1-18.
BOOT MODE UTMI PHY ULPI PHY ELVIS fuse BT_USB_SRC=0 BT_USB_SRC=1
The VID/PID and strings for USB device driver are listed in Table 1-19
Table 1-19. VID/PID and Strings for USB Device Driver
Descriptor
Value 0x15A2 (Freescale vendor ID)
Remarks
VID
PID
0x0041
Allocated Based on BPN (Before Part Number)
String Descriptor1(iManufacturer)
Freescale Semiconductor Inc. S Blank ELVIS SE Blank ELVIS NS Blank ELVIS Freescale Flash Freescale Flash
String Descriptor2(iProduct)
String Descriptor4 String Descriptor5
A typical USB boot flow is shown in Figure 1-10.

System Boot
Figure 1-10. USB Boot flow

Read BT_USB_SRC(1/0) fuse
BT_USB_SRC =1
BT_USB_SRC ??
BT_USB_SRC=0 Com plete ULPI 8 bit Synchronous C onfiguration and U SBO TG = HS with Non-stream m ode C om plete UTM I 8bit synchronous Configuration and USBO TG = HS with Non-stream m ode
ULPI, HS path
UTM I, HS path
Com plete the USB enum eration process
Poll for Activity
1.6.2.2
UART
All the UART (UART1, UART2 and UART3) port are boot device. Once initialized, the UART boot device uses a specific protocol Serial Downloader Protocol to download an application, DCD block or CSF and launch the application. The UART driver uses the communication parameters given in the Table 1-14
Proprietary
System Boot
Table 1-20. UART Configuration

Parameter Baud rate Parity check Word size Stop bits RTS CTS Receive pin Transmit pin 115.2 kbaud Disabled 8 bits 1 bit Ignored Controlled by host RXD1 TXD1 Value
1.6.3
Internal Boot Mode with Fuses(BMOD[1:0] = 10)
Internal boot (from boot fuses only) is selected by driving value of 10 on the BOOT_MODE[1:0] pins, at device power up. This mode is equivalent to the Internal boot (from boot pins), BOOT_MODE[1:0]=00,with the only difference that boot pins are ignored, regardless to BT_GPIO_SEL fuse value. Boot alway start from boot fuses. This allows to customers to burn fuses on the closed production device, with no external muxes on BOOT_MODE, pullups/pulldowns and with no uncertainty on the way to the fallback boot downloader, caused by unknown boot pin values during the initial boot from the product device. Customers can set BOOT_MODE[1:0]=10 on production device and burn fuses on the same device (by falling back to USB/UART downloader), without changing value of BOOT_MODE[1:0] or pullups/pulldowns on the boot pins. For cleaner jumping to UART/USB boot loader in case of initial fuse burning, BT_VIRGIN fuse was introduced. If BOOT_MODE[1:0]=10&&BT_VIRGIN=0, then ROM code jumps directly to UART/USB boot loader, without trying other interfaces. BT_VIRGIN is supposed to be burnt by the customer during initial fuse burning
1.6.4
Error Logging
All the ROM errors are logged to pu_irom_error_status(Address : 0x1ffe1a98) variable.

System Boot
1.7
Exception handling
The exception vectors located at the start of internal ROM are used to map all the ARM exceptions (except the reset exception) to a duplicate exception vector table in iRAM. During the boot phase, the iRAM vectors point to the serial downloader in iROM. After boot the OS loader can overwrite the vectors as required. The code below is used to map the ROM exception vector table to the duplicate one in iRAM.
;; Define linker area for iROM exception vector table AREA IROM_VECTORS, CODE, READONLY LDR LDR LDR LDR LDR NOP LDR LDR LDR PC, PC, PC, PC, PC, Reset_Addr Undefined_Addr SWI_Addr Prefetch_Addr Abort_Addr ; Reserved vector PC, IRQ_Addr PC, FIQ_Addr PC, SW_monitor_addr
;; Define exception vector table Reset_Addr DCD start_address Undefined_Addr DCD iRAM_Undefined_Handler SWI_Addr DCD iRAM_SWI_Handler Prefetch_Addr DCD iRAM_Prefetch_Handler Abort_Addr DCD iRAM_Abort_Handler DCD 0 ; Reserved vector IRQ_Addr DCD iRAM_IRQ_Handler FIQ_Addr DCD iRAM_FIQ_Handler SW_monitor_add DCD SW monitor exception start_address DCD start ;reset handler vector
No special interrupt handling routines are required during bootup. Instead, the iRAM exception table is filled with the address of the USB/UART Bootloader module, so that any exception or interrupt will result in the RAM Path being executed. Interrupts are disabled during bootROM code execution and can be enabled after bootROM code execution.Flash or RAM applications image are responsible for enabling of interrupt as required .
Proprietary
System Boot
1.8
USB Low Power Boot
Elvis supports low power boot (LPB) mode with depleted or disconnected battery, from USB power supply only. ROM involvement in LPB is required to be minimal, while the most configuration operations, if required, will be performed by downloaded PMIC and USB drivers. The platform current consumption during LPB ROM stage shall be less than 100mA of VUSB. For this purpose, DRAM module can be disabled and the primary boot image will be downloaded to iRAM. Three Low Power Boot modes have being supported: BT_LPB[1:0]=00 - LPB Disabled BT_LPB[1:0]=01 - Generic PMIC and one GPIO input (Low battery) BT_LPB[1:0]=10 - Generic PMIC and two GPIO inputs (Low battery and Charger detect) BT_LPB[1:0]=11 - Atlas AP Power Management IC. In case of BT_LPB[1:0] = 11, ROM expects the the Atlas Interrupt to be Routed via GPIO1_5 pin.ROM reads the value on the GPIO1_5 to see whether the PMIC Interrupt is set or not.If GPIO1_5 = 1,then the LPB Flow is executed,else Normal Boot flow continues. Generic PMICs indicate power conditions through GPIO1_2 pin. In the most basic case, Generic PMIC indicate low battery condition: 0 - means battery is low/depleted/not connected 1 - battery is Ok for the normal boot. LPB status is indicated to the upper layer software by means of the bits[1:0] of the SCS1 register of the IIM module. if the value of these bit fields is 00,then it indicates Normal Boot and if the value is found to be 11,then it indicates Low power Boot For better flexibility, in BT_LPB[1:0]=10 mode, GPIO1_3 receives an indication about charger presence in the system. Maximal LPB ARM core frequency is customed and stored in fuses BT_LPB_FREQ[2:0].
Table 1-21.
LPB_FREQ[2:0] 000 Frequency Value(MHz) 192 MHz(default,out of reset,depends on CKIH OSC frequency). Please refer to section 1.6.1.2 for more details on this particular frequency. 133 55.33
001 010

System Boot
LPB_FREQ[2:0] 011 100 101 110 111 200 220 166 266
Frequency Value(MHz)
Normal boot frequency,400MHz
ROM code supports all primary boot devices in LPB mode, however the assumption that UART and USB boot devices will not be used by customers in LPB mode.
LPB flowchart is shown in Figure 1-11
1. Check Whether the LPB feature is enabled by reading BT_LPB[1:0] fuse. 2. If low power boot feature is not enabled, boot up normally. 3. If LPB feature is enabled, then follow the below procedure. 4.Check for ATLAS PMIC if it is used follow below procedure else got to step -10 5.Check for GPIO1_5 ,if it is 1 follow the below procedure. 6.Check if PHY is UTMI (BT_USB_SRC==0) and charger is connected(Using UTMI charger detection procedure). if yes go to step-15 else follow below steps 7.Check if PHY is ULPI(BT_USB_SRC==1) or UTMI charger detection failed follow below steps 8.Update the status 0x03 in the SCS1 register which will be required for Application software . 9.Initializes the clocks based on the BT_LPB_FREQ[2:0].Go to step 16 10. Query LPB conditions are met via GPIO(s) as given in the flow chart. GPIO1_2 pin indicates low battery condition is present(value = 0), GPIO1_3 pin indicates charger connected status(value =1). 11.Check whether a low battery condition exist.if yes then proceed further else go to step15. Check for wall adapter/charger(GPIO1_3) if it is available go to step-15 else follow below steps 12.Check if PHY is UTMI (BT_USB_SRC==0) and charger is connected(Using UTMI charger detection procedure),if available go to step-15 else follow below steps. 13.Check if PHY is ULPI(BT_USB_SRC==1) or UTMI charger detection failed follow below steps.Update the status 0x03 in the SCS1 register which will be required for Application software . 14. Incase a 3rd Party PMIC is used, ARM core clock is configured based on LPB_FREQ[1:0].Goto step-16. 15. Configure the PLL and clocks as in normal boot
Proprietary
System Boot
16. After the Initial 2k Copy from the selected boot device,Check for the Following condition. if the ongoing Boot is on a lowpower scenario and the Fusebank 0, Offset 0x000C, bit 1 value equals Zero,then Do a Connect (pull up on the D+ line and initiate an attach event) on the respective USB interface.This is to gain another 500ms time in context of a dead battery.Copy the rest of the Image from

System Boot
the selected boot device and proceed with the secure boot flow , loads the customer application and jumps to execute it.
Proprietary
System Boot
Figure 1-11. USB Low Power Boot Flow

Yes
LPB (Low Power Boot Check)

No
Yes
Is BT_LPB==00 ? (Is LPB allowed?)
Yes
ATLAS AP LPB
No
A
Yes
BT_LPB==11 (Is ATLAS AP allowed?)
No
If GPIO1_2==1 (Low power condition exits ?)
Yes
No
Yes
BT_LPB[1:0]==10 AND GPIO1_3==1 (Wall adapter/Charger detected ?)
No
If UTMI Phy(BT_USB_SRC==00) AND Charger(wall/usb) detected
Yes
No
If ULPI_Phy(BT_USB_SRC)==1 || UTMI charger not detected)
Yes
NORMAL BOOT Clock

(Unlimited power budget) Copy initial 2k image from the boot device Update the SCS1 to 0x03.Low Power Boot Clock Copy initial 2k from boot device
Yes
If((lowpowerboot) and (fusebank 0 offset 0x000C bit1 == 0))
Initiate an attach event on the respective usb interface
No
Copy rest of the image and Continue with secure Boot flow

System Boot
Figure 1-12. USB Low Power Boot Flow(Contd.)
A
no If GPIO1_5 pin asserted 1' yes If UTMI Phy(BT_USB_SRC==0 0) AND Charger(wall/ usb) detected no If ULPI_Phy((BT_USB_ SRC==1) || UTMI charger not detected) yes Set IIM_SCS1 reg to 0x03
yes
NORMAL BOOT Clock Config (Unlimited power budget)Copy the Initial 2k
Low Power Boot Clock .Copy the initial 2K
no
If((lowpowerboot) and (fusebank 0 offset 0x000C bit1 == 0)) Initiate an attach event on the respective usb interface
yes
Copy rest of the image and Continue with secure Boot flow
Proprietary
System Boot
1.9
High Assurance Boot (HAB)
The High Assurance Boot (HAB) component of the ROM protects against the potential threat of attackers modifying areas of code or data in programmable memory to make it behave in an incorrect manner. The HAB also prevents attempts to gain access to features which should not be available. The integration of the HAB feature with the ROM code ensures that i.MX51 does not enter an operational state if the existing hardware security modules have detected a condition that may be a security compromise or areas of memory deemed to be important have been modified.
RTICv3
Flash
SCC2, SAHARAv4LT
Core Processor
ROM
RAM
HAB
Shared peripheral
Figure 1-13. Secure Boot Components
Figure 1-13 illustrates the components used during a secure boot, and is applicable to the AP. The AP core have independent HAB libraries and make use of the shared RTICv3, shared SAHARAv4LT and SCC2. The HAB provides support for SHA-256 message digests and RSA encryption operations. The HAB supports SHA-256 through SAHARAv4LT, RTICv3 hardware modules or through a software implementation that runs on the core processor. The RSA encryption operations are performed by software.
1.9.1
HAB TYPE
The HAB requires the location of two components in flash: the starting address of the Super Root Key (SRK) data and the starting address of the Command Sequence File (CSF) data. Both of these components are defined in the flash header as illustrated in Figure 1-4. The SRK defined in the application data located in flash is validated by the HAB. The HAB will perform a SHA-256 hash digest of the SRK provided in the application data. It will then compare the computed hash with that stored in the i.MX51 efuses. If validation of the SRK is unsuccessful the ROM will enter the serial bootloader. The CSF provides the signature and certificate information for the flash image. The CSF is generated by using a client/server Code Signing Tool (CST). Function Prototypes

System Boot
1.9.1.1
HAB TYPES
The boot flow is influenced by device HAB TYPE as specified in Table 1-16.
Table 1-22. HAB Types
HAB TYPE HAB_ENGINEERING Value 0x1 Action Initialize secure hardware, execute DCD block and authenticate applications prior to their execution. Any errors detected are logged, but have no influence on the boot flow. Initialize secure hardware, execute DCD block and authenticate applications prior to their execution. Any errors detected are logged and control passes to the USB/UART Bootloader. Bypass HAB functions: do not initialize SHW, do not execute HW Configuration block and do not authenticate applications prior to their execution.
HAB_PRODUCT
0x2
HAB_SEC_DISABLED
0x4
1.9.2
Function Prototypes
Three HAB functions are available to application code residing outside of the ROM. An additional function is also available to enter the ROM serial bootloader directly. These functions can be considered trustworthy since they are located in ROM and cannot be changed.
1.9.2.1
Syntax:
pu_irom_boot_decision
void pu_irom_boot_decision(void)
Description: Entry point for the serial downloader. Performs the check of whether to use UART or USB for the serial bootloader. Inputs: None. Returned Value: None. PreConditions/Assumptions: GPIO for selecting USB Serial PHY and ULPI PHY is set appropriately .
Proprietary
System Boot
Post Conditions: None.
1.9.2.2
Syntax:
hab_csf_check
hab_result hab_csf_check( UINT8 csf_count, UINT32 *csf_list);
Description Performs integrity checks on software in programmable memory as instructed by CSFs. Inputs: The number of CSFs to be processed and their locations Returned Value: The structure
typedef struct { unsigned char status; /* Status code */ unsigned char type; /* HAB type from Table 1-22 */ } hab_result;
with processor TYPE and one of the following status codes: HAB_PASSED if all CSFs are valid and all verifications in all CSFs are satisfied. HAB_DATA_OUT_OF_BOUNDS if csf_count is 0, csf_count exceeds maximum length of CSF chain or csf_list is NULL. Appropriate error code for other failures as stated in Table 1-24, Status CodeConstants. HAB_FAILURE otherwise. Pre Condition/Assumptions: Verified blocks list and subordinate keys list are initialized. The parameter csf_list points to a list of length csf_count. Post Condition: The verified blocks list contains the list of successfully verified data blocks,padded at the end of the list to indicate that no more verified block is available. The subordinate keys list contains successfully validated subordinate keys. If HAB_SHA1_RTIC_KEEP, HAB_RSA_SHA1_RTIC_KEEP, HAB_SHA256_RTIC_KEEP and HAB_RSA_SHA256_RTIC_KEEP algorithm types are used in CSF commands, the RTIC hash digest registers and runtime enable masks are initialized in preparation for run-time mode operation.

System Boot
1.9.2.3
Syntax:
hab_assert_verification
hab_result hab_assert_verification( UINT8 *block_start, UINT32 block_length);
Description: Perform only after a CSF Check. Determines if a block of data lies within the regions of the pre-authenticated block or the regions verified during CSF Check. The state of the SCC (if enabled and the processor TYPE is not engineering) is also tested to ensure that the hardware is secure. Inputs: Starting address and length (in bytes) of the data block. Returned Value: The structure:
typedef struct { unsigned char status; /* Status code */ unsigned char type; /* HAB type from Table 1-22 */ } hab_result;
with processor TYPE and one of the following status codes: HAB_PASSED if all tests pass, HAB_FAIL_ASSERT if block is not pre-authenticated or in regions verified during CSF Check, HAB_SCC_NOT_SECURE if SCC is not in the secure state and processor TYPE is not engineering, HAB_FAILURE otherwise. Pre Condition/Assumptions: The verified blocks list contains (start, length) pairs of 32 bit unsigned integer values, padded at the end of the list to indicate that no more verified block is available. If the given block has been verified or pre-authenticated, it is assumed to lie wholly within the boundaries of a single block in the verified blocks list.
Post Condition: None.
Proprietary
System Boot
1.9.3
API Jump Table Addresses
The address of the HAB functions are available via a jump table defined in the ROM.Table 1-23 below lists the functions and the associated jump table address. Jump table is placed before copyright section. A total of 0x48 bytes space is reserved for copyright section.
Table 1-23. HAB API Jump Table Addresses
HAB API Function
hab_csf_check hab_assert_verification pu_irom_boot_decision
Jump Table Address

0x40 0x44 0x50
1.9.4
HAB Status Codes and Algorithm Types

Table 1-24. HAB Status Codes Name HAB_DATA_OUT_OF_BOUNDS HAB_FAIL_ASSERT HAB_FAIL_HASH_VERIFICATION HAB_FAIL_PK_VER Description Data specified is out of bounds. Error during Assert Verification. Hash verification failed (including hash verification on certificates). Certificate parsing failed, or the certificate contained an unsupported key (including unsupported key length). Signature verification failed (including signature verification on certificate). Super-Root key installation failed. Failure not matching any other description. CSF Command Sequence contains an unsupported command identifier. Absence of expected CSF Header (including mismatched HAB Version). CSF length is unsupported. CSF TYPE does not match processor TYPE. Value 0x8d 0x55 0x36 0x33
HAB_FAIL_SIG_VERIFICATION
0x35
HAB_FAIL_SUPER_ROOT_INSTALL HAB_FAILURE HAB_INVALID_CSF_COMMAND HAB_INVALID_CSF_HEADER
0x47 0x39 0x4b 0x4e
HAB_INVALID_CSF_LENGTH HAB_INVALID_CSF_TYPE
0x4d 0x2e

System Boot
Name HAB_INVALID_CSF_UID HAB_INVALID_CSF_CODE
Description CSF UID does not match either processor UID or generic UID. CSF Customer/Product code does not match processor Customer/Product code. Key index is either unsupported, or an attempt is made to overwrite the Super-Root key from a CSF command. Successful operation completion. SCC unexpectedly not in Secure State. SecureRAM secret key invalid. SecureRAM initialisation failure. SecureRAM Self Test failure. SCC .unexpectedly not in Non-Secure State SecureRAM internal failure. SecureRAM secret key unexpectedly in use. SAHARA failure. SAHARA/SCC connectivity failure. All RTIC regions are allocated. RTIC/SCC connectivity failure. SHW is not enabled. An attempt is made to read a key from the list of subordinate public keys at a location where no key is installed. Algorithm type is either invalid or otherwise unsupported (e.g. Debug Port activated while the HAC of a non-engineering processor TYPE is in use). Write operation to register failed.
Value 0x2d 0x3a
HAB_INVALID_KEY_INDEX
0x87
HAB_PASSED HAB_SCC_NOT_SECURE HAB_SECURE_RAM_BAD_KEY HAB_SECURE_RAM_CLR_FAIL HAB_SECURE_RAM_FAIL HAB_SCC_FAIL HAB_SECURE_RAM_INT_ERR HAB_SECURE_RAM_SEC_KEY HAB_SAHARA_FAIL HAB_SAHARA_SCC_FAIL HAB_RTIC_REGION_FAIL HAB_RTIC_SCC_FAIL HAB_SHW_DISABLED HAB_UNINITIALISED_KEY_INDEX
0xf0 0x17 0x1e 0x1d 0x1b 0x53 0x2b 0x27 0x3c 0x59 0xa3 0x93 0x0f 0x8b
HAB_UNSUPPORTED_ALGORITHM
0x8e
HAB_INVALID_WRITE_REG
0x66
Proprietary
System Boot
1.10
SRTC Initialization
The SRTC is initialized by the ROM as part of the HAB library. The SRTC low power secured registers (Secure Counter MSB/LSB Register, Alarm register and Monotonic counter register) cannot be configured by non-secure software. Non-secure software is an considered as application code executing after a secure boot that: is not executed in Trusted mode on an ARM Trustzone capable core or; not in supervisor mode. A dedicated Non Secure Access (NSA) bit in SRTC low power control register can allow non-secured SW to update the secured registers. This bit can be set only by secured software. In any case, the SRTC secured registers cannot be configured once the SRTC is locked. Neither the time nor the monotonic count can be altered after SRTC is locked, and once the SRTC is locked it cannot be disabled. The initialization steps performed by the boot ROM depend on the security mode of the SRTC.
1.10.1
SRTC Security Modes
The security mode of the SRTC is controlled by the two SRTC security mode fuses defined in the IIM and are listed in Table 1-25 below. There are three different modes that can be defined, with each mode causing the boot ROM/HAB library to operate in a different manner.
Table 1-25. SRTC Security Modes
SRTC_SECMODE value Low Security Mode Medium Security Mode High Security Mode Fuse bits 00 01 1x
When SRTC security mode is set to the High Security Mode (1x), external images, even those that are authenticated by the HAB library, are not allowed to reprogram the SRTC secure time and monotonic counter registers. Only a special RAM kernel downloaded via a serial connection is capable of reprogramming the SRTC secure time and counter registers. When SRTC security mode is set to Medium Security Mode (01) or Low Security Mode (00), then any external image is able to reprogram the SRTC secure time and counter registers. The HAB library in boot ROM does not make use of the other fuses assigned to the SRTC defined in the IIM. That is, the monotonic counter update field (SRTC_MCOUNT) and the SRTC lock (SRTC_LOCK) fuses are not updated directly by the boot ROM or HAB.
1.10.2
HAB Support For SRTC in High Security Mode
Prior to exit from the ROM the HAB ensures that the SRTC is configured appropriately for the given security mode defined in the SRTC mode efuses. The following sections describe the functionality for each SRTC mode.

System Boot
NOTE: The HAB_TYPE (HAB_PRODUCT or HAB_ENGINEERING) does not impact how the HAB library initialized the SRTC. This is dictated by the SRTC mode efuses only. In order for an application to have the capability to update the SRTC time and counter values, a special CSF must contain the following two WRITE_TO_REGISTER (WTR) commands: A WTR command to write 0xFFFFFFFF to SRTC Low Power Status register (LPSR) to clear all the failure status bits, and A WTR command to write 0x00000000 to SRTC Low Power Control Register (LPCR) to disable counter and clock. A normal CSF will not have the above specified WRITE_TO_REGISTER commands, not allowing the application to update the time and count values.
1.10.3
HAB Support For SRTC in Medium and Low Security Modes
The HAB library does not perform any initialization for these SRTC modes.
1.10.4
External Boot Support
For direct (non-secure) boot modes that require boot ROM to be executed first, such as a direct NAND flash boot, If SRTC is in High or Medium security mode the HAB sets the SV bit in SRTC LPCR to move SRTC to FAIL state. If SRTC is in INIT state, the HAB will also set IE bit along with SV bit in SRTC LPCR to move SRTC out of INIT state to FAIL state.
1.11
Serial Download protocol
This section describes the serial download protocol used for all boot devices in the serial bootloader on i.MX51. Each stage in the protocol begins with a command issued by the host to the device, followed by a response from the device to the host. For most commands, that completes the protocol stage. The exception is the Write File command, which has an additional data stream sent from the host to the device after the response. The protocol is terminated by the host issuing a Write File command with application file type. After processing the Write File commands, the device interprets the next command as a Completed command, and resumes execution of the boot flow in order to authenticate the downloaded application (if required) and then execute it.
1.11.1
Get Status
The Get Status command retrieves the error log stored during a failed boot (or the success code when Serial bootloader is selected deliberately).
Proprietary
System Boot
Table 1-26. Get Status Command

Command Response 0x05 SC 0x05 SC SC SC SC -
The fields have the following interpretation: SC = Status Code. Four copies of the status code are sent. - = Dont Care (but must be present)
1.11.2
Read Memory
The Read Memory command reads a stream of bytes, half-words or words of data starting from a given address in memory. At production-level security, this command is ignored.
Table 1-27. Read Memory Command
The fields have the following interpretation: A[3:0] = Target address (most-significant byte first). DS = Data Size (0x08 = byte, 0x10 = half-word, 0x20 = word). Unsupported DS values result in the failure response. C[3:0] = Number of data elements (bytes, half-words or words as appropriate) in data stream (most-significant byte first). ACK[3:0] = 0x56, 0x78, 0x78, 0x56. - = Dont Care (but must be present)
1.11.3
Write Memory
Table 1-28. Write Memory Command
The Write Memory command writes a byte, half-word or word of data to a given address in memory.
The fields have the following interpretation: A[3:0] = Target address (most-significant byte first). DS = Data Size (0x08 = byte, 0x10 = half-word, 0x20 = word). Unsupported DS values result in the failure response.

System Boot
D[3:0] = Data to write(most-significant byte first). For DS = 0x08, only D[0] is used. For DS = 0x10, only D[1:0] is used. ACK[3:0] = 0x12, 0x34, 0x34, 0x12 for production-level security, and 0x56, 0x78, 0x78, 0x56 otherwise. - = Dont Care (but must be present) At production-level security, the address ranges which may be written are restricted to those listed for DCD. Attempts to write outside of the valid ranges are ignored and result in the failure response. For other security levels, no restrictions apply to the target address.
1.11.4
Re-enumerate
Table 1-29. Re-enumerate Command
The Re-enumerate command resets the USB connection with an updated descriptor.
Command Response 0x09 0x89 0x09 0x23 0x23 0x89 SN[3:0] -
The fields have the following interpretation: SN[3:0] = Serial number for enumeration descriptor. - = Dont Care (but must be present)
1.11.5
Write File
The Write File command writes a stream of bytes to a given address in memory. The byte stream may be assigned a file type in order to distinguish CSF, DCD and application files. An application file type leads to the termination the serial download protocol, with the next command (whatever the command byte values) being treated as the Completed command.
Table 1-30. Write File Command
The fields have the following interpretation: A[3:0] = Target address (most-significant byte first). C[3:0] = Number of bytes in data stream (most-significant byte first). FT= File Type (0xAA = application (terminates protocol), 0xCC = CSF, 0xEE = DCD). With unrecognized FT values, the file is still downloaded, but the pointers to the three essential files are not modified. ACK[3:0] = 0x12, 0x34, 0x34, 0x12 for production-level security, and 0x56, 0x78, 0x78, 0x56 otherwise. - = Dont Care (but must be present) At production-level security, the address ranges which may be written are restricted to those listed for
Proprietary
System Boot
DCD. Attempts to write outside of the valid ranges are ignored and result in the failure response. For other security levels, no restrictions apply to the target address.
1.11.6
Completed
The Completed command is required after the Write File command with application file type in order to terminate the protocol. The content of the command is irrelevant, but a command must be sent. This command triggers authentication and DCD processing (if required) followed by execution of the application. At production-level security, if application authentication fails, the serial download protocol resumes, with the status code for authentication failure available through the Get Status command.
Table 1-31. Completed Command
Command Response 0x88 0x88 0x88 0x88 -
The fields have the following interpretation: - = Dont Care (but must be present)

System Boot
1.12
Appendix - A
Table 1-32. Nand Device Addressing
Device Number of address cycle Page per Block Notes 1 Command Address 2 3 4 5 Command Col1 Row1 Row2 Row3 None None Col1 Col2 Row1 Row2 Row3 0x30 Col1 Col2 Row1 Row2 None 0x30 Col1 Col2 Row1 Row2 Row3 0x30
1/2 KB page, SLC/MLC
32
2KB SLC
62
5 LSB bits of Row1 give offset in block & 13 remaining bits choose block number 6 LSB bits of Row1 give offset in block & 11 remaining bits choose block number
0x00
0x00
2KB MLC
128
7 LSB bits of Row1 give offset in block & 9 remaining bits choose block number
0x00
4KB SLC/MLC
128
7 LSB bits of Row1 give offset in block & 12 remaining bits choose block number
0x00
Proprietary
System Boot

Device Page Copying for 8KB Block Address Cycle
Page1 Page2 Page3 Page4 Page5 512Byte Page SLC/MLC Page6 Page7 Page8
0x00,0x00,0x00,0x00 0x00,0x01,0x00,0x00 0x00,0x02,0x00,0x00 0x00,0x03,0x00,0x00 0x00,0x04,0x00,0x00 0x00,0x05,0x00,0x00 0x00,0x06,0x00,0x00 0x00,0x07,0x00,0x00
Next Block accesses (upon Error) Page1 Page2 Page3 Page4 Page5 Page6 Page7 Page8 0x00,0x20,0x00,0x00 0x00,0x21,0x00,0x00 0x00,0x22,0x00,0x00 0x00,0x23,0x00,0x00 0x00,0x24,0x00,0x00 0x00,0x25,0x00,0x00 0x00,0x26,0x00,0x00 0x00,0x27,0x00,0x00

System Boot

Page1 Page2 2 KB Page SLC 0x00,0x00,0x00,0x00,0x00 0x00,0x00,0x01,0x00,0x00
Next Block accesses (upon Error) Page1 Page2 0x00,0x00,0x40,0x00,0x00 0x00,0x00,0x41,0x00,0x00

Page1 Page2 2 KB Page MLC 0x00,0x00,0x00,0x00,0x00 0x00 0x00 0x01 0x00 0x00
Next Block accesses (upon Error) Page1 Page2 0x00 0x00 0x80 0x00 0x00 0x00 0x00 0x81 0x00 0x00
Figure 1-14. Nand Device Addressing

Device Page copying for 8KB Block Page1 Address Cycles 0x00,0x00,0x00,0x00,0x00
4 KB Page SLC/MLC
Next Block accesses (upon Error) Page1 0x00,0x00,0x80,0x00,0x00
Proprietary
System Boot
1.13 1.13.1
Appendix - B Application Note: Boot from a NAND device

Introduction
1.13.1.1
This Section explains the various fuse settings that need to be performed on the Elvis SOC for booting from NAND device to happen.Boot ROM copies only the Initial Program Loader(IPL),autenticates the IPL and jumps to execute the IPL.IPL is a small program whose responsibilty is to download and execute the rest of the Program Image.Also a brief description is given on the various components of the IPL(Initial Program Loader).
Download and Jump BOOT ROM
INITIAL PROGRAM LOADER (IPL)
Figure 1-15. ROM copies the IPL and jump to execute it
The various components that needs to be present in the IPL is dependent on the HAB_TYPE[2:0] fuse values.The Figure shown below shows the typical example about the IPL image layout. DCD DATA : Device configuration data.This block consist of the Barker value(0xB17219E9),length of the DCD,then the access type- address -value triplets. External Flash Header : The Length of the IPL has to be present in this field.It is expected to be present at the location where DCD data ends. APPLN : Customer application Code. Flash Header : This Block Contains the Information about the IPL.This is expected to be present at a fixed offset.For Nand,this is at 0x400byte offset from the base address. CSF DATA : Certificate and Command sequence file data SRK DATA : Super Root key data.

System Boot
NAND FLASH
Flash base 0x000
DCD DATA External flash header
DESTINATION MEMORY 0x90000000 0x90000100

DCD DATA External flash header
0x90000300
APPLN APPLN
Flash header 0x400
0x90000400
FLASH HEADER FLASH HEADER
0x90000500
CSF DATA
CSF DATA
0x90004F00
SRK DATA SRK DATA
app_start_addr app_barker csf_ptr dcd_ptr_ptr srk_ptr dcd_ptr app_dest_ptr

Flash header structure
IPL Component layout in Flash and the Destination Memory(CSD0)
Figure 1-16. IPL Component Layout in Flash and the Destination Memory
Proprietary
System Boot
The IPL should consist of the following components for various HAB TYPE values :-
Case 1: HAB TYPE = ENGG(001b)
1.FLASH HEADER (APP HDR) 2.APPLICATION (APPLN) 3.CSF data (CSF - Not Mandatory) 4.RSA Exponent and modulus(SRK data- Not Mandatory) 5.DCD Data( DCD)
Case 2: HAB TYPE = PROD(Any value in the range 000b to 111b other than 001b and 100b)
1.FLASH HEADER (APP HDR ) 2.APPLICATION (APPLN ) 3.CSF data (CSF ) 4.RSA Exponent and modulus(SRK data) 5.DCD Data( DCD)
Case 3: HAB TYPE = SECURITY DISABLED(100b)
1.FLASH HEADER (APP HDR) 2.APPLICATION (APPLN ) For the ROM to Work with SLC NAND Flash(Device Model Details :512 byte PageSize,8 bit Bus Width, 3 Address Cycle,128 byte Spare Area),the Fuses below has to be configured as Shown below. BT_MEM_CTL[1:0] = 01 BT_MEM_TYPE[1:0] = 00 BT_BUS_WIDTH[1:0] = 00 BT_PAGE_SIZE[1:0] = 00 BT_MLC_SEL =0 BT_SPARE_SIZE = 0 In addition to these fuses mentioned above,HAB TYPE[2:0]fuses and the BMOD pins has to be set as per the Intended case.
For Internal Boot Mode operation, the IPL for Nand has to have the Flash Header placed at an Offset of 0x400 from the base address.

System Boot
1.13.2
Flash Header details
Case 1 ENGG mode :
In BMOD[1:0] = 00(Internal Mode) with HAB TYPE[2:0] = 010(ENGG), then the FLASH HDR need to have a proper app_start_addr, app_barker(0x000000B1), dcd_ptr_ptr, dcd_ptr, app_dest_ptr. The Other pointers in the Flash header can be NULL. dcd_ptr_ptr: This must be set to point to the dcd_ptr which is present in the flash header structure.dcd_ptr points to the DCD data which is expected to be in the format as Suggested in the Device Configuration Data (DCD) section of the System Boot chapter.This field must be set to FLASH_HEADER start address + 0x14 (e.g., if the flash header starts at 0x1FFEA400, then dcd_ptr_ptr field must have a value of 0x1FFEA400 + 0x14 = 0x1FFEA414) ROM Copies the Initial 4K data from the Flash to the nfc buffer,Installs the DCD data,then copies the initial 4k data from the nfc buffer onto the destination address pointed by the app_dest_ptr. In the IPL,at the end of the DCD table,length of the IPL is expected by the ROM code.ROM uses this field to copy the rest of the Image from the NAND device onto the destinaton RAM pointed by the app_dest_ptr. The format of the srk_ptr can be found from the Flash header Section of the System boot chapter. If the app_dest_ptr is an IRAM address,then no DCD needs to be Installed.In this case the DCD data can have only the DCD-barker field and the DCD-block-length field whose value is equal to zero. A typical Flash header structure for ENGG mode is shown below:struct flash_hdr { UINT32 app_start_addr; UINT32 app_barker; UINT32 csf_ptr; UINT32 dcd_ptr_ptr; const hab_rsa_public_key *srk_ptr; UINT32 dcd_ptr; UINT32 app_dest_ptr; }const start_app = {0x90000300, 0x000000B1, 0x00, (0x90000400+0x14), 0x00, 0x90000100,0x90000000};
Case 2 PROD mode:
In BMOD[1:0] = 00(Internal Mode) with HAB TYPE[2:0] = PROD,then the FLASH HDR need to have all the elements properly filled.ROM Copies the Initial 4K data from the Flash to the nfc buffer,Installs the DCD data,then copies the initial 4k data from the nfc buffer onto the destination address pointed by the app_dest_ptr.
Proprietary
System Boot
In the IPL,at the end of the DCD table,length of the IPL is expected by the ROM code.ROM Uses this Field to Copy the rest of the Image from the NAND device onto the Destination RAM pointed by the app_dest_ptr. Then the Security check is performed on the Downloaded Code. Following region in the IPL has to be signed. 1.Flash Header 2.Application Code 3.DCD data. These regions has to be mentioned in the CSF certificate while doing the Signing. The SRK HASH values have to be blown onto the Fuses SRK_HASH[255:0]. The SCC key values has to be blown onto the fuses SCC_KEY[0:163],if not blown then the SCC will be moved to insecure state and Production test case fails. The Unique ID UID[0:63],Customer Code HAB_CUS[7:0] fuses also have to be blown to appropriate values that matches with that present in the CSF file. A typical Flash header structure for PROD mode is shown below:struct flash_hdr { UINT32 app_start_addr; UINT32 app_barker; UINT32 csf_ptr; UINT32 dcd_ptr_ptr; const hab_rsa_public_key *srk_ptr; UINT32 dcd_ptr; UINT32 app_dest_ptr; }const start_app = {0x90000300, 0x000000B1, 0x90000500, (0x90000400+0x14)), 0x90004F00, 0x90000100,0x90000000};
Case 3 Security Disabled Mode: In BMOD[1:0] = 00(Internal Mode) with HAB TYPE[2:0] = 100(Security Disabled),then the FLASH HDR need to have only the app_start_addr and the app_barker whose value is 0x000000B1.ROM Will Copy the initial 4k data onto the nfc buffer and check for the barker value and jump to the app_start_addr. Example of flash header can be as follows:struct flash_hdr { UINT32 app_start_addr; UINT32 app_barker; UINT32 csf_ptr; UINT32 dcd_ptr_ptr; const hab_rsa_public_key *srk_ptr; UINT32 dcd_ptr; UINT32 app_dest_ptr; }const start_app = {0xCFFF0000, 0x000000B1, 0x0, 0x0, 0x0, 0x0,0xCFFF0000}; Note : -In this case IPL should be linked to NFC Buffer as DCD processing is not supported in Security Disabled Mode.


MX51 Boot Block Guide 1.3

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

MX51 Boot Block Guide 1.3

Diunggah oleh

Hak Cipta:

Format Tersedia

System Boot

Chapter 1 System Boot

ELVIS IC Users Guide, Rev .1.3 1-2

Freescale Confidential Proprietary

iROM and iRAM memory map

R eset and E x c e p tio n v e c to r T a b le C o p y R ig h t a n d R O M v e r s io n H A B A P I V e c to r T a b le

DATA 0x1FFE 2000 0x00003FFF

STACK R O M B o o t s tr a p 20KB E x c e p tio n V e c to r T a b le 0x00408FFF

0x1FFFFFB 8 0x48 0x1FFFFFFF

Figure 1-1. iROM and iRAM memory map

Internal boot with fuses

ELVIS IC Users Guide, Rev .1.3 1-4

Freescale Confidential Proprietary

Table 1-2. Fuse Descriptions Fuse

Table 1-2. Fuse Descriptions (continued) Fuse

(eMMC4.3 fastboot is supported in eSDHC3-4)

ELVIS IC Users Guide, Rev .1.3 1-6

Freescale Confidential Proprietary

Table 1-2. Fuse Descriptions (continued) Fuse

Table 1-2. Fuse Descriptions (continued) Fuse

Varies - used by HAB Varies - used by HAB

Indication that BOOT area was not burnt yet

Options for Low Power Boot mode.

ELVIS IC Users Guide, Rev .1.3 1-8

Freescale Confidential Proprietary

DIR_BT_DISABLE 0(External boot is allowed)

Boot Option fuses and associated Pins

Table 1-5. Fuses and associated pins used for boot

ELVIS IC Users Guide, Rev .1.3 1-10

Freescale Confidential Proprietary

ELVIS MCU ROM Code High Level Bootflow

Boot pins and fuses are sampled

KEY Low Power Boot Boot Pins E- Fuses Hardware

FSL TEST MODE(BMOD=1) && DIR_BT_DIS=0

Yes Sleep mode

Security HW test (SCC key Check)

Infinite SCC_RAM test No INTERNAL Bootloader(BMOD=0 || (BMOD=2 && DIR_BT_DIS=1))

FSL Test Mode

Infinite GMEM test

BT_MEM_ CTL == EIM and BT_MEM_TYPE == NOR No

WEIM MUX mode selection BT_WEIM_MUXE D[1:0]

Basic Config and Obtain base addr Of boot device

BT_MEM_ CTL == EIM and BT_MEM_TYPE == OneNand No

HAB check image is verified ? Code Barker Valid? Yes No

Yes BT_MEM_CTL == NAND No BT_MEM_CTL == Expansion Card Device(SD/MMC / eMMC/eSD/) No Yes

Configure NFC controller and copy initial 4k of data to NFC Buffer

Configure eSDHC1-esdhc4 controller and read initial 2k of data to IRAM

Boot Mem ctrl SPI/I2C

Configure SPI/I2C And download initial 2k data to iRAM

HAB check and Execution Flow

Configure I2C Read ADR/DATA pairs To iRAM

UART UART/USB Secure Download? (Wait for activity on one of devices)

Initialize UART BT_UART_SR C[1: 0]

USB Start WDOG timer

Initialize USB Driver

Issue Reset to PMIC

Figure 1-2. Boot Flow

ELVIS IC Users Guide, Rev .1.3 1-12

Freescale Confidential Proprietary

Internal Boot mode (BMOD[1:0] = 00)

Table 1-7. PLL Configuration

Table 1-8. Normal Frequency Clocks Configuration

ELVIS IC Users Guide, Rev .1.3 1-14