Just wondering if anyone has booted the latest cubox-i test images with kernel 4.9.5 ? I tried the last couple of days with no joy; however I have not got around to full logs / troubleshooting. It looks like it is getting into u-boot OK but then not finding the dtb and drops to the u-boot shell.

I tried to fix the boot script based on provided log, but Igor may need to adjust it further since I don't have this hardware.

It works fine on Hummingboard 1 and 2 ... just built from sources.

 

This board looks like it's not properly recognised by u-boot or it's simply not supported. What kind of hardware is this? You can try to force fdtfile to imx6q-cubox-i.dtb (add fdt_file=xxxxx to /boot/armbianEnv.txt) or one of those:

 

 

imx6dl-apf6dev.dtb
imx6dl-aristainetos2_4.dtb
imx6dl-aristainetos2_7.dtb
imx6dl-aristainetos_4.dtb
imx6dl-aristainetos_7.dtb
imx6dl-cubox-i.dtb
imx6dl-dfi-fs700-m60.dtb
imx6dl-gw51xx.dtb
imx6dl-gw52xx.dtb
imx6dl-gw53xx.dtb
imx6dl-gw54xx.dtb
imx6dl-gw551x.dtb
imx6dl-gw552x.dtb
imx6dl-gw553x.dtb
imx6dl-hummingboard2.dtb
imx6dl-hummingboard.dtb
imx6dl-nit6xlite.dtb
imx6dl-nitrogen6x.dtb
imx6dl-phytec-pbab01.dtb
imx6dl-rex-basic.dtb
imx6dl-riotboard.dtb
imx6dl-sabreauto.dtb
imx6dl-sabrelite.dtb
imx6dl-sabresd.dtb
imx6dl-ts4900.dtb
imx6dl-tx6dl-comtft.dtb
imx6dl-tx6s-8034.dtb
imx6dl-tx6s-8035.dtb
imx6dl-tx6u-801x.dtb
imx6dl-tx6u-8033.dtb
imx6dl-tx6u-811x.dtb
imx6dl-tx6u-81xx-mb7.dtb
imx6dl-udoo.dtb
imx6dl-wandboard.dtb
imx6dl-wandboard-revb1.dtb
imx6q-apalis-ixora.dtb
imx6q-apf6dev.dtb
imx6q-arm2.dtb
imx6q-b450v3.dtb
imx6q-b650v3.dtb
imx6q-b850v3.dtb
imx6q-cm-fx6.dtb
imx6q-cubox-i.dtb
imx6q-dfi-fs700-m60.dtb
imx6q-dmo-edmqmx6.dtb
imx6q-evi.dtb
imx6q-gk802.dtb
imx6q-gw51xx.dtb
imx6q-gw52xx.dtb
imx6q-gw53xx.dtb
imx6q-gw5400-a.dtb
imx6q-gw54xx.dtb
imx6q-gw551x.dtb
imx6q-gw552x.dtb
imx6q-gw553x.dtb
imx6q-h100.dtb
imx6q-hummingboard2.dtb
imx6q-hummingboard.dtb
imx6q-icore-rqs.dtb
imx6q-marsboard.dtb
imx6q-nitrogen6_max.dtb
imx6q-nitrogen6x.dtb
imx6q-novena.dtb
imx6q-phytec-pbab01.dtb
imx6qp-nitrogen6_max.dtb
imx6qp-sabreauto.dtb
imx6qp-sabresd.dtb
imx6q-rex-pro.dtb
imx6q-sabreauto.dtb
imx6q-sabrelite.dtb
imx6q-sabresd.dtb
imx6q-sbc6x.dtb
imx6q-tbs2910.dtb
imx6q-ts4900.dtb
imx6q-tx6q-1010-comtft.dtb
imx6q-tx6q-1010.dtb
imx6q-tx6q-1020-comtft.dtb
imx6q-tx6q-1020.dtb
imx6q-tx6q-1036.dtb
imx6q-tx6q-1110.dtb
imx6q-tx6q-11x0-mb7.dtb
imx6q-udoo.dtb
imx6q-utilite-pro.dtb
imx6q-wandboard.dtb
imx6q-wandboard-revb1.dtb
imx6sl-evk.dtb
imx6sl-warp.dtb
imx6sx-nitrogen6sx.dtb
imx6sx-sabreauto.dtb
imx6sx-sdb.dtb
imx6sx-sdb-reva.dtb
imx6sx-sdb-sai.dtb
imx6ul-14x14-evk.dtb
imx6ul-geam-kit.dtb
imx6ul-pico-hobbit.dtb
imx6ul-tx6ul-0010.dtb
imx6ul-tx6ul-0011.dtb
imx6ul-tx6ul-mainboard.dtb

 

 

BTW: I notice on cool feature on recent imx mainline builds - display configuration works out of the box. 

 

It's an i4-pro. I have Armbian_5.20_Cubox-i_Debian_jessie_3.14.79_desktop.7z booted fine on the same box (and all previous versions of Armbian). Not sure why it is not recognised, but I will look at forcing the dtb tomorrow

