knaerzche - Could you enable NVMe support in the linux kernel? I already did the change locally (for the HEAD in LibreELEC) and it works fine (RockPro64), but I don't know about github pull request and how to get the change online I just copied the NVMe section from the armbian config over to the latest in LibreELEC.
I just tried your latest image on the RockPro64. Startup works, and my SSD over NVMe / PCIe is also detected. One question, should x265 10bit video playback be working? I saw a confirmation from xmixahlx in the armbian forum, but I don't know if you applied the mentioned patch to your build or if he uses a completly different build scripts.
Example video, which doesn't work:
Thanks for your time you invest in the project.
Try using these DTB options.
I used the rk3399-rockpro64.dtb and it works.
One question, what is the source of your build? Is it a nightly from the LibreElec Github or what it "underneath"?
Short info about HEVC: Videos with HW acceleration are not shown (only sound) and without HW acceralation the playback is not smooth.
H.264 videos work without problem.
I think the community is still working on the HEVC support for the Hantro drivers in the 5.x kernels. I saw some posts in the more recent kernels, but I don't know the details or progress
Hi balbes150.I don't can start up your builds for rockpro64. I get boot screen LE and then the boot does not go. I tried 4 latest builds:
Please help me.
I can confirm this a little bit, but my RockPro64 starts, "just" Kodi crashes. I can see that the RockPro gets a ethernet address assigned and can then access it via Samba for a short time, before it reboots. I use the normal DTB and not the V2
Attached is the zip file with all the logs.The only error I see is: "ERROR: DBus error: org.freedesktop.DBus.Error.ServiceUnknown - The name org.freedesktop.UPower was not provided by any .service files"
My main problem is that nmve ssd does not work in versions with 5 kernel . In versions with kernel 4 that I tested works, but I can't change 'zoom amount' in 'video settings'.
if you need NvmE support you need to enable PCI-E and NVME support in the kernel settings and rebuild the image.
jtosic - For HW decoding there are no drivers available yet for the 5.x kernel. So we just have to wait.
wonderfull built and also thanks for the support and feedback. I did a quick test on the RockPro64 with the following results:
-> Kodi starts without any problems
-> All 1080p/i videos work, without any green blocks or blury decoding, as reported in the previous images.
-> x265 HEVC videos don't work (1080). Sounds start, but no video is played.
I think x265 is still missing from Hantro drivers, so I won't post log files. If you need some, just let me know.
I tried your image and with the tipps about the replacing the uboot I got my RockPro64 to boot, thank you.
I don't know if its a bug, but I have to disable HW acceleration in Kodi to get any videos to work. With HW acceleration the videos are either displayed only on the lower screen (H.264) or don't work at all (H.265, only sound). I tried to google the error message and ended up in threads about v4l2 problems. I think "everything" is still in work for HW accerleration in the newer kernel.
The important bits of the log file:
2019-12-20 18:49:45.108 T:688 ERROR: ffmpeg[(nil)X]: [hevc] v4l2_request_probe_video_device: try output format failed
2019-12-20 18:49:45.109 T:688 ERROR: ffmpeg[(nil)X]: [hevc] Failed setup for format drm_prime: hwaccel initialisation returned error.
2019-12-20 18:49:45.109 T:688 ERROR: CDVDVideoCodecDRMPRIME::GetFormat - unsupported pixel format
Simular for h264.
If you have any working system on the SD card that starts normally, you will be able to check the LE. You need to try to replace the u-boot in LE, on the version with a working SD card. You need to perform a few additional steps when preparing an SD card.
1. Remove from working SD card u-boot. This can be done with this command on a Linux PC.
dd if=/dev/<name_you_SD_works_card> of=u-boot-rockpro.img bs=1M count=16
2. Write LE to SD card, configure DTB and replace u-boot with taken from working SD card. U-boot replacement is performed by two commands.
dd if=u-boot-rockpro.img of=/dev/<new_SD_card_LE> conv=fsync bs=1 count=442
dd if=u-boot-rockpro.img of=/dev/<new_SD_card_LE> conv=fsync bs=512 skip=1 seek=1
After that, you can try running LE on RockPro. The last two commands write a working u-boot and save the existing partition table for the system written to the SD card. By the way, in the same way you can replace u-boot for Armbian system and check the start of any image.
thanks for the explanation. Today I tried to compile the LibreElec from Head specifically for the RockPro64 and got a different uboot then in your image. With my build the RockPro64 started without any problems. Can you check your build parameters? Maybe it is not possible to just build one image for all RK3399 boards and then handle the difference via the DTB. (but I am no expert).
If anyone wants to try my build for the RockPro64 (also including the patch 3560 from Kwiboo for the Linux Kernel 5.4).
Kodi starts without any problems on my RockPro64.
Tried the latest image (20191210) on RK3399 RockPro with 5.4 kernel - Not booting (LEDs are not even active). I changed the DTB in extlinux.cfg and even tried to removed the "quiet" flag. Unfortuantly my RockPro is only connected to a TV, so if the RockPro hangs very early in the boot I cannot help.
SW: Mainline LibreElec + the kernel pull request 3560
HW: RockPro4 connected to a Denon 477 via HDMI. For the first test nothing changed in libreelec, so no passthrough and just 2.0.
Playback of mentioned Youtube Video via the plugin.
Kodi Debug Log - But I didn't see anything special.
Afterwards I enabled the verbose logging for ffmpeg, see attachment to the post. But there is nothing special in the Kodi log, or at least I don't see anything.
Anything else that would be helpfull?
JerryPenguin About the schedule question - It takes as long as it takes and you are requesting too much (new Kernel and new Kodi).
What WiFI module are you using (chipset) and does it work in other images with the 5.3 kernel, e.g. armbian? USB works correctly, but I think in the kernel config for LibreElec 5 / RK3399 some required modules are disabled. I can upload a working build with the "old" Kodi and the new kernel (I just applied the pull request 3560 to the mainline).
Where did you find the LOG entry?
Since the kernel is working and the problem is in Kodi I could connect via SAMBA. There you find a folder called "Log". In the log file 09_Journal-cur.log the kodi error is I posted here.
could you add the PCI-E express drivers for the RockPro64 to the latest kernel. It seems the option is missing in the kernel config. I am no expert, but I only see the PHY module config and not the PCIE module.
The name is CONFIG_PCIE_ROCKCHIP_HOST. In the armbian image it is included (as a module).
In the latest build Kodi 19 does not start (LibreELEC-RK3399.arm-9.80-devel-20191011115114-6e9040d-box.img) I think you forgot to link the libraries:
Oct 11 19:57:01 LibreELEC kodi.sh: /usr/lib/kodi/kodi.bin: error while loading shared libraries: librockchip_mpp.so.1: cannot open shared object file: No such file or directory
I have not tested the behaviour described in the forum. I only flashed the image to a SD card and started.
I switched to one earlier build (LibreELEC-RK3399.arm-9.80-devel-20191004125028-60568a1-box.img) and Kodi starts.
I stumbled upon this thread on the search for a newer build of libreelec for the rockpro64. Unfortunalty your latest images doesn't boot at all the the RockPro64, even the LEDs doen't start. The latest armbian (nightly with 5.3) works great on my rockpro, but i am too lazy to try to get Kodi running on a nightly build.
It it just a problem in the DTB maybe you can try the armbian DTB file of the RockPro.
Sorry if I hijack the thread. I can always open a new one, but I don't know if your files should even be tested yet
do you plan to make the Sonarr v3 beta available for testing (maybe as new plugin)? I just installed it and it runs quite nice on a RockPro. I only had to modify the service.start, because they renamed the main executable to Sonarr.exe . All the config files still worked (or were automatically converted).