Failure to boot off SD card in latest balena OS, works fine on previous

Product support
1

Our devices previously used the 2.50 image for startup based on the Variscite IMX8-mini SOM (on our custom board). This has worked fine for ~75 devices we’ve fielded.

We’re looking to upgrade the latest 2.85.2 which works great if we do a “upgrade” from the web UI on devices that had previous run 2.50.

However, when trying to bootstrap a new device with an SD image of 2.85.2, we get dumped into u-boot with an error about not finding a resin image, preceded by some other errors about the block device not being supported.

Raw Log:

U-Boot 2020.04-imx_v2020.04_5.4.24_2.1.0_var02+ga7f6308395 (May 19 2021 - 15:25:54 +0000)

CPU:   i.MX8MMQ rev1.0 1800 MHz (running at 1200 MHz)
CPU:   Commercial temperature grade (0C to 95C) at 53C
Reset cause: POR
Model: Variscite DART-MX8M-MINI
DRAM:  2 GiB
MMC:   FSL_SDHC: 1, FSL_SDHC: 2
Loading Environment from MMC... Card did not respond to voltage select!
*** Warning - No block device, using default environment

In:    serial
Out:   serial
Err:   serial

 BuildInfo:
  - ATF 7575633
  - U-Boot 2020.04-imx_v2020.04_5.4.24_2.1.0_var02+ga7f6308395


Part number: VSM-DT8MM-202A
Assembly: AS2007154104
Production date: 2020 Dec 09
Serial Number: f8:dc:7a:52:88:81
Card did not respond to voltage select!
flash target is MMC:1
Card did not respond to voltage select!
MMC card init failed!
Card did not respond to voltage select!
** Block device MMC 1 not supported
Net:   eth0: ethernet@30be0000
Fastboot: Normal
Normal Boot
Hit any key to stop autoboot:  0
Scanning mmc devices 0 1 2
Card did not respond to voltage select!
Card did not respond to voltage select!
ERROR: Could not find a resin image of any sort.
Loading resinOS_uEnv.txt from device partition 1
Loading extra_uEnv.txt from device partition 1
Loading bootcount.env from device partition 1
No bootcount.env file. Setting bootcount=0 in environment
** Bad device specification :2 resin_root_part_uuid **
gpio: pin 137 (gpio 137) value is 1
MMC Device 0 not found
no mmc device at slot 0
MMC Device 0 not found
no mmc device at slot 0
Bad Linux ARM64 Image magic!
u-boot=>
2

Also just to add, we need this primarily because as of now, there is no way for us to get a development build on our devices of the new OS version. If there is some magic to upgrade to a development build over the web UI, that would also be good to know. As it stands now however, we are completely blocked.

3

Hi @anathan84,

I just checked the 2.85.2 development image on the iMX8M Mini devkit v1.4 and it boots fine. In my logs, instead of
Card did not respond to voltage select!
I see
Run CMD11 1.8V switch

Looking at Re: iMX8M Mini: Problem boot from some micro SD ca... - NXP Community it seems that this could either caused by the Custom carrier board you are using, or by the sd-card, so it’s worth checking with multiple cards.

Regarding your second question, you can upgrade to v2.85.2 and after the device boots in the new OS, edit /mnt/boot/config.json and add developmentMode:

  "deltaEndpoint": "https://delta.balena-cloud.com",
  "developmentMode": "true",
...

and you will see the change reflected in the admin panel in a few seconds. Switching developmentMode to false or removing it completely will get the device back to production mode.

5

Thanks for the pointer on the workaround, that’s a good stopgap.

As for the sd card, I did try two different cards…one a sdhc 16gb card and another sdhx 64gb card since I also thought maybe that’s the issue.

High level though the same card works with the older OS.so something changed. I’m wondering if there is some implicit hardware dependency encoded in the he dev.board that isn’t in our carrier. We know the carrier functions just fine with the SD card since we use it for flashing and for use during application run (for logging).

Any ideas what the change may be or things we can try?

6

If all cards on this particular device work with the older release, then it’s something that might have changed in the upstream u-boot.

You can try booting the upstream yocto recovery sd-card images and see which one can’t access the sd anymore on the custom carrier board, and then raise a ticket in upstream u-boot. As soon as there is a change or fix in upstream we can then include it in newer image releases.