Jump to content

One (bsp) Kernel f RK3399/RK3328 and RK3288


chwe

Recommended Posts

As discussed on multiple threads, the aim of this thread is to bring all RockChip devices under one BSP (4.4) Kernel.  This discussion can be found (partly):

and a bit background here: https://github.com/rockchip-linux/kernel/issues/98

 

Cause I'm not willing to cut out all this stuff from the related threads (this would end in a complete disaster) I try to summarize it here (if something is missing, let me know I'll add it):

  • RockChips BSP kernel is not longer an option. Cause it breaks faster that our current resources allow to fix it.
  • Having all SoCs under one kernelsource would make it more predictable and decrease the efforts needed to keep them 'reliable working'.
  • Ayufans (https://github.com/ayufan-rock64/linux-kernel/tree/release-4.4) tends to be the preferred Kernel at the moment. First attempts to bring up rk3288 boards are made

 

notify some of the involved people just to make sure they don't miss it (I probably miss some, don't be upset :lol:): @TonyMac32, @JMCC, @tkaiser, @Igor, @zador.blood.stained, @hjc & @ayufan

 

Some questions which are open for me:

  • How can we ensure that the 4.4 kernel we currently use for the RK3288 get at least 'security updates' as long as the switch needs?
  • Is someone in touch with ayufan so that he recognizes our idea? (or @ayufan do you read the stuff here :P)
  • Can we 'channel our efforts' to ensure that we don't waste our and others time (e.g. open a transitions branch and make it clear that PRs against the old kernels don't make sense)

 

I hope this thread doesn't get floated with garbage but on the other side I hope that people write about their plans and 'results' so that we don't do the work twice. :) 

 

EDIT: BTW, I'm not sure if this thread fits better in development or here, but I think it's more recognized by the rk-users when we have it here..

Edited by chwe
Link to comment
Share on other sites

We have no options as far as security updates go in the kernel, we can't build it to add them.

As long as Ayufan's kernel hasn't mucked around with anything that could break the rk3288 this won't be too difficult.

Would the direction then be to commonize things in a similar fashion to Sunxi, or simply use the same kernel each with their own patchset (any common to all devices should be pushed to Ayufan anyway)?

Sent from my Pixel using Tapatalk

Link to comment
Share on other sites

1 hour ago, TonyMac32 said:

We have no options as far as security updates go in the kernel, we can't build it to add them.

I don't know how much it is broken since I digged around with the ISP driver, but fork it redirect kernelsource and just put greg-kh's weekly patchset on top of it and hope it doesn't break? :lol: In case it needs to much efforts <blasphemy on> better we have a 'insecure' kernel for a short time than messing around with two kernels and need months for the switch. <blasphemy off> :lol:

 

1 hour ago, TonyMac32 said:

Would the direction then be to commonize things in a similar fashion to Sunxi, or simply use the same kernel each with their own patchset (any common to all devices should be pushed to Ayufan anyway)?

Communism with an american on board? Your last election showed clearly that this doesn't work... :P Might be problematic for the Kernelconfig (e.g. the mali stuff). What about three different kernelconfigs (trying to keep them as close as possible). A main patchfolder with subdirectories for each architecture and keep as much as possible in the mainfolder? Only stuff which breaks other may be in the subdirectories? Sounds a bit complicated in the beginning... 

Link to comment
Share on other sites

8 hours ago, chwe said:

I don't know how much it is broken since I digged around with the ISP driver

Well I can't get it to build again, so...

 

8 hours ago, chwe said:

Communism with an american on board?

I promote no such thing.  :lol: I said commonize, which is quite different.

Link to comment
Share on other sites

14 minutes ago, TonyMac32 said:

OK.  I had forgotten the source packages being built, stupid me...

 

Sometimes it took a while to see the obvious :) It's also not a perfect solution but it's better than digging into the broken code. Even here I had a few troubles and I hope image works and I hope also MALI works.

Link to comment
Share on other sites

1 minute ago, Igor said:

Even here I had a few troubles and I hope image works and I hope also MALI works.

