Posts by Carey

Quote from Kwiboo

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:

I tried this build. HDMI is black, same as the build "LibreELEC-RK3328.arm-9.1-devel-20190416231707-c1c92b1-rock64" that I tried. I tried using SD and eMMC. Same results.

Just to reiterate. The 20181002 build still works on my board consistently. So I don't see why it can be a bad board or power supply. I am testing with 2 different power supplies, same results every test I do. I would now assume there is something different in the manufacturing of my board, as far as model/revision of chips, memory timing, etc. All I can say with certainty is that I get expected playback consistently using build 20181002 on my board. And no other builds I've tried have worked. So there is something "right" in that build that works on the version of board I have.

Quote from wkchick

As far as I could remember I also get my Power Supply from the Factory (Pine64). After all, it's almost two years and I got bad memory.

Our ROCK64 SBCs have the same date code 1748 (I presume it means year 2017 week 48), the only difference is you have 4GB RAM while I have only 2GB (I guess Carey got 2GB RAM as well). Hence it is possible that the manufacturer used RAM chip of different speeds for 4GB and 2GB variants. Or it might be the the newer kernel (4.4.156) requires more RAM to render?

If it is the power supply, then I do know how to explain why I got no issues with previous kernel 4.4.142. Anyway I will try to find another power supply to test. It won't be easy as it is not a microUSB socket.

@kostman, may I ask the brand, size and speed of your microSD card?

I have a 4GB board.

Quote from kostaman

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.

Display More

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.

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 mo123

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

Display More

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.

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?

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'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.

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.

Quote from smp

Run a few passes of memtester.

Thanks for the suggestion. Memory tests okay.

I tried another test with SD card instead of eMMC card. It's a brand new SanDisk Extreme Pro MicroSDXC UHS-I U3 A2 V30 64GB.

I wrote today's nightly image to the SD card, dated today 05-09. It boots, expands the OS to the card, reboots on it's own, and hangs at a kernel panic. I took a pic where it stops and attached the image. In case someone reading this knows if this looks like an LE OS problem or a hardware problem.

For example it says:

Kernel panic - not syncing: Fatal exception in interrupt

BUG: spinlock lockup suspected on CPU#1, systemd/1

This is first boot after install.

Quote from ArchNMy

That explains at least something, but now we need to find out why the Video FFU and the IOMMU crash. Are there any devices attached to the Rock64? What PSU are you using?

PS.: That download of 4K HEVC Big Buck Bunny takes forever ...

Attached are Logitech wireless mouse dongle, generic wireless keyboard dongle, and USB3 SSD.

I unplugged them all. Attached a corded keyboard. Rebooted. It hung on the next boot at the Kodi full screen logo. Reset. This time GUI comes up. I copy 2 videos over SSH to eMMC, one SD and one HD. I start with trying the SD video. Plays fine. First time I've had a video play on this thing. Stop and try the HD video. Unwatchable playback. Go back to the SD video. Now also unwatchable. Now neither video is watchable.

I check dmesg. I have hundreds of these:

[ 710.044979] rk_iommu ff360480.iommu: FORCE_RESET command timed out

[ 710.044996] rk-vcodec ff360000.rkvdec: Failed to attach iommu device

[ 710.045003] rk-vcodec ff360000.rkvdec: vcodec service attach failed

[ 710.079244] rk-vcodec ff360000.rkvdec: resetting...

[ 710.080587] dma-pl330 ff1f0000.dmac: Reset Channel-4 CS-20400f FTC-40000

[ 710.080757] rk-vcodec ff360000.rkvdec: reset done

[ 710.080769] rk-vcodec ff360000.rkvdec: reset done

[ 710.201615] rk_iommu ff360480.iommu: FORCE_RESET command timed out

[ 710.201632] rk-vcodec ff360000.rkvdec: Failed to attach iommu device

[ 710.201639] rk-vcodec ff360000.rkvdec: vcodec service attach failed

[ 710.235879] rk-vcodec ff360000.rkvdec: resetting...

[ 710.236156] rk-vcodec ff360000.rkvdec: reset done

[ 710.236166] rk-vcodec ff360000.rkvdec: reset done

[ 710.354932] rk_iommu ff360480.iommu: FORCE_RESET command timed out

[ 710.354949] rk-vcodec ff360000.rkvdec: Failed to attach iommu device

[ 710.354956] rk-vcodec ff360000.rkvdec: vcodec service attach failed

[ 710.389200] rk-vcodec ff360000.rkvdec: resetting...

[ 710.389485] rk-vcodec ff360000.rkvdec: reset done

[ 710.389494] rk-vcodec ff360000.rkvdec: reset done

At this point all that is plugged in is:

- LAN cable

- HDMI cable

- Audio patch cable to AV port

- Corded keyboard to USB 2.0 port

- 3A 5V power supply.

Quote from ArchNMy

eMMC should be fine as well as any memory amount that is available for Rock64 (1GB would be sufficient too). It would be worth a try playing a file from an HDD, but I doubt that eMMC is at fault here, if it is not broken.

Are there any errors/warnings in dmesg?

I am currently on a Rock64/2GB and everything except DivX/MPEG-4 content plays fine. I never tried 4K content tho.

This message repeats over and over again in dmesg:

[ 817.351570] rk_iommu ff360480.iommu: FORCE_RESET command timed out

[ 817.351587] rk-vcodec ff360000.rkvdec: Failed to attach iommu device

[ 817.351596] rk-vcodec ff360000.rkvdec: vcodec service attach failed

[ 817.385831] rk-vcodec ff360000.rkvdec: resetting...

[ 817.386107] rk-vcodec ff360000.rkvdec: reset done

[ 817.386117] rk-vcodec ff360000.rkvdec: reset done

Quote from mike2002

That's really weird. Just some little setings to check :

- Set GUI Resolution to 1920x1080p (system->Display) (personally I set it at 1280x720p)

- Set refresh rate to 60 Hz (System->Display)

- Whitelist all supported resolutions (System->Display) In particular do not select all resolution with 4096

- Adjust display refresh rate On start/stop (Players->Videos)

I did as suggested above, and attempted to play from a USB 3 SSD, and I have the same playback problems of one frame every few seconds, audio okay. Even SD content doesn't play smoothly.

Quote from mike2002

Hi Carey !

I try both video on my Rock64 and they play flawlessly.

I have a Rock64 with 4GB ram. I run Librelec nightly-20190501 build from a micro SD card (samsunbg EVO 32 GB). All my playback are done via my NAS with SMB protocol.

Just by curiosity, and I do not think it's related to your problem, how many ram do you have on your Rock64 ? And do you try to run the video via a HDD plug into your USB ?

Hi mike2002,

My Rock64 has 4GB RAM as well. I haven't tried a USB HD. I've only tried playing video from the local eMMC, the local SD card when I tried using the SD card instead of eMMC, and from the Kodi SMB shares.

I'm giving it another try...

I downloaded the nightly from today:

LibreELEC-RK3328.arm-9.1-nightly-20190509-1816bad-rock64.img

I used the Ameridroid USB2.0 eMMC writer to write the image to the 16GM eMMC 5.1 module I purchased for this board from Ameridroid. I used Win32DiskImager. Verified after writing. Put the eMMC into the Rock64. Powered up for first boot. No kernel panic this time. GUI opens. I do the setup and turn on SSH. I copy sample videos to the eMMC, to test playback locally. Big Buck Bunny and Tears of Steel. I make no other changes at all to settings. I try to play the videos I copied over, and I get the same unwatchable playback of less than a frame per second.

When I press X to stop playback, the GUI locks up, SSH is dead.

After reboot this is the last few lines of the log file:

2019-05-09 16:54:05.055 T:4086419472 NOTICE: Whitelist search for: width: 4096, height: 1714, fps: 24.000, 3D: false

