• Content Count

  • Joined

  • Last visited

About Set3

  • Rank
    Advanced Member

Recent Profile Visitors

690 profile views
  1. Hi martinayotte On var/log and var/log/.hdd : Done that, every hour, it works, obviously :-) . also using sed to remove the "IR event FIFO is full" lines But now, for a while or perhaps since then, my warning system, based on what df under /var/log reports gives false warnings : df misreports the real size eg : in WinSCP, the calculate button says 2.2MB, where df says 75% of 50MB Perhaps the varlog scripts are not happy with the delete/modify ? Reboot repairs the mismatch Edit : Moved to using du iso df, du is reporting correctly. so that is solved, but perhaps a point of attention for the developers ?
  2. I guess you are right, at least for what I tried with Rock64 and Armbian I have USB3.0 problems mentioned elsewhere on this forum and on I used tips above for an el cheapo USB3.0 JMS597 SATA adapter cable 0x152d:0x0578 In Armbian 5.59 I had read/write speed around 80MBps ish using samba (varying between 109 and 70) But with read, after a few seconds full speed, it froze for 10-15 sec, no errors in the transferred data, but with "ERROR Transfer event for disabled endpoint or incorrect stream ring" in dmesg every time it froze. With above tips I don't have freezes anymore, and using samba as server and W10 client, write speed still 80MBps ish, but read speed down to 50MBps. And as you predicted, I have now another error : "reset SuperSpeed USB device number 3 using xhci-hcd" But not in red :-) and without any noticeable delay. Hopefully the USB "ERROR Transfer event for disabled endpoint or incorrect stream ring" gets solved soon. Ill do some more testing on Pine and Armbian. Also always interested if you have better fixes.
  3. Hi guys, Using the Pine images from ayufan for a while, I still longed back to Armbian, so all SBCs look and feel the same :-) Not that the Pine images are bad, just a bit different. The latest Ubuntu (non desktop) image 5.59 now work also on Rock-64 1GB, thanks ! Reboot is also ok. It is only confusing that the HDMI does not show anything, so initially I missed that they work, but SSH works, and that is all I need anyway. Issue closed
  4. Ok, although I did see strange results earlier today, I now can say that the patch works, tested about 10 times from scratch so I can login, update/upgrade/install some stuff I see error messages in the boot : ** File not found /boot/dtb/rockchip/overlay/-fixup.scr ** and Starting kernel ... ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) Loading, please wait... starting version 229 and [ OK ] Started User Manager for UID 0. [FAILED] Failed to start Network Manager Wait Online. See 'systemctl status NetworkManager-wait-online.service' for details. [ OK ] Reached target Network is Online. Is that "normal" ? But reboot does not always work, hangs on one sbc, succeeds on another sbc, both show like : Starting kernel ... ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) Loading, please wait... starting version 229 [ 2.080920] Internal error: Oops: 96000004 [#1] SMP [ 2.081455] Modules linked in: [ 2.081810] CPU: 3 PID: 212 Comm: udevadm Not tainted 4.4.124-rk3328 #24 [ 2.082522] Hardware name: Pine64 Rock64 (DT) [ 2.082989] task: ffffffc037833600 task.stack: ffffffc027510000 [ 2.083627] PC is at __rmqueue.isra.7+0x84/0x3f4 [ 2.084120] LR is at get_page_from_freelist+0x20c/0x774 [ 2.084674] pc : [<ffffff800819550c>] lr : [<ffffff8008195a88>] pstate: 20000 1c5 [ 2.085447] sp : ffffffc027513a30 [ 2.085802] x29: ffffffc027513a30 x28: 0000000000000001 [ 2.086391] x27: 0000000000000010 x26: ffffffc03ff95d98 [ 2.086978] x25: 0000004036e79000 x24: ffffffc03ff95d88 [ 2.087565] x23: 0000000000000001 x22: 0000000000000001 [ 2.088153] x21: 0000000000000000 x20: ffffff800928a380 [ 2.0 etc etc
  5. Ok, Yes 2 images (bionic/xenial)boot now with serial connected, I can login,change root password dhcp/ssh works Edit 1 ( now only using dhcp/SSH, serial disconnected) Bionic looks ok, did an update/upgrade/ installed a few packages : all ok. but HDMI : no sync, no output, no boot log and no prompt ( is that normal for bionic=development ? ) But shutdown -h now leaves red/white LEDs on, strange Also power usage does not go down, remains on 1.5W serial: Edit 2 ( now only using dhcp/SSH, serial disconnected) Xenial looks ok, did an update/upgrade/ installed a few packages : all ok. HDMI does not show a boot log, but does show Ubuntu....Login, usb keyboard login works shutdown red/white LEDs off, Also power usage drops to 0.03W Looking good man ! Good work ! Edit 3 : Hmm, we are not there yet, Xenial boot / reboot is unreliable. Once it boots it looks good, but only half-ish of the boots succeeds I need to do more testing,
  6. So only 1 step to go then ? 1 : repair the boot script and get it into all Rock64 Armbian images Who can do that ?
  7. Yep, 4.4.124 not stuck indeed, ls does work. It is just not what I expected :-) Edit : same with dev_4.17.0-rc6 4.4.124 not stuck, ls command works
  8. Armbian_5.46.180611_Rock64_Ubuntu_bionic_dev_4.17.0-rc6.img also starts a boot, but is stuck even sooner
  9. Ok, next steps ? 1 : repair the boot script and get it into the Rock64 Armbian images 2: Why does it get stuck after it boots ? I will try it on the other image too.
  10. No problem guys, ok, I see a lot on the serial and hdmi screen, but I think is is stuck HDMI vendor storage : 20160801 ret = 1 Edit : get the whole start log in the spoiler
  11. Yes, I know I did not test yet as I guessed (All new to me :-) that I needed more time than I had yesterday late, still wanted to share my thoughts about timing. Ok, today I tested Below the results, but basically there is no "boot/zImage", so what am I doing wrong ? tried boot/Image, same thing
  12. Just thinking out loud : Could it be memory timing as mentioned earlier in this thread by boobypi ? Perhaps the Rock64 1GB have/need different timing than 2/4 GB ? My memory chip has the marking PB047-125PT Looks like this is the manufacturer chip code PB047 = 8GBit = SS256M32V01MD1LPF LPDDR3 somewhere else on that site, I found that code -125 stands for PC3-12800/DDR3 1600 11-11-11 What chips are on the 2G/4G ?
  13. Well we ( 1GB Rock64 owners ) only have problems with the Armbian images for Rock64, and not with the Pine64/Rock64 Bionic image, so despite how much we love Armbian, I can't imagine that the problem is not in the Armbian image. I see that it starts U-Boot 2018.01-rc2-armbian (May 14 2018 - 20:13:51 +0200), so that is Armbian right ? My guess is that the during boot, memory locations between 1GB and 2GB are used that are not there ? No idea where how to check / solve, as I am no expert in that, but I can make some time for that, as I am willing to learn, so anyone have a clue where to start ?
  14. Hi Santopol1 and Osiris, thanks for confirming, so I am not the only one, as one start doubting when being the only one. Osiris, for the support guys interesting I guess : Your answer could, perhaps, possibly suggest, not exclude, that you had Armbian on Rock64 1GB work with older images ? If so, around what date / version did it stop working ?
  15. Hi Igor, It was late yesterday, so just to be sure I was not dreaming, I did a restart : I use Rock64 to replace Orange Pi 2E Plus as headless server with Docker as a platform for multiple applications, and looking at memory usage before, I saw no need for more than 1GB to be honest. I use 5V2A and 5V3A supply, a few Samsung 16GB Evo+, etcher, that work fine with OrangePi I have 2 Rock64 1GB, and used the current images from None of these 3 work on either of the 2 sbc-s : 1. Armbian_5.42_Rock64_Debian_stretch_default_4.4.124_desktop 2. Armbian_5.42_Rock64_Ubuntu_xenial_default_4.4.124.img 3. Armbian_5.44.180515_Rock64_Ubuntu_bionic_dev_4.17.0-rc3.img After testing with Armbian, I used the Pine64 bionic-minimal-rock64-0.6.44-239-armhf.img on the same SD card, sbc, supply, and that boots and seems to work fine on HDMI and ssh. Let me know if you need more info / testing. Results : So I see "Found U-Boot script /boot/boot.scr" but before that there are also errors/warnings, but I am not sure if that is supposed to be like that. I think the output is the same, but for completeness : 1. 2. 3.