Jump to content

Recovery Mode for bricked Compulab Utilite Pro?

rolli_44

By rolli_44
in Beginners

 Share
Go to solution Solved by rolli_44,

Recommended Posts

rolli_44

rolli_44

Posted
Posted

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

0
Link to comment
Share on other sites
rolli_44

rolli_44

Posted
  • Author
Posted

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.

0
Link to comment
Share on other sites
umiddelb

umiddelb

Posted
Posted
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

0
Link to comment
Share on other sites
Gunjan Gupta

Gunjan Gupta

Posted
Posted
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.

0
Link to comment
Share on other sites
umiddelb

umiddelb

Posted
Posted (edited)
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 by umiddelb
0
Link to comment
Share on other sites
umiddelb

umiddelb

Posted
Posted
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.

0
Link to comment
Share on other sites
rolli_44

rolli_44

Posted
  • Author
Posted (edited)

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 by rolli_44
0
Link to comment
Share on other sites
umiddelb

umiddelb

Posted
Posted (edited)
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 by umiddelb
0
Link to comment
Share on other sites
rolli_44

rolli_44

Posted
  • Author
Posted (edited)

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 by rolli_44
0
Link to comment
Share on other sites
  • Solution
rolli_44

rolli_44

Posted
  • Author
  • Solution
Posted (edited)

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 by rolli_44
0
Link to comment
Share on other sites
rolli_44

rolli_44

Posted
  • Author
Posted (edited)

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 by rolli_44
0
Link to comment
Share on other sites
umiddelb

umiddelb

Posted
Posted

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

 

0
Link to comment
Share on other sites
rolli_44

rolli_44

Posted
  • Author
Posted (edited)

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...

 

grafik.png.8b5c691eb69802b35760f4d7d2aa80a0.png

 

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 by rolli_44
0
Link to comment
Share on other sites
umiddelb

umiddelb

Posted
Posted

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. 

0
Link to comment
Share on other sites
rolli_44

rolli_44

Posted
  • Author
Posted (edited)

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 by rolli_44
0
Link to comment
Share on other sites
umiddelb

umiddelb

Posted
Posted

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.

0
Link to comment
Share on other sites
umiddelb

umiddelb

Posted
Posted
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). 

 

0
Link to comment
Share on other sites
rolli_44

rolli_44

Posted
  • Author
Posted (edited)

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...)

grafik.png.71344f3e1eb3807dd11f4584dfa865af.png

 

Then after adjusting in boot.cmd:

setenv console "serial"
setenv earlycon "on"

 

MY FINAL RESULT !!!! 🙂

grafik.png.a97bd9c4a091ab9ebc21d8dff5a3e971.png

 

Problem solved...

 

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

Edited by rolli_44
0
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept