Recovery Mode for bricked Compulab Utilite Pro?

[rolli_44]

I have done a firmware update on my Compulab Utilite Pro using u-boot compiled from source. However something went wrong, leaving me with a bricked board. In the manual it is mentioned, that the iMX6 has 2 boot-modes. The recovery-mode can be configured by switching some pin to a high-level. On the PCB I can not find any jumper, that allows me to do so.

Question: Does anybody know how to switch the Compulab Utilite Pro to the recovery-mode?

Thanks in advance

[umiddelb]

Hm, iirc compulab has issued an updated firmware for the Utilite Pro in 2015 (utilite-updater-2015-10.tar.bz2) which tries to load the u-boot binary from µSD first, if present. 

 

[rolli_44]

The point is, there is currently a broken firmware in the flash. So, I have to rely on the recovery boot mode, which I assume is starting even without any firmware at all. In the IMX6 manual it is stated, I have to pull some pin to high-level. Also the pin-number is stated there. However, IMX6 SOC is directly soldered to the PCB, leaving no way to access its pins. If there is now way to set that pin, the device seem to be really bricked, without any way to bring it back to live again.

[Gunjan Gupta]

I don't see Compulab Utilite Pro listed on Armbian's download page. Could you please confirm which image you are using and the URL for the same?

[rolli_44]

Dear Gunjan Gupta,

the boot-process refered here, happens before a kernel image is to be loaded. However I have opened this topic here because "umiddelb" has proposed here -->

a Cubox-i image (see here https://www.armbian.com/cubox-i/) can be used for that device too.

Best Regards

 

[umiddelb]

4 hours ago, rolli_44 said:

The point is, there is currently a broken firmware in the flash. So, I have to rely on the recovery boot mode, which I assume is starting even without any firmware at all. In the IMX6 manual it is stated, I have to pull some pin to high-level. Also the pin-number is stated there. However, IMX6 SOC is directly soldered to the PCB, leaving no way to access its pins. If there is now way to set that pin, the device seem to be really bricked, without any way to bring it back to live again.

The matter is, which part of the firmware seems to be broken? If you have flashed the firmware-update mentioned above (before you have bricked it) and if the SPL is still intact, the SPL tries to load the u-boot binary from µSD first. Since Compulab has abandoned Utility Pro support I share the latest "official" firmware here.   

utilite-updater-2015-10.tar.bz2

[rolli_44]

Thank you very much. I'll give it a try.

[Gunjan Gupta]

2 hours ago, rolli_44 said:

the boot-process refered here, happens before a kernel image is to be loaded.

 

That part I understood already. I was just trying to track if this was a supported device so that I can track if the update that broke your board was from Armbian and what could have went wrong. Wasn't aware of background context as that was certainly not mentioned in the first post.

 

I would leave you guys alone to discuss it further.

[umiddelb]

2 hours ago, rolli_44 said:

a Cubox-i image (see here https://www.armbian.com/cubox-i/) can be used for that device too.

Best Regards

The good thing is: You don't need to modify the contents of the image in order to make it run on an Utilite Pro (This image is supposed to support more or less all imx6 based devices).

The nasty thing is: You need to modify the Utilite u-boot environment to make it compatible with the "distroboot-method" and you need to circumvent the limitations of the firmware. The Utilite u-boot cannot read from ext4 filesystems with 64 bit extensions enabled. 

1. Download the cubox-image and write it to an usb storage (a)
2. Prepare another usb key (b) with an ext4 filesystem: sudo mkfs.ext4 -O ^64bit /dev/sdxX
3. Mount both and copy the contents from (a) to (b)
4. Adjust the rootfs UUID in /boot/armbianEnv.txt and /etc/fstab
5. Plug-in usb key (b) to your Utilite and check if it boots up. 

 

Edited December 4, 2023 by umiddelb

[umiddelb]

22 minutes ago, rolli_44 said:

Thank you very much. I'll give it a try.

The standard Armbian kernel has no support for flash memory access, because the Cubox-i has no flash-memory. So you need to build your own kernel with flash memory support. If you are familiar with flash memory access in u-boot, this might be an alternative.

[rolli_44]

I prepared a SD-card, FAT16 formatted, copied file "cm-fx6-firmware" you gave me. Unfortunately, as I expected, nothing happens. So the SPL loader seem to be bricked too.

Next days I'm trying to solder a very thin copper wire to pin P2-117, connect it to a 3.3V point on the PCB (have to find it before) and hope to activate this way the alternate boot mode from an SD-card on MMC-3 (wherever this might be). See reference guide p.56 in attachment...

CM-FX6-reference-guide.pdf

Edited December 5, 2023 by rolli_44

[umiddelb]

8 hours ago, rolli_44 said:

SD-card on MMC-3 (wherever this might be)

Several devices (e.g. BT & Wifi) are using MMC(SDIO)-interfaces as well (p.10, last row & p.42) , I suppose MMC-3 will be wired to the µSD card receptacle, at least on the CoM, hopefully on the Utilite as well.

Edited December 5, 2023 by umiddelb

[rolli_44]

What I found out by my hardware work is quite confusing to me:

1. ALT_BOOT (P2-117) ist connected via a 3.5kOhm resistor to V_ROOT (P2-115). V_ROOT is the supply voltage of +5V.

2. ALT_BOOT is thus in the normal operation on a voltage level of +3.1V. According to the manual this is equal to a logic high level. So, according to the manual the board should always boot from SD-card (alternative boot mode). I would expect a low level (0V) to select the default boot mode (on-board SPI NOR flash).

3. By pulling ALT_BOOT to low level (0V), nothing happens. (i.e. no output on serial console, no OTR-USB)

So, I'v no idea how to proceed. However, I'm quite sure, that the board itself is still intact, because the only cause was obviously my programming of the internal flash.

Edited December 6, 2023 by rolli_44

[umiddelb]

Hm, the documentations refers to the carrier board, which imho is different to the board used in the Utilite Pro. You may try to get in touch with people from Compulab directly (nice people, very helpful).

[rolli_44]

Do you have a contact for me?

[umiddelb]

Mor Winkler <mor.winkler@compulab.co.il>

 

[rolli_44]

this contact doesnt exist anomore...

[rolli_44]

Finally after a number of tries I got the device back to live. My procedure:
1. prepare sd-card: wrote the file cm-fx6-firmware to a plain sd-card using the command "sudo dd if=cm-fx6-firmware of=/dev/sdX bs=1K skip=1 seek=1 oflag=dsync"

2. booting from prepared sd-card

3. flashing the firmware to SPI using the procedure described on Compulab's Website (https://mediawiki.compulab.com/w/index.php?title=CM-FX6:_U-Boot:_Firmware_Update)

 

The selected boot-mode (pin P2-117 = high-level) works as follows: a) sd-card --> if not present b) SPI-flash

