AXEL ULite SOM/AXEL ULite Hardware/Power and Reset/Boot process and bootstrap configuration

Introduction

NXP iMX6UL processor implements a very flexible boot process. This versatility comes at the price of a non trivial bootstrap configuration scheme. Typical system-on-module (SOM for short) adopter does not want/need to deal with such complexity. In other words he/she expects to manage few boot configuration issues because it is assumed they are handled by the SOM itself. Nevertheless, there are specific applications where the system integrator needs full control of all the bootstrap configuration options, even if the design is built upon a SOM.

These two needs - ease of use and configurability - clearly push in opposite directions. During the conception of the product AXELULite, specific attention has been addressed to find a viable trade off to satisfy such requirements. This effort has led to the options that are detailed in the section Options for AXELULite users. Before skipping to it, it is recommended to read this section that depicts an overview of the processor's boot process. For more details about it please refer to .

Overview of NXP iMX6UL bootstrap process

When it comes to boot process, three factors play a major role:

• BOOT_MODE signals (BOOT_MODE1, BOOT_MODE0)
• eFUSE bits
• GPIO settings.

Generally speaking, three main boot modes are supported. These modes are selected by BOOT_MODE signals that are latched when processor comes out of reset.

BOOT_MODE[1:0]	Boot type
00	Boot from eFUSEs
01	Serial downloader
10	Internal boot
11	reserved

It is worth remembering that, no matter what modes is selected, when processor reset is released, internal Boot ROM is executed. Its behavior depends on selected mode as described in the following sections.

Boot from eFUSEs

The term eFUSEs refers to an one-time-programmable (OTP) memory integrated in iMX6UL processor. This memory is organized in several 32-bit words. Some of these words - named BOOT_CFG - are used to store configuration bits that affect the boot process, when Boot from eFUSEs mode is selected. In this case, Boot ROM reads BOOT_CFG words and acts consequently. In particular it tries to retrieve the Program Image [1] from the selected device (NOR flash, NAND flash, SD card etc.), as per BOOT_CFG bits.

BOOT_CFG includes many configuration settings. Some of them are particularly important for the boot strategy:

• BT_FUSE_SEL (shipped value = 0)
• SDMMC_MFG_DISABLE (shipped value = 0)
• FORCE_INTERNAL_BOOT.

The use of these settings will be more clear soon.

In case Program Image retrieval fails, Boot ROM can attempt to retrieve an alternative valid Program Image. For more details please refer to .

[1] Program Image includes - but it is not limited to - the code that is executed by the processor when Boot ROM jumps to it.

Internal boot

This mode is similar to Boot from eFUSEs with one notable difference related to the so called GPIO override option.

The selection of the device from which the Boot ROM retrieves Program Image along with several further device-specific configuration settings, can be done in two different ways, depending on BT_FUSE_SEL bit:

• 0 (shipped value): GPIOs
  • This technique - also known as GPIO override - is typically used during the development stage. It allows to use 24 GPIOs (specifically LCD1_DATA[23:00]) to configure BOOT_CFG bits.
• 1: eFUSE.
  • In this case BOOT_CFG bits are fetched from OTP memory.

Serial downloader

Serial Downloader mode is used to download a Program Image over one of the following connections:

• USB OTG1
• UART1
• UART2.

When this mode is selected, Boot ROM continuously polls for a connection over these interfaces.

It is worth remembering that, when Serial Downloader is enabled, Boot ROM needs to initialize muxing of UART1/UART2 signals as per the following table.

Ball name	Ball reference	Signal name	Mux mode
UART1_TX_DATA	TBD	uart1.TX_DATA	Alt 0
UART1_RX_DATA	TBD	uart1.RX_DATA	Alt 0
UART2_TX_DATA	TBD	uart2.TX_DATA	Alt 0
UART2_RX_DATA	TBD	uart2.RX_DATA	Alt 0

Since these pads may be used to implement different functions other than UART signals in customer's application, system integrator needs to verify that the Serial Downloader - if used - is electrically compatible with his/her own carrier board.

Typical scenario

This section describes the typical scenario related to the development/manufacturing process of an iMX6UL-based system.

During the development stage, processor is configured as follows:

• Boot mode is Internal boot, selected via BOOT_MODE pins
• eFUSE have not been programmed, thus GPIO override is enabled because BT_FUSE_SEL is 0
• according to GPIOs settings, Boot ROM retrieves program image from the selected device.
• LCD1_DATA[23:00] are connected to a circuitry [1] that allows to change easily GPIO settings in order to test different configurations.

Once the product has been qualified and the production boot strategy has been defined, the definitive boot configuration needs to be stored permanently in OTP memory. This operation is usually performed during the manufacturing process. To implement it, the Manufacture mode may come to help. This mode is associated to the SDMMC_MFG_DISABLE setting that by default is 0 (manufacture mode enabled). Therefore the typical manufacturing process looks like this:

• BOOT_MODE pins are set to 00 in order to select Boot from eFUSEs boot mode
• at the first power up
  • Boot ROM tries to load a Program Image from SDHC1 because SDMMC_MFG_DISABLE is 0
  • if no SD/MMC card is found [2], Boot ROM switches to serial download mode
    • as a consequence, Boot ROM polls for a connection over these interfaces: USB OTG1, UART1 and UART2
  • Boot ROM jumps to user code (no matter if this has been retrieved from SD/MMC card or downloaded through serial connection)
  • user code takes care of several tasks including the programming of eFUSEs; in particular:
    • SDMMC_MFG_DISABLE is blown [3] in order to disable permanently manufacture mode
    • BT_FUSE_SEL is blown in order to indicarte Boot ROM that eFUSEs have been programmed
    • FORCE_INTERNAL_BOOT is blown in order to ignore BOOT_MODE pins from now on
    • depending of application's security requirements, other eFUSEs may be blown; for example SDP_DISABLE is blown in case serial download has to be completely disabled
• the system has been fully programmed and can be finally booted in its production configuration
  • as FORCE_INTERNAL_BOOT has been blown, Internal boot mode is selected, no matter the status of BOOT_MODE pin is
  • as BT_FUSE_SEL is 1, Boot ROM retrieves the Program Image according to BOOT_CFG bits that are read from eFUSEs
  • Boot ROM jumps to user code and normal boot process is performed (this typically consists of the execution of the bootloader U-Boot and then the operating system kernel).

[1] This circuitry - that will not be populated in mass production stage - is such that it operates until Boot ROM reads GPIO pads status. Once this operation is completed, GPIO pads should be electrically disconnected from this circuitry to prevent any interference with the actual use of these signals.

[2] The detection of SD/MMC card presence is done by polling the status of the pad SD1_CD. If it is 0, SD/MMC card is present.

[3] It means it is set to 1.