sunxi-6.11 Switch EDGE to v6.11

[The-going]

Description

• Add megous patches
• Add a series of Armbian patches
• Switch edge to v6.11
• Fix compilation error incompatible pointer type
• xradio: exclude driver if kernel version >= 6.11

How Has This Been Tested?

• Test build for arm. Work on bananapi-m3 board.
• Test build for arm64. Work on bananapi-m64 board.

[The-going]

@igorpecovnik "xradio" is out of my area of interest and out of a series of patches, so I just turned it off.

I had the idea to split the Armbian patches into two or more series.
Select overlay patches and patches for h6, h616, h618 processors in separate folders.
What is your opinion?

[igorpecovnik]

"xradio" is out of my area of interest and out of a series of patches, so I just turned it off.

Understand. We will need to deal with this sooner or later, but IMO it can wait in this state for another 6 months easily.

Select overlay patches and patches for h6, h616, h618 processors in separate folders.

@Tonymac32 @paolosabatino perhaps you have any ideas here?

Otherwise I think - if this way helps you, go for it.

[The-going]

Otherwise I think - if this way helps you, go for it.

This will most likely help other developers to add patches correctly, I hope.
When migrating from 6.7, I came across a number of duplicate nodes in the DTS.
This is almost impossible to control during the pull request process.

[paolosabatino]

@igorpecovnik sorry but I have no clever suggestion for that kind of issue, perhaps ex-novo overlays can be put in overlay directory as regular .dtso files and not in patch form and leverage the automatic copy/patching system? (see, for example, https://github.com/armbian/build/tree/main/patch/kernel/archive/rockchip64-6.11/overlay)

Those overlays files usually never go in mainline kernel and so should not require to be rebased upon mainline at source level, hence there is no advantage on keeping them as patches

[The-going]

Those overlays files usually never go in mainline kernel and so should not require to be rebased upon mainline at source level, hence there is no advantage on keeping them as patches

I'm loving it.
I've been wanting to do this for a long time, but there are two folders of overlays here:

> find arch/ -name overlay
arch/arm/boot/dts/allwinner/overlay
arch/arm64/boot/dts/allwinner/overlay

What needs to be done additionally?

[The-going]

Oh! As far as I understand this code, the ability to add two or more overlay folders for different architectures is not provided.
dt_makefile_patcher.py
Or am I wrong?

[paolosabatino]

@The-going AFAIK no, it is not provided; nonetheless it should be safe enough to put all of them, both arm and arm64 overlays, in the same overlay directory: the directory content will be copied as-is (including Makefile and other ancillary files) into arch/{$arch}/boot/dts/allwinner/overlay before the compilation step, so {$arch} will either be arm or arm64 depending upon the current target.

I expect the device tree compiler to make no hassle and compile all of them, since device trees actually are architecture-agnostic.

The only drawback is that the final .deb package will contain the overlays for both arm and arm64 targets. Anyway a major advantage is that the overlays are much more easier to modify and maintain.

This is what is in use for rockchip64 patch directory

I may add that something similar is available for non-mainlined base device trees within the dt directory: you can put the source device trees there and the patching system will copy them into arch/{$arch}/boot/dts/allwinner directory as-is. It will also automatically include them in Makefile for compilation. In this case, though, the distinction among arm and arm64 architecture may be of some importance. Beware also that you should put in the dt directory only those source device trees that are not already in the mainline kernel, otherwise they will get overwritten and the patching system will prompt a warning in the patch summary step during compilation. In such case, you would prefer to go with a regular patch file.