UART Failure after upgrading to 2.71.3+rev1 from 2.50.1+rev1 on Variscite IMX8M

Hi @anathan84, thanks for confirming that the kernel 5.4.85 solves this issue for you. I’ve opened a github ticket to track your request, you can keep an eye on it for updates.

Any guess on timing of the update? Else I may try bitbaking the new version on top of your yocto layers locally.

@anathan84 the item is in our queue but we can’t offer a release estimate for it right now.

Hi @anathan84 , have you bitbaked the latest version locally, did it work as expected? If you haven’t checked yet, we have a WIP PR that updates to Dunfell + kernel 5.4.85 and which you can build locally with:

git checkout set_state_to_released
git submodule update --init -recursive
balena-yocto-scripts/build/barys -b build_mm -m imx8mm-var-dart

Let us know how it works.

Hi @anathan84 @adamshapiro0 , the v2.80.5+rev2 BalenaOS image in the dashboard for the DART MX8M Mini is based on Dunfell and has the kernel 5.4.85. Let us know how it works for you.

Great thank you for the follow up. Well get this tested in our next sprint.

Just to update the thread, we’ve been unable to get he 2.80.5 official build to run on our hardware. We tried a fresh install with SD Card which appears to be getting jammed up with u-boot (using the exact same hardware with 2.50 and 2.7 work fine). We also tried upgrading a device using the web console from 2.50 to 2.80 and the system failed to boot. I’ve attached the log of that here.
upgrade failure.txt (17.1 KB)

Interesting, the same image boots fine on the hardware we have. In your logs I see you have the VSM-DT8MM-202A, whereas we have the:

Part number: VSM-DT8MM-102
...
Production date: 2020 Jan 15
...
Booting from mmc ...
fdt_file=imx8mm-var-dart-dt8mcustomboard-legacy.dtb
45402 bytes read in 26 ms (1.7 MiB/s)

Can you stop u-boot in cmdline by pressing space or esc in the serial console of the development image, and load the non-legacy dtb to check if the device boots with it? With the -102 and non-legacy device tree the pcie driver prints a few errors but the OS boots successfully, would be interesting to see if it works the other way around.

For example:

u-boot=> editenv findfdt
edit: if test $fdt_file = undefined; then if test $board_name = VAR-SOM-MX8M-MINI; then if test $carrier_rev = legacy; then setenv fdt_file imx8mm-var-som-symphony-legacy.dtb; else setenv fdt_file imx8mm-var-som-symphony.dtb; fi; else if test $carrier_rev = legacy; then setenv fdt_file imx8mm-var-dart-dt8mcustomboard.dtb; else setenv fdt_file imx8mm-var-dart-dt8mcustomboard.dtb; fi; fi; fi;
u-boot=> run bootcmd

I must be doing something odd, I changed the env variable but the script still prints out the legacy dtb. See below:

u-boot=> editenv findfdt
edit: if test $fdt_file = undefined; then if test $board_name = VAR-SOM-MX8M-MINI; then if test $carrier_rev = legacy; then setenv fdt_file imx8mm-var-som-symphony-legacy.dtb; else setenv fdt_file imx8mm-var-som-symphony.dtb; fi; else if test $carrier_rev = legacy; then setenv fdt_file imx8mm-var-dart-dt8mcustomboard.dtb; else setenv fdt_file imx8mm-var-dart-dt8mcustomboard.dtb; fi; fi; fi;
u-boot=> run bootcmd
Scanning mmc devices 0 1 2
Card did not respond to voltage select!
Found resin image on mmc 2
Loading resinOS_uEnv.txt from mmc device 2 partition 1
38 bytes read in 5 ms (6.8 KiB/s)
Import resinOS_uEnv.txt in environment
Loading extra_uEnv.txt from mmc device 2 partition 1
Loading bootcount.env from mmc device 2 partition 1
13 bytes read in 5 ms (2 KiB/s)
Import bootcount.env in environment
WARNING! BOOTLIMIT EXCEEDED. SWITCHING TO PREVIOUS ROOT
WARNING! was: resin_root_part=3
WARNING! now: resin_root_part=2
gpio: pin 137 (gpio 137) value is 1
switch to partitions #0, OK
mmc2(part 0) is current device
11069394 bytes read in 58 ms (182 MiB/s)
Uncompressed size: 24745992 = 0x1799808
Booting from mmc ...
fdt_file=imx8mm-var-dart-dt8mcustomboard-legacy.dtb
WARN: Cannot load the DT
u-boot=>

Admittedly this is not something I’ve done before, so maybe I’m screwing up the basic syntax of editenv?

Also tried this:

u-boot=> setenv fdt_file imx8mm-var-som-symphony.dtb
u-boot=> run bootcmd
Scanning mmc devices 0 1 2
Card did not respond to voltage select!
Found resin image on mmc 2
Loading resinOS_uEnv.txt from mmc device 2 partition 1
38 bytes read in 5 ms (6.8 KiB/s)
Import resinOS_uEnv.txt in environment
Loading extra_uEnv.txt from mmc device 2 partition 1
Loading bootcount.env from mmc device 2 partition 1
13 bytes read in 4 ms (2.9 KiB/s)
Import bootcount.env in environment
WARNING! BOOTLIMIT EXCEEDED. SWITCHING TO PREVIOUS ROOT
WARNING! was: resin_root_part=3
WARNING! now: resin_root_part=2
gpio: pin 137 (gpio 137) value is 1
switch to partitions #0, OK
mmc2(part 0) is current device
11069394 bytes read in 58 ms (182 MiB/s)
Uncompressed size: 24745992 = 0x1799808
Booting from mmc ...
fdt_file=imx8mm-var-som-symphony.dtb
WARN: Cannot load the DT
u-boot=>

No luck either.

Looks like you are rebooting the device right after updating the HostOS, u-boot notices the device rebooted before the healthchecks in the new OS completed, and it proceeds to switch to loading the dtb and kernel from the old OS. And since in the old OS the dtb has a different name, you get the error:

WARN: Cannot load the DT

This mechanism is used to keep the device accessible in case of potential boot issues in the new OS. Therefore, you need to either wait for at least 3-4 minutes before rebooting the board after the HostOS update, or, flash the board directly with the new OS.

About the dtb, you can also try set it directly:

setenv fdt_file imx8mm-var-dart-dt8mcustomboard.dtb

it shouldn’t get overridden:

if test $fdt_file = undefined; then if ...