Bump meson and meson64 EDGE kernel to 6.9.y

[igorpecovnik]

Description

Maint. There is a problem AR-2352 i need help with.

How Has This Been Tested?

• CI

Checklist:

• My changes generate no new warnings
• Any dependent changes have been merged and published in downstream modules

[hzyitc]

It's seem like that you forget to move patch/kernel/archive/meson{,64}-6.8 to 6.9.

[paolosabatino]

Hello @igorpecovnik, I did some experimentaton to address the dtb overlay compilation and installation issues with kernel 6.9; you can see the progress on rockchip 32 bit edge bump

[paolosabatino]

Hello, I allowed myself this commit to update general-add-overlay-compilation.patch as used in rockchip families: I did some tweaks to generalize the "directory flattening" which on arm platforms is true only for 32 bits. I hazard to say that we could think to move the patch in misc directory and allow overlays compilation on all platforms without having the patch living in each family.

Also I renamed all the overlay/*.dts files to .dtso to use the machinery that is already in the kernel makefile.

I tested the results on a khadas vim3l and it works: the kernel boots and the overlays gets applied.

I spotted though that some meson64 overlays do not apply correctly and make u-boot complain about "missing __symbols__ node in the base fdt", which is false because the __symbols__ table is there.

The reason they don't work is because they miss the /plugin/; statement at the top (for example, this is a broken one, this is a good one).

[adeepn]

Update meson-gx-socinfo-sm driver patchset to latest version

[kernelzru]

hdmi patch for meson from v6.8 seems broken with 6.9 kernel.

[igorpecovnik]

... and 8723cs wireless driver.

[igorpecovnik]

@kernelzru do you have time to check this HDMI patch or I disable it for now?

[kernelzru]

@igorpecovnik updated patches from xdarklight (pr #6698), it now builds and boots, but need testing hdmi. I can test in a few days.

[igorpecovnik]

Many thanks! I will merge this so we can build, tests can wait longer.

[paolosabatino]

... and 8723cs wireless driver.

I the offender is the shared driver in patches/misc, I can handle that.

[ColorfulRhino]

... and 8723cs wireless driver.

... and 8723cs wireless driver.

I the offender is the shared driver in patches/misc, I can handle that.

8723cs is supported by the RTW88 mainline driver. You can try that one instead. If it works just as well as the old driver, we can leave the 8723cs for the older kernels and move to RTW88 for the new kernel versions.
Eventually we should move most wireless devices to use RTW88 if that's stable enough, since the wireless drivers/patches are often a hassle when bumping kernel versions.

[adeepn]

8723cs is supported by the RTW88 mainline driver. You can try that one instead. If it works just as well as the old driver, we can leave the 8723cs for the older kernels and move to RTW88 for the new kernel versions. Eventually we should move most wireless devices to use RTW88 if that's stable enough, since the wireless drivers/patches are often a hassle when bumping kernel versions.

rtw88 not all time works stable, and for some card not support AP mode.

[igorpecovnik]

8723cs is supported by the RTW88 mainline driver. You can try that one instead. If it works just as well as the old driver, we can leave the 8723cs for the older kernels and move to RTW88 for the new kernel versions.

This would need to be tested by people that have hardware and time. I can only keep this going as is.

If better option exists, its sane to switch, but it seems its still a trade in term of functionality.

[SteeManMI]

My thoughts on the RTW88 issue, is that this is what the edge kernel is for. To be moving forward towards full mainline support, edge = unstable. So I say we should move forward with the mainline driver now in edge. Get six months or a year of experience with it. Then next year when we have discussions of moving the current kernel to the new LTS kernel (6.12 or whatever it will be at the time), we can decide if RTW88 is stable enough in mainline or not at that time. We can always keep what we currently have from current 6.1 at that time.

[paolosabatino]

8723cs is supported by the RTW88 mainline driver. You can try that one instead. If it works just as well as the old driver, we can leave the 8723cs for the older kernels and move to RTW88 for the new kernel versions. Eventually we should move most wireless devices to use RTW88 if that's stable enough, since the wireless drivers/patches are often a hassle when bumping kernel versions

It appears to me that 8723cs has been introduced in kernel 6.10, kernel 6.9 has is no rtw8723cs.c in the sources

[ColorfulRhino]

Apologies, I didn't see your comments before writing PR #6703

This would need to be tested by people that have hardware and time. I can only keep this going as is.

Yes, that's totally understandable.

My thoughts on the RTW88 issue, is that this is what the edge kernel is for. To be moving forward towards full mainline support, edge = unstable. So I say we should move forward with the mainline driver now in edge. Get six months or a year of experience with it. Then next year when we have discussions of moving the current kernel to the new LTS kernel (6.12 or whatever it will be at the time), we can decide if RTW88 is stable enough in mainline or not at that time. We can always keep what we currently have from current 6.1 at that time.

While I wouldn't consider edge kernel unstable, I agree with you that it is definitely the best kernel to test out new stuff compared to current.

Maybe someone who owns a device with this wifi chip can test it out. But the best tests will be out in the wilds when it has already been commited. While the testing methodology of "commit and wait if someone complains" is rather crude, it is a viable strategy nonetheless. It's more a matter of "does this methodology conform with the project's philisophy".

It appears to me that 8723cs has been introduced in kernel 6.10, kernel 6.9 has is no rtw8723cs.c in the sources

Yes, you are correct.

[brentr]

Are there any other Armbian supported boards using the RTL8723DS aside from the RockPi-S?

[brentr]

I'm fairly certain this is the RTW88 bug impacting the 8732DS:

lwfinger/rtw88#157 (comment)

This is the most comprehensive discussion on the efuse problem I have ever found!
It doesn't look like there's going to be a solution any time soon.

[ColorfulRhino]

Are there any other Armbian supported boards using the RTL8723DS aside from the RockPi-S?

Sifting through the Armbian forums I believe "tinkerboard r2.0" does have this chip as well.
Although the above discussion in this PR is about the 8723CS which is a different driver than 8732DS.

This is the most comprehensive discussion on the efuse problem I have ever found!

Interesting, thanks! I might have seen something regarding efuse during my research yesterday as well, maybe I'll find it again.

[paolosabatino]

Are there any other Armbian supported boards using the RTL8723DS aside from the RockPi-S?

It should be in the Asus Tinkerboard Rev.2, which is a recent revision of the original Asus Tinkerboard with rk3288, still with the rk3288; it is in graylist: most of the board is the same, the soc is a revised version and wifi is rtl8723ds. Can't test though directly since I have the revision with rtl8723bs

[kernelzru]

Many thanks! I will merge this so we can build, tests can wait longer.

Btw, tested hdmi with 6.9.3 meson kernel with new patches, it's working, it was tested on odroid c1