There are a few things we can patch into it that were bugfixes, I'll dig around and figure out what is what.  (the new wifi driver is one I can think of). Feature wise it was complete other than camera (which I think just needs time and someone actually working on it who cares)

Link to comment
Share on other sites

1 hour ago, TonyMac32 said:

which I think just needs time and someone actually working on it who cares

changes aren't that much between ISP from march and yet.. So 'bring it up' wouldn't be a problem.. Only depends which prize we're willing to pay for it.. For me it doesn't make sense to bring up the camera to the prize that we lose the possibility of devicetree overlay.. And what's needed to patch CONFIG_OF_OVERLAY and/or the ISP so that they don't mess much with each other needs actually someone who understand what happens there.. :lol:

Link to comment
Share on other sites

Hi @TonyMac32, @ayufan, @chwe

 

Looking at the download page https://www.armbian.com/tinkerboard/ and the text there, is this still correct (UART and such) ?

 

Available downloads https://dl.armbian.com/tinkerboard/  :

Ubuntu Xenial legacy kernel 4.4.y

 

Debian Stretch desktop legacy kernel 4.4.y
Debian Stretch desktop mainline kernel 4.14.y
Debian Stretch mainline kernel 4.14.y

 



What about changes with regard to the discussion on this thread, One (BSP) Kernel f RK3399/RK3328 and RK3288 -> https://forum.armbian.com/topic/7661-one-bsp-kernel-f-rk3399rk3328-and-rk3288/

 

Are the images ready for a fresh test run?
Would I have to switch to BETA?

 


== Testing - Multimedia ==
HDMI - HD-Ready, Full-HD, 1280x1024
Audio Jack out
DSI-connection
CSI-connection


== RK3288 MEDIA TESTING SCRIPT - https://forum.armbian.com/topic/7262-rk3288-media-testing-script/ 

does it work with Chrome on YouTube
MPV, Gstreamer and Kodi 18.0 alpha preview

 

== Testing - Connectivity ==
802.11 b/g/n Wi-Fi
Bluetooth 4.0 + EDR

 


What else needs testing ?

 

Link to comment
Share on other sites

As I only really handle the RK3288 stuff, I was seeing what the agreement of others was.  But, as both topics (as @tkaiser pointed out) died, I'll pose questions:

 

kernel 4.4:

 

@ayufan I don't see any problem with rebasing for releases.  Do you see any issue with having patches for the MiQi/Tinker Board involved?  In any case I could simply hold those locally to the Armbian build script.

 

 

kernel 4.14+: 

 

I see no reason we couldn't have all mainlines lumped together on Rockchip, I've been careful to avoid cross-contamination on my side

Link to comment
Share on other sites

1 minute ago, Igor said:

And we could just bump all to 4.17.y at this point?

We could, but 4.14 is working nicely, we could wait until we get the next LTS to switch Next, since that should happen in a few months, giving us some time to prepare and consolidate if necessary..  We could try to work to get everything staged for that. 

 

We also need to decide (meaning I'm not just going to do random stuff) on moving the HDMI-hotplug scripts provided by @botfap to the generic section, as the same script is currently servicing at least 3 families (XU4, Rockchip, Meson64), and is "hiding" in the Rockchip bsp folder.

Link to comment
Share on other sites

Generic questions (ignoring the existence of ayufans excellent work for a moment):

 

Whats missing or non optimal on mainline for RK? Why are we pegged at 4.14? (lts?)

 

Are you holding different patch sets for each SoC or each board? For both mainline and BSP

 

Is there really a need for SoC / board specific patch sets for modern RK kit? Can it not be dealt with in a single code base with different config or compile time options?

Link to comment
Share on other sites

Hi @TonyMac32

 

The HDMI script is very generic, I created it to handle most use cases for display output and is not SoC specific. I have an extended version that also covers LVDS and VGA output devices if you wanted to include a more generic version to cover all possible displays and SoC's for a generic Armbian script.

 

Im working with some students, teaching (and creating) an embedded systems course for my local tech college till the end of the year. We are using Tinkers and some RK3399 dev boards that I managed to pick up very cheaply. I have built them a minimalist OS (glibc, busybox, weston/wayland, gtk3: ~56MB image size, not debian/ubuntu based) to get started with and their project is to create working kernel images, bug fix, add features and build a simple cloud management solution. My next step was to get them to examine Armbian's kernels to use as a starting point, compare to RK-BSP and mainline and figure out how to package it in a single code base to work across multiple RK boards and generic armhf / aarch64 qemu targets. So I have 3 unskilled but willing students I can point to help on this if you like.

Link to comment
Share on other sites

6 minutes ago, botfap said:

Is there really a need for SoC / board specific patch sets for modern RK kit? Can it not be dealt with in a single code base with different config or compile time options?

That's the question we're working on.  I think we can handle all from one codebase, at least as long as there aren't too many Tinker Reboot workarounds on other boards (I have that "contained" so it doesn't break anything)

 

