Bureaucrats, dave_user, Administrators
4,650
edits
Changes
no edit summary
The use of these settings will be more clear soon.
In case internal boots 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>.
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.
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===
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 enabledbecause <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 qualified and the production boot strategy has been defined, the definitive boot configuration is needs to be stored permanently in OTP memory. This operation is usually performed during the manufacturing process. To implement it, the ''Manufacture mode'' comes 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**Boot ROM tries to load a Program Image from SDHC1 because <code>SDMMC_MFG_DISABLE</code> 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:***<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 indicarte Boot ROM that eFUSEs have been programmed***<code>FORCE_INTERNAL_BOOT</code> 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 <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 - 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 <code>SD1_CD</code>. If it is 0, SD/MMC card is present.
[3] It means it is set to 1.
==Options for AXELULite users==
