[Task / Story]: Clean up old kernels/kernel patch leftovers

[ColorfulRhino]

Task description

This is part of #6820

The goal is to remove

1. deprecated/unused kernels from the code
2. kernel patch folder of kernels which are not used anymore (just forgotten to delete in the past)

Please add leftovers if you know of any. Feel free to discuss and improve :)
Please correct me if I do wrong assumptions. I am not familiar with all the families.

Remove kernel patch folders of unused kernels:

• rockchip-4.4 [Cleanup] Remove some leftover kernel patch folders #6831
• rockchip-5.10 [Cleanup] Remove some leftover kernel patch folders #6831
• rockchip-5.15 [Cleanup] Remove some leftover kernel patch folders #6831
• rockchip-6.1 [Cleanup] Remove some leftover kernel patch folders #6831
• rockchip64-6.1 [Cleanup] Remove some leftover kernel patch folders #6831
• meson64-5.10 [Cleanup] Remove some leftover kernel patch folders #6831

Remove unused kernels:

• rk322x: [Cleanup] Remove leftovers of former BOARDFAMILY rk322x (now integrated into the rockchip family) #6832
• Abandoned media kernel: Integrate media boards into the rockchip64 family #6834
• Remove OrangepiZero2 heavily outdated legacy kernel #6854
• [Task]: Deprecate rk3588-legacy in favor of rk3588-vendor #6835
• s5p6818 is unmaintained and stuck on ancient Linux 4.14: Purge s5p6818 board family #6869
• rockpi-s: Remove legacy kernel 4.4 support #6879
• mt7623: Bump legacy 4.19 to current 6.6 kernel #6902

[github-actions]

Jira ticket: AR-2392

[rpardini]

Nice initiative. I guess it's time to let those go. (I was personally attached to 5.10 meson64 as it took years for 6.x to reach the same level).

[igorpecovnik]

What's up with s5p6818? It's stuck on ancient Linux 4.14

Yes, unfortunately and u-boot is not build-able anymore. Full remove?

[ColorfulRhino]

Yes, unfortunately and u-boot is not build-able anymore. Full remove?

I was first thinking keeping it is better since this family has no other kernel than legacy. But the family has not seen any meaningful activity in 4 years and there are only 4 boards using this family (all NanoPi/NanoPC), without any maintainer.

So after seeing this information, I vote for dropping. especially if it doesn't even build.

I guess in that case we remove the boards as well? They're all just 9 lines of code, nothing worth keeping even in case someone wants to bring this back with an update.

Edit: Also there's mt7623 which has only legacy 4.19 kernel (no current or edge) and is only used for one board without a maintainer. What to do with that?

[ColorfulRhino]

Also I've discovered that the kernel family rockpis (which is only used by 1 board) is still on even more ancient Linux 4.4.
How should we proceed with that one? The board config doesn't even enable legacy so it's just dead code.

As proposed in the forums, it could simply be integrated into rockchip64: https://forum.armbian.com/topic/32916-ideas-on-how-to-make-soc-family-patches-more-manageable/
So the family is fully integrated.

@brentr would you like to do this yourself and move stuff from the family config that is still relevant?

For setting a fixed MAC we have also this btw, maybe it can help:

build/packages/bsp/common/usr/lib/armbian/armbian-common

Line 38 in ffe83ab

set_fixed_mac ()

[brentr]

@ColorfulRhino
I agree that the 4.4 Kernel support for RockPI-S can be removed.
As for "moving stuff", what stuff in particular? Examples of similar situations would help.
Setting different, random MAC addresses on every reboot makes assigning the same IP address to the interface via DHCP very difficult.
For headless IOT devices, assigning them fixed IP addresses ensures that port forwarding rules can always reach them behind NAT routers. Do you know of a cleaner way to assign unchanging MACs to boards that lack dedicated EEPROMs for them?

I don't have access to hardware to test until September. (traveling)
I'd suggest that you remove the Legacy 4.4 kernel support now and I will "move stuff" out of the RockPI-S family in September, after I can test again.

[ColorfulRhino]

@brentr Thanks for your reply!

As for "moving stuff", what stuff in particular? Examples of similar situations would help.

Apologies, I should have been more precise. By integrating the rockpis "family" (rock-s0 family is also a candidate) into rockchip64, all stuff that is specific to the board can be moved to the board config and other stuff that may be beneficial for all rockchip64 devices could be moved into the rockchip64 family config. Things that are a legacy or workarounds from the past and are not needed anymore can be dropped.

Setting different, random MAC addresses on every reboot makes assigning the same IP address to the interface via DHCP very difficult.

The set_fixed_mac() function can be run in armbian_firstrun for specific boards and will assign a fixed mac to all ethernet interfaces if called, via declarative config (Netplan). Wifi interfaces are not yet implemented for this, feel free to tackle that if you like the function :)
This was just meant as a reminder that this functionality is present in Armbian, since we recently updated this function a bit. Of course you can also use the board specific bsp to solve this.

I'd suggest that you remove the Legacy 4.4 kernel support now and I will "move stuff" out of the RockPI-S family in September, after I can test again.

Alright, I'll see what I can do and let the other stuff for you to work on in September 👍

[ColorfulRhino]

There is now only mt7623 left in the list. It has only legacy 4.19 kernel (no current or edge) and is only used for one board without a maintainer. I don't have much insight into this kernel/board though.
What to do with that? Leave it as it is for now? @igorpecovnik

[igorpecovnik]

Leave it as it is for now?

There is an attempt to bump it to mainline but it got stalled:
#4873
@martinl @adeepn

If nothing comes out of pings, IMO, lets remove it. Anyway it can be brought-up if there is some interest.

[adeepn]

Leave it as it is for now?

There is an attempt to bump it to mainline but it got stalled: #4873 @martinl @adeepn

If nothing comes out of pings, IMO, lets remove it. Anyway it can be brought-up if there is some interest.

Oh, I forgot about him. I thought I'd have r2 free for experiments, but it's still busy on the home network and I can't touch it yet. so I'm taking a break. if anything, I'll restore it to csc status later.

p.s. i can try move it to 6.x kernel without testing on real hardware.

[ColorfulRhino]

p.s. i can try move it to 6.x kernel without testing on real hardware.

The hard part is not the bumping itself, but finding and removing every old/leftover stuff in order to keep everything clean and tidy 😄

I've taken #4873 and adapted it to current standards. @adeepn I'll leave the testing to you once you got time. Feel free to improve it to get it working :)

[ColorfulRhino]

This is now done! No 4.x kernels are remaining in the system, everything is at least 5.x 🎉
(5.x I'm coming for you soon™ as well 😈)

Remaining stuff like integrating families into rockchip64 has been split off to other tasks.

Thanks to everyone who helped :)

[rpardini]

Excellent work @ColorfulRhino.