From kernel to kernel the MAli drivers need tweaking, and while @Myy does excellent work with this, I thought it easier to keep Next on an an LTS kernel, then if people want bleeding edge they can compile a Dev image.

 

Also, welcome back!

Link to comment
Share on other sites

The principal major feature not implemented in mainline kernels is the VPU driver. I'll try to give H264 decoding on mainline kernels a shot today.

 

Still, there's  a few bugs here and there in the mainline kernels that impact various RK3288 boards, notably USB hotplug, HDMI audio and MMC detection on some systems.

There's also some minor warnings regarding framebuffer initialization with some screens that a bug reporter named samsonluk is trying to pinpoint.

Link to comment
Share on other sites

If you get VPU working on RK3288 this will be a crazy SBC year, since Amlogic video code is being reviewed, Allwinner is working, etc.  This USB hotplug issue, I saw it on Amlogic, but I didn't see it on Rockchip.  I did miss a few weeks though 4.17.7 or so I think it "disappeared" from being a problem on Amlogic.

Link to comment
Share on other sites

On 8/5/2018 at 1:58 AM, Myy said:

The principal major feature not implemented in mainline kernels is the VPU driver. I'll try to give H264 decoding on mainline kernels a shot today.

I think their ISP driver is also only partly mainlined. Well, it has also issues with the 4.4 kernel (https://github.com/rockchip-linux/kernel/issues/98#issuecomment-396422765), seems that it doesn't like CONFIG_OF_OVERLAY for whatever reason....

 

@botfap cool project, I would have loved to see such courses back then... But instead we had to learn R.. :lol: Learning R with limited statistics experience was just...

 

seems to be consensus that:

  • default should be @ayufans 4.4 kernel 
  • next 4.14 (and hopefully the next LTS by end of the year)
  • dev 4.17/18 for the cowboys (& cowgirls) being able to deal with bloody edge kernels. 

proposed patch structure:

Rockchip (for everything which doesn't have conflict to other SoCs)
|_RK3288
| |_MIQI
| |_Tinker
|
|_RK3328
| |_Rock64
| |_Renegade
|
|_RK3399
  |_all those new shiny boards.. :D 

Cause @TonyMac32 does most of the work on behalf of armbian in those days for RK boards I suggest, that you've a veto in case you're not happy with it. I think patches should be whenever possible in the Rockchip patchfolder and only when they're in conflict with each other in the rk3288 or boardspecific patchfolders. 

 

For the RK3328 & RK3399 boards. How well are they supported by 4.14? In case not that well we might not provide next images until we get a new LTS kernel, this should give us some time to work on the dev kernel so that we can provide a next image as soon as the next LTS kernel shows up. 

Link to comment
Share on other sites

On 8/7/2018 at 4:45 AM, chwe said:

proposed patch structure:

 

I'd suggest keep the rk-armv7a's as one... both the little and big cores - the intrinsics are well understood, and most are mainline these days...

 

Upcoming stuff - the 3328 and 3399 are all armv8, and 3399 is big.LITTLE, so there's a fair amount of concern there - but the little cores generally need to match big cores there for features...

 

Should be impressive performers across the board....

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines