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

<section begin="History" />
{| style="border-collapse:collapse; "
! colspan="4" style="width:100%; text-align:left" ; border-bottom:solid 2px #ededed" |History
|- 
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Issue Date
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#73B2C7; padding:5px; color:white" |Notes
|-
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |{{oldid|5201|2016/07/21}}
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |New documentation layout
|-
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |{{oldid|11245|2020/11/03}}
| style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#edf8fb; padding:5px; color:#000000" |Add NOR-NAND boot option information
|-
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#ededed; padding:5px; color:#000000" |2021/07/15
! style="border-left:solid 2px #73B2C7; border-right:solid 2px #73B2C7;border-top:solid 2px #73B2C7; border-bottom:solid 2px #73B2C7; background-color:#ededed; padding:5px; color:#000000" |Add DLT eFuses programmed model
|}
<section end="History" />
__FORCETOC__
<section begin="Body" />

==Boot process and bootstrap configuration==
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 need to deal with such a complexity. In other words, he/she expects to manage few boot configuration issues because it is assumed that most of them are "hidden" within 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 inception of the AXEL ULite product, 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 AXEL ULite users|Options for AXEL ULite users]]. Reader can skip directly to this paragraph, however he/she is encouraged to read [[#Overview of NXP iMX6UL bootstrap process|this section]] as well, in order to get an overview of the processor's boot process. 

It is worth remembering that an exhaustive discussion of this issue is beyond the scope of this article. For more details, please refer to <ref name="IMX6ULRM">NXP, IMX6ULRM, ''i.MX 6UltraLite Applications Processor Reference Manual''</ref>.

===iMX6UL bootstrap process overview===
When it comes to boot process, three factors play a major role:
*BOOT_MODE signals (<code>BOOT_MODE1</code>, <code>BOOT_MODE0</code>)
*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.
{|class="wikitable" style="text-align: center;"
|-
!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 <code>BOOT_CFG</code> - are used to store configuration bits that affect the boot process, when ''Boot from eFUSEs'' mode is selected. In this case, Boot ROM reads <code>BOOT_CFG</code> 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 <code>BOOT_CFG</code> bits.

<code>BOOT_CFG</code> includes many configuration settings. Some of them are particularly important for the boot strategy:
*<code>BT_FUSE_SEL</code> (shipped value = 0)
*<code>SDMMC_MFG_DISABLE</code> (shipped value = 0)
*<code>FORCE_INTERNAL_BOOT</code>.
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 <ref name="IMX6ULRM"></ref>.


[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 <code>BT_FUSE_SEL</code> 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 <code>BOOT_CFG</code> bits.
* 1: eFUSE.
**In this case <code>BOOT_CFG</code> 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.
{|class="wikitable" style="text-align: center;"
|-
!Ball name
!Ball reference
!Signal name
!Mux mode
|-
| UART1_TX_DATA||K14||uart1.TX_DATA||Alt 0
|-
| UART1_RX_DATA||K16||uart1.RX_DATA||Alt 0
|-
| UART2_TX_DATA||J17||uart2.TX_DATA||Alt 0
|-
| UART2_RX_DATA||J16||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 <code>BT_FUSE_SEL</code> 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 validated 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 <code>SDMMC_MFG_DISABLE</code> setting that by default is 0 (manufacture mode enabled). Therefore the typical manufacturing process looks like this:
*<code>BOOT_MODE</code> pins are set to 00 in order to select ''Boot from eFUSEs'' boot mode
*at the first power up
**if SD/MMC card connected to SDHC1 is found [2], Boot ROM tries to load a Program Image from it, as  <code>SDMMC_MFG_DISABLE</code> is 0
**if no card is found, 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:
***<code>SDMMC_MFG_DISABLE</code> is blown [3] in order to disable permanently ''manufacture mode''
***<code>BT_FUSE_SEL</code> is blown in order to indicate to Boot ROM that eFUSEs have been programmed
***<code>FORCE_INTERNAL_BOOT</code> is blown in order to ignore <code>BOOT_MODE</code> pins from now on
***depending of application's security requirements, other eFUSEs may be blown; for example <code>SDP_DISABLE</code> 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 <code>FORCE_INTERNAL_BOOT</code> has been blown, ''Internal boot'' mode is selected, no matter the status of <code>BOOT_MODE</code> pin is
**as <code>BT_FUSE_SEL</code> is 1, Boot ROM retrieves the Program Image according to <code>BOOT_CFG</code> 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 - operates until Boot ROM reads GPIO pads status. Once this operation is completed, GPIO pads should be electrically disconnected from this circuitry in order to prevent any interference with the functional use of these signals.

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

[3] It means it is set to 1.

===AXEL ULite boot options===
From the point of view of boot configuration programming, AXEL ULite portfolio consists of two basic categories of ordering codes:
#part numbers in the form DLTx0xx'''0'''0x2R have eFUSEs not programmed
#the other ordering codes have eFUSE programmed as detailed in the [[#P-eFUSE ordering codes|following section]].
For convenience, the products belonging to the first category will be denoted as ''NP-eFUSE''. The others will be referred as ''P-eFUSE''.

====P-eFUSE ordering codes====
P-EFUSE codes address users that don't need full control of boot configuration and can use one of the preconfigured options. These configurations are intended to satisfy most commonly used boot schemes. Nevertheless, '''users are strongly recommended to understand the limitations of such configurations in order to verify they meet system requirements'''.

Generally speaking, AXEL ULite supports two kind of memories as internal boot devices: NOR flash (connected to ESCPI1 interface) and NAND flash. 

These devices can be combined differently. However, no matter how NAND and NOR flash are combined, all of P-eFUSE ordering codes have:
*<code>SDMMC_MFG_DISABLE</code> set to 0: ''manufacture mode'' is '''enabled'''
*<code>BT_FUSE_SEL</code> is set to 1, meaning that that eFUSEs have been programmed
*<code>FORCE_INTERNAL_BOOT</code> is set to 0, in order to let <code>BOOT_MODE</code> pins to select main boot mode
*<code>SEC_CONFIG[1:0]</code> are set to 01 to allow any program image, even if authentication fails ('''this option is intended for non-secure products''')
*<code>eFuse 0x470[4]</code> is set to 1, to disable UART serial download.
This leads to three different boot flows and that are shown in the following pictures.

=====NAND-NOR option=====

This configuration makes use of NAND flash as primary internal boot device. NOR flash is used as secondary boot device where, for example, a so-called ''golden image'' of the bootlader can be stored. 
[[File:AXELULite-boot-NAND-NOR.png|thumb|center|750px|Boot flow for ordering code in the form DLTxxxx'''2'''0x2R]]


=====NAND-only option=====

This configuration makes use of NAND flash as primary - and only - internal boot device. [[File:AXELULite-boot-NAND.png|thumb|center|750px|Boot flow for ordering code in the form DLTx0xx'''2'''0x2R]]


=====NOR-NAND option=====

This configuration makes use of NOR flash as primary internal boot device. Nevertheless, NAND flash is available for generic storage. NAND flash can not be used as booting device.
[[File:AXELULite-boot-NOR-NAND.png|thumb|center|750px|Boot flow for ordering code in the form DLTxxxx'''1'''0x2R]]

*NOR option: From the point of view of boot process, this configuration is identical to the NOR-NAND option. This is clearly cheaper because NAND flash is not populated.



The following table details eFUSE programming of available P-eFUSE ordering codes.
{| style="color:#000000; border:solid 2px #73B2C7; background-color:#ededed;font-size:95%; vertical-align:middle;"
| [[File:TBD.png|30px]]
| '''Section not completed yet'''
|}

{|class="wikitable" style="text-align: center;"
|-
!p/n
!BOOT_CFG1
!BOOT_CFG2
!BOOT_CFG4
!Note
|-
| TBD||TBD||TBD||TBD||TBD
|-
| TBD||TBD||TBD||TBD||TBD
|-
| TBD||TBD||TBD||TBD||TBD
|-
| TBD||TBD||TBD||TBD||TBD
|}

P-eFUSE products yet provides a moderated freedom in terms of configurability and openness. Generally speaking, this may affect system security. '''Hence it is strongly recommended that system integrator does a detailed assessment in case he/she is considering the use of P-eFUSE SOMs, especially if security concerns are relevant'''.

====NP-eFUSE ordering codes====
Users who need to have the '''full control''' of the boot process should choose one of the NP-eFUSE part numbers. This allows them to be able to
*program eFUSEs by themselves
*implement circuitry at carrier board level to exploit ''GPIO override''
*decide to use ''GPIO override'' approach even for mass production.

=====AXEL ULite adapter=====
To ease the development effort of the customers working with NP-eFUSE SOMs, DAVE Embedded Systems has made available a specific adapter board. For more information please see [[AXEL ULite adapter|this page]].

===References===
{{=reflist}}
<section end="Body" />