New Rock64 User Problems

    Quote from geno

    I use the Pine64 installer and the images work for me on the SD and on the emmc card. maybe you are testing the pine64 installer or etcher as recommended by pine64.

    Thanks for the suggestion. I get the same results. I can use the pine installer and run Ubuntu and it is real laggy, but runs, no kernel panics. I use pine installer to write LE and I get the same boot kernel panics and poor video playback.

    I'm wondering if someone can point me to a known working version of LE for the Rock64 board? I've tried the last few nightly builds and they don't play back with HW decoding on my board. The 8.9.x version doesn't playback with HW decoding working on my board. SW decoding does work.

    The reason I'm asking is because I honestly don't know if I have a bad board or not. I can get some versions of linux I download and install to work, and some have kernel panics. Same with Android. Every version of LE I've tried has kernel panics on random boots, and HW decoding doesn't work. But once it did play back with HW decoding, maybe twice.

    I've spent many many hours now experimenting, trial and error, and searching forums online. I'm not the only person having the same error messages and kernel panics with this rockchip. Currently it appears to me to be a simply a bad purchase of a problematic board and/or chipset.

    But if at some point, someone reading this can point me at a build of LE that they are currently using, and know to be working on their own Rock64 board, I'd love to try and see if it will run on mine. And if someone knows if it is possible to find older nightlies online, or if they are deleted each time a new one is posted, that would be great. As I have read that some people do have older nightlies working on their board. But I don;t know where to find pervious nightlies...if they still exist.

    Until then I'm writing the Rock64 off as a waste of time. This is the second board I've bought. But don't get me wrong, I appreciate the LE rockchip devs work a great deal. This is in no way a complaint against the project. I suppose this is just a review of my own experience with Rock64. I don't recommend it to anyone. Stay with Intel and Amlogic.

    Thanks to everyone that has offered help and advice.

    Do the crashes mainly happen during hw decoding? I am wondering if it is related to dynamic changing of memory clock speed and voltage.

    What board revision do you have? (Has Rock64 rev3 started shipping?)

    Please try an early mainline image at Index of /test/ and see if it is more stable, it only have mpeg2 hw decoding and other limitations.

    (Plan to push updated linux v5.1 images for wider public testing sometime later this weekend)

    Carey It must be because you have a different revised board.

    Most Rock64 users have the non revised or rev1 boards that they bought one or two years ago.

    The kernel dts file might not contain the correct settings for the latest rev2 or 3 boards I think.

    It can hopefully be fixed with the correct kernel changes later on.

    Pine64 should have made one board with everything improved from user feedback before the device was released since all these revised boards become a nightmare later on to all support correctly.

    Maybe something also causing problems with rev3 boards and micro-sd cards.

    Wonder how it passed quality control?

    Rock64 v3 and SD-Cards

    Edited once, last by mo123 (May 11, 2019 at 10:43 AM).

    Carey, I share your feeling on ROCK64, only I've never experienced kernel panic. I bought my ROCK64 SBC in 2017. FYI, the board marked ROCK64 2,0 2017-0713 with date code 1704. There is no eMMC and I used only 16GB microSD card. I got the same 5V3A AC adapter as you did, together with the remote control from PINE64.

    I experienced with kernel 4.4.156, heavy stuttering during playback of 720p and 1080p HEVC (8-bit or 10-bit) video files. Every 10 or 15 seconds, the video freezes for a few seconds and then playing catch up. Then the same thing repeats itself again while audio is fine. The last good (or less problematic) kernel was the one released on 2018/10/02.

    Would it be the hardware problem? AC adapter (voltage unstable)? Processor temperature too high due to heat sink too small? I don't think so. In fact before LibreELEC official release, I was testing Raybuntu's ROCK64 build and that was good at least for video playback. After I read your post, I pull the image file out and test it once again on the same hardware and playback was smooth, no stuttering or audio out of sync at all for the whole movie. Color is also very good.

    I still keep the image file of the last build by Raybuntu LibreELEC-rock64.arm-rb-leia24.img.gz but only the tar file (for update) of 2018-10-02 LibreELEC-RK3328.arm-9.0-nightly-20181002-8b3e678-rock64.tar, you can download from here and test them on you SBC if you like.

    I also tested the image that Kwiboo suggested with kernel 4.9 or 5.0, If I turned on HW acceleration, video was not playing at all but audio was fine. If I turned off HW acceleration, video was playing significantly behind the audio but no stuttering. All tests were done with the same video 10bit HEVC 1080p video file on the same SBC hardware.

    Quote from wkchick

    Carey, I share your feeling on ROCK64, only I've never experienced kernel panic. I bought my ROCK64 SBC in 2017. FYI, the board marked ROCK64 2,0 2017-0713 with date code 1704. There is no eMMC and I used only 16GB microSD card. I got the same 5V3A AC adapter as you did, together with the remote control from PINE64.

    I experienced with kernel 4.4.156, heavy stuttering during playback of 720p and 1080p HEVC (8-bit or 10-bit) video files. Every 10 or 15 seconds, the video freezes for a few seconds and then playing catch up. Then the same thing repeats itself again while audio is fine. The last good (or less problematic) kernel was the one released on 2018/10/02.

    Would it be the hardware problem? AC adapter (voltage unstable)? Processor temperature too high due to heat sink too small? I don't think so. In fact before LibreELEC official release, I was testing Raybuntu's ROCK64 build and that was good at least for video playback. After I read your post, I pull the image file out and test it once again on the same hardware and playback was smooth, no stuttering or audio out of sync at all for the whole movie. Color is also very good.

    I still keep the image file of the last build by Raybuntu LibreELEC-rock64.arm-rb-leia24.img.gz but only the tar file (for update) of 2018-10-02 LibreELEC-RK3328.arm-9.0-nightly-20181002-8b3e678-rock64.tar, you can download from here and test them on you SBC if you like.

    I also tested the image that Kwiboo suggested with kernel 4.9 or 5.0, If I turned on HW acceleration, video was not playing at all but audio was fine. If I turned off HW acceleration, video was playing significantly behind the audio but no stuttering. All tests were done with the same video 10bit HEVC 1080p video file on the same SBC hardware.

    wkchick

    Thank you for the reply.

    My board is marked: ROCK64-V2.0 2017-1713

    If the board has a separate date code, I didn't see it. Maybe it's under the heat sink now.

    I'm not using the power adapter sold by Ameridroid. I purchased a 5V3A unit new from Amazon. I've also tried another 5V4A PS that I purchased surplus, same results, which I've used on other SBC's without an issue.

    I'm using the heat sink that Ameridroid sells for this board. The temp shown using the heat sink in LE hardware screen is around 60C. Below the 80C that I've read that people say the board shuts down or throttles at.

    Thanks very much for making the downloads available. I did DL them. Dumb question....how do I make use of the tar files to create an img file to write to the SD or eMMC cards?

    I believe we have the same ROCK64, as least the circuit board is the same. The heat sink I have can only cover only the RK3288 processor. It's about 13 x 18mm in size. My Odroid-C2 is equipped with a much bigger heat sink. Heat sink on Rock Pi 4 is also bigger.

    You need to prepare the SD card with an image file, either the rb image or any one downloaded from LibreELEC website. I would suggest you prepare the SD card with this LibreELEC-rock64.arm-rb-leia24.img.gz first. If it works (or there's no more kernel panic), then update using the tar file. I personally did this process once today.

    BTW, the linux kernel of recent testing image released after 2018/10/02 is 4.4.154 whereas the kernel before that is 4.4.142. For me, there is no stuttering at all for the two LibreELEC builds I uploaded. If anyone could prepare a build with Kodi 18.2 (LibreELEC 9.0.2) with kernel 4.4.142, that would be fantastic!

    Quote from wkchick

    I believe we have the same ROCK64, as least the circuit board is the same. The heat sink I have can only cover only the RK3288 processor. It's about 13 x 18mm in size. My Odroid-C2 is equipped with a much bigger heat sink. Heat sink on Rock Pi 4 is also bigger.

    You need to prepare the SD card with an image file, either the rb image or any one downloaded from LibreELEC website. I would suggest you prepare the SD card with this LibreELEC-rock64.arm-rb-leia24.img.gz first. If it works (or there's no more kernel panic), then update using the tar file. I personally did this process once today.

    BTW, the linux kernel of recent testing image released after 2018/10/02 is 4.4.154 whereas the kernel before that is 4.4.142. For me, there is no stuttering at all for the two LibreELEC builds I uploaded. If anyone could prepare a build with Kodi 18.2 (LibreELEC 9.0.2) with kernel 4.4.142, that would be fantastic!

    Okay, I finally have made headway with the thing! Only possible with your help wkchick

    I created a install image on SD using the ROCK64 nightly dated 20190510.

    I manually copied the KERNEL, SYSTEM and dtb files from the nightly image dated 20181002 kindly provided by whchick.

    The LE image installed, then rebooted as expected. After first boot I had no trouble playing my same test videos I've been using, SD, HD, HEVC 1080p, 4K BBB, 4K Tears of Steel, all played flawlessly.

    But when I stopped playback of one of the versions of BBB, the board locked up upon returning to the GUI. I hit reset, the next boot had kernel panic. Reset again, it booted fine, test played all the same videos, played back perfectly again, including my HEVC and 4K samples using HW decoding.

    It would now appear there is nothing wrong with my ROCK64 board, as this is a giant improvement over the current builds. Even ignoring my comments about the lockup and kernel panic, the fact that an old build plays video as expected, but current builds do not. Are the current builds being tested on some old revision board and not the current board that is being sold? Should the builds be posted with what board revision they are being tested on perhaps?

    mo123 I really appreciate your feedback.

    So to be clear, are you saying that you think just the dtb file needs to be revised on the current builds for the ROCK64 V2.0 boards? And not the older kernel and system files as well?

    Thanks for helping me understand.

    I thought you used the usual update method (copy the tar file to the update directory using Samba and then reboot) to roll back from any current version to that one dated 2018/10/02. Anyway, it doesn't matter as long as it works! I sometimes use your approach (copy KERNEL, SYSTEM and dtb files to the FAT partition of microSD card) to update as well.

    I also experienced occasionally hang up of the SBC before with the build on 2018/10/02, I think you can rule out you got a defective ROCK64.

    Quote from Kwiboo

    Do the crashes mainly happen during hw decoding? I am wondering if it is related to dynamic changing of memory clock speed and voltage.

    What board revision do you have? (Has Rock64 rev3 started shipping?)

    Please try an early mainline image at Index of /test/ and see if it is more stable, it only have mpeg2 hw decoding and other limitations.

    (Plan to push updated linux v5.1 images for wider public testing sometime later this weekend)

    Kwiboo

    Hi Kwiboo,

    I have the V2.0 2017-1713 rev board.

    I did manage to get a playable install using the suggestion from wkchick that I posted earlier, by creating a boot image using files from the 20181002 nightly. So I do have a functioning board, but it appears that the current nightly builds aren't compatible with the v2.0 board.

    I tried the build to referred me to:

    LibreELEC-RK3328.arm-9.1-devel-20190416231707-c1c92b1-rock64

    And the I get nothing from HDMI, no boot text scrolling by, no boot up logo, no eventual GUI. Monitor stays black.

    Quote from Carey

    mo123 I really appreciate your feedback.

    So to be clear, are you saying that you think just the dtb file needs to be revised on the current builds for the ROCK64 V2.0 boards? And not the older kernel and system files as well?

    Thanks for helping me understand.

    I played around with different combinations of dtb and build images before and found not much differences. I believe the main issue is due to the newer linux kernel 4.4.154. One way to prove is to get LibreELEC 9.0.2 with kernel 4.4.142 and test. I understand that they are working on kernel 4.20, that why I had never reported this before.

    No issues comparable with any of the above with my Rock64 .

    I am using the Factory Power Supply.

    LE Via SD Card. 4gb Ram.

    Rock64 HDMI straight into TV.

    One USB stick and one USB receiver for remote inserted.

    See my Board. Just to compare.

    Edited once, last by kostaman (May 12, 2019 at 7:10 AM).

    Comparing the silk screened text on your board and mine are the same other than the code 1748 on your board. In that spot my board has 1752.

    Carey I would immediately point Ameridroid to this forum on your issues. They're probably going to say it's a Power supply. I don't know. If it's possible to send it back for testing. Could be bad Memory / Flash . Damn electronics. Bad batch in their stock they should know about it. Sorry i can't help further. At least the board looks identical to mine. Except that one number.

    I think the issue is with the different memory modules used, my Rock64 boards is from one of the batches when the board was rather new and when 1866mhz memory modules was used even if the board spec was 1600mhz.

    The old images did not have dfi/dmc ddr devfreq enabled in device tree and possible explains why you have a more stable board with the old image and problems with newer images.

    The linux v5.0 image I linked to possible had the 933mhz ddr init code and that would explain why it does not work on your board, I have uploaded a linux v5.1 image with the 786mhz ddr init code: libreelec-rk3328.arm-9.1-devel-20190512071134-2f3393e-rock64.img.gz

    One of my Rock64 boards: