Jump to content
  • 0

[Cubox-i] Unable to boot latest test images with kernel 4.9.5


jpearn

Question

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.

post-773-0-30910900-1485029021_thumb.jpg

Link to comment
Share on other sites

16 answers to this question

Recommended Posts

  • 0

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. 

 

Screenshot_2017-01-21_21-20-01.png

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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 .

Link to comment
Share on other sites

  • 0

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)
 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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

 

 

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

  • 0

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? 

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines