That’s re-work from Kwiboo’s earlier patches to enable higher resolution modes with RK3328 && RK3399 SBCs through HDMI.
What the patch-set effectively does - makes changes to use the big vop along with mpll_cfg table alterations to allow the devices to output up-to UHD resolutions.
On my particular setup, it enables:
Use of the full WQHD resolution on my main monitor with the RockPro64 - previously stuck at FHD only
Correct detection and use of the QHD monitor with RP64/ Rock64 (previously neither SBCs could even detect compatible mode - monitor doesn’t work)
Correct detection and use of 1440x900 monitor (previously, neither SBCs could detect compatible mode - monitor doesn’t work)
Here is my kernel package setup to use the patch-set if someone wants to give it a shot:
Here is the RockPro64 connected to 27" QHD ElectriQ monitor using the native resolution:
As a note - I’m not sure if UHD resolution is sustained at 60Hz or 30Hz (can’t verify it with my devices).
For my WQHD monitor it seems to work fine with 60Hz but ymmv
Having that patchset reworked and submitted properly upstream would be a big step up in the usefulness of the rk3328 and rk3399 boards for me. And will likely also make it easier for rk3568, rk3566 and rk3588 to get support for it too, as soon as they get HDMI out support in the first place.
I got my Rock Pi 4C today so I’d like to try your package under Manjaro to hopefully make 4K output possible but Manjaro isn’t booting your kernel after installing the package and rebooting.
I noticed that pacman didn’t run/update u-boot after I installed your kernel package so I presume thats what I need to do but I don’t know what command(s) to run to do that?
Does your kernel have working HDMI audio for RK3399?
Thanks
EDIT
I was unable to get Manjaro to boot off nvme but apparently thats because I need to flash the SPI first, as per this guide:
I’ll do that and re-install Manjaro and your kernel. ATM its booting off eMMC but the root is on the (very slow) nvme, which is only doing about 200 MB/s with the stock Manjaro kernel so it doesn’t look like its using the proper PCIe driver yet.
The good news is that I’m happy to confirm that @Pak0st 's kernel enables both UHD and full 4K output on my RockPi 4c when connected to my LG NANO866NA. You might want to add that to the compat section of its github page’s README?
The bad news (for me) is that ethernet, wifi and BT aren’t working but because @Pak0st isn’t running a RockPi I kinda expected that.
The other bit of bad news is the RockPi 4 can’t boot directly from Samsung EVO SSDs, although it is usable with having /boot on uSD or eMMC. I was hoping to boot directly from NVME with my Samsung EVO 970.
I found out how to enable PCIe 2.0 mode and it doubled the read speed of the nvme to almost 400 MB/s under the Radxa Ubuntu but I was hoping it would perform better than that. Maybe you need a fully compat SSD to get (almost) full speed from nvme?
@danboid , thanks! Will add that to the description tomorrow.
For HDMI audio - no, I don’t get that option. It will be good for me make a new build against 5.16 and try again.
I’m not sure about Ethernet It’s working fine on my RockPro64 and currently that is my preferred use. The patches should be affecting that portion of the functionality.
For WiFi and BT check for ap6256-firmware package - at least this is listed on this Rock Pi spec page: Rockpi4/hardware - Radxa Wiki
The same package is required for RockPro64 if using the official WiFi/BT module from Pine64.
When it comes to booting from SSD → you need to check if you have SPI on that board.
It comes down to how RK3399 boots and it’s programmed with the following boot order: SPI-> eMMC-> SD. You would need to put uboot in one of those.
Currently on my PBP, I’ve left uboot on the eMMC and just removed (renamed actually) extlinux.conf on the eMMC so that I can boot from the NVMe drive.
I’m not sure if tow-boot is compatible with Rock Pi 4c though I don’t see why it wouldn’t (afaik tow-boot is wrapper for uboot so it should be compatible but read the docs first)
Yes my RPi4c does have an SPI so I will have to try tow-boot.
The first distro I tried booting on my RPi4c was Armbian TwisterOS. I was pleasantly surprised that HDMI audio was working so it is supported on RK3399. However Twister failed to update and I think it was 32 bit as I saw it trying to download armhf packages so it got binned pretty quickly.
“This would only be possible if you have the board firmware on the boards SPI flash.”
The Radxa Ubuntu server image includes a script to flash the SPI. I have run that and afterwards I tried booting Radxa Ubuntu, Manjaro and the latest RPi4c Armbian build off NVME but none of them booted.
Need to check for the audio through HDMI though. My setup is a bit confusing even for me (monitors and boards to 4x3.5mm splitter box so I need to track which is which)
@danboid , I’ve already discussed with @Strit strategies for those patches and this is what we’ve landed on.
The main reason is that the patch-set is downstream. Manjaro ARM attempts to use only mainline kernel if downstream changes are not required for the core functionality of the devices. This helps lessening the burden of maintaining the system as well as contributing to the ecosystem.
I’m not willing to put the burden of maintaining those downstream patches to the Manjaro team.
I lack the technical expertise to maintain them myself (given their complexity) which obviously is far from the experience the majority of ManjaroARM users would expect.
They are fine for personal use but are not tested extensively from my understanding. Especially in 4k@60 mode - I don’t own a device (read monitor) that can be used for this purpose. Even if I had a 4k monitor, that would be a sample of 1 whereas we need far wider test coverage.
It could’ve been possible to add a separate kernel package similar to linux-pinebookpro to make it easier for other users to give it a try and report their findings.
However, ultimately this is no different than me distributing the modified kernel with the exception of creating more work for the Manjaro team. I would argue that it would cause more confusion even if there is proper description to the package as not many people read those and instead just jump to pacman -S <package_name>.
Leaving this modified kernel on my GitHub page is fine for now - it ensures that the user is well aware what he/she is getting into
As @Strit pointed out, the best course of action is to help the developers behind the patch-set to mainline the changes.
Speaking of which, my thread on LibreELEC’s forum never got a reply
PS: I’ve been busy at work in the past few days - will make the GitHub upload of the new release when I get a few hours.
When it comes to the audio from HDMI - this was my bad. I do have it working however here is the kicker - the option to select in plasma was actually Analog Output (Built-in Audio Stereo) instead of HDMI.
You can see that here in this video - the RP64 clearly doesn’t have any other connection to the speakers but through the HDMI
Oh, I do believe it’s very important to note - Doug Anderson, one of the creators of the downstream patches, did reply to my question about the auto-generated tables. Huge thanks for the reply!
PS: Getting to know how the patch-set was made is very interesting. Patches for veyron (rk3328) ultimately help out for wider Rockchip SoC support is intriguing. Some of the earlier blog posts from Alyssa Rosenzweig also show that Panfrost wouldn’t be where it is today if it wasn’t for Veyron Chromebooks
In any case, looks like Sascha Hauer has begun a proper upstreaming effort
You can see the patches for RK356x VOP2 that contain LibreELEC’s patch-set as well here: DRI devel - Patchwork
Maybe in the weekend I will have some time to use that as the base instead of the current patch-set
Will update in the evening all of my threads (here, pine64 and LibreELEC’s forum) to point to Sascha’s patches as well.
I’ve only just got round to trying your latest kernel on my rockpi4c after finally getting direct nvme boot to work and, much to my surprise, wifi, bluetooth and ethernet are working too! Yay! I’ve got a fully functional board now but it’ll be better when the RK VOP stuff gets mainlined and I don’t need to pin your kernel to stop it getting ‘upgraded’.
It’s working fine on my RockPro64 and currently that is my preferred use. The patches should be affecting that portion of the functionality.
(monitors and boards to 4x3.5mm splitter box so I need to track which is which)
