Uboot Failed to run after flashing in recovery mode

I put the module in recovery mode by shorting 2 pads on the module. I was able to load the uboot to the module and run it by executing “sudo ./update.sh -d” command on host. At uboot prompt, I entered “run setupdate;run update” with Toradex Linux Image V2.6. and everything seemed working fine with an output message:
“successfully updated U-Boot, power-cycle and enter “run setupdate; run migrate” to complete update”.
Then I put the module back to normal mode and powered the module up.but it failed to boot. There is a very similar issue posted in the forum: Can't flash uboot Colibri iMX6 in recovery mode - Technical Support - Toradex Community . I have double checked that my SD card was not damaged.

Then I put the module in recovery mode and loaded & ran uboot again. The uboot was able to start kernel.

Here is an output of boot_info

root@colibri-imx6:~# cat /sys/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0\:0001/boot_info
[   47.417629] mmc0: BKOPS_EN bit is not set
boot_info:0x07;
  ALT_BOOT_MODE:1 - Supports alternate boot method
  DDR_BOOT_MODE:1 - Supports alternate dual data rate during boot
  HS_BOOTMODE:1 - Supports high speed timing during boot
boot_size:2048KB
boot_partition:0x48;
  BOOT_ACK:1 - Boot acknowledge sent during boot operation
  BOOT_PARTITION-ENABLE: 1 - Boot partition 1 enabled
boot_bus:0x16
  BOOT_MODE:2 - Use dual data rate in boot operation
  RESET_BOOT_BUS_WIDTH:1 - Retain boot bus width and boot mode after boot operation
  BOOT_BUS_WIDTH:2 - x8 (sdr/ddr) bus width in boot operation mode     

The I tried to copy uboot and enable boot partition:

root@colibri-imx6:~# dd if=u-boot.imx of=/dev/mmcblk0boot0 bs=512 seek=2
598+0 records in
598+0 records out
root@colibri-imx6:~# echo 1 > /sys/block/mmcblk0boot0/force_ro
root@colibri-imx6:~# echo 10 > /sys/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0\:0001/boot_bus_config
root@colibri-imx6:~# echo 8 > /sys/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0\:0001/boot_config

It seems my boot partition got corrupted:

root@colibri-imx6:~# cat /sys/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0\:0001/boot_info
[  688.964287] Unable to handle kernel paging request at virtual address 92c89f0c
[  688.971526] pgd = 8e74c000
[  688.974237] [92c89f0c] *pgd=00000000
[  688.977833] Internal error: Oops: 805 [#2] SMP ARM
[  688.982626] Modules linked in:
[  688.985703] CPU: 0 PID: 815 Comm: cat Tainted: G      D      3.14.52-00011-g9f2723e #2
[  688.993625] task: 8e15b600 ti: 8f332000 task.ti: 8f332000
[  688.999036] PC is at mmc_read_ext_csd+0x358/0x7dc
[  689.003744] LR is at 0x8e1c7800
[  689.006891] pc : [<80454c40>]    lr : [<8e1c7800>]    psr: 600f0113
[  689.006891] sp : 8f3339e8  ip : 92c89c00  fp : 8f333a14
[  689.018372] r10: 00000000  r9 : 8f333a6c  r8 : 8e489c00
[  689.023600] r7 : 00000001  r6 : 00000001  r5 : 8e8c7600  r4 : 8e489c00
[  689.030130] r3 : 00200000  r2 : 00000000  r1 : 807bad80  r0 : 04800000
[  689.036662] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  689.043974] Control: 10c5387d  Table: 1e74c059  DAC: 00000015
[  689.049723] Process cat (pid: 815, stack limit = 0x8f332238)
[  689.055384] Stack: (0x8f3339e8 to 0x8f334000)
[  689.059749] 39e0:                   000055b0 8e489c08 0000b288 8f333a70 8067ffec 8e489c00
[  689.067933] 3a00: 8f333a6c 00000000 8f333adc 8f333a18 80455d18 804548f4 00000001 00000000
.....
[  689.704765] Code: e2827001 e30a1d80 e084c000 e348107b (e58c330c)
[  689.710864] ---[ end trace fa92dd4f8b345141 ]---
Segmentation fault

I am now stuck at this fault and don’t know how I should proceed. What am I doing wrong? Any help would be appreciated.
William

