JMCC

Okay, NanoPC-T4 can run now dual displays, and GPU 3D acceleration works flawlessly:
https://users.armbian.com/jmcc/misc/nanopct4-dual-screen.mp4
 
@TheGuv It seems like a problem specific to Helios64. @aprayoga Maybe you can shed some light on the problem? This is the post where the user reported failing GPU acceleration: https://forum.armbian.com/topic/16516-rk3399-legacy-multimedia-framework/?do=findComment&comment=116900
 
[EDIT]: And this is the fix that enabled NanoPC-T4 DP, in case it is helpful to debug the Helios64 problem: https://github.com/armbian/build/pull/2647
 
 

Seems to work fine on the M4.
 
Linux nanopim4 4.4.213-rk3399 #6 SMP Thu Feb 18 19:25:55 CET 2021 aarch64 aarch64 aarch64 GNU/Linux  

You need to assign a fix version. Compare yours https://armbian.atlassian.net/browse/AR-600 with this one from Igor: https://armbian.atlassian.net/browse/AR-630

Definitely, according to the picture, something went wrong. Can you do the installation again from scratch, and this time copy-paste the installation output? And also "armbianmonitor -u".

Nice! Always helpful to have a working test device
 

@balbes150 This commit takes care of the issue. I built and tested a xfce-buster image, and everything seems OK.
 
I also added the session selector to LightDM greeter, so people can choose Kodi or any other desktop of their choice.

I used master. From what you say, it looks like we need to put some "Provides: armbian-xxx-desktop" field in the package control files, to ensure backwards compatibility. I will look into it.

Last time I tried, it was working fine, but it was two weeks ago. Let me test when I get home.

I never said it didn't, but one still has to read up on how it works, how to get it to compile just the kernel, after applying patches, how to use that kernel and handle unbootable systems etc.;  that sort of thing.  I'm very new to Armbian.
 
 
I meant that, since you're currently working on getting the Media Framework to work based on the mainline kernel and asssuming that this HDR issue is, at least in part, due to something missing from the kernel, whether it might be better to troubleshoot this in the mainline version of the Media Framework.  But read also below.
 
 
I sort of managed to do the reverse: find a libreelec setting that makes HDR output not work and exhibits the same behavior I get on Armbian.  As far as I can see, librelec for rockchip devices doesn't apply any KODI patches (although there is this).  I'm not sure if that means that the plain/unmodified source is used for KODI, or whether some patches are applied regardless of board, but on librelec, KODI has an extra option that lets you select the "HDMI output format".  This essentially sets the color space to RGB or YCbCr (4:2:2 or 4:4:4 ).  The display only switches to HDR with the (default) YCbCr mode, not with RGB.
 
The Media Framework version of KODI is missing that option.  In fact I haven't found any reference to it, outside of libreelec.  Output seems to default to RGB colorspace, as can be seen with:
 
 
In contranst in librelec, I get something like:
 
 
I'm not sure of course, that getting KODI to switch to a YUV HDMI output mode will be enough to make the display switch to HDR, but it seems worth trying, especially since it should be easier than semi-blindly applying kernel patches.  That said, I can't seem to find much info on how to do so.  Let me know if you have any insight to share.

You don't need to change anything. I found a solution-changed the patches so that can now use a common core for p1. 

I would like to bring something to attention. Right now, Station P1 and M1 legacy are being added as new kernel packages. I think ideally, the changes should be merged into some of the existing RK3399/Rockchip64 legacy kernels. We were aiming to reduce the multiplicity of RK kernels, but now we are introducing two new kernel packages, station-m1 and station-p1, one of each for a single device.
 
Of course, I understand all the work involved on bringing up a new board, and how frustrating it is when new kernel configs or patches conflict with the existing one. But it is probably worth the effort to try and merge the changes for P1/M1 into Rockchip64, if that were possible.
 
 
@piter75 @martinayotte @balbes150 @TonyMac32 @Igor What do you think?

The DTS patch is sufficient to enable NVMe. For the rest of the elements-I'm just now preparing patches for the current Legacy kernel (rockchip64), which is used to build the version for P1 in the official GIT.
 
 

Yes, meson uses stateful whereas Cedrus and rkvdec use stateless (request api).
Actually only one really worked on this driver but stopped working on most (all?) things due to real-life issues.
Vanilla Kodi will work for video decoding, but if you want HW deinterlacing, that will need Kodi patch and additional one for ffmpeg.

I apologize. Yes, jernej hasn't actually said what I've instead said but just that there is a lot of work (optimizations) to do. I've said it my way which is the wrong way because linked with my very very limited knowledge, not Armbian fault nor its developers. You're absolutely right and I can only apologize.

The build script, after git checking out the kernel sources, will apply the patches. All of the applied patches will appear in order, with a green indicator when they are applied OK and yellow or red when there is some problem. Though, since the text moves so fast, you probably didn't notice it.
 
The easiest way to check how the patches are applied is to add the option CREATE_PATCHES=yes to compile.sh. It will make the script pause twice, first after applying the u-boot patches and then after the kernel patches. You can see if your patch was applied correctly, and troubleshoot if not.
 
Simply open the commit in GitHub, and then at the address bar add ".patch" at the end.

What? Why don't you use the Armbian Build Script? That is what all this project is about! 
 
Applying a patch is as easy as putting it on the corresponding folder under "userpatches", or either use the command line option "CREATE_PATCHES=yes" in case you want to apply it manually.

No support for anything other than Armbian 
 
Yes, I realized it recently. Only 32-bit userspace will have Widevine DRM. I thought to make Kodi run in a 32-bit docker container, but there is no ETA for that project.

Let's do it
 
P.S.: Not a big fan of ZSH so far. I installed it on my Ubuntu PC, and it all just looked like an unconfigured BASH, needing plenty of work to make it useful. I guess the Armbian version comes pre-configured, I'll give it a chance in some near future.

I just enabled the 1.5Ghz OPP for legacy. The board is clearly the fastest RK3328 I've used so far, most probably due to good emmc and memory, plus great thermal management.
 
Due to the good thermals , I dared to dial down just a few uV from our standard 1.5Ghz OPP patch (1425000 instead of 1450000). I tested it extensively and found it stable. Reducing it to 1400000 caused some occasional instabilities.

@Werner How about changing this topic title, or splitting all posts except the very first ones to a new one, calling it "Station P1/M1 Board bring up"?

Let's do it
 
P.S.: Not a big fan of ZSH so far. I installed it on my Ubuntu PC, and it all just looked like an unconfigured BASH, needing plenty of work to make it useful. I guess the Armbian version comes pre-configured, I'll give it a chance in some near future.

With https://github.com/armbian/build/pull/2569 and https://github.com/armbian/upload/pull/33 the problem seems to finally be gone.

Some day I have to test this ZFS. I'm too attached to the good ol' EXT4 

Media info:
https://arstechnica.com/gadgets/2020/12/openzfs-2-0-release-unifies-linux-bsd-and-adds-tons-of-new-features/
 
Remarks: 32bit support is broken in Debian Stretch, no upgrade there. Also this upgrade is needed to bump kernel to 5.10.y

Sorry, my USB-C to DP/HDMI converter is broken, and I have no plans to make room in my budget for a new one, at least for now. So I cannot debug or fix this problem.
 
TBH, I am very surprised there is people using the Helios64 as a desktop device, I always considered it a NAS