jpearn

Members
  • Content Count

    18
  • Joined

  • Last visited

About jpearn

  • Rank
    Member

Recent Profile Visitors

728 profile views
  1. This works well for me, thanks ! The rest of Bionic on Cubox-i is much more stable now :)
  2. Still getting the error, is it safe to remove armbian-tools-xenial for now or is it needed ?
  3. 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 sp
  4. 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?
  5. 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 !
  6. 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 !
  7. 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 Li
  8. 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 4
  9. 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
  10. 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
  11. 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.
  12. 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
  13. 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 !
  14. OK attached is the serial console output where it hangs. OPI2log.txt
  15. 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.