search

compulab-yokneam / meta-bsp-imx8mp

13 stars 13 forks source link

Provisioning reference image fails on iot-gate-imx8plus #23

Closed acostach closed 9 months ago

acostach commented 10 months ago

Hi @vraevsky , we have balenaOS user who reports that he is no longer able to flash the reference Debian image offered by Compulab on his device in this thread: https://forums.balena.io/t/install-balena-os-to-compulab-imx8plus/368506/16

From the problem description it appears that Windows may have formatted the hw boot partition on which u-boot is stored and from that point on ums can no longer expose it, nor does u-boot run anymore unless loaded with uuu.

iot-gate-imx8plus=> ums 0 mmc 2.1
** Invalid partition 1 **

User also reports that writing the reference recovery u-boot image doesn't help either and that he's still unable to run u-boot after performing the flashing steps at https://mediawiki.compulab.com/w/index.php?title=IOT-GATE-IMX8PLUS_and_SBC-IOT-IMX8PLUS:_U-Boot:_Recovery

What would be the steps needed to fix u-boot and run the Debian flasher?

Thanks

vraevsky commented 10 months ago

Please follow the instructions of the: https://mediawiki.compulab.com/w/index.php?title=IOT-GATE-IMX8PLUS_and_SBC-IOT-IMX8PLUS:_U-Boot:_Recovery   make the device get into SDPS mode (Flashing_U-Boot_Firmware), but don’t issue any command.   Flash the device using this command: sudo  uuu -v -b emmc_all  /path/to/balena-imx-boot.bin /path/to/balena/Debian.image

acostach commented 10 months ago

Thanks @vraevsky , for balenaOS provisioning we use uuu to load and run the balenaOS imx-boot and from that running instance we expose the eMMC and the boot partition for writing the eMMC image as well as imx-boot, for example: ums 0 mmc 2 -> write balenaOS image ums 0 mmc2.1 -> write balenaOS imx-boot.

These are the steps we use and work for us.

However, what the customer currently asked for is to flash the Compulab u-boot so he can get to the Grub installer on the USB stick, not the balenaOS one. He used the steps https://mediawiki.compulab.com/w/index.php?title=IOT-GATE-IMX8PLUS_and_SBC-IOT-IMX8PLUS:_U-Boot:_Recovery and the Compulab recovery u-boot written with

sudo uuu -v -b emmc /path/to/iot-gate-imx8plus-firmware/flash.bin.d2d4

did not run after the flashing and disconnecting the PROG cable - https://forums.balena.io/t/install-balena-os-to-compulab-imx8plus/368506/16

The only potential causes that come to mind is that the board used may not be a D2D4 configuration but in that case the balena-imx-boot built in d2d4 configuration wouldn't have worked.

Also, the same steps work fine for us but not for the user.

Should the following steps work for the customer for flashing the Compulab reference image? 

sudo  uuu -v -b emmc_all  /path/to/compulab-recovery-imx-boot.bin /path/to/compulab-debian-image

Would it allow using ums to expose the u-boot partition again and fix the problem below?

iot-gate-imx8plus=> ums 0 mmc 2.1
** Invalid partition 1 **
vraevsky commented 10 months ago

This command does work for deploying both imx-boot + debian image: sudo uuu -v -b emmc_all /path/to/compulab-recovery-imx-boot.bin /path/to/compulab-debian-image

BalenaOS + imx-boot update) If the device should be updated with all Balena imx-boot + image use this procedure: sudo uuu -v /path/to/compulab-recovery-imx-boot.bin sudo uuu -v -b emmc_all /path/to/balena-imx-boot.bin /path/to/balenaOS.image

Anyway if a ums approach is required, then issue: sudo uuu -v /path/to/compulab-recovery-imx-boot.bin ums 0 mmc 2.1

From the https://forums.balena.io/t/install-balena-os-to-compulab-imx8plus/368506/16: wrong commad) unzip -p iot-gate-imx8plus_debian-linux_2023-03-20.zip | sudo dd of=/dev/sdb1 bs=1M status=progress conv=fsync correct command) unzip -p iot-gate-imx8plus_debian-linux_2023-03-20.zip | sudo dd of=/dev/sdb bs=1M status=progress conv=fsync

About CompuLab GRUB) _https://github.com/compulab-yokneam/Documentation/blob/master/etc/internal/compulab_grub.md_

acostach commented 10 months ago

Thanks @vraevsky !

The customer reported that they've tried the steps but didn't work: https://forums.balena.io/t/install-balena-os-to-compulab-imx8plus/368506/23

vraevsky commented 10 months ago

Hello @acostach,

I'd appreciate it if you could provide the Balena bootloader and the os-image, so we could try to reproduce the customer issue.

acostach commented 10 months ago

@vraevsky sure, a pre-compiled version of the blenaOS development bootloader is available at https://github.com/balena-os/balena-iot-gate-imx8plus/blob/master/imx-boot_4g , and the balenaOS images are available at https://dashboard.balena-cloud.com/signup . You can quickly sign-up with google, and the service is free for up to 10 running instances.

Leaving the a short summary of how things stand as of now:

Thanks!

