• Content Count

  • Joined

  • Last visited

About Mathias

  • Rank

Profile Information

  • Gender
  • Location
  • Interests
    Debian on RockPro64

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi! On my RockPro64, I usually run Armbian with Ayufan's 5.1 kernel (it runs very well and after manually compiling the dtb file most of the error messages at startup are gone). I've tried a few days ago to run Armbian's dev kernel (5.0), and both the sdcard and my usb3 attached ssd could not be detected. The network was also missing. I have pasted the output of armbianmonitor -U here. Mathias
  2. I finally managed to understand why neither pine64 nor Ayufan could reproduce this bug: this has to do with usb autosuspend. On a freshly booted system, USB3 works perfectly fine. On a system that has been idle for a day (so the USB had time to suspend), the problem is back with tons of error messages as soon as I try to copy a few hundred Mb. This was also mentioned in this thread. [edit] The autosuspend is not the culprit... This has to do with some underpower, see this (long) thread. Sorry for the fake news and the disappointment!
  3. Replying even later... This definitely has to do with USB suspend (see this link): on a freshly booted system, no problems at all. On a system that has been running for a day (ie the USB had enough time to suspend), the problem is back with tons of error messages... [edit] The autosuspend is not the culprit... This has to do with some underpower, see this (long) thread. Sorry for the fake news and the disappointment!
  4. Jumping in a little late, but on the RockPro64 (also Rk3399), the same kind of problems happen (also very easily reproducible, it happens every single time under load). See my post on Pine64's forums. I am in contact with them (well, so far they just keep bouncing me around to another forum / email / person...) to try learning from them if they ever managed to get some sort of usb3 working on this board. Other people are also wondering if the hardware is the root cause of these issues...
  5. I'm sorry to jump into this thread, but I was wondering if there is any way to get a changelog for the kernels released by Armbian... I've just got an updated kernel to my RockPro64 (through apt dist-upgrade), but before I run some tests, I would like to have a look into the full changelog and I could not find a way to get one.
  6. I have replaced the cable by another one (freshly purchased and tested on my laptop), I still have the same problems. I've not been able to capture the backtrace this time, but at least I have some kernel messages showing how the kernel is fighting to make it work: some messages early on and then more later on (it fully crashed a few minutes later). Again, this is with kernel 4.4.174 and a JMS578 (patched firmware) based enclosure...
  7. @IgorThanks! Now I need to deliver... :-) @chweNo, I'm using a "noname" enclosure that is based around the JMS578. But again, it just works great when connected to my laptop (with Debian Buster) and always makes trouble on the RockPro. I wanted to make sure this is not a problem with power, so I used a 6A power supply (universal power supply designed for laptops) and got the same trouble. But I'll try again with this power supply and the "stable" 4.4 kernel and either come back with a big smile on my face or with a backtrace...
  8. @chweI've used the enclosure (based on JMicron JMS 578 chip) on my laptop to transfer almost 400G of data without any problems twice (with UAS mode, thanks to an updated firmware ) but as soon as it is connected to my RockPro, I can not transfer/read more than a few Gb (ie the nightly rsync of my hosted Nextcloud to my backup system was enough to trigger the bug). I've tried disabling uas (blacklisting it and checking that it was really used as "mass storage") but this was not enough to make it stable. So far, I've reverted to moving my Nextcloud to an sdcard (so the rsync does not find anything on the USB3 drive that needs syncing). If you want, I can provide a backtrace (I ssh to it and start copying data around, so when it goes down, I still have the backtrace in my ssh terminal). @IgorI would love to step in as board "maintainer" but so far, I don't have enough days as registered member... (and I can not promise to test all new stuff regularly, since I also use my board as a server, so I can not always afford to bring it down at any given time). In the mean time, I can start a thread in the forums to collect some links and information about the board.
  9. @anonymoustemp for me, no matter which kernel I use, USB3 is not stable. With Armbian's 4.4.173, I end up with kernel NULL pointer when performing "heavy" I/O on USB3 (here "heavy" means reading or writing a few Gb of data). With Ayufan's builts (4.20 or 5.0 kernels), I end up with filesystem corruption (and the system must be restarted because it is so messed up). @IgorThanks a lot for your explanations! I was actually wondering if I could offer to write some RockPro64 documentation somewhere in the wiki, Bu I am not sure where it would fit best. Would creating a RockPro64 "hardware notes" section be acceptable to the Armbian community? Thanks anyway for the good work! Mathias
  10. Mathias


  11. Thanks all for your help! So, to keep for the record: 0) before you play around with a new kernel, make sure you have a backup of /boot (I keep such a backup as /boot_bak directly on the system). Worst case, flash a new image on a usb stick and grab its /boot 1) in order to rescue a system where a new kernel does not boot: * in /boot, there are 3 symbolic links that must point to the right place: dtb, Image and uInitrd. The last two must point to the same version. For example, dtb -> dtb-4.4.174-rockchip64, Image -> vmlinuz-4.4.174-rockchip64, uInitrd -> uInitrd-4.4.174-rockchip64 (I could not find any version other than 4.4.174 for the dtb, so I've always kept the link pointing to it); * of course, you still need config-4.4.174-rockchip64, and your kernel, for example vmlinuz-4.4.174-rockchip64 * you can keep several kernel version, just adjust the three symlinks mentioned above to point to the version you want to use for your next boot; * All these steps can obviously be done by mounting your sdcard or emmc on your computer. 2) Then boot/reboot your system * keep in mind that the rockpro64 is very unreliable when it's about starting... if the system does not boot, check if the ethernet leds came up or not, if the power led came up or not, etc Mine often does not even get the power led turning on! So try several time to press the power and/or reset buttons, plugin in/unplugging before you give up; * some kernels do not support hdmi output yet (actually, most of them beside the Rockship original patches). So don't despair if nothing comes on the screen... If you've added a dptx.bin firmware, it can be that the board does not boot if no screen is connected... So far, I could not boot with the Armbian 4.20.0 kernels but everything works fine with the Ayufan kernels installed on Armbian (both 4.19 and 5.0 ). In this case, just copy the deb package from Ayufan that you want and install it with dpkg (dpkg -i {package name}). You will have to redo one of the mentioned symlinks, but other than that, everything works. Mathias
  12. Thanks! And this also means, that if I check and fix the symlinks in /boot just after upgrading the kernel to 4.20.0 with amrbian-config (ie making sure /boot/dtb points to /boot/dtb-4.20.0-rockchip64), I should be able to boot with kernel 4.20.0?!
  13. Thanks a lot for your posts! I actually had the same problem and ended up re-flashing my emmc... Now that my whole system is configured, I obviously don't want to overwrite it with a fresh new image. So, this means that if I backup /boot, I can play around with any BETA kernel and if my board gets bricked, I can just overwrite /boot with my backup to be able to boot again, right? (ie no need to run a special command like grub-update or similar for arm) If somebody could confirm, that would be great! Mathias