sunxi-6.1: switch to tag:v6.1.97, re-extracting the corrected ones

[The-going]

Fix: dtb dtbo install, wrong select media sensors

Disable incorrectly designed patches.
They need to be aligned with the kernel code.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration.

• Test build sunxi
• Test build sunxi64

[The-going]

test work on bananapi-m3:

 ____  ____  _   __  __ _____ 
| __ )|  _ \(_) |  \/  |___ / 
|  _ \| |_) | | | |\/| | |_ \ 
| |_) |  __/| | | |  | |___) |
|____/|_|   |_| |_|  |_|____/ 
                              
Welcome to Armbian_community 24.8.0-trunk.104 Bookworm with Linux 6.1.97-legacy-sunxi

No end-user support: untested automated build

System load:   24%              Up time:       0 min
Memory usage:  4% of 1.96G      IP:            192.168.100.101
Usage of /:    18% of 7.3G   

leo@bananapim3:~$ armbianmonitor -m
Two CPU clusters are available for monitoring
Stop monitoring using [ctrl]-[c]
Time    CPU_cl0/CPU_cl1  load %cpu %sys %usr %nice %io %irq  C.St.

11:15:45  1344/ 768 MHz  0.02   3%   1%   1%   0%   0%   0%  0/5
11:15:50   576/ 576 MHz  0.02   0%   0%   0%   0%   0%   0%  0/5
11:15:55   576/ 576 MHz  0.02   0%   0%   0%   0%   0%   0%  0/5

Poorly designed patches result in the maintainer having to do extra work.
They're off now.
I tried to turn them on, but for bananapi-m3 it had no effect.
These patches must be redone according to the kernel code.

I leave this opportunity to the community.

[viraniac]

I use to face kernel loading problems on sunxi when doing kernel bumps as kernel used to get into infinite loop trying to allocate memory during ftrace initialization IIRC. Trying to trace the reason down always used to bring me to a random commit which when reverted used to solve the issue. In reaity it used to be change in the memory size required by ftrace that was solving the issue. To avoid reverting commits I generally used to toggle some random config to change memory size required by ftrace, I believe it used to be CONFIG_RCU_TRACE or something like that.

I wonder if its the same issue you faced which led to reverting the commit.

[The-going]

I wonder if its the same issue you faced which led to reverting the commit.

Discussion on the forum:
linux-image-legacy-sunxi=24.5.1 (kernel 6.1.92) is broken: stuck at "Starting kernel ..."

[viraniac]

Discussion on the forum:
linux-image-legacy-sunxi=24.5.1 (kernel 6.1.92) is broken: stuck at "Starting kernel ..."

From quick read it seems like the same issue. Its been happening from time to time for more than a year since the introduction of Maple tree in 6.1 kernel. I have faced it in 6.1-6.4 may be 6.5 kernel as well IIRC, but then it stopped happening on 6.6 kernel. I will suggest to test once by removing the revert patch and then toggling the CONFIG_RCU_TRACE. it changes enough of the required memory size for ftrace to get kernel loading again.

[The-going]

From quick read it seems like the same issue. Its been happening from time to time for more than a year since the introduction of Maple tree in 6.1 kernel. I have faced it in 6.1-6.4 may be 6.5 kernel as well IIRC, but then it stopped happening on 6.6 kernel. I will suggest to test once by removing the revert patch and then toggling the CONFIG_RCU_TRACE. it changes enough of the required memory size for ftrace to get kernel loading again.

I have not encountered this problem before. And my kernel configuration file is very different from Armbian.

I understand everything. But unfortunately, I can allocate 1-2 hours in the morning and donate them to Armbian.
This is enough to recycle patches, but no more.

With respect.

[The-going]

 ____  ____  _   __  __ _____ 
| __ )|  _ \(_) |  \/  |___ / 
|  _ \| |_) | | | |\/| | |_ \ 
| |_) |  __/| | | |  | |___) |
|____/|_|   |_| |_|  |_|____/ 
                              
Welcome to Armbian_community 24.8.0-trunk.104 Bookworm with Linux 6.1.97-legacy-sunxi

No end-user support: untested automated build

System load:   20%              Up time:       0 min
Memory usage:  4% of 1.96G      IP:            192.168.100.101
CPU temp:      41°C             Usage of /:    18% of 7.3G   

Last login: Tue Jul  9 09:03:51 2024 from 192.168.100.100
leo@bananapim3:~$ armbianmonitor -m
Two CPU clusters are available for monitoring
Stop monitoring using [ctrl]-[c]
Time    CPU_cl0/CPU_cl1  load %cpu %sys %usr %nice %io %irq   Tcpu  C.St.

09:09:16   576/1344 MHz  1.25  13%   5%   6%   0%   1%   0%  40,0 °C  0/5
09:09:21   576/ 576 MHz  1.15   0%   0%   0%   0%   0%   0%  40,5 °C  0/5
09:09:26   576/ 576 MHz  1.06   0%   0%   0%   0%   0%   0%  40,0 °C  0/5
09:09:31   576/ 576 MHz  0.97   0%   0%   0%   0%   0%   0%  40,4 °C  0/5

[igorpecovnik]

LGTM