Can anyone help me???
No, it doesn't have any Linux support.
You need a RK3328, RK3399 or RK3288 device.
Can anyone help me???
No, it doesn't have any Linux support.
You need a RK3328, RK3399 or RK3288 device.
thanks mo123, another question, i have a rock64, but i'm inclined to buy a rock64pro just to get the pci express dual sata card to connect 2 Hard disks.
the question is does libreelec have drivers to support this card? so i can build a libreelec with 2 hard disks connected to the system?
Best regards.
You might need to add the drivers or make dts changes to the LE kernel and build your own image to support that or ask Pine64 if it works.
does the rock64/rock64pro can output them correctly in HDR? did anyone made the tests?
Best Regards.
With the mainline HDR support Kwiboo is working on and the driver only recently being created by Intel, it should be possible later.
Display MoreHello colleagues,
i'm trying to load the LibreElec firmware onto my VS_RK3399, but the upgrade_tool uf LibreELEC-RK3399.arm-9.1.002-sapphire.img command fails:
The output is:
And that's it.
The board is in recovery mode and is also recognized by the upgrade_tool:
Coderoot@Hades:/opt/dev_boards/rk3399/linux/rkbin/tools# ./upgrade_tool LD Program Data in /root/.config/upgrade_tool List of rockusb connected(1) DevNo=1 Vid=0x2207,Pid=0x330c,LocationID=10105 Mode=Loader root@Hades:/opt/dev_boards/rk3399/linux/rkbin/tools#
Any ideas?
Many thanks!
How do you want to use an Android flash tool to write LibreELEC to EMMC?
You write LibreELEC with etcher to a micro-sd card.
I'm not aware of any compatible LibreELEC image for VS-RK3399.
Someone can perhaps build an addon like this but for Rockchip devices?
GitHub - roidy/script.amlogic.colorformat: Amlogic color format information script.
It can be very useful to test display mode, color depth, color space, color range etc.
Display MoreHi, guys. First of all, let me congratulate everyone for making amazing progress on making LibreELEC work as perfect as possible on Rockchip devices.
I thought I'd give feedback regarding my overall experience after testing various current images for RK3328 devices and hopefully this feedback will help improve any future releases.
First off, I am running an R10 RK3328 Android TV Box.
Second, my preferred LibreELEC build is the latest MVR9 image (LibreELEC 9.2 Alpha) which you can download right from this site: Rockchip – LibreELEC
I have tested all the LibreELEC 9.2 Alpha images for RK3328 devices. They all boot into LibreELEC but MVR9 image works best for me because I get Internet connection via Wi-Fi (wired connection doesn't work) and I get sound from my speakers via AV port by selecting the I2S analogue sound option in Kodi settings.
Regarding other LibreELEC 9.2 Alpha versions I tested, some of them don't have Internet at all / others have Internet via Ethernet but no Wi-Fi, but those images don't have the I2S analogue sound option so I get no sound to my speakers.
Okay, that would be my feedback regarding sound and Internet.
Now, to the second part, which is video playback.
Again, LibreELEC 9.2 Alpha MVR9 image works best for me. There are only two small problems: a) colors in 4K videos seem to be a bit washed up. That's especially apparent if I bring up navigation bar during playback. Then the colors become even more pale
b) MPEG-4 files are extremely choppy as LibreELEC 9.2 Alpha doesn't yet use HW acceleration for those files, so I guess that's where the problem lies.
The two latest developmental images I've tested have other bugs, but they fix these two video playback problems for me.
First off, regarding washed up colors in 4K videos, the latest MVR9 LibreELEC version on this link (LibreELEC-RK3328.arm-9.80-nightly-20190719-235fdbc-box-trn9.img.gz) has better colors, but here videos get a bit choppy when bringing up the navigation bar.
And secondly, regarding choppy MPEG-4 videos, the latest image by Kwiboo (LibreELEC-RK3328.arm-9.1-devel-20190512173254-bdfaff1-box-trn9.img.gz) fixes that problem, but the playback of other video formats has gotten worse and very, very buggy.
So, if you could somehow merge the official RK3328 MVR9 image with the good points from these two other images, it would improve things a lot.
I guess my recommended list of fixes would be:
1) HW acceleration for MPEG-4 files
2) improved 4K video colors
3) Ethernet connection available on MVR9 image.
Thank you for reading.
Gigabit ethernet is broken for all RK3328 devices at the moment., Kwiboo said he will look into it.
It is working on the old 4.4 kernel images that are now discontinued.
By running the MVR9 images on your device, you must make sure your device also uses DDR4 RAM otherwise in the long run it will cause wear & tear on your RAM chips and can also cause stuttering video playback if used on a DDR3 device.
Kwiboo, we really need new images for testing, please
Display MoreHi all,
I am new to LE OS and I want to install it on a chinese tv box, Beelink A1 model
Specs for the box are:
Processor: RK3328
CPU type: Quad Core ARM Cortex-A53
GPU: Mali-450MP2
RAM: 4G RAM DDR3
ROM: 16G
I don't know what version of LE to download. The versions I found are:
Early mainline images for RK3288, RK3328 and RK3399
Rockchip – LibreELEC (Generic Rockchip Box - LibreELEC-RK3328.arm-9.1.001-box.img.gz)
Are there any stable releases for this type of android box/CPU?
What version of LE should I install?Thank you!
No support for that Beelink device.
But you can try all the images, maybe one will boot but wifi, bluetooth and ethernet will most likely not work.
The device was also discontinued by them 3 months after release, so you also won't get any Android updates.
TICTID, MVR9, ROC CC, Rock64 RK3328 are the only ones with mainline LE support.
Display MoreHi Folks!
I just bought me some Rock Pi 4s to replace the old Raspberries here running Librelec.
So far, it looks good, even 4k films can be played (sometimes )
But I have noticed that Audio Passthrough to an external Amp really does not work with the Rock
Only static noise comes out of the Speakers (I've learned it the hard way last night, very late already.... bad karma...)
The Amp does not recognise any Dolby Digital or DTS Frames, instead it keeps on playing PCM, which explains the evil noise fairly well.
I found this thread, read it and hoped, there will be a solution, at least somebody is working on it right now.
But, I cannot make head or tails out of it, one says "yes", others say "no", one points to the "nightly" or "development" image (I've tried it right now, still no go )
So, at the end I feel quite lost.
a) is this problem known ?
b) does somebody work on it already?
c) if the answers are "no" what is the best place to report it???
You have to wait until mainline Linux support is added for Rockchip devices.
4.4 kernel images don't support audio passthrough.
Please check gigabit lan support on RK3328 mainline.
It is missing some code in the dts files that was present in the 4.4 kernel dts files.
Trn9 board uses gigabit lan and maybe some others too like ROC CC.
Thanks
Kwiboo I have a RK3399 box (X99) for which I had a working 4.4 dts. I tried booting the rockpro64 img, but it gave an error wrt i2c on the serial console.
I ended up modifying the original 4.4 dts which got rid of the i2c error bringing it closer to rockpro64, but the screen is blank. There is an error regarding EDID is blank.
Let me know so I can provide any debug logs or dump of any parameters from serial console.
Code Display More# cat /sys/kernel/debug/dri/0/state plane[31]: plane-0 crtc=(null) fb=0 crtc-pos=1024x768+0+0 src-pos=1024.000000x768.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range plane[33]: plane-1 crtc=(null) fb=0 crtc-pos=0x0+0+0 src-pos=0.000000x0.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range plane[36]: plane-2 crtc=crtc-0 fb=44 allocated by = kodi.bin refcount=2 format=XR24 little-endian (0x34325258) modifier=0x0 size=1024x768 layers: size[0]=1024x768 pitch[0]=4096 offset[0]=0 obj[0]: name=0 refcount=3 start=00000000 size=3145728 imported=no crtc-pos=1024x768+0+0 src-pos=1024.000000x768.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range plane[38]: plane-3 crtc=(null) fb=0 crtc-pos=0x0+0+0 src-pos=0.000000x0.000000+0.000000+0.000000 rotation=1 normalized-zpos=0 color-encoding=ITU-R BT.601 YCbCr color-range=YCbCr limited range crtc[35]: crtc-0 enable=1 active=1 planes_changed=1 mode_changed=0 active_changed=0 connectors_changed=0 color_mgmt_changed=0 plane_mask=4 connector_mask=1 encoder_mask=1 mode: "1024x768": 60 65000 1024 1048 1184 1344 768 771 777 806 0x40 0xa connector[41]: HDMI-A-1 crtc=crtc-0 hdr_metadata_changed=0
Code Display More[ 8.659739] rockchip-drm display-subsystem: HDMI-A-1: EDID is invalid: [ 8.659794] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.659801] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.659805] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.659810] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.659814] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.659818] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.659822] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.659826] [00] ZERO 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8.677009] SWITCH_REG1: supplied by vcc3v3_sys [ 8.689483] SWITCH_REG2: supplied by vcc3v3_sys [ 8.738088] Console: switching to colour frame buffer device 128x48 [ 8.743182] rk808-rtc rk808-rtc: registered as rtc0 [ 8.775272] rockchip-drm display-subsystem: fb0: frame buffer device
You will need a 5.1 not 4.4 dts kernel file to test with mainline images used here.
But I can't help further.
from where I can download the 5.x kernel image (package) so that we also can test and give you the feedback. Thank you
Here are the test images with mainline Linux 5.1 kernels.
Mpeg2 should work.
It seems there is progress being made with H264 and hopefully that should work too early next month.
Then H265 and VP9 video playback code still has to be created and tested with mainline Linux.
I can't wait until everything works fully with mainline Linux.
May I ask you to point me the correct build and/or dtb file for RK3399 H96 Max 2g RAM version?
There is no support for that device.
Please ask the manufacturer to send sample devices to the LibreELEC developers plus the kernel source code.
Try all the other RK3399 dts files and check which one works the best then the things not working can perhaps be fixed.
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?
I'm on the latest alpha build of libreelec, and have an issue with the video on my rock64 1GB board. I've just now started using this board, and I have found 2 issues. One is that when i start a video I lose hdmi output, the other is when i do have hdmi output the color is not correct. The interface works correctly, this only happens when i start a video. Has anyone else had this same issue and have you been able to get it corrected or should i go back to using my raspberry pi and find another use for the rock64.
Did you try the latest nightly?
libreelec-rk3328.arm-9.1-nightly-20190501-6f2af43-rock64.img.gz
Hi,
i use my Rockpi4 dayli with live tv and netflix. I have also a tvheadend server with german sky Card. Everything works well, but sometimes the video has to reload and at this point i have to stop the program and start it again, because the video is showing slideshow. If i turn of the Hardware decoder and use SW everything works fine!! It would be nice if someone can test this issue!
Sorry for my english...
The nightly images are missing the software decode patches from Kwiboo for Inputstream Netflix decoding.
Otherwise everything could be hardware decoded and Netflix software decoded automatically with much better performance.
Things will improve even more with the switchover to the Linux 5 kernel.
Of course it will be open-source.
The main use of RK3588 is Linux support.
It just depends which companies will release development boards based on it and send sample devices to developers.
Don't expect cheap no name brands that only ship with Android to have any LE support.
But it's still almost a year away.
The S905X3 is a low cost device, RK3588 won't compete against it, rather against the S922 but the RK3399 performance is already a bit faster than the S922. I would rather say the RK3530 will compete against S905X2 & S905X3.
Hello,
sorry, I have to open a new topic, since noone gives answers...is there a offical (alive) develoment topic for the rock64 with changelogs?! I cant do testing when I dont know what to look for...I do all the updates usually.
Thanks,
regards
Compare the commit number in your image to the one in the Github page to see commits newer than it or the ones included in the image. Eg. b090091bb921 That is your change-log.
Commits · LibreELEC/LibreELEC.tv · GitHub
The daily images are all still using the old 4.4 kernel that is now discontinued since mainline v5.x kernel support is being worked on.
Just some of the hundreds of mainline patches that will be tested and merged soon.
WIP: Rockchip: add initial mainline support · Kwiboo/LibreELEC.tv@60355a0 · GitHub
The kernel update from 4.4 to 5.0.7 alone already contains a few thousand changes.
Some mainline kernel work being done on a daily basis.
With mainline support lots of things like 10-bit, HDR, interlaced playback, HD Audio have to be redone and for HDR, follow standards set by Intel code that have to be tested and still merged into mainline kernel. But if finished, everything will run a lot more stable and be better supported. All of this takes tremendous time and effect from several different developers.
Several Rockchip devices are tested not just Rock64, there is no special support for one device.