No U-boot display trying to recover Colibri iMX6

Technical Support
, , , ,
1

I’m trying to recover a Colibri iMX6 board and hitting a wall. We’d like to use a Toradex SOM at our company and I’m evaluating them for production use. While flashing one of my images, the power burped and now it won’t boot. I’ve flashed several before without a problem, so I’ve already gone through the process. I’ve scoured the community and message threads and found a patchwork of solutions that I can’t put together to make work.

*** The main problem is that I can ./update.sh the board successfully, but whatever I do, I never get a u-boot banner or display on the serial console to continue the update from the sdcard (minicom just says OFFLINE).

  • Colibri iMX6 module on Colibri eval board V3.2
  • linux
  • basic BSP image (V2.5)

Basically, I’ve done the following:

  • already started it in recovery mode

  • connected on USB X29 (‘lsusb’ showed connection for NXP/Freescale) to the host (Ubuntu 14.04) and did ‘./update.sh -d’ and all looked good:

    …
    loading binary file(…/colibri-imx6_bin/u-boot.imx) to 177ff400, skip=0, fsize=4

    <<<306176, 306176 bytes>>>
    succeeded (status 0x88888888)
    jumping to 0x177ff400

  • already had a working connection with minicom on serial UART_A (115200, 8N1) for flashing before this.

  • some message threads said to disconnect the serial connection while doing the ./update.sh…also tried it

Seems like a common problem out there…all I have to get to is the u-boot display, then all that’s left is a ‘run set/update’ like normal but I don’t get any display or connection. Need to get this resolved so any help is appreciated…

thanks in advance,
Dave

2

Hi

Can you try to bring the module into recovery mode by shorting the two pads as per the Colibri iMX6 datasheet?

It is possible to have a half dead U-Boot which does configure the DDR RAM but then fails to further boot and an exception gives back control to the bootrom which then will go into recovery mode. If you then run the ‘./update.sh -d’ that will fail because the DDR cannot be configured a second time without giving any indication on the hosts console. Forcing recovery mode makes the bootrom go to recovery mode immediately.

If that doesn’t help we will have to look further.

Max

3

I’m relatively new to this specific type of board…

  • I forced it into recovery mode by shorting the 2 pins (above)
  • did the ‘update.sh -d’ (and it seemed to be successful, but from what you’re saying, how can you be able to tell?)

Sorry, not sure what you’re suggesting…I think I did that the first time. How do I get this board kickstarted?

thanks, Dave

4

You may also try my suggestions here.

5

Great, thanks Max and Marcel for the help with this…

U-boot now loads and boots in RAM when I run update.sh and the board now can boot successfully. One last (hopefully not dumb) question: since u-boot gets copied and executed in RAM, it starts booting immediately and there’s no way to catch it at the u-boot prompt (but it’ll make it all the way to the login prompt).

Is there a way to delay the autoboot so I can catch it or a command to temporarily flash u-boot in memory to the board so I can power off/on and catch it faster?

6

I guess bootdelay is the U-Boot environment variable you are looking for. However that delay will be active on every boot, even in those cases were you’d like it to boot fast.

Note that even with a setting of ‘0’ one can stop in the console. So I’m usually able to run ‘./update.sh -d’ in one console and then move focus to a second console and press any key to stop in U-Boot command line mode.

If you have problems doing that but you still get a login for Linux you could use the fw_setenv tool in Linux to manipulate the U-Boot environment:

root@colibri-imx6:~# fw_printenv | grep bootdelay                               
bootdelay=1                                                                     
root@colibri-imx6:~# fw_setenv bootdelay 5
7

thanks, I was able to do run setupdate, then update…one last thing is that after what seems to be normal writes, the last write hangs at when it tries to reset…

MMC write: dev # 0, block # 958464, count 43008 … 43008 blocks written: OK
resetting …

Some other threads said to just power it off/on, but that didn’t work - it didn’t come back to a usable, bootable board…

Again, thanks in advance for any and all suggestions… Dave

8

This is not related to the last write but rather the subsequent software resting which won’t be able to clear any hardware strapping state meaning if you did enter the recovery mode by shortening some pads a full power cycle will be required.

If it does not boot after that something else may have failed before. One thing that comes to mind are the i.MX 6 SoC fuses which can be checked from within U-Boot as explained here.

9

As part of evaluating the iMX6 board and building images, I’ve been trying to move back and forth between 2.5 and 2.6. If I interpreted the statements in the link that Marcel posted about ‘eMMC Fast Boot Mode (Apalis/Colibri iMX6)’, because of fast boot mode, you can never downgrade from a 2.6 BSP.

If that’s the case, that’s probably what happened during the iterations where I was
unknowingly trying to recover with a 2.5 image after 2.6 (not realizing that I couldn’t downgrade). I was able to build a fresh 2.6 image and recovered successfully.

  • bitbaked a new 2.6 image
  • loaded it on the sdcard (./update.sh -o /media/sdcard)
  • connected to host over USB serial connection, powered up the board in recovery
  • opened minicom in a separate console
  • from host ran ./update -d and stopped u-boot in minicom
  • did a ‘run setupdate’, then ‘run update’

Instead of the update hanging when resetting, it resetted successfully. All sounds
straightforward and by the book, but when you’re in the weeds, it’s a grind…
Thanks again to Max and Marcel for the help…

Dave

10

Our BSP 2.5 never left its beta state, was only ever released for sample hardware and is since no longer supported really.

11

Strange though, the board came with it installed, and I never saw any reference that 2.5 was always beta, so I tried to use it. Thanks again for the help and the info.

12

Yes, we are aware of this but decided to wait before switching to anything else due to that eMMC fast boot mode fusing being irreversible. We plan to send out a PCN before we switch the pre-installed software which we plan to change to the Toradex Easy Installer later this year.