It's an i4-pro. I have Armbian_5.20_Cubox-i_Debian_jessie_3.14.79_desktop.7z booted fine on the same box (and all previous versions of Armbian). Not sure why it is not recognised, but I will look at forcing the dtb tomorrow

 

I am pretty sure, the problem is in u-boot, since our boot scripts uses parameters, which are detected by u-boot. There were some recent changes in u-boot and regression is possible - because of latest hw revisions, which brought: eMMC, 4G and HB2. But anyway, just try to set dtb file manually. If that won't help, you need to ask Solidrun to fix u-boot.

OK, just to check I dug out my i2-ex Cubox-i and it is having the same problem of the DTB not being found / unrecognized filesystem type etc. Will try manually setting up the armbianEnv.txt

Judging by the DTB file names reverting this (or adding a reverse patch to the Armbian patches) may help.

OK, just looked in  /boot and see this. no armbianEnv.txt ?

 

-rwxr-xr-x  1 root root 4907656 Jan 20 21:33 vmlinuz-4.9.5-cubox
-rw-r--r--  1 root root 2668239 Jan 20 21:33 System.map-4.9.5-cubox
-rw-r--r--  1 root root  143921 Jan 20 21:33 config-4.9.5-cubox
drwxr-xr-x 22 root root    4096 Jan 21 16:09 ..
lrwxrwxrwx  1 root root      19 Jan 21 16:10 zImage -> vmlinuz-4.9.5-cubox
-rw-r--r--  1 root root       0 Jan 21 16:10 .next
drwxr-xr-x  2 root root    4096 Jan 21 16:13 dtb-4.9.5-cubox
lrwxrwxrwx  1 root root      15 Jan 21 16:13 dtb -> dtb-4.9.5-cubox
-rw-r--r--  1 root root 4652094 Jan 21 16:14 initrd.img-4.9.5-cubox
-rw-r--r--  1 root root 4652158 Jan 21 16:14 uInitrd-4.9.5-cubox
lrwxrwxrwx  1 root root      19 Jan 21 16:14 uInitrd -> uInitrd-4.9.5-cubox
-rw-r--r--  1 root root    6944 Jan 21 16:14 boot.bmp
-rw-r--r--  1 root root    1459 Jan 21 16:14 boot.cmd
-rw-r--r--  1 root root       0 Jan 21 16:14 .verbose
-rw-r--r--  1 root root    1557 Jan 21 16:14 armbian_first_run.txt
-rw-r--r--  1 root root    1531 Jan 21 16:16 boot.scr
drwxr-xr-x  3 root root    4096 Jan 21 16:16 .

@jpearn

 

This file doesn't exist by default in older images, and I'm not sure if creating it will work without updating the boot script too.

OK, so I used an older boot.cmd and made a new boot.scr with the dtb manually set and ended up with :

 

Kernel image @ 0x10800000 [ 0x000000 - 0x4ae288 ]
## Loading init Ramdisk from Legacy Image at 14800000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4652094 Bytes = 4.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 18000000
   Booting using the fdt blob at 0x18000000
   Using Device Tree in place at 18000000, end 1800b26f

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
Unhandled fault: alignment exception (0x001) at 0xadd7e295
pgd = 80004000
[add7e295] *pgd=3dc1141e(bad)
Internal error: : 1 [#1] SMP THUMB2
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.5-cubox #3
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
 

OK, my i2 cubox uses the imxq dtb not imxdl so it has started booting the kernel after going back to the boot.cmd !

 

It's booting to a login with no errors, so have a look after Sunday lunch Thanks for the help !

Working fine after the manual mod to boot.cmd and recreating the boot.scr

I added the beta.armbian repo and the kernel 'updated' to 4.9.4 ? Newer compile date. Still works OK though !

Working fine after the manual mod to boot.cmd and recreating the boot.scr

I added the beta.armbian repo and the kernel 'updated' to 4.9.4 ? Newer compile date. Still works OK though !

 

Yes, boot environment configuration should survive kernel upgrade.

 

BTW: I notify Solidrun about this issue.

Hi Igor, thanks for the update. Any reason why the kernel version went down from 4.9.5 to 4.9.4 from the beta repo?

Hi Igor, thanks for the update. Any reason why the kernel version went down from 4.9.5 to 4.9.4 from the beta repo?

 

That was pure coincidence. We are preparing to put out update for all images and I made first test build two days ago. Kernel on those images (the one you downloaded) is having higher kernel number but lower package version number than nightly builds ... which are currently on hold due to changes on download server. 

 

In any case, don't bother with that

 

 

Hi guys, 

 

Just dug out my Cubox after a few years and tried to install Armbian but I am having the same error as jpearn. 

 

Is there any way to resolve this (step by step) ? or a previous version that I can use? 

 

Thanks

Hi guys, 

 

Just dug out my Cubox after a few years and tried to install Armbian but I am having the same error as jpearn. 

 

Is there any way to resolve this (step by step) ? or a previous version that I can use? 

 

Thanks

Perhaps you have older Cubox which is based on Marvell chip set and not imx6 ? Are there any marks on the box? Can you open and check the chip?