chwe Posted July 7, 2018 Posted July 7, 2018 (edited) 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 ): @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 ) 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 July 7, 2018 by chwe
TonyMac32 Posted July 7, 2018 Posted July 7, 2018 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
chwe Posted July 7, 2018 Author Posted July 7, 2018 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? 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> 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... 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...
TonyMac32 Posted July 8, 2018 Posted July 8, 2018 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. I said commonize, which is quite different.
Igor Posted July 8, 2018 Posted July 8, 2018 What about starting with this: https://apt.armbian.com/pool/main/l/linux-source-4.4.120-default-rockchip/ 1
Igor Posted July 8, 2018 Posted July 8, 2018 6 hours ago, Igor said: What about starting with this: https://apt.armbian.com/pool/main/l/linux-source-4.4.120-default-rockchip/ https://github.com/armbian/build/commit/fab979feeaac093494ca29a17000989d4970483f Tinker sources restored to this. Building works, haven't manage to boot the board yet.
TonyMac32 Posted July 8, 2018 Posted July 8, 2018 OK. I had forgotten the source packages being built, stupid me...
Igor Posted July 8, 2018 Posted July 8, 2018 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.
TonyMac32 Posted July 8, 2018 Posted July 8, 2018 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)
chwe Posted July 8, 2018 Author Posted July 8, 2018 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..
ayufan Posted July 18, 2018 Posted July 18, 2018 I posted this comment: that discribes a little my kernel 1
Tido Posted July 30, 2018 Posted July 30, 2018 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 ?
TonyMac32 Posted August 4, 2018 Posted August 4, 2018 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
Igor Posted August 4, 2018 Posted August 4, 2018 51 minutes ago, TonyMac32 said: kernel 4.4 I tried today once again with https://github.com/rockchip-linux but it doesn't boot. I haven't got a chance to see the logs yet ... Damn 4.4.y 53 minutes ago, TonyMac32 said: kernel 4.14+: And we could just bump all to 4.17.y at this point?
TonyMac32 Posted August 4, 2018 Posted August 4, 2018 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.
botfap Posted August 4, 2018 Posted August 4, 2018 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?
botfap Posted August 4, 2018 Posted August 4, 2018 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. 1
TonyMac32 Posted August 4, 2018 Posted August 4, 2018 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! 2
Myy Posted August 4, 2018 Posted August 4, 2018 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.
TonyMac32 Posted August 5, 2018 Posted August 5, 2018 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.
TonyMac32 Posted August 5, 2018 Posted August 5, 2018 OK, verified hotplug issue on Rockchip when building a 4.18-rc. Also verified there are a seemingly random assortment of other bugs.
chwe Posted August 7, 2018 Author Posted August 7, 2018 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.. 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.
TonyMac32 Posted August 7, 2018 Posted August 7, 2018 2 hours ago, chwe said: In case not that well we might not provide next images until we get a new LTS kernel That would be my recommendation.
sfx2000 Posted September 22, 2018 Posted September 22, 2018 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....
Recommended Posts