vraevsky commented 10 months ago

@acostach please have a look at this procedure: https://github.com/compulab-yokneam/Documentation/blob/master/iot-gate-imx8mplus/balenaOS.adoc

acostach commented 10 months ago

Hi @vraevsky and thank you for sharing this document! I was able to flash production balenaOS images using the steps in the document you created with minor changes. A couple points about the doc update:

a) For https://github.com/compulab-yokneam/Documentation/blob/master/iot-gate-imx8mplus/balenaOS.adoc#ums-method

the imx-boot_4g from https://github.com/balena-os/balena-iot-gate-imx8plus/blob/master/imx-boot_4g should only be used when loaded with uuu to expose the boot partition using ums 0 2.1. So the command, without unzip because the bootloader is not compressed, would be:

sudo dd if=imx-boot-iot-gate-imx8plus-sd.bin-flash_evk of=/dev/sdb bs=1M status=progress conv=fsync

where imx-boot-iot-gate-imx8plus-sd.bin-flash_evk is taken from the resin-boot partition of the image. The difference between img-boot_4g and imx-boot-iot-gate-imx8plus-sd.bin-flash_evk is that imx-boot-iot-gate-imx8plus-sd.bin-flash_evk has shell access disabled.

b) For https://github.com/compulab-yokneam/Documentation/blob/master/iot-gate-imx8mplus/balenaOS.adoc#uuufastboot-method , a third step is necessary, which is exposing the boot partition using ums 0 2.1 and writing the production bootloader that has shell access disabled:

sudo dd if=imx-boot-iot-gate-imx8plus-sd.bin-flash_evk of=/dev/sdb bs=1M status=progress conv=fsync

Also, we could mention that the steps 1) and 2) can be swapped if shell access is disabled, to run fastboot 0. I can confirm that this worked for me to restore the board even after I created an ex4 partition on the mmcbllk2boot0.

Now, regarding the problem our user is facing, what could be causing the following logs on his side when running

sudo uuu -v -b emmc_all flash.bin.d2d4 debian-bullseye-arm64_iot-gate-imx8plus_live-img.img

and getting

Detect USB boot. Will enter fastboot mode!
Net:   eth0: ethernet@30be0000 [PRIME], eth1: ethernet@30bf0000
Fastboot: Normal
Boot from USB for mfgtools
*** Warning - Use default environment for                                mfgtools
, using default environment

Run bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fastboot ..."; fastboot 0; fi;
Hit any key to stop autoboot:  0

## Checking Image at 43800000 ...
Unknown image format!
Run fastboot ...

and there's where all u-boot logs stop?

On my side I see the image getting written with the exact same command:

sudo uuu -v -b emmc_all flash.bin.d2d4 debian-bullseye-arm64_iot-gate-imx8plus_live-img.img 

MMC Device 0 not found
no mmc device at slot 0
Detect USB boot. Will enter fastboot mode!
Net:   eth0: ethernet@30be0000 [PRIME], eth1: ethernet@30bf0000
Fastboot: Normal
Boot from USB for mfgtools
*** Warning - Use default environment for                                mfgtools
, using default environment

Run bootcmd_mfg: run mfgtool_args;if iminfo ${initrd_addr}; then if test ${tee} = yes; then bootm ${tee_addr} ${initrd_addr} ${fdt_addr}; else booti ${loadaddr} ${initrd_addr} ${fdt_addr}; fi; else echo "Run fas
tboot ..."; fastboot 0; fi;
Hit any key to stop autoboot:  0 

## Checking Image at 43800000 ...
Unknown image format!
Run fastboot ...
Detect USB boot. Will enter fastboot mode!
flash target is MMC:0
MMC Device 0 not found
invalid mmc device 0
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
Detect USB boot. Will enter fastboot mode!
flash target is MMC:2
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
switch to partitions #0, OK
mmc2(part 0) is current device
Detect USB boot. Will enter fastboot mode!
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
Starting download of 16776232 bytes
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
..........................................................................
.....................................................
downloading of 16776232 bytes finished
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
writing to partition 'all'
sparse flash target is mmc:2
writing to partition 'all' for sparse, buffer size 16776232
Flashing sparse image at offset 0
Flashing Sparse Image
........ wrote 16776192 bytes to 'all'
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
Starting download of 16776244 bytes
(NULL udevice *): request 0000000052f3eb00 was not queued to ep1in-bulk
..........................................................................
.....................................................

but on the customer's side it gets stuck. Could the customer's problem be caused by debian image corruption or by something else?

vraevsky commented 10 months ago

Hi @acostach,

Thanks for reviewing the document. 1) ums 0 mmc 2.1 with unzip fixed. 2) uuu/fastboot requires no additional steps at all; "uuu -b emmc_all ..." flashes both the OS image and after that issues mmc dev 2 1 and flashes the bootloader. Have a look at the logs at:https://drive.google.com/drive/folders/1u6Dlnq-t2g77KgcDkfbhy_0Sy0aPsO69 3:user issue) It could be if more that one uuu instance is running at the same time. 3+) it could be a host issue as well. We've never issued uuu on Windows. Suggestion: is to look into the host syslog.