Comparing your boot_info output above to what we documented on our developer website you clearly miss-configured at least the eMMC side of things. As @max.tx pointed out in the question you referred to above the fuse sense 0 5 output would be interesting to know the configuration of the SoC side of things.

Thank you for your reply.
I was surprised to see that the uboot was actually running successfully after I put the module back in normal mode and cycled power even though the boot_info was showing “segmentation fault” as above! Here is the boot_info again after kernel boot:

root@colibri-imx6:~# cat /sys/devices/soc0/soc.0/2100000.aips-bus/2198000.usdhc/mmc_host/mmc0/mmc0\:0001/boot_info
[   27.029349] mmc0: BKOPS_EN bit is not set
boot_info:0x07;
  ALT_BOOT_MODE:1 - Supports alternate boot method
  DDR_BOOT_MODE:1 - Supports alternate dual data rate during boot
  HS_BOOTMODE:1 - Supports high speed timing during boot
boot_size:2048KB
boot_partition:0x48;
  BOOT_ACK:1 - Boot acknowledge sent during boot operation
  BOOT_PARTITION-ENABLE: 1 - Boot partition 1 enabled
boot_bus:0x0a
  BOOT_MODE:1 - Use single data rate + high speed timings in boot operation mode
  RESET_BOOT_BUS_WIDTH:0 - Reset bus width to x1, single data rate and backwardcompatible timings after boot operation
  BOOT_BUS_WIDTH:2 - x8 (sdr/ddr) bus width in boot operation mode

It’s same as in the developer website except the boot_size (2048KB vs. 4096KB).
The fuse configuration is showing correct value:

Colibri iMX6 # fuse sense 0 5
Sensing bank 0:

Word 0x00000005: 00005072

Here is a weird thing I just noticed. If I issue “run setupdate;run update” at uboot prompt, uboot will fail to run again. But if I do individual update with “run setupdate;run update_uboot;run update_kernel;run update_fdt;run migrate”, everything will be working. It seems to me that “update” command has a bug causing the boot failure.

Thank you for your reply.

You are very welcome.

I was surprised to see that U-Boot was actually running successfully after I put the module back in normal mode and cycled power even though the boot_info was showing “segmentation fault” as above!

I guess it actually took your new settings then. I believe it crashes when one makes changes and wants to dump them again afterwards. As we do not usually configure those things from within Linux we did not dare to investigate this any further so far.

Here is the boot_info again after kernel boot:

It’s same as in the developer website except the boot_size (2048KB vs. 4096KB).

Yes, now it looks correct. Before you had it in DDR mode which unfortunately does not seem to play nice with the i.MX 6 boot ROM.

The fuse configuration is showing correct value:

Yes, that looks proper too.

Here is a weird thing I just noticed. If I issue “run setupdate;run update” at uboot prompt, uboot will fail to run again.

And that is with our stable V2.6 release?

Do you regularly boot into U-Boot or use the recovery mode? Because after using the recovery mode you would always need a full power-cycle in order for the boot ROM to revert back to eMMC booting.

We are really not aware that there should be any issues around any of this.

But if I do individual update with “run setupdate;run update_uboot;run update_kernel;run update_fdt;run migrate”, everything will be working. It seems to me that “update” command has a bug causing the boot failure.

I really doubt this. The run migrate is really what is different in your procedure above. If you do look at colibri-imx6_bin/flash_blk.scr you actually notice 3 variants of updating the boot loader:

  1. migrate_uboot_old applicable for booting without any hardware area boot partition
  2. migrate_uboot applicable for booting from the primary hardware area boot partition but without eMMC fast boot mode
  3. update_uboot applicable for the state-of-the-art eMMC fast boot mode booting off the primary hardware area boot partition

So if what you are saying is true it would mean your module somehow does not want to boot in the eMMC fast boot mode and only boots from the primary hardware area boot partition otherwise. However your i.MX 6 SoC fuses tell us otherwise

Could you please also indicate what exact hardware version of Colibri iMX6S module you have?

We are using qt5 x11 image built with Toradex BSP V2.6.
Hardware: Colibri iMX6 solo 256MB IT v1.0B

I really recommend trying the same with our stock BSP V2.6 demo image to rule out any other influence whatsoever. Please follow the following article on our developer website.