U-boot won't accept keyboard input

Hi,

I am trying to use the Recovery Mode to update my u-boot image. Once the recovery is done I can’t type anything at the command prompt. It won’t accept any inputs. Hence I can’t issue the “run setupdate” and “run update” commands. [upload|S1jkljgoHBQhrqGNwoO0DBDb7Sc=]

I am connecting to the Colibri evaluation board V3.2B via USB on X27 connector. The JP17/JP19/JP20/JP21 jumpers point to FTDI. I issue the ./update.sh -d /dev/ttyUSB0 command and get this output.

[upload|AYW7iRE2bQqzY9m2g9Sg6d3f5BE=]

I know my connections are good, because if I let the device boot with the existing images I can get access to the RootFS. I can even modify the u-boot environment variables from Linux.

My main intention is to flash a new u-boot image and if there’s any other alternate method I’d be glad to hear that too.

I don’t know if this could help but this is the output of running the fw_printenv command on my device.

fw_printenv_output_vf61

I am trying to use the Recovery Mode to update my u-boot image.

And you initially did set your module into recovery mode by what means?

Once the recovery is done I can’t type anything at the command prompt.

How exactly are you connecting to that command prompt? You will need a serial terminal e.g. like minicom or screen to connect to the resp. ttyUSB instance as explained e.g. here.

It won’t accept any inputs. Hence I can’t issue the “run setupdate” and “run update” commands.

I am connecting to the Colibri evaluation board V3.2B via USB on X27 connector. The JP17/JP19/JP20/JP21 jumpers point to FTDI. I issue the ./update.sh -d /dev/ttyUSB0 command and get this output.

Above command would only ever be needed if the module does indeed no longer at least boot the U-Boot boot loader and is bricked. Otherwise, just stopping in U-Boot would be enough.

I know my connections are good, because if I let the device boot with the existing images I can get access to the RootFS.

Meaning by the same serial terminal connection? What exact configuration thereof are you using?

I can even modify the u-boot environment variables from Linux.

Then, you could also modify bootcmd to e.g. initiate an update:

fw_setenv bootcmd 'run setupdate; run update'

However, care needs to be taken that it does not go into a boot update loop e.g. one would need editing resp. U-Boot update script aka flash_blk.img (resp. flash_blk.scr and regenerate the img files using mk-u-boot-scripts.sh) to reset the bootcmd after a successful update instead of just resetting.

My main intention is to flash a new u-boot image and if there’s any other alternate method I’d be glad to hear that too.

Just to update U-Boot one could do run setupdate; run update_uboot e.g. from within Linux as follows:

fw_setenv bootcmd 'run setupdate; run update_uboot; env default -a; saveenv'
1. fw_setenv bootcmd 'run setupdate; run update_uboot; env default -a; saveenv'

Thank you @marcel.tx that worked perfectly. I have control of my u-boot console again.

You are very welcome.

So I seem to have encountered this problem again. And this time I may be worse off.

Some background:

In my efforts to productize the BSP, I had disabled the console output in u-boot and linux. I had also disabled remote login via SSH. I know my system boots fine because my application runs fine and turns on the expected LEDs.

Now I want to reflash my debug bootloader and kernel for which I assume I need to go back into Recover Mode? But when I run the recovery bootloader I run into the same issue as the original post. I get the U-boot prompt but can’t enter the “run setupdate” and “run update” commands because it won’t take any keystrokes.

The solution worked last time because I had access to the shell. This time unfortunately I don’t have that either. The screenshots from the original post are still valid.

Looking at this image from the Flashing Embedded Linux wiki I expect the below result.

u-boot-toradex

But I don’t see the “Hit any key to stop autoboot: 0” line.

A little more information I’ve discovered about what’s happening in case it helps in providing a resolution.

After the recovery u-boot runs from RAM, instead of stopping there it then automatically runs the kernel/rootfs that was already present on the board. (i.e., my application).

You would need to compile and subsequently run via the recovery mode a special U-Boot which ignores the U-Boot environment still stored in the on-module flash (e.g. using CONFIG_ENV_IS_NOWHERE) but rather uses the compiled-in default environment. This is exactly what the special Toradex Easy Installer U-Boot does. However, keep in mind that such special U-Boot is then also only ever suitable for recovery. Unfortunately, we currently have no plans to port the Toradex Easy Installer which may solve any and all of your encountered issues to the somewhat older Colibri VF50/VF61 aka Vybrid module family.

Thank you @marcel.tx ! Not only did that work, I also learned something new that can be done with u-boot. It’s because of support like this that I continue to use and recommend Toradex. :slight_smile:

You are very welcome.