Armbian v21.02

[Igor 2293]

Release planning: January 2nd. Meeting location is IRC channel #armbian on freenode. Meeting starts at 2pm GMT.

 

Open topics / development directions:

- desktop branch merge into the master

- enabling 3D support on desktop(s)

- update u-boot (where possible) to 2020.10 and K5.10.y

Spoiler

My test farm is updated to 2020.10 / 5.10.y

Cubieboard
Cubietruck
Cubox i2eX/i4 (old u-boot)
Le potato
Lime 2
NanoPi K2 (NIC not working)
NanoPi M4
NanoPi M4V2
NanoPi Neo 3
Nanopi R2S
Odroid C1
Odroid C2
Odroid C4
Orange Pi Lite
Orange Pi Lite 2
Orange Pi One+
Orange Pi R1
Orange Pi Win
Orange Pi Zero
Orange Pi Zero2 (private u-boot / WIP target)
Orange Pi Zero Plus
Orange Pi Zero Plus 2
Pine H64
Rockpi 4B
RockPro 64
Tinkerboard (u-boot stays behind)
ZeroPi

 

- ZSH setting to default or optimise 1st run choosing

- moving blob section (except build packages) to newly created structure inside "desktop" branch (need to discuss best way / adjust framework if needed and set rules!)

- and Jira bugs / features we chose to deal with by then

 

There are reports about some broken images on Rockchip legacy, K5.9.y is EOL so there is an option to squeeze another bugfix update with focus on u-boot / kernel update + image refreshing. Anything that is outside of my test rig - I have no idea about the statue - except well known NIC troubles with Orangepi 3.

 

@Myy @TonyMac32 @balbes150 @piter75 @sfx2000 @ebin-dev @Heisath @chwe @ning @lanefu @gprovost @aprayoga @5kft @JMCC @martinayotte @going @jeanrhum @dolphs @jock @belfastraven @TRS-80 @Bozza @Rich Neese @sgjava

[sfx2000 100]

Just curious as to why proposing to change the default shell from bash to zsh?

 

u-boot updates - agree/concur where applicable.

 

