LE13 Testing for RK3288, RK3328, RK3399, RK3566, RK3568, RK3576, RK3588

    Quote from Elicity

    Which one do you recommend:

    I recommend you experiment and figure out if one of them boots with the device-tree file that Armbian are using. Then (most important) you keep quiet if there are any issues, because it's a hack. I'll happily pick support for any new boards to the patchset, but it's a hard requirement to see the patches on a mailing list first.

    I pushed updated images for all Rockchip hardware to my test share. Older hardware now includes the kernel fixes recently made for LE12.2 images and a bump to 6.16.4. Newer hardware has additional realtek NIC firmware(s) to silence missing firmware messages noticed in some of the logs recently shared. Kernel for newer hardware is bumped to 6.17-rc5 .. no media capability changes.

    Quote from diederik

    I did some testing on the PINE64 Quartz64 Model B (rk3566) with my standard set of test files:

    Several days ago I checked chewitt's repo and didn't see any additions to the rk356x-base.dtsi (or sth like that), which I think means that rkvdec2 support doesn't work for devices like my Q64-B? That would explain the less then stellar results I got.

    Initial support for RK356X, RK3576, and RK3588 has been merged!

    I'll give it a few days for 'the internet' to self-build and point out obvious mistakes and then we'll get some nigthlies organised for the wider unsuspecting public to break their setups with :)

    chewitt I did make/try something for rk356x and I'm about to test whether (and to what extend) that works. Will let you know what comes of it.

    In the mean time, I did a new test with the image build dd 20250911 on my Rock64 and while it was generally good, it did have some problems starting my BBB x265 videos (both 8-bit and 10-bit), so I booted again with debug logs enabled and played those 2 files and uploaded the compressed log to 'my share'.

    When you go to 'my share' you'll notice that I renamed some files so x264/x265 and 8/10-bit is directly visible in the file name. And it also contains some new files, including 'bbb_sunflower_1080p_60fps_normal.x265.cf24.slow.8bit.mp4' which was one of those test files.

    Quote from diederik

    Several days ago I checked chewitt's repo and didn't see any additions to the rk356x-base.dtsi (or sth like that), which I think means that rkvdec2 support doesn't work for devices like my Q64-B? That would explain the less then stellar results I got.

    Updated to chewitt's latest build on Q64-B and tried some of my test file while being ssh-ed into the device and running htop. Now I'm sure it doesn't do HW decoding on rk356x. So whether it seems to work or not, depends on the complexity (bitrate I guess) of the video file.

    On the bright side, my tests on Q64-B (rk3566) and NanoPi R5S (rk3568) on my Debian system (with a whole bunch of patches) were quite successful \o/

    Chewitt: I'll CC you on my test result post and on an RFC PATCH submission I'll do (soon (tm)).

    I've merged CI changes so LE13 nightlies should commence in the next 24-48h. There's a probability of boot issues with RK3576 as the Rock4D that I have boots and runs great .. for 30 seconds .. then the board stops responding.

    There's also a Rock 3C gathering dust that needs to go into the test rotation so I can look for issues.

    I'm not aware of any other issues, but ignorance is bliss ;)

    chewitt
    Could you please test the latest image on your RK3588 device?
    RK3588S devices were able to boot on the latest image. (NanoPi R6C, NanoPi R6S, OrangePi 5, ROCK 5A, ROCK 5C)
    But, RK3588 devices weren't able to boot. (ArmSom Sige7, OrangePi 5 Max, OrangePi 5 Plus)

    In my RK3588 cases, it restarts on u-boot phase (OrangePi 5 Max, OrangePi 5 Plus) or it stops on u-boot phase (ArmSom Sige7).

    I don't know what the cause is because I don't understand it well enough.

    NB:
    OrangePi 5 Max device with OrangePi 5 image was able to boot.
    OrangePi 5 device with OrangePi 5 Max image wasn't able to boot.
    - it restarts on u-boot phase.
    So both image may had something difference or not.

    Code
    U-Boot SPL board init
U-Boot SPL 2017.09-orangepi (Aug 30 2024 - 22:09:16)

    Yasai-san all three boards are trying to boot a prehistoric vendor u-boot, e.g. ^

    I'd guess they have it installed to SPI flash, so erase that and the boards should find upstream u-boot on the SD card and boot.

    Quote from chewitt
    Code
    U-Boot SPL board init
U-Boot SPL 2017.09-orangepi (Aug 30 2024 - 22:09:16)

    Yasai-san all three boards are trying to boot a prehistoric vendor u-boot, e.g. ^

    I'd guess they have it installed to SPI flash, so erase that and the boards should find upstream u-boot on the SD card and boot.

    I got to know the RK3588 device boot failed reason a little.

    In past chewitt development version, these devices were booted.
    I temporary changed(reverted) u-boot version from 2025.10-rc3 to 2025.07, it is worked again.

    This boot fail happenes from u-boot 2025.10-rc1 after.
    I can't find yet which commit affects it because v2025.10-rc1 has 1025 commits from 2025.07.

    BTW the u-boot has new tag 2025.10-rc4 already.
    But I didn't try to shift yet sorry.

    Quote from Yasai-san

    I can't find yet which commit affects it because v2025.10-rc1 has 1025 commits from 2025.07.

    RK3588 boards should be usable without the additional patches that LE is using (which are mostly for 3576 support) so clone u-boot sources and start a git bisect to track success/failure, but use the githashes (and no patches) in the LE buildsystem. No matter how large the number of commits difference between the start points is, bisect will find the breaking commit within 8-10 moves, and if the rest of the LE image is static this is probably no more than an hour of effort. NB: I normally edit scripts/uboot_helper so I don't waste time building images for hardware that I won't be testing with.

    Quote from chewitt

    RK3588 boards should be usable without the additional patches that LE is using (which are mostly for 3576 support) so clone u-boot sources and start a git bisect to track success/failure, but use the githashes (and no patches) in the LE buildsystem. No matter how large the number of commits difference between the start points is, bisect will find the breaking commit within 8-10 moves, and if the rest of the LE image is static this is probably no more than an hour of effort. NB: I normally edit scripts/uboot_helper so I don't waste time building images for hardware that I won't be testing with.

    Thank you very much good information:)
    I will try "git bisect":!: and I wiil report.

    RK356X images in my share now have a working OSD in Kodi and what appears to be working HEVC support. RK3566/3568 appear to be a bit forgotten; the hardware is largely derivative of RK3588 so e.g. the same vdpu381 decoder can be added easily, but as these chips are not targetted by any funded Collabora development, they aren't being tested (by Collabora) with numerous in-flight patch series. Hopefully LE crowdtesting will fill some gaps. I'm also noticing that MPEG2 support (hantro) has issues with some of the test media that I have, but I haven't been able to spot patterns.

    Quote from Yasai-san

    Thank you very much good information:)
    I will try "git bisect":!: and I wiil report.

    progress:
    I was able to get the commit for this RK3588 boot failure with "git bisect" maybe , many thanks.

    Merge tag 'v2025.07-rc5' into next · u-boot/u-boot@184e7d0
    Prepare v2025.07-rc5 With this merge, tighten up the LTO_FLAGS removal we added to not trigger on ARMv7 (which is Thumb-2 and should be fine).
    github.com

    This commit was merge commit, I will investigate more.

    The RK3588, RK3576, and RK356X images in my test share have been updated to u-boot 2025.10-rc4. The bump drops quite a few now-merged patches from the patchset, but no idea if it also fixes anything?