jpearn

This works well for me, thanks ! The rest of Bionic on Cubox-i is much more stable now :)

Still getting the error, is it safe to remove armbian-tools-xenial for now or is it needed ?

I've been upgrading to the latest nightly mainline kernel every couple of weeks or so and had a problem today whilst updating linux-xenial-root-next-cubox-i dpkg output throws an error : root@JPCuboxi4:/boot# apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: linux-xenial-root-next-cubox-i 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/332 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] y (Reading database ... 177105 files and directories currently installed.) Preparing to unpack .../linux-xenial-root-next-cubox-i_5.32.170728_armhf.deb ... Leaving 'diversion of /etc/mpv/mpv.conf to /etc/mpv/mpv-dist.conf by linux-xenial-root-next-cubox-i' Unpacking linux-xenial-root-next-cubox-i (5.32.170728) over (5.32.170716) ... dpkg: error processing archive /var/cache/apt/archives/linux-xenial-root-next-cubox-i_5.32.170728_armhf.deb (--unpack): trying to overwrite '/usr/bin/brcm_patchram_plus', which is also in package armbian-tools-xenial 5.27.170301 Processing triggers for initramfs-tools (0.122ubuntu8.8) ... update-initramfs: Generating /boot/initrd.img-4.12.3-cubox update-initramfs: Converting to u-boot format Errors were encountered while processing: /var/cache/apt/archives/linux-xenial-root-next-cubox-i_5.32.170728_armhf.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This happens on both my cubox-i's. I tried to move brcm_patchram_plus but it still throws out the error. Any ideas ?!

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?

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 !

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 !

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

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

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

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.

What is interesting is that the RPi3 will throttle on stock speeds after a while, mine does this. Apparently it is hit and miss whether you can get one which will overclock at all . . . http://www.jackenhack.com/raspberry-pi-3-overclocking/ Even the engineers have recommended a heatsink for hefty processing : https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=6201&sid=600aa15ee596c0d9cb6a756ecb8ba60c&start=1075

Well I am up and running 4th attempt with manual resizing of the SD card and copying across of script.bin. Not sure what was going on there !

OK attached is the serial console output where it hangs. OPI2log.txt

I had a quick play with my OPI 2 and the image boots 1st time, then after the 2nd boot hangs. Quickly looking at the SD card shows it picked the orangepiplus.bin and didn't complete the fsresize, so I swapped that out for the orangepi2.bin, but still no boot. Did this a couple of times with different SD cards with the same result. Will look into it further today with the serial console.