Desktop vs Master/Mainline merge - depends on 3D support (I'd recommend not by default), and blob-space - this seems to be the bigger topic...

 

 

 

 

[lanefu 343]

Re opi3.  Are you able to test this branch on your farm and see if it breaks anything?  5k added some fixes..  i guess i need to just grep around for that chipset 

 

https://github.com/armbian/build/pull/2473#issuecomment-746744252

 

Re 3d support.  Should probably limit that to rk3399 stuff.   

 

However we should definitely replace the NOGPU Xconfig we ship with aml and rockchip to use modsetting driver instead of fbdev.   Leave acceleration at none 

[Igor 2293]

7 hours ago, sfx2000 said:

Just curious as to why proposing to change the default shell from bash to zsh?

 

Why not let people have the best shell OOB? "It will spoil you rotten. Its features are so much more powerful than Bash, you'll never be happy with Bash ever again.". I manage to tweak it that it works fast also on slowest machine. Its my daily driver - I can trade anything, just not ZSH.

 

7 hours ago, sfx2000 said:

u-boot updates - agree/concur where applicable.

Mainly its done. And we don't need to deal with exotics that doesn't wanna go up.

 

7 hours ago, sfx2000 said:

Desktop vs Master/Mainline merge - depends on 3D support

3D support is optional in any case. "Desktop" is perhaps not most appropriate way of this branch since its core is structural changes to support more desktops. Package configurations is modular, so there are big changes. Sadly documentation is not fully ready which means its hard for anyone - also for me - to jump on new features at this moment. Anyway learning how things are now and overall stability - after merge - is key priority. Then using new features.

 

7 hours ago, sfx2000 said:

and blob-space - this seems to be the bigger topic...

 

and dealing with this.

 

7 hours ago, lanefu said:

Re opi3.  Are you able to test this branch on your farm and see if it breaks anything?  5k added some fixes..  i guess i need to just grep around for that chipset 

OK, I'll.

 

7 hours ago, lanefu said:

Re 3d support.  Should probably limit that to rk3399 stuff.   

Others not stable enough? Allwinner?

 

7 hours ago, lanefu said:

Leave acceleration at none 

But have to inform users how to enable it and experiment with this somehow.

[sfx2000 100]

16 hours ago, Igor said:

Why not let people have the best shell OOB? "It will spoil you rotten. Its features are so much more powerful than Bash, you'll never be happy with Bash ever again.". I manage to tweak it that it works fast also on slowest machine. Its my daily driver - I can trade anything, just not ZSH.

 

"best" is subjective - yes zsh is nice, and now the default shell even on MacOS BigSur.

 

I'm a bit old-school - bash is good enough for me, I know it's quirks, and zsh (or others) is always an option post first-boot.

 

On my other efforts - I'm still dealing with busybox (and that is ash.c)...

[belfastraven 7]

@Igor,  I am happy to help with documentation--I have been playing with the desktop branch (I'm now running hirsute with gnome on wayland on my pinebook pro--which I doubt you will be recommending to users, (but  have tried various other combinations).   I still don't understand whether this desktop/package flexibility is just for builders or will in someway available to people who would normally be downloading just images, or perhaps assembling pre-built images using native builds?   Anyway,  I am volunteering documentation assistance...

[Igor 2293]

4 hours ago, belfastraven said:

I am happy to help with documentation-

Technical part of the documentation should be done by @Myy - next year  Plan is to do around the merge time. Once we have things in the main branch, people will probable start asking about. Currently we have only code commenting and a small start here https://github.com/armbian/documentation/pull/98/files

 

4 hours ago, belfastraven said:

I'm now running hirsute with gnome on wayland on my pinebook pro--which I doubt you will be recommending to users

I am glad that its possible to build such combination. And on top of that it works  Its too early to recommend anything beside XFCE for now. Our focus was to turn things upside down while trying not to break anything. I am sure some problems exists and current focus is to find and fix possible bugs we added to basic functions. I hope none, but only broad usage will tell ...

 

4 hours ago, belfastraven said:

 I still don't understand whether this desktop/package flexibility is just for builders or will in someway available to people who would normally be downloading just images, or perhaps assembling pre-built images using native builds?

Both. We had to redesign it otherwise we would suffer when tweaking and adding some desktop. Now it should be easier for us but end users can easily build their own desktop - with this and that set of applications. We will not build all combinations, but only add 1-2 full desktop variants. 

 

4 hours ago, belfastraven said:

Anyway,  I am volunteering documentation assistance...

Experiences and exploration of possibility  and changes from before? This could be as a reminder or a base, a help for creating a documentation. I am not the author of this change and for the past month I had to do other stuff. @Rich Neese is tweaking desktop look, shaffle packages around, otherwise development is done. We made what was planned before merge except cleaning and documentation.

[piter75 120]

Unfortunately I will not be able to attend the meeting today

 

My plans outline for rockchip64 in v21.02 is:

• u-boot v2020.10 in rockchip64 (it still needs a few tweaks/tests)
• switching rockchip64's current to LK5.10.y (it is already in dev)
• enabling SPI boot for a few more rk3399 boards (where it makes sense) and polishing the install process

[Werner 402]

Agenda, mostly generic from last meeting:

 

• check meeting attendees (if nick is not self explanatory, add your forum/Github handle. Just say hi or something)
• present tasks, bugs or project you are working on (open discussion if there will not be much people, otherwise meeting officer call people out). Jira should be open in not already.
• cycle Jira backlog:
• discuss task / bug (one at a time)
• assign to person / release / tag
• re-prioritise
• cycle open issues and PR on build engine
• board status update on download pages and build engine (wip, supported, eol)
• choosing upcoming release officer (so far it was Igor and Lane)
• misc / open discussion

[JMCC 340]

Darn it, I totally missed the meeting. Christmas season is so hectic, I didn't even notice. @Werner Is the log available somewhere?

[Igor 2293]

We had some troubles with the usual tool, but backup is this:

https://freenode.irclog.whitequark.org/armbian/2021-01-02

[Werner 402]

6 hours ago, Igor said:

We had some troubles with the usual tool

Yeah. no fancy output this time

[JMCC 340]

5 hours ago, Werner said:

no fancy output this time

It's OK,  the chat log works. I really wanted to be there, but for some reason I had in my mind it was later in the month.

 

Even though late, here is an update about my work, and what I can contribute after seeing the chat log:

• Right now, I am brushing up the last fixes to RK legacy multimedia. Only the camera fix for RK3399 is missing, and it should be done.
• After that, I need to document the XU4 multimedia framework, which is also there already, and equal or more interesting than RK. 
• When I finish with it, I would like to focus on mainline desktop/multimedia. I have done some experiments already with X11 3D acceleration, so I guess I could help with that.

Besides that, there are a few other points I think I could implement easily, and would be useful:

• Adding some help pages to armbian-config. Docs are there already, it would be a matter of making them appear in the script. I will explain this more in detail in some other post.
• Some fixes to XU4 boot. I can further explain this somewhere else too.

And for last, I have a couple questions too:

• Regarding the CSC boards available in the build script, there are some that we offer images to download, and some others that we don't. It would be nice to clarify what is the criteria about that. Even if it is just "we offer CSC downloads for a board if someone cares enough to ask for the image to be there", or something alike.
• Not every board supporting overlays has the "Hardware" option in armbian-config (e.g. nanopc-t4 legacy doesn't). Is that supposed to be so for a reason, or it is a bug?

 

 

[Igor 2293]

38 minutes ago, JMCC said:

Regarding the CSC boards available in the build script, there are some that we offer images to download, and some others that we don't. It would be nice to clarify what is the criteria about that. Even if it is just "we offer CSC downloads for a board if someone cares enough to ask for the image to be there", or something alike.

There is no policy for this. I guess until we don't have any constraint with build / download resources we don't need to worry about. Perhaps we can limit the selection of available images for those? Or just don't do nothing at all and remove them first once space becomes an issue?

 

40 minutes ago, JMCC said:

Not every board supporting overlays has the "Hardware" option in armbian-config (e.g. nanopc-t4 legacy doesn't). Is that supposed to be so for a reason, or it is a bug?

If overlay directory exists, option hardware is show, but if you choose it, it should be empty

https://github.com/armbian/config/blob/master/debian-config-submenu#L74-L75
https://github.com/armbian/config/blob/master/debian-config-jobs#L1162-L1185

 

Thank you for update!

[piter75 120]

11 hours ago, JMCC said:

Not every board supporting overlays has the "Hardware" option in armbian-config (e.g. nanopc-t4 legacy doesn't). Is that supposed to be so for a reason, or it is a bug?

@JMCC This should do the trick to fix it for boards in rk3399 family:

https://github.com/armbian/config/pull/134/files

[JMCC 340]

BTW, anybody stepped it as a maintainer for the Pinebook Pro? It seems to be out of stock since some months ago, so it may be hard even to get a unit.

[Werner 402]

I think @lanefu was THE man who maintained it a bit since he had the luck to have such a device. I dont think we found somebody for the job yet which is quite a bummer for such a nice device...

[lanefu 343]

1 minute ago, Werner said:

I think @lanefu was THE man who maintained it a bit since he had the luck to have such a device. I dont think we found somebody for the job yet which is quite a bummer for such a nice device...

I'll continue to help with PBP..   As you all are familiar my work usually comes in bursts..  But yeah i'd like to build kind of a specific community up for it.. almost wonder if its worth a subforum under RK3399 or osmething.

I'm getting a PBP bare motherboard that i can use for the bare metal testing of liek uboot etc... and @Rich Neesehas a PBP coming in the mail

 

[Igor 2293]

Proposed action plan:

 

1. Fixing open Jiras that can be fixed in short time

2. Releasing 21.02 by the end of the week - or next week ( build is relaitively stabilised https://users.armbian.com/igorp/2021-02-01_00.15.07.html )

3. Merging desktop by the same time, keeping 21.02 branch supported for a longer time / volunteer needed

4. Focus into solving build bugs, helping on desktop documentation

Comments / suggestion?

[lanefu 343]

Yep I like the idea of keeping the branch supported...  Glad to help cherry-pick fixes etc as needed etc

[Igor 2293]

Before we move to 

I am proposing another small bugfix 21.02.3 update:

 

- reboot troubles on meson64 family / fixed (all images need to be rebuilt)

- allwinner a20 fail to init hdmi in many cases / fixed (all images need to be rebuilt)

- zsh upgrade disable zsh / fixed

I am fixing small troubles on the way, test report: https://users.armbian.com/igorp/2021-03-07_20.39.37.html @gprovostHow is stability with Helios64 with a u-boot / kernel combo build from the trunk? Others are more or less covered. Can't be worse than what we have now ...

[gprovost 156]

2 hours ago, Igor said:

I am proposing another small bugfix 21.02.3 update

 

Yes I agreed, there was the PR from @aprayoga that we would like to see deployed before the v21.05 comes. Hopefully it solves most of instability issue for all Helios64 board. I have tested latest from nightly repo (trunk.40) and it works. @aprayoga Can you please confirm also on your side that all good for a new 21.02.3 build.

[piter75 120]

2 hours ago, Igor said:

I am proposing another small bugfix 21.02.3 update

Great. Will it cover all the boards?

If not please add NanoPi M4V2 images to the build. It also contains a long overdue stability issue fixed in current and dev.

[Igor 2293]

1 minute ago, piter75 said:

Great. Will it cover all the boards?

So far its planned to rebuild them all. Building one or all its pretty much the same trouble  

[SteeMan 104]

5 hours ago, Igor said:

reboot troubles on meson64 family / fixed (all images need to be rebuilt)

Igor, could you point me to a description and/or the fix for this issue?  This is an issue that I am having with meson64 based TV boxes and it has also been reported by others in the TV Box club.  I want to see if this fix addresses the issues we have been seeing - or if we have a different issue.

[Igor 2293]

5 minutes ago, SteeMan said:

Igor, could you point me to a description and/or the fix for this issue?  This is an issue that I am having with meson64 based TV boxes and it has also been reported by others in the TV Box club.  I want to see if this fix addresses the issues we have been seeing - or if we have a different issue.

I am still in the dark ... 

- most recent u-boot for some https://github.com/armbian/build/blob/master/config/sources/families/meson-gxbb.conf#L6
- and reverting "fix" https://github.com/armbian/build/commit/b355a3110907be526028531a402955482b2af926

fixes C2, N2, C4, HC4, Lepoto, doesn't fix on K2 S905.

[Igor 2293]

In case I forgot to mention something important https://github.com/armbian/documentation/commit/99875c73cdcdfd82ddbf58c3929b8cef5be0d4a6