0
chwe

One (bsp) Kernel f RK3399/RK3328 and RK3288

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

Share this post


Link to post
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

Share this post


Link to post
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... 

Share this post


Link to post
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.

Share this post


Link to post
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.

Share this post


Link to post
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)

Share this post


Link to post
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:

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
0