jpearn Posted January 21, 2017 Posted January 21, 2017 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.
zador.blood.stained Posted January 21, 2017 Posted January 21, 2017 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.
Igor Posted January 21, 2017 Posted January 21, 2017 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.dtbimx6dl-aristainetos2_4.dtbimx6dl-aristainetos2_7.dtbimx6dl-aristainetos_4.dtbimx6dl-aristainetos_7.dtbimx6dl-cubox-i.dtbimx6dl-dfi-fs700-m60.dtbimx6dl-gw51xx.dtbimx6dl-gw52xx.dtbimx6dl-gw53xx.dtbimx6dl-gw54xx.dtbimx6dl-gw551x.dtbimx6dl-gw552x.dtbimx6dl-gw553x.dtbimx6dl-hummingboard2.dtbimx6dl-hummingboard.dtbimx6dl-nit6xlite.dtbimx6dl-nitrogen6x.dtbimx6dl-phytec-pbab01.dtbimx6dl-rex-basic.dtbimx6dl-riotboard.dtbimx6dl-sabreauto.dtbimx6dl-sabrelite.dtbimx6dl-sabresd.dtbimx6dl-ts4900.dtbimx6dl-tx6dl-comtft.dtbimx6dl-tx6s-8034.dtbimx6dl-tx6s-8035.dtbimx6dl-tx6u-801x.dtbimx6dl-tx6u-8033.dtbimx6dl-tx6u-811x.dtbimx6dl-tx6u-81xx-mb7.dtbimx6dl-udoo.dtbimx6dl-wandboard.dtbimx6dl-wandboard-revb1.dtbimx6q-apalis-ixora.dtbimx6q-apf6dev.dtbimx6q-arm2.dtbimx6q-b450v3.dtbimx6q-b650v3.dtbimx6q-b850v3.dtbimx6q-cm-fx6.dtbimx6q-cubox-i.dtbimx6q-dfi-fs700-m60.dtbimx6q-dmo-edmqmx6.dtbimx6q-evi.dtbimx6q-gk802.dtbimx6q-gw51xx.dtbimx6q-gw52xx.dtbimx6q-gw53xx.dtbimx6q-gw5400-a.dtbimx6q-gw54xx.dtbimx6q-gw551x.dtbimx6q-gw552x.dtbimx6q-gw553x.dtbimx6q-h100.dtbimx6q-hummingboard2.dtbimx6q-hummingboard.dtbimx6q-icore-rqs.dtbimx6q-marsboard.dtbimx6q-nitrogen6_max.dtbimx6q-nitrogen6x.dtbimx6q-novena.dtbimx6q-phytec-pbab01.dtbimx6qp-nitrogen6_max.dtbimx6qp-sabreauto.dtbimx6qp-sabresd.dtbimx6q-rex-pro.dtbimx6q-sabreauto.dtbimx6q-sabrelite.dtbimx6q-sabresd.dtbimx6q-sbc6x.dtbimx6q-tbs2910.dtbimx6q-ts4900.dtbimx6q-tx6q-1010-comtft.dtbimx6q-tx6q-1010.dtbimx6q-tx6q-1020-comtft.dtbimx6q-tx6q-1020.dtbimx6q-tx6q-1036.dtbimx6q-tx6q-1110.dtbimx6q-tx6q-11x0-mb7.dtbimx6q-udoo.dtbimx6q-utilite-pro.dtbimx6q-wandboard.dtbimx6q-wandboard-revb1.dtbimx6sl-evk.dtbimx6sl-warp.dtbimx6sx-nitrogen6sx.dtbimx6sx-sabreauto.dtbimx6sx-sdb.dtbimx6sx-sdb-reva.dtbimx6sx-sdb-sai.dtbimx6ul-14x14-evk.dtbimx6ul-geam-kit.dtbimx6ul-pico-hobbit.dtbimx6ul-tx6ul-0010.dtbimx6ul-tx6ul-0011.dtbimx6ul-tx6ul-mainboard.dtb BTW: I notice on cool feature on recent imx mainline builds - display configuration works out of the box.
jpearn Posted January 21, 2017 Author Posted January 21, 2017 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
Igor Posted January 22, 2017 Posted January 22, 2017 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.
jpearn Posted January 22, 2017 Author Posted January 22, 2017 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
zador.blood.stained Posted January 22, 2017 Posted January 22, 2017 Judging by the DTB file names reverting this (or adding a reverse patch to the Armbian patches) may help.
jpearn Posted January 22, 2017 Author Posted January 22, 2017 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-cuboxdrwxr-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 .nextdrwxr-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-cuboxlrwxrwxrwx 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.scrdrwxr-xr-x 3 root root 4096 Jan 21 16:16 .
zador.blood.stained Posted January 22, 2017 Posted January 22, 2017 @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.
jpearn Posted January 22, 2017 Author Posted January 22, 2017 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 1800b26fStarting kernel ...Uncompressing Linux... done, booting the kernel.Unhandled fault: alignment exception (0x001) at 0xadd7e295pgd = 80004000[add7e295] *pgd=3dc1141e(bad)Internal error: : 1 [#1] SMP THUMB2Modules linked in:CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.5-cubox #3Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
jpearn Posted January 22, 2017 Author Posted January 22, 2017 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 ! 1
jpearn Posted January 22, 2017 Author Posted January 22, 2017 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 !
Igor Posted January 22, 2017 Posted January 22, 2017 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. 1
jpearn Posted January 22, 2017 Author Posted January 22, 2017 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?
Igor Posted January 22, 2017 Posted January 22, 2017 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 1
piflex Posted February 17, 2017 Posted February 17, 2017 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
Igor Posted February 17, 2017 Posted February 17, 2017 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?
Recommended Posts