Armbian v20.05 (Kagu) Planning Thread

[lanefu]

This is to discuss and prioritize enhancements and bugfixes we want to target for v20.05 (Kagu).  We will lock this thread 2020-03-15 to manage scope creep.

 

Many items are currently in Jira here https://armbian.atlassian.net/projects/AR/issues/?filter=allopenissues If you're a frequent contributor and would like to join our Jira, please PM me.   It's not mandatory, but it would make things easier. To track.

 

Remember the Armbian Mission Statement:   Armbian is a base operating system platform for single board computers that other projects can trust to build upon.   Let's try to prioritize things that help us deliver on that mission

 

 

[Igor]

Our next release date is coming and perhaps its time to discuss what to push into 20.05, what not, resolve open questions and distract from most used keyword for past few weeks.

 

@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @count-doku @chwe @ning @lanefu @gprovost @aprayoga @5kft

@JMCC @Werner @karabek @martinayotte @tkaiser @selfbg @Siraj ... to name just a few which might find this move useful  

 

I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

As my example -  what I am currently working and IMHO could be implemented by 20.05:

 

- setting up auto test facility, software and hardware which is a great support tool for making releases. It is already helping me finding bugs.

- merging mainstream kernel config in the non-hardware areas could go into this release

- firmware split up with @ning

 

... more Jira's during a week.

 

Ideally it would be that prior to this meeting you write into Jira what you are working and join discussion about your task/project/idea with a link - who does not have access shall PM to @lanefu or @Igor - reviewing and prioritising goes faster and better with Jira.

 

Welcome!

[ning]

for split firmware, I can do rk3399, and amlogic. but still need other maintainer's help.

[sfx2000]

10 hours ago, Igor said:

I am preparing a meeting on IRC in Saturday at 1 pm GMT - this is reasonable good timing for US / EU folks. The idea behind this meeting is that (ideally) everyone, who will be present, quickly present (in alphabetical nick order) what they are working (not working on anything is equally legit) on followed by a discussion. If a feature, project or a fix can be pushed into this release. Plus answer and decide on other open questions. You are welcome to expand this with a PR/change document directly. This way we could - on a long run - improve all project parameters.

 

I can host a Zoom Telecon - let's say 8AM PDT on 4/4 - I have a 100 seat license, so happy to share

 

(note, this does not mean corporate sponsorship - I'm involved with Armbian on a personal/individual contributor level.)

 

Let me know, and I can set it up.

 

tim

[gprovost]

Actually would have been nice to open an Armbian Slack (Nonprofits) Workspace since it's free and interacts very well with Jira.

 

@sfx2000 It's a cool suggestion and nice of you, but I personally think that it will be more efficient to use IRC / Slack to perform such discussion. The chat history log will be useful to clarify anything if needed later on... with audio too many info get redirect to /dev/null

[Igor]

6 hours ago, ning said:

for split firmware, I can do rk3399, and amlogic. but still need other maintainer's help.

Perhaps we need one example how this is planned and others can follow this? I am not sure everyone noticed this and even I was confused how this should be done.

 

@sfx2000 @gprovost I would like not to deal with more gadgets at this point. We added Jira several months ago and we haven't manage to use much of its powers. IRC is nothing fancy, but its good enough. We have a channel recorder, no need to deal with any subscriptions and/or legal stuff. It works. Consider that many folks are old school or geeky, where IRC is the thing and already a Skype represent a far end of comm tools  

Anyway, my concerns goes to the meeting content. To come up with an agenda that will help us bring up, put attention to common problems and to spark our comm channel regardless of technology behind this. For the future, if majority decide we need to upgrade to something from this century , I will follow.

[Myy]

So Saturday 4th April on IRC then ?

 

For chat services, I tried setting up a Synapse Matrix chat system using Docker these last days... It works, as long as you disable the whole "federation" thing, since the server will go down if anybody reaches a federated crowded room...

That said, Matrix+Riot offers web conferencing with chat services, file exchange, Android chat app, ...

I still have to test Rocket.chat though, which might be better for that task (no configuration hassles, it seems).

[Werner]

I started playing with slack.

Though I have my doubts to get everybody over there for quite a bunch of reasons. Last but not least we put effort in finally setting up irc for armbian and this would more or less throw it away.

Also there would be a new thing that needs attention to maintain, regardless of matrix, slack, riot, skype or whatever.

 

Also funny: Switched the language from German to English and still see some German elements that cannot be adjusted by the user

 

 

[gprovost]

 Ok let's stick to IRC, then you need to post the info here how to connect.

 

17 minutes ago, Igor said:

Anyway, my concerns goes to the meeting content.

 

Would it make sense to go through each issues one by one (backlog + the ones we are supposed to fill up by the end of this week) and see if it goes or not into releases 20.05 ? You and Lanefu will make the first call if yes or no it goes in 20.05 and if anyone object it should voice out and explain why we should or not make part of 20.05.

 

Then for the issue you need to figure out who he's in charge of the issue ? Hopefully someone is already in charge or you need to call someone to take charge of the issue.

 

Then at the end you sum-up for each contributor their list of issues they need to take care off and see if any red flag (e.g someone seems to have too many issue to resolve for its available bandwidth).

 

Just some suggestions on how you guys should drive the chat, you don't want everyone to talk at the same time. Beside you and lanefu, we should be in listen mode and only interact when necessary or asked.

[Werner]

1 minute ago, gprovost said:

 then you need to post the info here how to connect.

 

[Igor]

1 hour ago, Myy said:

So Saturday 4th April on IRC then ?

Yes, at 1 pm GMT which translates to 3 pm local time for most of EU based folks. 

 

45 minutes ago, gprovost said:

Would it make sense to go through each issues one by one (backlog + the ones we are supposed to fill up by the end of this week) and see if it goes or not into releases 20.05

I leave this open for each of you. Add, change, comment, be natural and reasonable - some tasks are good, some bad, some are pointless, some need more attention, some can't be done.

 

Also important is to fill in and close (major only) tasks that has been done after release of 20.02. since otherwise it might slip out from the release documentation. Simply open a new Jira Task or bug, add a tittle and optionally a link to forum topic or Github commit / issue / MR tag with 20.05 and set it to "Done".

 

45 minutes ago, gprovost said:

Then for the issue you need to figure out who he's in charge of the issue ? Hopefully someone is already in charge or you need to call someone to take charge of the issue.

I would propose to self assign, the rest we will do in the meeting by asking people out. Anyway we usually know who is working what, but keeping track at once place is generally good and also for those that are not here every day. Assigning is not obligatory to finish the task. If you can't, speak out, perhaps someone else can take over and / or simply change its status from "In-progress" back to "To-do". https://armbian.atlassian.net/browse/AR-71

 

45 minutes ago, gprovost said:

Then at the end you sum-up for each contributor their list of issues they need to take care off and see if any red flag (e.g someone seems to have too many issue to resolve for its available bandwidth).

Yes. The idea is to lower the load. I am sure sometimes we start to work on a task that is sadly too big for us and frustration kicks in. If nothing worse. This will also give us some overview what kind of help we actually need.

 

45 minutes ago, gprovost said:

we should be in listen mode and only interact when necessary or asked.

 

https://github.com/armbian/documentation/commit/9ea6bcf7c77db18aeaebdfed10fce301388d1a88

[chwe]

just a short one.. and I didn't read all of it.. working on:

• rk3399 to 5.6 (more or less done with: https://github.com/armbian/build/pull/1759 but testing needed especially for everything except pbp)
• display of pinebook pro working with mainline kernel - same PR
• camera working on 4.4 for pinebook - not even started yet
• I would love to merge rk3399 and rockchip64 bsp kernels to keep maintenance easier there - let's see if we get the mali mess sorted out there
• rk1808 into wip - the boards are there.. but time is missing and kernel source will be a pain
• maybe further cleaning of opi 4b DT

[martinayotte]

On my side, I'm planning to commit my work for Allwinner 5.6.y, since it now without RCs ...

[dolphs]

Wow - Would love to see my H6 and H5 boards performing with this new dev build,

due to mainlining efforts code being merged in 5.6 as well official kernel support for wg.

 

Oh yea H6 orange pi one plus now runs on 1.8 again or similar "hack" needed as back then for neo2 v1.1 to " overclock " while 1,5 is default ( 1 GHz on h5 if I remember correctly )

 

BTW I found something strange on 28 March update ( neo2 ):

 

/var/log.hdd/apt/term.log {
  rotate 12
  monthly
  compress
  missingok
  notifempty
}
/var/log.hdd/apt/history.log {
  rotate 12
  monthly
  compress
  missingok
  notifempty
}
 

Where is this coming from in the armbianEnv.txt OR my podgies #fingers ?

 

[Tido]

8 hours ago, Werner said:

to get everybody over there

I don't know if this is still this way, but I have heard that the free-account on Slack is collecting up until 10'000 messages. Then every addititonal message will delete the oldest.

 

[Werner]

5 minutes ago, Tido said:

I don't know if this is still this way, but I have heard that the free-account on Slack is collecting up until 10'000 messages. Then every addititonal message will delete the oldest.

 

It is unless you pay for it.

 

[Igor]

2 hours ago, dolphs said:

Wow - Would love to see my H6 and H5 boards performing with this new dev build,

due to mainlining efforts code being merged in 5.6 as well official kernel support for wg.

 

My auto test facility shows 1.8Ghz for Opi3 and One+, others are not hooked up due to lack of RJ45 so I don't know without looking to the code or test.

 

IHMO for Nanopi Neo we should not change defaults. We have overlays.

 

WG < 5.6 is maintained separately and also present in all versions of Armbian. But currently there are some problems. I believe DKMS should fix that and if not, this could be also a bug needs to be solved before 20.05. We fixed headers and sources.

 

2 hours ago, dolphs said:

Where is this coming from in the armbianEnv.txt OR my podgies #fingers ?

 

Changes to scripting comes with a board support package, ex. linux-root-buster-current-orangepi3.deb

 

5 hours ago, chwe said:

would love to merge rk3399 and rockchip64 bsp kernels to keep maintenance easier there - let's see if we get the mali mess sorted out there

Do we know what will this merge drag with?

[chwe]

21 minutes ago, Igor said:

Do we know what will this merge drag with?

I don't think so.. e.g. to reduce fall out we could first let both use the same kernelsoruces... then patch them until they're even and finally merge but either ditch ayufans or friendlies kernel.. one part which will mess is likely mali drivers but @JMCC knows more about that for sure..

 

ah and before we forget..  rk3399 boards going upstream u-boot one or the other way would also be nice..

[JMCC]

4 hours ago, chwe said:

one part which will mess is likely mali drivers

Not if we put all RK3399 boards in rk3399, and all RK3328 in rockchip64. In that case, we could just keep our current kernel config and that would work.

[Igor]

21 hours ago, martinayotte said:

On my side, I'm planning to commit my work for Allwinner 5.6.y, since it now without RCs ...

 

- 5.6.1 has been branched

- i am about to sort out 8189ES and FS to be ready and remove existing patches in this PR https://github.com/armbian/build/pull/1860

 

12 hours ago, JMCC said:

Not if we put all RK3399 boards in rk3399, and all RK3328 in rockchip64.

Legacy kernels only, right?

[JMCC]

6 minutes ago, Igor said:

Legacy kernels only, right?

Well, once a board goes into a family, it shares legacy, current and dev with the others, doesn't it? I don't understand exactly what you mean.

[Igor]

1 minute ago, JMCC said:

Well, once a board goes into a family, it shares legacy, current and dev with the others, doesn't it? I don't understand exactly what you mean.

Not necessarily. Family can be divided only for legacy(rk3399,rk3399-1,rk3399-2) and merged on current/dev (rockchip64).

[JMCC]

Well, if that's the case, then we should probably first try to merge legacy too and "sort out the mali mess" as @chwe said above, and if we are not able to do it, then we can split.

 

Regarding what I have been working on: I was preparing an extension for the build system, in order to build the multimedia packages that are on the media script. It was well advanced, but I stopped it since I am not so sure about the prospective for legacy kernels. The impression I get is that most members are willing to get rid of them and stick with Mainline. So I would like to hear some impressions about it, to see if it is worth integrating that into the build script or not.

[balbes150]

2 hours ago, Igor said:

i am about to sort out 8189ES and FS to be ready and remove existing patches in this

Everything you need for the 8189 ES \ FS on the 5.6 core is ready and tested, in addition, I added a few more modules 8822xS 8192cu\eu\du (but they are not yet tested, I do not have hardware). I wanted to send a PR, but I stopped it for now (you know the reason).

[chwe]

IMO as easy as it is.. as long as we've no proper mainline drivers for the VPU stuff and 4.4 allows us to build debian/ubuntu on top of 4.4 without affecting much. we can stick to it..

 

I assume rockchip will rebase their BSP on something newer in the future (even their most recent SoCs are integrated into 4.4, e.g rk1808 and rk1806) and I don't think they go EOS prior to 4.4 goes EOL. Btw.. all the camera stuff also is a 4.4 only thing at the moment.. and we've a bunch of boards with doublecam ect. now.. for sure something people might get interested in once it works..

 

So I guess the way to go is base rockchip64 and rk3399 on the same BSP kernel (this release), base both on the same patchset (maybe this maybe next) base all on upstream u-boot (next release - rochchip64 is based on the bsp u-boot) and then we can merge it.. I guess by compile the mali stuff as modules we might get around having Utgard (rk3328) and Midgard (rk3399) in the same kernel.. and otherwise.. we may just have 2 slightly different configs whatever works here.. Or prioritize rk3399 over rk3328 in terms of mali support (we clearly see that more boards based on rk3399 are developed for those usecases - but let's call this the nuclear option.. :D)...

 

Just now, JMCC said:

Regarding what I have been working on: I was preparing an extension for the build system, in order to build the multimedia packages that are on the media script.

If you feel motivated - go for it. don't let my rants about 4.4 let yourself demotivate.. :D  In general I would be a fan if the buildscript allows a quick way to produce debs for custom packages. And I'll still play with 4.4 for a while anyway cause display and cameras on rk3399 are untouched till now.. and it's on my list to play with..

 

[Myy]

So the main lacklusters for 5.x kernels are : VPU, Cameras... and NPU maybe ?

 

Nobody was able to test the Hantro VPU code staged into mainline kernels ?

@Kwiboo were you able to test video hardware decoding on mainline kernels with RK3399 boards (using any distro whatsoever) ?

[Kwiboo]

6 minutes ago, Myy said:

were you able to test video hardware decoding on mainline kernels with RK3399 boards (using any distro whatsoever) ?

 

Yes, I have had VPU working on 5.4 kernel since the new year started, my test images from 31 dec / 1 jan at http://kwiboo.libreelec.tv/test/ should "work", at least for MPEG-2, H264 and VP8 codecs on RK3288, RK3328 and RK3399.

The VPU patchset used in LibreELEC has not been touched/rebased for 5.5/5.6 yet, but I am hoping to get some time to work on that later this weekend and next week.

[Myy]

5 minutes ago, Kwiboo said:

 

Yes, I have had VPU working on 5.4 kernel since the new year started, my test images from 31 dec / 1 jan at http://kwiboo.libreelec.tv/test/ should "work", at least for MPEG-2, H264 and VP8 codecs on RK3288, RK3328 and RK3399.

The VPU patchset used in LibreELEC has not been touched/rebased for 5.5/5.6 yet, but I am hoping to get some time to work on that later this weekend and next week.

Alright.

Still the same version of FFMPEG ? I remember that some of your patches were integrated by the FFMPEG team, but I don't know if they were all integrated.

I tried brezillion version of FFMPEG, since he played with FFMPEG and the VPU too, but he got that too many branches on his git, and the rare ones I tested still had a few issues here and there.

[Kwiboo]

3 minutes ago, Myy said:

Still the same version of FFMPEG ?

 

I have not synced any possible update from @jernej or the Raspberry Pi team yet, the latest ffmpeg that works with the cedrus/hantro patches we use in LibreELEC is located at https://github.com/Kwiboo/FFmpeg/commits/v4l2-request-hwaccel-4.2.2

That version is still not compatible with the rkvdec driver targeted for 5.7 due to incompatible use of flags, I will update the ffmpeg code to work with both hantro and rkvdec when I rebase my patches for 5.6.

The main diff between upstream hantro and the patches we use in LibreELEC is support for field encoded (interlaced) H264.

 

The ffmpeg v4l2 request api hwaccel is not yet upstreamed and the main reason is that it depends on private kernel headers not yet part of the uapi.

[Myy]

Alright then, I'll see if I can test that this week-end. If we can have some Video acceleration on mainline kernels, with Panfrost kicking in, the only issue left with mainline kernels should be the cameras.