If pin P2-117 is pulled to low-level it tries to boot from SPI-flash only.

OTG-USB seem to be unfunctional.

 

Next I'm trying to install the cubox-i ambian image on my Compulab Utilite Pro. Hope that's working...

 

Edited December 11, 2023 by rolli_44

[umiddelb]

7 hours ago, rolli_44 said:

I got the device back to live

very cool!

[rolli_44]

Well, the circle is closing. While installing the latest Armbian Bookworm CLI image for Cubox-i, I face the problem, that the kernel itself is larger then 8MB, u-boot (version 2015.07-cm-fx6-3) (not the SPL!) is throwing the the error-messge: "Image too large: increase CONFIG_SYS_BOOTM_LEN". From my investigations this requires me to compile an up-to-date SPL and u-boot from source. This however, I have already done. Compilation exited with success. But when I write the resulting SPL into the correct place to sd-card (now I know for sure how to do  🙂 ), nothing happens (i.e. system doesnt boot up)...

Do you have any idea? Are there Cubox-i versions with kernelsize < 8MB?

Edited December 12, 2023 by rolli_44

[umiddelb]

Hm, I'm using the same firmware but I don't get this error during boot. The default u-boot env doesn't incorporate with Armbian. You need to adjust certain parameters and macros.

CM-FX6 # printenv
_1=setenv devplist 1;setenv boot_targets sata0; boot
_2=setenv devplist 2;setenv boot_targets sata0; boot
_3=setenv devplist 3;setenv boot_targets sata0; boot
autoload=no
baudrate=115200
board=utilite-pro
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc0 usb0 sata0
bootcmd=run findfdt; run distro_bootcmd
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_sata0=setenv devnum 0; run sata_boot
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=5
bootenv=uEnv.txt
bootfstype=ext4
bootscr=boot.scr
cons=ttymxc3,115200
console=ttymxc3
cpu=6Q
devnum=0
devplist=1 2 3
devtype=sata
distro_bootcmd=for target in ${boot_targets}; do run bootcmd_${target}; done
eth1addr=00:01:c0:13:fb:ef
ethact=FEC
ethaddr=00:01:c0:13:ed:ea
ethprime=FEC
fdt_addr_r=0x15000000
fdt_high=0xffffffff
fdtfile=undefined
filesize=5de
findfdt=setenv fdtfile imx6q-utilite-pro.dtb
initrd_high=0xffffffff
ip_dyn=yes
kernel_addr_r=0x10800000
loadaddr=0x10800000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot_part; fi
preboot=sata init
ramdisk=uInitrd
ramdisk_addr_r=0x18000000
sata_boot=if sata dev ${devnum}; then setenv devtype sata; run scan_dev_for_boot_part; fi
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}:${distro_bootpart}...; for prefix in ${boot_prefixes}; do run scan_dev_for_scripts; done;
scan_dev_for_boot_part=for distro_bootpart in ${devplist}; do if fstype ${devtype} ${devnum}:${distro_bootpart} bootfstype; then run scan_dev_for_boot; fi; done
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${distro_bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x10800000
serial=CM-FX6-C1200QM-D2G-N0-ND0-U5-E-A-WB-V100-131028-0001c013edea
splashpos=m,m
stderr=serial,vga
stdin=serial,usbkbd
stdout=serial,vga
usb_boot=usb start; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot_part; fi
video_dvi=mxcfb0:dev=dvi,1280x800M-24@50,if=RGB24
video_hdmi=mxcfb0:dev=hdmi,1920x1080M-24@50,if=RGB24

 

[rolli_44]

Your actual boot is done in a script on the selected device. Can you supply me that script too?

 

On my system the "bootz" command seem to be unfunctional.

 

I got the cubox-i image working by simply copying a stone-old uncompressed arm kernel 4.11.3-1-ARCH (5.9MB) from a working utilite-pro linux-installation to the boot partition, loading it into the memory and using the "bootm"-command. For the boot-process there is only the kernel, no device tree, no ram-disk - suprisingly though...

 

 

The armhf netinst kernel from Debian (inside that iso-file https://cdimage.debian.org/debian-cd/current/armhf/iso-cd/debian-12.4.0-armhf-netinst.iso) (5.4MB) (https://wiki.debian.org/InstallingDebianOn/CompuLab/PC-Utilite/buster) is also not working, even in uncompressed form. I have no idea what the difference between the my ARCH and the Debian kernel might be.

Edited December 13, 2023 by rolli_44

[umiddelb]

The script is the standard boot.cmd (https://github.com/armbian/build/pull/3527)

 

# DO NOT EDIT THIS FILE
#
# Please edit /boot/armbianEnv.txt to set supported parameters
#

# default values
setenv rootdev "/dev/mmcblk0p1"
setenv verbosity "1"
setenv console "display"
setenv bootlogo "false"
setenv disp_mode "1920x1080m60"
setenv earlycon "off"
if test -z "${bootfstype}"; then setenv rootfstype "ext4"; else setenv rootfstype "${bootfstype}"; fi

if test "${board}" = mx6cuboxi; then
  setenv ramdisk_addr_r "0x14800000"
  if test -z "${fdtfile}"; then setenv fdtfile "imx6q-cubox-i.dtb"; fi
  if test -z "${cons}"; then setenv cons "ttymxc0,115200"; fi
fi

if load ${devtype} ${devnum}:${distro_bootpart} ${loadaddr} ${prefix}armbianEnv.txt ; then
	env import -t ${loadaddr} ${filesize}
fi

if test "${console}" = "display" || test "${console}" = "both"; then setenv consoleargs "console=tty1"; fi
if test "${console}" = "serial" || test "${console}" = "both"; then setenv consoleargs "${consoleargs} console=${cons}"; fi
if test "${earlycon}" = "on"; then setenv consoleargs "earlycon ${consoleargs}"; fi
if test "${bootlogo}" = "true"; then
	setenv consoleargs "splash plymouth.ignore-serial-consoles ${consoleargs}"
else
	setenv consoleargs "splash=verbose ${consoleargs}"
fi

setenv bootargs "root=${rootdev} rootfstype=${rootfstype} rootwait ${consoleargs} consoleblank=0 video=mxcfb0:dev=hdmi,${disp_mode},if=RGB24,bpp=32 coherent_pool=2M cma=256M@2G rd.dm=0 rd.luks=0 rd.lvm=0 raid=noautodetect pci=nomsi vt.global_cursor_default=0 loglevel=${verbosity} usb-storage.quirks=${usbstoragequirks} ${extraargs}"
load ${devtype} ${devnum}:${distro_bootpart} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
load ${devtype} ${devnum}:${distro_bootpart} ${ramdisk_addr_r} ${prefix}uInitrd
load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} ${prefix}zImage

bootz ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

 

You may pay attention to the predefined u-boot variables containing memory adresses and limits. 

[rolli_44]

As is said, the "bootz" command doesnt work on my system. It loads the kernel, writes "Starting Kernel..." and then freezes.

 

The only way, that works for me is the command "bootm", however even this needs a strange special preparation:

1. Concatenate vmlinuz and device tree to a special zImage by "cat vmlinuz_armhf_debian_netinst imx6q-utilite-pro.dtb > zImage-cm-fx6"

2. Convert that special zImage to an uImage by "mkimage -A arm -O linux -T kernel -C none -a 0x10008000 -e 0x10008000 -n "Linux armhf debian netinst" -d zImage-cm-fx6 uImage-cm-fx6"

3. Load into memory by "load $dev $dev_num $loadaddr uImage-cm-fx6"

4. Boot from memory by "bootm $loadaddr"

 

However using this new debian-kernel, it hangs after about 4sec with "waiting for root device /dev/mmcblk0p1", even though this is available... (see attached boot-log)

 

Ah, maybe this small kernel doesnt have mmc support compiled into... Hmm, I have to find a new arm-kernel with mmc-support with size <8MB...

 

bootlog.txt

Edited December 14, 2023 by rolli_44

[umiddelb]

If you post the your u-boot environment here I can have a look on it. Some u-boot variables may interfere with bootz.

The Utilite default console is ttymxc3, not ttymxc0. If the kernel command line refers to ttymxc0 you won't see any output.

 

Btw. the latest kernel (6.1.63-current-imx6) doesn't seem to be a good choice, the kernel crashes after a while.

[rolli_44]

my environment:

environment.txt

[umiddelb]

1 hour ago, rolli_44 said:

my environment:

 

This looks like the original boot environment, bootz won't work there. Do you think you would be able to adopt my boot environment? You may prepare it in the same format like /boot/armbianEnv.txt and load it according to /boot/boot.cmd. Before making these changes permanent (# saveenv) you can try them in advance (# run bootcmd). 

 

[rolli_44]

ok I will try it

[rolli_44]

this u-boot environment is totally buggy:

writing files doesnt work, env import behaves erratic and causes erratic characters to appear in the env, etc.

I'm still tring...

got it: bytes read output of load command is decimal, while env import size is hexadecimal 🙂

 

Finally I was able to debug and adopt your environment and boot.cmd. Everything works seemingly fine, until it comes to the bootz-command. Here it stops with the error message:

 

ERROR: Did not find a cmdline Flattened Device Tree

Could not find a valid device tree

SCRIPT FAILED: continuing...

 

device tree file "imx6q-utilite-pro.dtb" has not been correctly loaded to address 0x15000000...

 

After manually loading device tree file, next error message:

 

Wrong Ramdisk Image Format

Ramdisk image is corrupt or invalid

 

I found out, that the device tree is placed inside the ramdisk, thus both corruptiong each other... After ajusting fdt_addr_r to 20000000, my result (same problem seemingly freezing with Starting kernel...)

 

Then after adjusting in boot.cmd:

setenv console "serial"
setenv earlycon "on"

 

MY FINAL RESULT !!!! 🙂

 

Problem solved...

 

And you are right the kernel is crashing after about 15minutes.

Edited December 19, 2023 by rolli_44

[umiddelb]

Very good! Usually the bootscript doesn't need to be modified if the u-boot environment looks more or less like the one I've posted above (only the MAC addresses should differ) .

 

The 6.1.50 kernel runs smoothly, just extract the 6.1.50-current-imx6.tgz in /