Unable to recover a VF61

I am trying to recover a VF61 which already booted.

Using my IRIS v1.1, I can enter the recovery mode and run the update.sh script, which output seems correct:

>$ ./update.sh -d ...
Colibri VF rootfs detected
Put the module in recovery mode and press [ENTER]...

config file <vf_flash/vybrid_usb_work.conf>
parse vf_flash/vybrid_usb_work.conf
starting associating phase
association phase succeeded, response was 0x23454523
HAB security state: development mode (0x56787856)
== work item
filename colibri-vf_bin/u-boot.imx
load_size 0 bytes
load_addr 0x00000000
dcd 1
clear_dcd 0
plug 1
jump_mode 2
jump_addr 0x00000000
== end work item
main dcd length 8
sub dcd length 4

loading binary file(colibri-vf_bin/u-boot.imx) to 3f4074e8, skip=0, fsize=6eb18 type=aa

<<<453400, 453400 bytes>>>
succeeded (status 0x88888888)
jumping to 0x3f4078e8

I found multiple questions like this one except that I can see some output (on the X13 connector of my IRIS v1.1):

CPU: Freescale Vybrid VF610 at 500 MHz
Reset cause: POWER ON RESET
DRAM:  

And, that’s all. I cannot access U-Boot.
I don’t know if I missed something of if I should consider the VF61 as dead (I have another one which boots, that’s why I’m pretty sure I can exclude an issue with the IRIS)

We’re experiencing the same problem. Is this a systematic problem?

If you do get this running our latest stable BSP release V2.5_20151216 which has been fully validated & verified you should RMA the module as @stefan.tx mentioned.

However if you do get this running our latest V2.7 beta 1 release then it is just a software regression in U-Boot. Either compile U-Boot from our -next branch as outlined here or wait for the upcoming Q1 release which may take until early April to be available.

U-Boot hangs during main memory initialization. It looks like a hardware issue, please request a RMA.

As @marcel.tx mentioned below, there is a issue in V2.7 beta 1 (24327). This release was the first release with a U-Boot version 2016.11. The above request has been made at a time before we released a BSP V2.7 beta 1 (and hence U-Boot 2016.11). So the original request is likely due to a RMA case.

If you see the issue with a U-Boot version 2016.11, please build a new U-Boot from our 2016.11-toradex-next branch, wait for the upcoming BSP V2.7 beta 2 release or revert to a earlier BSP release.