ketominer

Members
  • Content Count

    13
  • Joined

  • Last visited

  1. Try going with the 4.4.180, it's the one that gives me the best results (although not on 100% of the boards)
  2. yup. Armbian_5.75_Rock64_Ubuntu_bionic_default_4.4.174.7z
  3. Actually even the stable armbian is way better, it now has dmc and the ram is clocked at 768*2! Just double checked with a few fresh installs + upgrade
  4. Just switched to the latest nightly... seems to fix things a lot
  5. OK after a long and painful investigation with pine64 and other people doing distributions for them + members of the community, the problem is that by default the memory runs "full" speed which is way above specs, as it should be running at 800 MHz max. We need the dmc driver and being able to setup the max clock for the memory to run these boards in good conditions.
  6. and when browsing the differences between the kernels, I come up with this which looks pretty promising... https://github.com/ayufan-rock64/linux-kernel/commit/063c10147b3cfc326adda195f004b130dbd11ff6 -- scrap that, it's for the 3399 so not related
  7. OK definitely not u-boot related as rc9 and rc10 has the exact same one. So the answer is somewhere in the kernel... digging deeper.
  8. no luck. I'm starting to wonder if this is all not about something someone mentioned earlier, being that it's the u-boot settings slowing down the RAM that fix the problem... https://transfer.nodl.it/4bgnD/armbianmonitor.txt
  9. Info from "bad" kernel (freshly updated armbian bionic but it's the same for 6 months): https://transfer.nodl.it/fJ3wP/armbianmonitor.bad.txt (used my own transfer side because the one used by default by armbianmonitor -u doesn't show any url after upload) Info from "good" distro (that works on the "bad" boards is): http://ix.io/1HKS (somehow worked on this one) Distribution used is bionic-minimal-rock64-0.8.0rc9-1120-arm64.img.xz from https://github.com/ayufan-rock64/linux-build/releases The kernel is linux-headers-4.4.167-1169-rockchip-ayufan-g3cde5c624c9c:arm64 install linux-image-4.4.167-1169-rockchip-ayufan-g3cde5c624c9c:arm64 install u-boot-rockchip-rock64-2017.09-rockchip-ayufan-1045-g9922d32c04 install and board package board-package-rock64-0.8-126 install This leads to the correct dependencies: https://github.com/ayufan-rock64/linux-build/releases/download/0.8.0rc9/linux-rock64-0.8.0rc9_arm64.deb please note that the rc10 of ayufan's distro breaks again what rc9 was fixing... Hope that helps
  10. no luck so far, I've updated previous post (maybe not a good thing to do)
  11. Probably, I've even got a kernel package from him that "should" work on armbian but I've broken everything trying to install it...
  12. Thank you for your answer, will test the beta very quick and let you know how it goes. I will have to figure out how to safely push that to our users without breaking everything update: switching to nightly, kernel panic as soon as I run my test program (simple argon2i hashing test + stress-ng running in the background, it tends to be easier to trigger under load on some boards) (also subcription done, hopefully moving to the biggest one when we can). Let me know if you want the full test protocol along with some boards.
  13. Hi, We are using hundreds of Rock64 boards for a project and we are facing a lot of unreliabilities due to the kernel Armbian is currently using. After long discussions with Lukasz, Kamil, and Pine64 support, we concluded that some kernel fixes are necessary to have a reliable operation. These fixes are available for example in Ayufan's rc9 bionic distribution and all the boards that fail with armbian (it goes from kernel crash at boot to just some subtle miscalculations during some FPU operations) work perfectly well with his kernel. We are ready to support Armbian by providing v2 and v3 Rock64 4GB boards as well as a monetary support to get a kernel update as quick as possible to "un-brick" the 50-60 boards we currently can't use (and to avoid having to switch to another distribution). Please let us now if you're interested and how we could arrange that.