2019-05-09 16:54:05.067 T:4086419472 NOTICE: Display resolution ADJUST : 1680x1050 @ 60.000000 Hz (16) (weighx: 0.037)

2019-05-09 16:54:12.137 T:3603391360 WARNING: CRenderManager::WaitForBuffer - timeout waiting for buffer

NUL NUL NUL NUL NUL....a few hundred repeated NUL characters till the end of the log file.

I try the same again using a different monitor, a monitor I use daily with LE9 on a Tanix TX5 with an S905X. Same results, unwatchable playback, GUI crash at stop video playback.

If anyone can comment on what I might be missing, please let me know.

P.S. I had trouble posting this message cause the word "weigh t" without a space is censored, and it shows in the Kodi log. Why is "weigh t" a censored word?

Quote from ukmark62

That's weird. I have a cheap MX10 Android RK3328 TV box and I have zero problems on all playback with HW decoding on. In fact, playback on this box is better than any of my S905* amlogic boxes - it's faultless. 99% of my media is HEVC. I have no issues with 4K HDR playback with HW decoding on. This is using the latest nightlies (I might not be up to date but it's a fairly recent one). The only small issue for me is the built-in wifi does not work, but I have a USB wifi adapter that does.

Is this a clean install? Have you any "advancedsettings.xml" file in your kodi "userdata" folder, or anything in the ".config" folder such as an "autostart.sh" that may be messing things up??

Could it be a faulty board?

Thanks for the reply.

Yes, it's a clean new install. New board. My first board from Ameridroid didn't start up, so sent it back, ordered a new one. Second one powers up fine. It would seem unlikely that I'd get 2 bad boards in a row, with different issues, unless other people that have bought the Rock64 also have histories of having faulty boards.

No config other than changing audio to the A/V port, my SMB shares, and turning off GUI sounds.

No advancedsettings.xml. No autostart.sh in config dir.

Just a Logitech wireless mouse USB dongle, and generic wireless keyboard dongle in USB ports.

Often after booting to the point of getting the LibreELEC logo, there are kernel panic error messages, memory dumps to screen, then just hangs.

"kodi_crash.log" is created and is empty.

In the Kodi log the only things that stand out are:

2019-05-09 01:31:57.691 T:4091109392 ERROR: DBus error: org.freedesktop.DBus.Error.ServiceUnknown - The name org.freedesktop.UPower was not provided by any .service files

2019-05-09 01:31:58.935 T:4069520256 WARNING: Pulseaudio module module-allow-passthrough not loaded - opening PT devices might fail

Hello,

I recently purchased a Rock64 SBC. I know that LE is still in alpha for this board, but I thought I had been reading in the forums that people were having reasonable luck with playback and usage. But I'm not. The video playback I get on almost all videos I try, isn't even stuttering, it's still frames that change at seeming random intervals, sometimes every few seconds to maybe 15 or 20 seconds. During this audio plays fine. I also sometimes get kernel panics on boot. It sometimes takes 3 resets to get the GUI to come up. And the GUI will freeze/crash on occasion.

I've had the same results with the current nightly:

LibreELEC-RK3328.arm-9.1-nightly-20190507-4df8ad4-rock64

The 2 nightlies before that. And the 8.9.x version also won't play video any better.

I've tried using both eMMC and a fast SD card. Same results. If I turn the HW decoder off, it will play non HEVC video reasonably well with the CPU's maxed. But with the HW decoder on, no luck. I've assumed that the comments on the Rock64 decent playback was with HW decoder on, or are people only using this board with LE with HW decoding turned off for now?

If this is the state of the current builds for Rock64, that's perfectly fine, I realize it's a WIP. Unless I'm mistaken, I thought I read that other people are getting decent playback on the board even with HEVC content. And if so, I'm not sure what I'm doing wrong.

I'd appreciate whatever clarification I can get, on what I should be able to expect working on the Rock64 build right now.

Thanks very much.