iMX6: boot from a non selected device (internal boot).

[EgleTeam]

Hi,

we have developed an iMX6 SoM. The SoM has installed switches to be able to boot from any device. On a very first expansion board it's only possible to boot from SD2 port. We have noticed that the processor boots right from this device (SD2) independently of the value on the GPIOs associated to the eFUSES (for example: BOOT_CFG0 & BOOT_CFG1 = 0x00, NOR boot). This makes us think that in the boot procedure the processor looks for other devices in case the selectioned by the eFUSES/GPIOs is not available: am I wrong?. Is there any order of preference or device by default?

Regards,

Manuel.

[breixolopezgarc]

Hi Manuel,

I have seen behavior like that, always when the Boot system selected doesn't contain a correct process to boot: It means bootloader (U-boot in a huge number of cases) in the correct partition of the deice to boot (SD-CArd, Nand or EMMC). Because If the board can not find it, automatically it jumps to USB serial Download. It is the default sistem to boot, and it protects you to not enable to boot the board anymore if something goes wrong in the U-boot, this system of freescale could create some missunderstood, but I find really usefull.

Perhaps Egle has a similar Issue, in the case of Egle I didn't understand the Issue very well.

-Regards

-Breixo

[EgleTeam]

Hi Breixo,

I know what you say but this is not our case. If something is wrong configured i.MX6 jumps to USB: that is normal. What I say is that with a particular silicon revision of duallite (not solo, dual neither quad) the processor boots from SD2 even when is configured for booting from another device: moreover, we can see in u-boot that the boot registers (SRC_SMBR2 & SRC_SMBR1) are consequent with the boot pins (not a hardware mistake).

Regards,

Manuel.

[praveeng]

Hello Eagle team,

Should we use

1)  OCOTP_CTRL  0x21bC000    OR

2) SRC_SBMR2 (0x020D801C)

to Boot from NOR using EIM??

In above post you mention only SRC_SBMR,?? SHould I use only this register to boot from NOR?

[aven_tsao]

Firstly, please check the BOOT_MODE[1:0] pins settings, the system will boot from efuses settings if the value is “00”, and the system will boot from GPIO settings (Internal Boot) if the value is “10”.

If the boot mode is “10”, then the system will check the GPIO (BOOT_CFG1[7:4]) pins to determine the boot device (NOR, SATA, SD, eMMC, NAND …etc), please reference to the table 8-8 Boot device selection of MX6DQ Reference Manual.   

[EgleTeam]

Hi Yung-Wen Tsao,

I apologize: I didn't see your answer before.

BOOT MODE is "10". The issue is that whichever is the value of BOOT_CFG1[7:4] the processor boots from the only available device (SD2). We expected that if the processor doesn't find the configured boot device it simply doesn't boot.

Is this normal?.

Regards,

Manuel

[aven_tsao]

Sorry for my late reply.

Ideally, the boot device is depends on the value of BOOT_CFG1[7:4] when internal boot mode, so only boot from SD2 is abnormal.

But the value of BT_FUSE_SEL also controls the boot device, so please check the value of BT_FUSE_SEL.

Please reference the page 395 of MX6DQ RM

When set to internal boot, the boot flow may be controlled by a combination of eFUSE

settings with an option of overriding the fuse settings using General Purpose I/O (GPIO)

pins. The GPIO Boot Select FUSE (BT_FUSE_SEL) determines whether the ROM uses

GPIO pins for a select number of configuration parameters or eFUSEs in this mode. See

Table 8-4 for more details.

• If BT_FUSE_SEL = 1, all boot options are controlled by the eFUSEs described in

Table 8-2.

• If BT_FUSE_SEL = 0, specific boot configuration parameters may be set using

GPIO pins rather than eFUSEs. The fuses that can be overridden when in this mode

are indicated in the GPIO column of Table 8-2. Table 8-3 provides the details on the

GPIO pins.

Best regards

Aven

[EgleTeam]

Hi Aven,

This is what I get when the "switches" in our custom board are configured for boot from SD2:

SRC_SBMR2 (0x020D801C) = 0x32000001 ==>> BT_FUSE_SEL ([25:24]) = 0b0, BMOD ([3]) = 0b10

SRC_SBMR1 (0x020D8004) = 0x00002840 ==>> BOOT_CFG1[7:4 ]= 0b0100, BOOT_CFG2[4:3 ] = 0b01 ====>> BOOT FROM SD2

The processor boots from SD2.

This is what I get when the "switches" in our custom board are all pulled to ground:

SRC_SBMR2 (0x020D801C) = 0x32000001 ==>> BT_FUSE_SEL ([25:24]) = 0b0, BMOD ([3]) = 0b10

SRC_SBMR1 (0x020D8004) = 0x00000000 ==>> BOOT_CFG1[7:4 ]= 0b0000 ====>> BOOT FROM EIM

There's no EIM in our board. EVEN WRONG CONFIGURED: THE PROCESSOR STILL BOOTING FROM SD2.

This is what I get when the "switches" in our custom board are configured for boot  from Nand:

SRC_SBMR2 (0x020D801C) = 0x32000001 ==>> BT_FUSE_SEL ([25:24]) = 0b0, BMOD ([3]) = 0b10

SRC_SBMR1 (0x020D8004) = 0x00000080 ==>> BOOT_CFG1[7:4 ]= 0b1000  ====>> BOOT FROM NAND

There's a nand in our board but is blanked. EVEN WRONG CONFIGURED: THE PROCESSOR STILL BOOTING FROM SD2.

This is what I get when the "switches" in our custom board configured for boot  from MMC:

SRC_SBMR2 (0x020D801C) = 0x32000001 ==>> BT_FUSE_SEL ([25:24]) = 0b0, BMOD ([3]) = 0b10

SRC_SBMR1 (0x020D8004) = 0x00000060 ==>> BOOT_CFG1[7:4 ]= 0b0110  ====>> BOOT FROM MMC

There's no MMC in our board. EVEN WRONG CONFIGURED: THE PROCESSOR STILL BOOTING FROM SD2.

And so on....

----------------------------------------

As you can see BMOD & BT_FUSE_SEL are configured for internal boot from GPIO pins: registers are read in UBOOT ("md" command). This is what I refer: we don't understand WHY the processor still booting from SD2 (the only available device) when is not configured for that.

Thanks,

Manuel.

[aven_tsao]

HI Manuel:

I tried to reproduce the boot mode test on SARBE SD board, but the test result is different with yours.

I put the boot SD card to SD2 slot, and the system only can boot up success when boot configure is boot from SD2.

(The system can't boot up when boot configure is EIM, eMMC, NAND ...etc)

Can you double check the boot mode test on both SARBE SD and customer board again?

Best regards

Aven

[EgleTeam]

Hi Aven,

This is the test with our board with a Quad core version:

SRC_SBMR2 (0x020D801C) = 0x22000001 (reserved bits value has changed)

SRC_SBMR1 (0x020D8004) = 0x00002840

Silicon Revision (0x020c8260) = 630002

And....If I change the switches (boot configure) then the PROCESSOR CAN'T BOOT: same than your tests with SABRE SD.

Has Freescale ever tested this situation with iMX6DL silicon rev.1.1 ? It sounds like a bug or simply that the ROM code doesn't do what is reflected in the reference manual.

Best regards,

Manuel.

[chrisloental]

Manuel,

Did you ever find a solution to this? I am using an IMX6 SoloLite and we are also having issues where we are booting to a non-selected device as per our bootstraps. In our case, we are incorrectly booting to USB Serial Download instead of to eMMC as desired.

We also see the corrupted reserved bits in the SRC_SMBR2 register.

We are on a tight deadline and ANY information about resolution to this issue would be much appreciated!

Thanks!

-Chris

[EgleTeam]

Hi Chris,

unfortunately we didn't find the solution. At the moment I said "it sounds like a bug" nobody of freescale's staff replied again: I apologize if someone felt displeased by my comment and to have taken precipitated conclusions.

The only that is 100% true is that we have a common design for SOLO/DUAL_LITE/DUAL/QUAD and dual_lite doesn't respond to the boot pins in the same way that the others.

We have not assemblied boards with a different silicon revision. Once we do it I will post again. Chris, that's the only that I can suggest : try with another silicon revision.

Best regards,

Manuel.

[EgleTeam]

Hi Aven,

unfortunately we don't have a SABRE SD. The only board different to our custom board that we have is a sabrelite but seems we damaged it so we can't test.

On any case: we are testing a DL part, so we are going to assembly quad and solo versions to test if the behavior is the same or not

By the way, SRC_SBMR2 (value=0x32000001 ) shows something strange since reserved bits [31:26] are not all zeros like section 60.7.6 says that should be. Silicon revision is 0x610001.

I will post again when I perform new tests.

Best Regards,

Manuel.