Re: mvebu: armada 3720 cpufreq reverts
On 7/1/21 11:08 AM, Robert Marko wrote: On Thu, Jul 1, 2021 at 12:42 AM Marek Behun wrote: On Wed, 30 Jun 2021 17:51:24 +0200 Robert Marko wrote: On Wed, Jun 30, 2021 at 3:19 PM Marek Behún wrote: Hello Robert, I am writing regarding commit mvebu: 5.10 fix DVFS caused random boot crashes https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=080a0b74e39d159eecf69c468debec42f28bf4d8 in OpenWRT. This commit reverts the one patch of a3720 cpufreq driver, but not the subsequent ones. Your commit message says that some 1.2 GHz SOCs are unstable with the fix. Did you also test this with the subsequent patches, which are now in stable kernels? I guess the answer is yes, because all these patches were backported to 5.10.37. Hi Marek, Yes, the rest of the patches were there as well. I am of the opinion that a better approach would be to - either disable cpufreq for 1.2 GHz variants - fix a3720 cpufreq driver to only scale up to 1 GHz on 1.2 GHz variant I would prefer limiting it to 1GHz as that would not cause performance issues, but 1GHz models could have the same issue as well. This is because the voltages that are set as a minimum are from the testing that Pali and the Turris guys did, but it really depends on the SoC batch you receive. Since the approach you've taken now (reverting the patch) basically changes the CPU parnet clock to DDR clock, which is just wrong. Worse is that you are doing this for everybody, not just for the 1.2 GHz variants. What do you think? I understand that it was not the best solution, but something had to be done as I was not able to even finish booting on multiple boards before crashing. It just reverted the things back to the previous state. I really could not figure a proper solution even after being in touch with Pali, and contacting GlobalScale. This is an issue caused by Marvell simply ignoring the issue and refusing to publish a fix or release the OTP and AVS docs as they all have a validated voltage in the OTP somewhere. Robert, we've found this table in linux-marvell repository: https://github.com/MarvellEmbeddedProcessors/linux-marvell/blob/dc33b62c90696afb6adc7dbcc4ebbd48bedec269/drivers/regulator/armada-37xx-regulator.c#L99-L105 Do you still have the 1.2 GHz boards which were crashing? Would you be willing to test whether those boards are stable if we provided patch for you? Yes, I tested on 4 boards If I remember correctly and they all crashed with the voltages that are set, only by manually raising to at least 1.1902V one got stable while other required 1.2+V I would be glad to test a possible solution. Regards, Robert Marek Hi, any progress on this? Are there any patches to avoid the 1.2GHz? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] at91: add pioBU label to secumod
On 7/16/21 7:08 AM, Claudiu Beznea wrote:
Add pioBU label to secumod. Along with this set gpio controller
properties for secumod.
Signed-off-by: Claudiu Beznea
---
.../linux/at91/patches-5.4/104-add-piobu.patch | 16
1 file changed, 16 insertions(+)
create mode 100644 target/linux/at91/patches-5.4/104-add-piobu.patch
diff --git a/target/linux/at91/patches-5.4/104-add-piobu.patch
b/target/linux/at91/patches-5.4/104-add-piobu.patch
new file mode 100644
index ..2495fe4635a1
--- /dev/null
+++ b/target/linux/at91/patches-5.4/104-add-piobu.patch
Please take this patch from upstream with the comments in it:
https://git.kernel.org/linus/4514a7c81234673a764c59e59a0c34c1921f093b
@@ -0,0 +1,16 @@
+--- a/arch/arm/boot/dts/sama5d2.dtsi
b/arch/arm/boot/dts/sama5d2.dtsi
+@@ -885,9 +885,12 @@
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 18>;
+ };
+
+- secumod@fc04 {
++ pioBU: secumod@fc04 {
+ compatible = "atmel,sama5d2-secumod", "syscon";
+ reg = <0xfc04 0x100>;
++
++ gpio-controller;
++ #gpio-cells = <2>;
+ };
+
+ tdes@fc044000 {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/3] at91: add pioBU label to secumod
On 7/24/21 7:42 PM, Hauke Mehrtens wrote: On 7/16/21 7:08 AM, Claudiu Beznea wrote: Add pioBU label to secumod. Along with this set gpio controller properties for secumod. Signed-off-by: Claudiu Beznea --- .../linux/at91/patches-5.4/104-add-piobu.patch | 16 1 file changed, 16 insertions(+) create mode 100644 target/linux/at91/patches-5.4/104-add-piobu.patch diff --git a/target/linux/at91/patches-5.4/104-add-piobu.patch b/target/linux/at91/patches-5.4/104-add-piobu.patch new file mode 100644 index ..2495fe4635a1 --- /dev/null +++ b/target/linux/at91/patches-5.4/104-add-piobu.patch Please take this patch from upstream with the comments in it: https://git.kernel.org/linus/4514a7c81234673a764c59e59a0c34c1921f093b You could also update the at91 target to kernel 5.10. I think most of the changes you want tot do ares already in kernel 5.10. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mvebu: armada 3720 cpufreq reverts
On 7/24/21 7:50 PM, Josef Schlehofer wrote: On 24. 07. 21 19:37, Hauke Mehrtens wrote: On 7/1/21 11:08 AM, Robert Marko wrote: On Thu, Jul 1, 2021 at 12:42 AM Marek Behun wrote: On Wed, 30 Jun 2021 17:51:24 +0200 Robert Marko wrote: On Wed, Jun 30, 2021 at 3:19 PM Marek Behún wrote: Hello Robert, I am writing regarding commit mvebu: 5.10 fix DVFS caused random boot crashes https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=080a0b74e39d159eecf69c468debec42f28bf4d8 in OpenWRT. This commit reverts the one patch of a3720 cpufreq driver, but not the subsequent ones. Your commit message says that some 1.2 GHz SOCs are unstable with the fix. Did you also test this with the subsequent patches, which are now in stable kernels? I guess the answer is yes, because all these patches were backported to 5.10.37. Hi Marek, Yes, the rest of the patches were there as well. I am of the opinion that a better approach would be to - either disable cpufreq for 1.2 GHz variants - fix a3720 cpufreq driver to only scale up to 1 GHz on 1.2 GHz variant I would prefer limiting it to 1GHz as that would not cause performance issues, but 1GHz models could have the same issue as well. This is because the voltages that are set as a minimum are from the testing that Pali and the Turris guys did, but it really depends on the SoC batch you receive. Since the approach you've taken now (reverting the patch) basically changes the CPU parnet clock to DDR clock, which is just wrong. Worse is that you are doing this for everybody, not just for the 1.2 GHz variants. What do you think? I understand that it was not the best solution, but something had to be done as I was not able to even finish booting on multiple boards before crashing. It just reverted the things back to the previous state. I really could not figure a proper solution even after being in touch with Pali, and contacting GlobalScale. This is an issue caused by Marvell simply ignoring the issue and refusing to publish a fix or release the OTP and AVS docs as they all have a validated voltage in the OTP somewhere. Robert, we've found this table in linux-marvell repository: https://github.com/MarvellEmbeddedProcessors/linux-marvell/blob/dc33b62c90696afb6adc7dbcc4ebbd48bedec269/drivers/regulator/armada-37xx-regulator.c#L99-L105 Do you still have the 1.2 GHz boards which were crashing? Would you be willing to test whether those boards are stable if we provided patch for you? Yes, I tested on 4 boards If I remember correctly and they all crashed with the voltages that are set, only by manually raising to at least 1.1902V one got stable while other required 1.2+V I would be glad to test a possible solution. Regards, Robert Marek Hi, any progress on this? Are there any patches to avoid the 1.2GHz? Hello, The patch [1] was sent to the linux-arm-kernel mailing list, but there was no response from Marvell even though it was requested multiple times. Hopefully, it will be merged soon. [1] https://lore.kernel.org/linux-arm-kernel/20210630135942.29730-1-ka...@kernel.org/T/ Josef Hi, Should we then better revert the patch from Robert and take this additional patch from Marek even when Marvell does not react? Does anyone have a better idea? Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] dropbear: add config options for agent-forwarding support
On 7/16/21 12:44 AM, Sven Roederer wrote: * SSH agent forwarding might cause security issues, locally and on the jump machine (https://defn.io/2019/04/12/ssh-forwarding/). So allow to completely disabling it. * separate options for client and server * keep it enabled by default How much bigger will the dropbear binary get with these options? Will dropbear always activate agent forwarding for the client connection? I think it is no security problem when the server always uses agent forwarding, but when the client forwards the agent to every host it could get a problem. Signed-of-by: Sven Roederer --- package/network/services/dropbear/Config.in | 9 + package/network/services/dropbear/Makefile | 5 - 2 files changed, 13 insertions(+), 1 deletion(-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v5] mvebu: add support for iEi Puzzle-M901/Puzzle-M902
On 7/20/21 5:10 AM, eveans2...@gmail.com wrote: From: Ian Chang Hardware specification -- * CN9130 SoC, Quad-core ARMv8 Cortex-72 @ 2200 MHz * 4 GB DDR * 4 GB eMMC * mmcblk0 - mmcblk0p164M kernel_1 - mmcblk0p264M kernel_2 - mmcblk0p3 512M rootfs_1 - mmcblk0p4 512M rootfs_2 - mmcblk0p5 512M Reserved - mmcblk0p664M Reserved - mmcblk0p7 1.8G rootfs_data * 4 MB (SPI Flash) * 6 x 2.5 Gigabit ports (Puzzle-M901) - External PHY with 6 ports (AQR112R) * 6 x 2.5 Gigabit ports (Puzzle-M902) - External PHY with 6 ports (AQR112R) 3 x 10 Gigabit ports (Puzzle-M902) - External PHY with 3 ports (AQR113R) * 4 x Front panel LED * 1 x USB 3.0 * Reset button on Rear panel * UART (115200 8N1,header on PCB) Flash instructions: The original firmware is based on OpenWrt. Flash firmware using LuCI and CLI Signed-off-by: Ian Chang --- .../base-files/etc/board.d/02_network | 6 + .../cortexa72/base-files/lib/upgrade/emmc.sh | 36 ++ .../base-files/lib/upgrade/platform.sh| 8 + .../boot/dts/marvell/cn9131-puzzle-m901.dts | 319 .../boot/dts/marvell/cn9132-puzzle-m902.dts | 481 ++ target/linux/mvebu/image/cortexa72.mk | 18 + ...l-Add-support-for-Marvell-CN9130-SoC.patch | 61 +++ 7 files changed, 929 insertions(+) create mode 100644 target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh create mode 100644 target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-puzzle-m901.dts create mode 100644 target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9132-puzzle-m902.dts create mode 100644 target/linux/mvebu/patches-5.4/000-v5.5-arm64-dts-marvell-Add-support-for-Marvell-CN9130-SoC.patch . diff --git a/target/linux/mvebu/patches-5.4/000-v5.5-arm64-dts-marvell-Add-support-for-Marvell-CN9130-SoC.patch b/target/linux/mvebu/patches-5.4/000-v5.5-arm64-dts-marvell-Add-support-for-Marvell-CN9130-SoC.patch new file mode 100644 index 00..008bf9e24d --- /dev/null +++ b/target/linux/mvebu/patches-5.4/000-v5.5-arm64-dts-marvell-Add-support-for-Marvell-CN9130-SoC.patch @@ -0,0 +1,61 @@ +From 6b8970bd8d7a17a648e31f3996d9b21336b4a2cf Mon Sep 17 00:00:00 2001 +From: Miquel Raynal +Date: Fri, 4 Oct 2019 16:27:35 +0200 +Subject: [PATCH] arm64: dts: marvell: Add support for Marvell CN9130 SoC + support + +A CN9130 SoC has one AP807 and one internal CP115. + +Signed-off-by: Miquel Raynal +Signed-off-by: Gregory CLEMENT +--- + arch/arm64/boot/dts/marvell/cn9130.dtsi | 37 + + 1 file changed, 37 insertions(+) + create mode 100644 arch/arm64/boot/dts/marvell/cn9130.dtsi + +diff --git a/arch/arm64/boot/dts/marvell/cn9130.dtsi b/arch/arm64/boot/dts/marvell/cn9130.dtsi +new file mode 100644 +index ..a2b7e5ec979d +--- /dev/null b/arch/arm64/boot/dts/marvell/cn9130.dtsi +@@ -0,0 +1,37 @@ ++// SPDX-License-Identifier: (GPL-2.0+ OR MIT) ++/* ++ * Copyright (C) 2019 Marvell International Ltd. ++ * ++ * Device tree for the CN9130 SoC. ++ */ ++ ++#include "armada-ap807-quad.dtsi" When I compile this code in OpenWrt master with kernel 5.4 I am getting this error message: /build_dir/target-aarch64_cortex-a72_musl/linux-mvebu_cortexa72/linux-5.4.134/arch/arm64/boot/dts/marvell/cn9130.dtsi:8:10: fatal error: armada-ap807-quad.dtsi: No such file or directory #include "armada-ap807-quad.dtsi" The file armada-ap807-quad.dtsi was only added with kernel 5.5, see here: https://git.kernel.org/linus/cbafcad0641e99831ff7c57ac8f79aed502f33e5 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mvebu: armada 3720 cpufreq reverts
On 7/27/21 9:50 AM, Josef Schlehofer wrote: On 24. 07. 21 20:03, Hauke Mehrtens wrote: On 7/24/21 7:50 PM, Josef Schlehofer wrote: On 24. 07. 21 19:37, Hauke Mehrtens wrote: On 7/1/21 11:08 AM, Robert Marko wrote: On Thu, Jul 1, 2021 at 12:42 AM Marek Behun wrote: On Wed, 30 Jun 2021 17:51:24 +0200 Robert Marko wrote: On Wed, Jun 30, 2021 at 3:19 PM Marek Behún wrote: Hello Robert, I am writing regarding commit mvebu: 5.10 fix DVFS caused random boot crashes https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=080a0b74e39d159eecf69c468debec42f28bf4d8 in OpenWRT. This commit reverts the one patch of a3720 cpufreq driver, but not the subsequent ones. Your commit message says that some 1.2 GHz SOCs are unstable with the fix. Did you also test this with the subsequent patches, which are now in stable kernels? I guess the answer is yes, because all these patches were backported to 5.10.37. Hi Marek, Yes, the rest of the patches were there as well. I am of the opinion that a better approach would be to - either disable cpufreq for 1.2 GHz variants - fix a3720 cpufreq driver to only scale up to 1 GHz on 1.2 GHz variant I would prefer limiting it to 1GHz as that would not cause performance issues, but 1GHz models could have the same issue as well. This is because the voltages that are set as a minimum are from the testing that Pali and the Turris guys did, but it really depends on the SoC batch you receive. Since the approach you've taken now (reverting the patch) basically changes the CPU parnet clock to DDR clock, which is just wrong. Worse is that you are doing this for everybody, not just for the 1.2 GHz variants. What do you think? I understand that it was not the best solution, but something had to be done as I was not able to even finish booting on multiple boards before crashing. It just reverted the things back to the previous state. I really could not figure a proper solution even after being in touch with Pali, and contacting GlobalScale. This is an issue caused by Marvell simply ignoring the issue and refusing to publish a fix or release the OTP and AVS docs as they all have a validated voltage in the OTP somewhere. Robert, we've found this table in linux-marvell repository: https://github.com/MarvellEmbeddedProcessors/linux-marvell/blob/dc33b62c90696afb6adc7dbcc4ebbd48bedec269/drivers/regulator/armada-37xx-regulator.c#L99-L105 Do you still have the 1.2 GHz boards which were crashing? Would you be willing to test whether those boards are stable if we provided patch for you? Yes, I tested on 4 boards If I remember correctly and they all crashed with the voltages that are set, only by manually raising to at least 1.1902V one got stable while other required 1.2+V I would be glad to test a possible solution. Regards, Robert Marek Hi, any progress on this? Are there any patches to avoid the 1.2GHz? Hello, The patch [1] was sent to the linux-arm-kernel mailing list, but there was no response from Marvell even though it was requested multiple times. Hopefully, it will be merged soon. [1] https://lore.kernel.org/linux-arm-kernel/20210630135942.29730-1-ka...@kernel.org/T/ Josef Hi, Should we then better revert the patch from Robert and take this additional patch from Marek even when Marvell does not react? Does anyone have a better idea? Hauke Hello, Yes, we should do it before there is going to be OpenWrt 21.02 release. Should I send v2? Josef Hi Josef, Yes, please send a v2. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 7/20/21 9:40 AM, Andy Botting wrote:
- IPv6 broken with flow offloading (according to reports, potentially
related to hw flow offloading)
There is a bug report about this at:
- https://bugs.openwrt.org/index.php?do=details&task_id=3373
I've reproduced it with and without hw flow offloading on mt7621.
I think it's very important to do something about this issue before
the release, as it took me nearly a week to track down. I found it
quite hard to isolate as it's like some packets just disappear, so
makes for a very bad user experience.
Hi,
Thank you for the link and the description on how to reproduce this:
while [ 1 ]; do curl -k -s -o /dev/null -L -I -w "%{http_code}
'%{time_total}'\n" -H 'Host: www.6connect.com'
https://[2607:fae0:a000::9]; sleep 1; done
I see this problem once every 250 tries, but I got a wireshak capture.
A TCP package is lost and we get the next one after 6 seconds. I would
have expected a retransmission much earlier.
I have to check that I do not see this without the offloading and then
also capture before the device.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 7/31/21 9:05 AM, Andy Botting wrote:
Thank you for the link and the description on how to reproduce this:
while [ 1 ]; do curl -k -s -o /dev/null -L -I -w "%{http_code}
'%{time_total}'\n" -H 'Host: www.6connect.com'
https://[2607:fae0:a000::9]; sleep 1; done
I see this problem once every 250 tries, but I got a wireshak capture.
A TCP package is lost and we get the next one after 6 seconds. I would
have expected a retransmission much earlier.
I have to check that I do not see this without the offloading and then
also capture before the device.
Thanks for looking into it. I've just had a look on my setup, and I
can easily reproduce it, so if there are some specific scenarios you'd
like me to capture, let me know.
cheers,
Andy
Hi Andy,
Could you please try this patch:
https://patchwork.ozlabs.org/project/openwrt/patch/20210531195732.522580-1-dqf...@gmail.com/
I do not see this problem with this patch any more, I am not sure which
change exactly fixed it or if I am unable to reproduce it any more.
I have some wireshark dumps of the problem with unmodified OpenWrt 21.02.
Before the flow handling: offload-ipv6-problem2-wifi.pcapng
On the PC receiving the stream: offload-ipv6-problem2-pc.pcapng
Some packets of this TCP stream are not forward.
Hauke
offload-ipv6-problem2-pc.pcapng
Description: application/pcapng
offload-ipv6-problem2-wifi.pcapng
Description: application/pcapng
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.0 Fourth release candidate
Hi, The OpenWrt community is proud to announce the fourth release candidate of the upcoming OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year. Changes between OpenWrt 21.02.0-rc3 and 21.02.0-rc4 Software updates * Linux kernel: updated to version 5.4.137 (from 5.4.124 in v21.02.0-rc3) * mt76: Update to version 2021-06-06 (from 2021-05-15 in v21.02.0-rc3) * wireguard: Update with recent Linux stable fixes * exfat: Update to version 5.12.3 (from 5.10.1 in v21.02.0-rc3) Misc changes * failsafe: Fixes failsafe network configuration with swconfig and DSA: FS#3866 * odhcpd: fix invalid DHCPv6 ADVERTSIE with small configured leasetime * ugps: parse $GPZDA and $GPGLL sentences, improve interoperability with kplex * netifd: WDS with bridge-vlan fixed Device support * New devices MikroTik RouterBOARD 912UAG-2HPnD and Joy-IT JT-OR750i * Device fixes for TP-Link CPE, MikroTik RouterBOARDs and AVM FRITZRepeater 1200 Known issues * Some packets from IPv6 streams are getting dropped in software and hardware flow offloading: FS#3373 Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.0-rc4 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.0-rc4#known_issues For a detailed list of all changes since 21.02.0-rc3, refer to https://openwrt.org/releases/21.02/changelog-21.02.0-rc4 To download the 21.02.0-rc4 images, navigate to: https://downloads.openwrt.org/releases/21.02.0-rc4/ - --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 19.07.8 service release
Hi, The OpenWrt community is proud to announce the eighth service release of OpenWrt 19.07. It fixes security issues, improves device support, and brings a few bug fixes. The main changes from OpenWrt 19.07.7 are: Security fixes == * Fix FragAttacks (fragmentation and aggregation attacks) vulnerabilities in cfg80211, mac80211, ath10k and ath10k-ct * We are not sure if some closed source firmware files are still affected by these problems. * Security Advisory 2021-08-01-1 - XSS via missing input validation of host names displayed (CVE-2021-32019) * Security Advisory 2021-08-01-2 - Stored XSS in hostname UCI variable (CVE-2021-33425) * Security Advisory 2021-08-01-3 - luci-app-ddns: Multiple authenticated RCEs (CVE-2021-28961) * Various security fixes in packages Major bug fixes === * Minor bugfixes to support GCC 11 as host compiler Device support == * TP-Link C7v5 allow flashing from vendor firmware bigger than v1.1 * FRIZZ!Box 7320 Activate power supply to USB ports. Various fixes and improvements == * Only pack the signing keys for OpenWrt 19.07 and 21.02 and not the personal keys any more. Core components === * Update Linux kernel from 4.14.221 to 4.14.241 * Update mac80211 from 4.19.161-1 to 4.19.193-1 * Update ath10k-ct 4.19 driver from 2019-09-09 to 2021-06-03 * Update OpenVPN from 2.4.7 to 2.4.11 * Update openssl from 1.1.1i to 1.1.1k * Update mbedtls from 2.16.9 to 2.16.10 * Update wolfssl from 4.6.0 to 4.7.0 Full release notes and upgrade instructions are available at https://openwrt.org/releases/19.07/notes-19.07.8 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/19.07/notes-19.07.8#regressions For a very detailed list of all changes since 19.07.7, refer to https://openwrt.org/releases/19.07/changelog-19.07.8 For latest information about the 19.07 series, refer to the wiki at: https://openwrt.org/releases/19.07/ To download a OpenWrt 19.07.8 firmware image for your device, head to the Table of Hardware: https://openwrt.org/toh/start Or use the new firmware selector: https://firmware-selector.openwrt.org/ You can also navigate directly in the list of firmware images: https://downloads.openwrt.org/releases/19.07.8/targets/ As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: mvebu: armada 3720 cpufreq reverts
On 8/8/21 8:15 PM, Josef Schlehofer wrote: On 27. 07. 21 11:24, Hauke Mehrtens wrote: On 7/27/21 9:50 AM, Josef Schlehofer wrote: On 24. 07. 21 20:03, Hauke Mehrtens wrote: On 7/24/21 7:50 PM, Josef Schlehofer wrote: On 24. 07. 21 19:37, Hauke Mehrtens wrote: On 7/1/21 11:08 AM, Robert Marko wrote: On Thu, Jul 1, 2021 at 12:42 AM Marek Behun wrote: On Wed, 30 Jun 2021 17:51:24 +0200 Robert Marko wrote: On Wed, Jun 30, 2021 at 3:19 PM Marek Behún wrote: Hello Robert, I am writing regarding commit mvebu: 5.10 fix DVFS caused random boot crashes https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=080a0b74e39d159eecf69c468debec42f28bf4d8 in OpenWRT. This commit reverts the one patch of a3720 cpufreq driver, but not the subsequent ones. Your commit message says that some 1.2 GHz SOCs are unstable with the fix. Did you also test this with the subsequent patches, which are now in stable kernels? I guess the answer is yes, because all these patches were backported to 5.10.37. Hi Marek, Yes, the rest of the patches were there as well. I am of the opinion that a better approach would be to - either disable cpufreq for 1.2 GHz variants - fix a3720 cpufreq driver to only scale up to 1 GHz on 1.2 GHz variant I would prefer limiting it to 1GHz as that would not cause performance issues, but 1GHz models could have the same issue as well. This is because the voltages that are set as a minimum are from the testing that Pali and the Turris guys did, but it really depends on the SoC batch you receive. Since the approach you've taken now (reverting the patch) basically changes the CPU parnet clock to DDR clock, which is just wrong. Worse is that you are doing this for everybody, not just for the 1.2 GHz variants. What do you think? I understand that it was not the best solution, but something had to be done as I was not able to even finish booting on multiple boards before crashing. It just reverted the things back to the previous state. I really could not figure a proper solution even after being in touch with Pali, and contacting GlobalScale. This is an issue caused by Marvell simply ignoring the issue and refusing to publish a fix or release the OTP and AVS docs as they all have a validated voltage in the OTP somewhere. Robert, we've found this table in linux-marvell repository: https://github.com/MarvellEmbeddedProcessors/linux-marvell/blob/dc33b62c90696afb6adc7dbcc4ebbd48bedec269/drivers/regulator/armada-37xx-regulator.c#L99-L105 Do you still have the 1.2 GHz boards which were crashing? Would you be willing to test whether those boards are stable if we provided patch for you? Yes, I tested on 4 boards If I remember correctly and they all crashed with the voltages that are set, only by manually raising to at least 1.1902V one got stable while other required 1.2+V I would be glad to test a possible solution. Regards, Robert Marek Hi, any progress on this? Are there any patches to avoid the 1.2GHz? Hello, The patch [1] was sent to the linux-arm-kernel mailing list, but there was no response from Marvell even though it was requested multiple times. Hopefully, it will be merged soon. [1] https://lore.kernel.org/linux-arm-kernel/20210630135942.29730-1-ka...@kernel.org/T/ Josef Hi, Should we then better revert the patch from Robert and take this additional patch from Marek even when Marvell does not react? Does anyone have a better idea? Hauke Hello, Yes, we should do it before there is going to be OpenWrt 21.02 release. Should I send v2? Josef Hi Josef, Yes, please send a v2. Hauke Hello Hauke, I sent 2nd version almost 2 weeks ago [1] [2]. [1] master: https://patchwork.ozlabs.org/project/openwrt/list/?series=255415 + https://patchwork.ozlabs.org/project/openwrt/list/?series=254135 [2] openwrt-21.02: https://patchwork.ozlabs.org/project/openwrt/list/?series=255418 Is there something wrong with it? Looking forward to hearing from you, Josef Schlehofer Hi Josef, I overlooked these patches before and applied them now to master and 21.02. Today I applied multiples patches and pull request and already had them in my list, I just took the one for the 21.02 branch initially into master. If some new developments happen upstream and they apply a better fix upstream, please send a backport to OpenWrt. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02.0 Fourth release candidate
On 8/8/21 1:43 PM, Arınç ÜNAL wrote: Congrats! Before we get to the final release, the DSA migration script should be included. Looks like I'm going to hire someone to write the script for me. I know DSA, not changing text on configuration files with awk, grep, etc. Want to give a hand? Please let me know. I still plan to update the converting to DSA page here: https://openwrt.org/docs/guide-user/network/dsa/converting-to-dsa Cheers. Arınç Hi Arınç, Thanks for working on a swconfig to DSA migration script. I would prefer not to delay the final 21.02 release further. We should fix the IPv6 flow offload problems and then do the final 21.02 release. Such a migration script also needs testing, user will have all sorts of strange configurations, so I would assume that we would need 2 months for testing after the initial version is ready. For 21.02 we should work on the DSA documentation which Rafal and Rich already did and continue like it is now. Not all targets are migrated to DSA yet, so a migration script would still be useful for the next release or we could integrate it into a later minor release. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 5/6] toolchain: drop GCC 9
On 8/15/21 12:51 PM, Stijn Tintel wrote: Since we switched to GCC 10 by default, with the previous default being GCC 8, it doesn't make much sense to keep GCC 9 around, so drop it. Signed-off-by: Stijn Tintel --- toolchain/gcc/Config.in | 3 --- toolchain/gcc/Config.version | 5 - 2 files changed, 8 deletions(-) There is also a directory with the gcc 9 specific patches, please remove that too. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/6] toolchain: drop binutils 2.35.1
On 8/15/21 12:51 PM, Stijn Tintel wrote: Since we switched to binutils 2.36.1 by default, with the previous default being binutils 2.34, it doesn't make much sense to keep binutils 2.35.1 around, so drop it. Signed-off-by: Stijn Tintel --- toolchain/binutils/Config.in | 4 toolchain/binutils/Config.version | 4 2 files changed, 8 deletions(-) There is a directory with the binutils 2.35.1 specific patches, please remove that too. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/6] use binutils 2.36.1 and gcc 10 by default
Thank you Stijn for taking care of this toolchain upgrade and Rosen for preparing it. On 8/15/21 12:51 PM, Stijn Tintel wrote: Since 21.02 has been branched, it's a good time to switch master to a more recent toolchain by default. I have been test-driving binutils 2.36.1 and gcc 10.3 for months on many different targets without issues. Additionally I've compile-tested x86/64 with CONFIG_ALL_PACKAGES=y, and all packages in OpenWrt core build fine. Did you compile umbim on MIPS 32 bit? I think I only saw the warning on such systems. The packages feed contains a few packages that will need to be fixed. One of them is the perl package. Unfortunately, the perl package seems to contain a bunch of undocumented patches that have either not been accepted by upstream, or haven't been submitted upstream at all, so I'll leave it up to the maintainer(s) and/or community to handle the perl bump, as I do not use perl at all. Another package that doesn't build is gnupg (v1). Users are encouraged to use gnupg2 instead. I suggest to drop gnupg v1 entirely. After many hours of fixing random breakage in the packages feed, many of which not even caused by the GCC bump, I gave up and decided to just send out this patch series. Did you create pull request for the packages which you fix? Someone can later fix the rest of them. ;-) Did you check if the size of some of our images changed? Stijn Tintel (6): busybox: fix compilation with GCC 10 umbim: fix compilation with GCC 10 toolchain/binutils: switch to version 2.36.1 by default toolchain/gcc: switch to version 10 by default toolchain: drop GCC 9 toolchain: drop binutils 2.35.1 I would prefer if we wait 1 months till we drop gcc 9 and binutils 2.35.1, if we see some problems with gcc 10 and the new binutils we can easily try the intermediate versions if they are still included. We can then remove gcc 7 and 9 and binutils 2.32 and 2.35.1. package/network/utils/umbim/patches/999-gcc10.patch | 13 + package/utils/busybox/Makefile | 3 --- toolchain/binutils/Config.in| 6 +- toolchain/binutils/Config.version | 6 +- toolchain/gcc/Config.in | 5 + toolchain/gcc/Config.version| 13 - 6 files changed, 20 insertions(+), 26 deletions(-) create mode 100644 package/network/utils/umbim/patches/999-gcc10.patch Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 0/6] use binutils 2.36.1 and gcc 10 by default
On 8/15/21 2:00 PM, Stijn Tintel wrote: On 15/08/2021 14:53, Hauke Mehrtens wrote: Thank you Stijn for taking care of this toolchain upgrade and Rosen for preparing it. Thanks for reviewing! On 8/15/21 12:51 PM, Stijn Tintel wrote: Since 21.02 has been branched, it's a good time to switch master to a more recent toolchain by default. I have been test-driving binutils 2.36.1 and gcc 10.3 for months on many different targets without issues. Additionally I've compile-tested x86/64 with CONFIG_ALL_PACKAGES=y, and all packages in OpenWrt core build fine. Did you compile umbim on MIPS 32 bit? I think I only saw the warning on such systems. Compile-tested on ramips, my proposed change fixes the warning. Thanks for testing. The packages feed contains a few packages that will need to be fixed. One of them is the perl package. Unfortunately, the perl package seems to contain a bunch of undocumented patches that have either not been accepted by upstream, or haven't been submitted upstream at all, so I'll leave it up to the maintainer(s) and/or community to handle the perl bump, as I do not use perl at all. Another package that doesn't build is gnupg (v1). Users are encouraged to use gnupg2 instead. I suggest to drop gnupg v1 entirely. After many hours of fixing random breakage in the packages feed, many of which not even caused by the GCC bump, I gave up and decided to just send out this patch series. Did you create pull request for the packages which you fix? Yes, see https://github.com/openwrt/packages/pulls :-) Someone can later fix the rest of them. ;-) Did you check if the size of some of our images changed? I did not. I can do that, but it'll take some time. I started regularly wiping build_dir/ staging_dir/ and tmp/ due to vague heisenbugs that kept appearing. >> Stijn Tintel (6): busybox: fix compilation with GCC 10 umbim: fix compilation with GCC 10 toolchain/binutils: switch to version 2.36.1 by default toolchain/gcc: switch to version 10 by default toolchain: drop GCC 9 toolchain: drop binutils 2.35.1 I would prefer if we wait 1 months till we drop gcc 9 and binutils 2.35.1, if we see some problems with gcc 10 and the new binutils we can easily try the intermediate versions if they are still included. We can then remove gcc 7 and 9 and binutils 2.32 and 2.35.1. I will drop them for now. package/network/utils/umbim/patches/999-gcc10.patch | 13 + package/utils/busybox/Makefile | 3 --- toolchain/binutils/Config.in | 6 +- toolchain/binutils/Config.version | 6 +- toolchain/gcc/Config.in | 5 + toolchain/gcc/Config.version | 13 - 6 files changed, 20 insertions(+), 26 deletions(-) create mode 100644 package/network/utils/umbim/patches/999-gcc10.patch Updated series at https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/gcc10 - shall I send a v2, or can we ack the series as is over there? No need to send a v2 for me. I am not aware of any other problems or reports form people about problems with this gcc and binutils combination. You can add my Acked-by: Hauke Mehrtens Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: disable CONFIG_RCU_EXPERT and friends
On 8/22/21 10:01 AM, Rui Salvaterra wrote: Based on the existing documentation [1][2], I dare anyone to demonstrate that we need to fine-tune these RCU parameters. The (performance) breakage potential for doing so is immense, so let's just please put down this loaded footgun. Disable CONFIG_RCU_EXPERT and dependent symbols. [1] https://www.kernel.org/doc/Documentation/RCU/Design/Data-Structures/Data-Structures.html [2] https://lwn.net/Articles/777214/ Signed-off-by: Rui Salvaterra There are also some targets which explicitly unset CONFIG_RCU_EXPERT: $ git grep CONFIG_RCU_EXPERT target/linux/gemini/config-5.10:# CONFIG_RCU_EXPERT is not set target/linux/gemini/config-5.4:# CONFIG_RCU_EXPERT is not set target/linux/generic/config-5.10:CONFIG_RCU_EXPERT=y target/linux/generic/config-5.4:CONFIG_RCU_EXPERT=y target/linux/ipq807x/config-default:# CONFIG_RCU_EXPERT is not set target/linux/layerscape/armv7/config-5.4:# CONFIG_RCU_EXPERT is not set target/linux/layerscape/armv8_64b/config-5.4:# CONFIG_RCU_EXPERT is not set target/linux/mediatek/mt7623/config-5.10:# CONFIG_RCU_EXPERT is not set target/linux/oxnas/ox810se/config-default:# CONFIG_RCU_EXPERT is not set target/linux/oxnas/ox820/config-default:# CONFIG_RCU_EXPERT is not set target/linux/rockchip/armv8/config-5.10:# CONFIG_RCU_EXPERT is not set target/linux/rockchip/armv8/config-5.4:# CONFIG_RCU_EXPERT is not set target/linux/tegra/config-5.10:# CONFIG_RCU_EXPERT is not set target/linux/tegra/config-5.4:# CONFIG_RCU_EXPERT is not set This should be removed from the target config file. CONFIG_RCU_STALL_COMMON=y and CONFIG_RCU_NEED_SEGCBLIST=y are also set in most target configurations. Should we move them to the generic configuration? Hauke --- target/linux/generic/config-5.10 | 7 +-- target/linux/generic/config-5.4 | 6 +- 2 files changed, 2 insertions(+), 11 deletions(-) diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index f944f1718f..91f137fbc3 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -4631,12 +4631,8 @@ CONFIG_PWRSEQ_SIMPLE=y CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_RCU_EQS_DEBUG is not set # CONFIG_RCU_EXPEDITE_BOOT is not set -CONFIG_RCU_EXPERT=y -CONFIG_RCU_FANOUT=32 -CONFIG_RCU_FANOUT_LEAF=16 -# CONFIG_RCU_FAST_NO_HZ is not set +# CONFIG_RCU_EXPERT is not set CONFIG_RCU_KTHREAD_PRIO=0 -# CONFIG_RCU_NOCB_CPU is not set # CONFIG_RCU_PERF_TEST is not set # CONFIG_RCU_REF_SCALE_TEST is not set # CONFIG_RCU_SCALE_TEST is not set @@ -5995,7 +5991,6 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_TARGET_CORE is not set # CONFIG_TASKSTATS is not set # CONFIG_TASKS_RCU is not set -CONFIG_TASKS_TRACE_RCU_READ_MB=y # CONFIG_TASK_XACCT is not set # CONFIG_TC35815 is not set # CONFIG_TCG_ATMEL is not set diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4 index 45d8f0976e..06f5e43a6d 100644 --- a/target/linux/generic/config-5.4 +++ b/target/linux/generic/config-5.4 @@ -4262,12 +4262,8 @@ CONFIG_PWRSEQ_SIMPLE=y CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_RCU_EQS_DEBUG is not set # CONFIG_RCU_EXPEDITE_BOOT is not set -CONFIG_RCU_EXPERT=y -CONFIG_RCU_FANOUT=32 -CONFIG_RCU_FANOUT_LEAF=16 -# CONFIG_RCU_FAST_NO_HZ is not set +# CONFIG_RCU_EXPERT is not set CONFIG_RCU_KTHREAD_PRIO=0 -# CONFIG_RCU_NOCB_CPU is not set # CONFIG_RCU_PERF_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY=3 OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 4/8] at91: use make kernel_menuconfig and save for sam9x kernel config
On 8/20/21 1:42 PM, Claudiu Beznea wrote: Use kernel_menuconfig and save for sam9x kernel config. Is the result of this command the same? (executed with the sam9x and the sama5 sub target selected) make kernel_oldconfig CONFIG_TARGET=subtarget This would run an oldconfig using the subtarget config. I would prefer if you just squash the refresh of the kernel configuration into the "at91: kernel: bump to 5.10" so that the system is still building and booting after the first patch. Hauke Signed-off-by: Claudiu Beznea --- target/linux/at91/sam9x/config-default | 61 +- 1 file changed, 1 insertion(+), 60 deletions(-) diff --git a/target/linux/at91/sam9x/config-default b/target/linux/at91/sam9x/config-default index d0a1cbc0a45b..ebfd38d131db 100644 --- a/target/linux/at91/sam9x/config-default +++ b/target/linux/at91/sam9x/config-default @@ -1,22 +1,6 @@ CONFIG_ALIGNMENT_TRAP=y CONFIG_ARCH_32BIT_OFF_T=y CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_HAS_BINFMT_FLAT=y -CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y -CONFIG_ARCH_HAS_DMA_WRITE_COMBINE=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -CONFIG_ARCH_HAS_FORTIFY_SOURCE=y -CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y -CONFIG_ARCH_HAS_KCOV=y -CONFIG_ARCH_HAS_KEEPINITRD=y -CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y -CONFIG_ARCH_HAS_PHYS_TO_DMA=y -CONFIG_ARCH_HAS_SETUP_DMA_OPS=y -CONFIG_ARCH_HAS_SET_MEMORY=y -CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y -CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y -CONFIG_ARCH_HAS_TEARDOWN_DMA_OPS=y -CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_KEEP_MEMBLOCK=y CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y @@ -27,14 +11,7 @@ CONFIG_ARCH_MULTI_V4_V5=y CONFIG_ARCH_MULTI_V5=y CONFIG_ARCH_NR_GPIO=0 CONFIG_ARCH_OPTIONAL_KERNEL_RWX=y -CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y -CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y -CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y -CONFIG_ARCH_WANT_GENERAL_HUGETLB=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_ARM=y CONFIG_ARM_HAS_SG_CHAIN=y CONFIG_ARM_L1_CACHE_SHIFT=5 @@ -43,7 +20,6 @@ CONFIG_ARM_THUMB=y CONFIG_ARM_UNWIND=y CONFIG_AUTO_ZRELADDR=y CONFIG_BINFMT_FLAT_ARGVP_ENVP_ON_STACK=y -CONFIG_CC_HAS_KASAN_GENERIC=y CONFIG_CLKDEV_LOOKUP=y CONFIG_CLONE_BACKWARDS=y CONFIG_COMMON_CLK=y @@ -98,42 +74,6 @@ CONFIG_HARDIRQS_SW_RESEND=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y -CONFIG_HAVE_ARCH_AUDITSYSCALL=y -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_PFN_VALID=y -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y -CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -CONFIG_HAVE_CLK=y -CONFIG_HAVE_CLK_PREPARE=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_COPY_THREAD_TLS=y -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DMA_CONTIGUOUS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y -CONFIG_HAVE_EBPF_JIT=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y -CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE_NET_DSA=y -CONFIG_HAVE_OPROFILE=y -CONFIG_HAVE_OPTPROBES=y -CONFIG_HAVE_PCI=y -CONFIG_HAVE_PERF_EVENTS=y -CONFIG_HAVE_PERF_REGS=y -CONFIG_HAVE_PERF_USER_STACK_DUMP=y -CONFIG_HAVE_PROC_CPU=y -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y -CONFIG_HAVE_RSEQ=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y -CONFIG_HAVE_UID16=y -CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y CONFIG_HZ_FIXED=0 CONFIG_HZ_PERIODIC=y CONFIG_INITRAMFS_SOURCE="" @@ -144,6 +84,7 @@ CONFIG_IRQ_WORK=y CONFIG_LIBFDT=y CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_MEMFD_CREATE=y +# CONFIG_MICROCHIP_PIT64B is not set CONFIG_MIGRATION=y CONFIG_MMC=y CONFIG_MMC_BLOCK=y OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 6/8] at91: enable specific sam9x kernel config flags
On 8/20/21 1:42 PM, Claudiu Beznea wrote: Enable specific sam9x kernel config flags. Signed-off-by: Claudiu Beznea --- target/linux/at91/sam9x/config-default | 182 - 1 file changed, 176 insertions(+), 6 deletions(-) diff --git a/target/linux/at91/sam9x/config-default b/target/linux/at91/sam9x/config-default index d8b5c31dc7e5..0b8e8947ee12 100644 --- a/target/linux/at91/sam9x/config-default +++ b/target/linux/at91/sam9x/config-default @@ -20,7 +20,7 @@ CONFIG_ARM_PATCH_PHYS_VIRT=y +CONFIG_INPUT=y +CONFIG_INPUT_KEYBOARD=y +CONFIG_IPV6=y +# CONFIG_IPV6_SEG6_LWTUNNEL is not set IPv6 should not be activated in the target configuration, but it is globally controlled by CONFIG_KERNEL_IPV6. CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_KUSER_HELPERS=y CONFIG_NEED_PER_CPU_KM=y +CONFIG_NFS_FS=y Is NFS really needed build into the kernel? +CONFIG_NLS=y +CONFIG_NVMEM=y +CONFIG_NVMEM_SYSFS=y CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y @@ -130,40 +201,139 @@ CONFIG_OF_FLATTREE=y CONFIG_OF_GPIO=y CONFIG_OF_IRQ=y CONFIG_OF_KOBJ=y +CONFIG_OF_MDIO=y CONFIG_OF_NET=y CONFIG_OLD_SIGACTION=y CONFIG_OLD_SIGSUSPEND3=y CONFIG_PAGE_OFFSET=0xC000 CONFIG_PERF_USE_VMALLOC=y CONFIG_PGTABLE_LEVELS=2 +CONFIG_PHYLIB=y CONFIG_PINCTRL=y CONFIG_PINCTRL_AT91=y # CONFIG_PINCTRL_AT91PIO4 is not set +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_AT91_POWEROFF=y +CONFIG_POWER_RESET_AT91_RESET=y +# CONFIG_POWER_RESET_AT91_SAMA5D2_SHDWC is not set +CONFIG_POWER_SUPPLY=y +CONFIG_PPP=m PPP is added with a kmod package. Selecting anything as =m does not make sense as the module would only be build and not packaged into the image without the OpenWrt kmod package being selected too. The target configuration should only contain the minimal kernel options which are needed for this target. This includes options which are needed to boot up the system and options for driver which are used on most boards like an IP core of the SoC which is used by many boards. +CONFIG_PPPOE=m +CONFIG_PPP_ASYNC=m ... +CONFIG_SCSI=y Is SCSI really needed? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] kernel: disable CONFIG_RCU_EXPERT and friends
On 8/22/21 2:17 PM, Rui Salvaterra wrote: Hi, Hauke, On Sun, 22 Aug 2021 at 10:20, Hauke Mehrtens wrote: There are also some targets which explicitly unset CONFIG_RCU_EXPERT: [snipped] This should be removed from the target config file. Sure thing, I'll clean up the targets and fold the changes into this patch. CONFIG_RCU_STALL_COMMON=y and CONFIG_RCU_NEED_SEGCBLIST=y are also set in most target configurations. Should we move them to the generic configuration? Good question. Those symbols are only relevant when tree RCU is enabled, which is everything except non-preemptible, non-SMP kernels. We don't enable preemption, so basically these will only be relevant for SMP devices. That said, I believe moving them to the generic kconfigs is the right thing to do. Do you agree? Both options are hidden anyway, so we can manually change them: config RCU_STALL_COMMON def_bool ( TREE_RCU || PREEMPT_RCU ) help config RCU_NEED_SEGCBLIST def_bool ( TREE_RCU || PREEMPT_RCU || TREE_SRCU ) They are automatically activated when the dependencies are satisfied. I would add this to the generic kernel configurations and remove the individual ones in a separate patch: CONFIG_RCU_STALL_COMMON=y CONFIG_RCU_NEED_SEGCBLIST=y Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 5/6] qoriq: new target
On 8/22/21 1:15 AM, Stijn Tintel wrote: Add a new target named "qoriq", that will support boards using PowerPC processors from NXP's QorIQ brand. This doesn't actually add support for any board yet, so that installation instructions can go in the commit message of the commit that adds actual support for a board. Signed-off-by: Stijn Tintel --- target/linux/qoriq/Makefile | 21 ++ target/linux/qoriq/config-5.10 | 414 +++ target/linux/qoriq/generic/target.mk | 3 + target/linux/qoriq/image/Makefile| 34 +++ target/linux/qoriq/image/generic.mk | 0 5 files changed, 472 insertions(+) create mode 100644 target/linux/qoriq/Makefile create mode 100644 target/linux/qoriq/config-5.10 create mode 100644 target/linux/qoriq/generic/target.mk create mode 100644 target/linux/qoriq/image/Makefile create mode 100644 target/linux/qoriq/image/generic.mk diff --git a/target/linux/qoriq/Makefile b/target/linux/qoriq/Makefile new file mode 100644 index 00..d9a9f4d226 --- /dev/null +++ b/target/linux/qoriq/Makefile @@ -0,0 +1,21 @@ +# SPDX-License-Identifier: GPL-2.0-only +# +# Copyright (C) 2021 Stijn Tintel + +include $(TOPDIR)/rules.mk + +ARCH:=powerpc64 +BOARD:=qoriq +BOARDNAME:=NXP QorIQ (PowerPC) +CPU_TYPE:=e6500 +FEATURES:=boot-part ext4 fpu legacy-sdcard powerpc64 ramdisk root-part rtc source-only +SUBTARGETS:=generic + +KERNEL_PATCHVER:=5.10 +KERNEL_TESTING_PATCHVER:=5.10 + +KERNELNAME:=zImage + +include $(INCLUDE_DIR)/target.mk + +$(eval $(call BuildTarget)) diff --git a/target/linux/qoriq/config-5.10 b/target/linux/qoriq/config-5.10 new file mode 100644 index 00..d9d7e9bcf4 --- /dev/null +++ b/target/linux/qoriq/config-5.10 @@ -0,0 +1,414 @@ +CONFIG_ASN1=y Why do you need CONFIG_ASN1? +CONFIG_CRYPTO_AUTHENC=y +CONFIG_CRYPTO_CRC32C=y +# CONFIG_CRYPTO_CRC32C_VPMSUM is not set +CONFIG_CRYPTO_DES=y +CONFIG_CRYPTO_DEV_FSL_CAAM=y +CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API_DESC=y +CONFIG_CRYPTO_DEV_FSL_CAAM_COMMON=y +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_DESC=y +CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI=y +# CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG is not set +# CONFIG_CRYPTO_DEV_FSL_CAAM_INTC is not set +CONFIG_CRYPTO_DEV_FSL_CAAM_JR=y +CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API=y +CONFIG_CRYPTO_DEV_FSL_CAAM_RINGSIZE=9 +CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API=y +# CONFIG_CRYPTO_DEV_NX is not set +CONFIG_CRYPTO_ECB=y +CONFIG_CRYPTO_ENGINE=y +CONFIG_CRYPTO_GF128MUL=y +CONFIG_CRYPTO_HW=y +CONFIG_CRYPTO_LIB_DES=y +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=1 +# CONFIG_CRYPTO_MD5_PPC is not set +CONFIG_CRYPTO_NULL2=y +CONFIG_CRYPTO_RNG=y +CONFIG_CRYPTO_RNG2=y +CONFIG_CRYPTO_RSA=y +# CONFIG_CRYPTO_SHA1_PPC is not set +CONFIG_CRYPTO_XTS=y Do you need all this crypto stuff com,piled in or is a module also sufficent? +CONFIG_EXT4_FS=y +CONFIG_EXT4_FS_POSIX_ACL=y +CONFIG_EXT4_FS_SECURITY=y CONFIG_EXT4_FS_SECURITY is normally activated by KERNEL_EXT4_FS_SECURITY in OpenWrt. +CONFIG_GCC_PLUGINS=y Why do you activate CONFIG_GCC_PLUGINS ? +# CONFIG_GCC_PLUGIN_CYC_COMPLEXITY is not set +# CONFIG_GCC_PLUGIN_LATENT_ENTROPY is not set +# CONFIG_GCC_PLUGIN_RANDSTRUCT is not set +# CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF is not set +# CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL is not set +# CONFIG_GCC_PLUGIN_STRUCTLEAK_USER is not set +# CONFIG_HANGCHECK_TIMER is not set +# CONFIG_HARDENED_USERCOPY is not set CONFIG_HARDENED_USERCOPY should only cause crashes when it detects a buffer overflow. Do you have more details about the crashes? +CONFIG_KGDB=y Is KGDB needed in the default kernel config? +CONFIG_KGDB_HONOUR_BLOCKLIST=y +# CONFIG_KGDB_KDB is not set +CONFIG_KGDB_SERIAL_CONSOLE=y +# CONFIG_KGDB_TESTS is not set +CONFIG_PTP_1588_CLOCK=y +CONFIG_PTP_1588_CLOCK_QORIQ=y We also have kmod-ptp-qoriq Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 2/2] kernel: move two symbols to the generic kconfigs
On 8/22/21 3:17 PM, Rui Salvaterra wrote:
CONFIG_RCU_{NEED_SEGCBLIST,STALL_COMMON} are set basically everywhere. Move them
to the generic kconfigs. And resort the generic kconfigs while at it.
Signed-off-by: Rui Salvaterra
---
target/linux/arc770/config-5.4 | 2 --
target/linux/archs38/config-5.4 | 2 --
target/linux/armvirt/config-5.10 | 2 --
target/linux/armvirt/config-5.4 | 2 --
target/linux/bcm27xx/bcm2709/config-5.10 | 2 --
target/linux/bcm27xx/bcm2709/config-5.4 | 2 --
target/linux/bcm27xx/bcm2710/config-5.10 | 2 --
target/linux/bcm27xx/bcm2710/config-5.4 | 2 --
target/linux/bcm27xx/bcm2711/config-5.10 | 2 --
target/linux/bcm27xx/bcm2711/config-5.4 | 2 --
target/linux/bcm4908/config-5.4 | 2 --
target/linux/bcm53xx/config-5.10 | 2 --
target/linux/bcm53xx/config-5.4 | 2 --
target/linux/bcm63xx/smp/config-default | 1 -
target/linux/bmips/config-5.10 | 2 --
target/linux/gemini/config-5.10 | 2 --
target/linux/gemini/config-5.4 | 2 --
target/linux/generic/config-5.10 | 3 ++-
target/linux/generic/config-5.4 | 14 --
target/linux/imx6/config-5.10| 2 --
target/linux/imx6/config-5.4 | 2 --
target/linux/ipq40xx/config-5.4 | 2 --
target/linux/ipq806x/config-5.10 | 2 --
target/linux/ipq806x/config-5.4 | 2 --
target/linux/ipq807x/config-default | 2 --
target/linux/lantiq/xrx200/config-5.10 | 2 --
target/linux/lantiq/xrx200/config-5.4| 2 --
target/linux/layerscape/armv7/config-5.4 | 2 --
target/linux/layerscape/armv8_64b/config-5.4 | 2 --
target/linux/malta/config-5.10 | 2 --
target/linux/malta/config-5.4| 2 --
target/linux/mediatek/mt7622/config-5.10 | 2 --
target/linux/mediatek/mt7623/config-5.10 | 2 --
target/linux/mediatek/mt7629/config-5.4 | 2 --
target/linux/mpc85xx/p1020/config-default| 1 -
target/linux/mpc85xx/p2020/config-default| 2 --
target/linux/mvebu/config-5.10 | 2 --
target/linux/mvebu/config-5.4| 2 --
target/linux/octeon/config-5.10 | 2 --
target/linux/octeon/config-5.4 | 2 --
target/linux/octeontx/config-5.4 | 2 --
target/linux/omap/config-5.4 | 2 --
target/linux/oxnas/ox810se/config-default| 2 --
target/linux/oxnas/ox820/config-default | 2 --
target/linux/pistachio/config-5.4| 2 --
target/linux/ramips/mt7621/config-5.10 | 2 --
target/linux/ramips/mt7621/config-5.4| 2 --
target/linux/rockchip/armv8/config-5.10 | 2 --
target/linux/rockchip/armv8/config-5.4 | 2 --
target/linux/sunxi/config-5.4| 2 --
target/linux/tegra/config-5.10 | 2 --
target/linux/tegra/config-5.4| 2 --
target/linux/x86/64/config-5.10 | 2 --
target/linux/x86/64/config-5.4 | 2 --
target/linux/x86/generic/config-5.10 | 2 --
target/linux/x86/generic/config-5.4 | 2 --
target/linux/zynq/config-5.4 | 2 --
57 files changed, 10 insertions(+), 115 deletions(-)
diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10
index 91f137fbc3..007ad89f57 100644
--- a/target/linux/generic/config-5.10
+++ b/target/linux/generic/config-5.10
@@ -4633,9 +4633,11 @@ CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_RCU_EXPEDITE_BOOT is not set
# CONFIG_RCU_EXPERT is not set
CONFIG_RCU_KTHREAD_PRIO=0
+CONFIG_RCU_NEED_SEGCBLIST=y
# CONFIG_RCU_PERF_TEST is not set
# CONFIG_RCU_REF_SCALE_TEST is not set
# CONFIG_RCU_SCALE_TEST is not set
+CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_STRICT_GRACE_PERIOD is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY=3
@@ -6816,7 +6818,6 @@ CONFIG_VHOST_MENU=y
# CONFIG_VIDEO_IMX355 is not set
# CONFIG_VIDEO_IMX477 is not set
# CONFIG_VIDEO_IR_I2C is not set
-# CONFIG_VIDEO_IRS1125 is not set
Why is this only removed?
# CONFIG_VIDEO_IVTV is not set
# CONFIG_VIDEO_KS0127 is not set
# CONFIG_VIDEO_LM3560 is not set
OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/2] kernel: disable CONFIG_RCU_EXPERT and friends
On 8/22/21 3:17 PM, Rui Salvaterra wrote: Based on the existing documentation [1][2], I dare anyone to demonstrate that we need to fine-tune these RCU parameters. The (performance) breakage potential for doing so is immense, so let's just please put down this loaded footgun. Disable CONFIG_RCU_EXPERT and its dependent symbols. Additionally, remove the CONFIG_RCU_EXPERT symbol from the target kconfigs which contain it. [1] https://www.kernel.org/doc/Documentation/RCU/Design/Data-Structures/Data-Structures.html [2] https://lwn.net/Articles/777214/ Signed-off-by: Rui Salvaterra Acked-by: Hauke Mehrtens --- target/linux/gemini/config-5.10 | 1 - target/linux/gemini/config-5.4 | 1 - target/linux/generic/config-5.10 | 7 +-- target/linux/generic/config-5.4 | 6 +- target/linux/ipq807x/config-default | 1 - target/linux/layerscape/armv7/config-5.4 | 1 - target/linux/layerscape/armv8_64b/config-5.4 | 1 - target/linux/mediatek/mt7623/config-5.10 | 1 - target/linux/oxnas/ox810se/config-default| 1 - target/linux/oxnas/ox820/config-default | 1 - target/linux/rockchip/armv8/config-5.10 | 1 - target/linux/rockchip/armv8/config-5.4 | 1 - target/linux/tegra/config-5.10 | 1 - target/linux/tegra/config-5.4| 1 - 14 files changed, 2 insertions(+), 23 deletions(-) diff --git a/target/linux/gemini/config-5.10 b/target/linux/gemini/config-5.10 index 2382e85bea..37a7b16a25 100644 --- a/target/linux/gemini/config-5.10 +++ b/target/linux/gemini/config-5.10 @@ -333,7 +333,6 @@ CONFIG_PREEMPT_RCU=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_RATIONAL=y CONFIG_RCU_CPU_STALL_TIMEOUT=21 -# CONFIG_RCU_EXPERT is not set CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_RCU_STALL_COMMON=y CONFIG_RD_BZIP2=y diff --git a/target/linux/gemini/config-5.4 b/target/linux/gemini/config-5.4 index 9d84571b3c..702810413c 100644 --- a/target/linux/gemini/config-5.4 +++ b/target/linux/gemini/config-5.4 @@ -369,7 +369,6 @@ CONFIG_PREEMPT_RCU=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_RATIONAL=y CONFIG_RCU_CPU_STALL_TIMEOUT=21 -# CONFIG_RCU_EXPERT is not set CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_RCU_STALL_COMMON=y CONFIG_RD_BZIP2=y diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index f944f1718f..91f137fbc3 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -4631,12 +4631,8 @@ CONFIG_PWRSEQ_SIMPLE=y CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_RCU_EQS_DEBUG is not set # CONFIG_RCU_EXPEDITE_BOOT is not set -CONFIG_RCU_EXPERT=y -CONFIG_RCU_FANOUT=32 -CONFIG_RCU_FANOUT_LEAF=16 -# CONFIG_RCU_FAST_NO_HZ is not set +# CONFIG_RCU_EXPERT is not set CONFIG_RCU_KTHREAD_PRIO=0 -# CONFIG_RCU_NOCB_CPU is not set # CONFIG_RCU_PERF_TEST is not set # CONFIG_RCU_REF_SCALE_TEST is not set # CONFIG_RCU_SCALE_TEST is not set @@ -5995,7 +5991,6 @@ CONFIG_SYSVIPC_SYSCTL=y # CONFIG_TARGET_CORE is not set # CONFIG_TASKSTATS is not set # CONFIG_TASKS_RCU is not set -CONFIG_TASKS_TRACE_RCU_READ_MB=y # CONFIG_TASK_XACCT is not set # CONFIG_TC35815 is not set # CONFIG_TCG_ATMEL is not set diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4 index 45d8f0976e..06f5e43a6d 100644 --- a/target/linux/generic/config-5.4 +++ b/target/linux/generic/config-5.4 @@ -4262,12 +4262,8 @@ CONFIG_PWRSEQ_SIMPLE=y CONFIG_RCU_CPU_STALL_TIMEOUT=60 # CONFIG_RCU_EQS_DEBUG is not set # CONFIG_RCU_EXPEDITE_BOOT is not set -CONFIG_RCU_EXPERT=y -CONFIG_RCU_FANOUT=32 -CONFIG_RCU_FANOUT_LEAF=16 -# CONFIG_RCU_FAST_NO_HZ is not set +# CONFIG_RCU_EXPERT is not set CONFIG_RCU_KTHREAD_PRIO=0 -# CONFIG_RCU_NOCB_CPU is not set # CONFIG_RCU_PERF_TEST is not set # CONFIG_RCU_TORTURE_TEST is not set CONFIG_RCU_TORTURE_TEST_SLOW_INIT_DELAY=3 diff --git a/target/linux/ipq807x/config-default b/target/linux/ipq807x/config-default index 94acb8672d..fc77a4995b 100644 --- a/target/linux/ipq807x/config-default +++ b/target/linux/ipq807x/config-default @@ -531,7 +531,6 @@ CONFIG_QUEUED_SPINLOCKS=y # CONFIG_RANDOMIZE_BASE is not set CONFIG_RATIONAL=y CONFIG_RCU_CPU_STALL_TIMEOUT=21 -# CONFIG_RCU_EXPERT is not set CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_RCU_STALL_COMMON=y CONFIG_RD_GZIP=y diff --git a/target/linux/layerscape/armv7/config-5.4 b/target/linux/layerscape/armv7/config-5.4 index 54ac6a4152..126402d76c 100644 --- a/target/linux/layerscape/armv7/config-5.4 +++ b/target/linux/layerscape/armv7/config-5.4 @@ -505,7 +505,6 @@ CONFIG_QORIQ_CPUFREQ=y CONFIG_RAS=y CONFIG_RATIONAL=y CONFIG_RCU_CPU_STALL_TIMEOUT=21 -# CONFIG_RCU_EXPERT is not set CONFIG_RCU_NEED_SEGCBLIST=y CONFIG_RCU_STALL_COMMON=y CONFIG_RD_BZIP2=y diff --git a/target/linux/layerscape/armv8_64b/config-5.4 b/target/linux/layerscape/armv8_64b/config-5.4 index 2ab42c9d70..6846fc96aa 100644 --- a/target/linux/layerscape/armv8_64b/config-5.4 +++ b/target/
Re: [PATCH] prereq-build: require python3-distutils
Hi Andre, I will backport this to 21.02 in the next days. I want to wait if there are more problems showing up in master. Hauke On 8/23/21 10:47 PM, Andre Heider wrote: Hi Hauke, thanks for merging the patch! Can we also get this cherry-picked to the 21.02 branch, please? Jeffery makes some good points as to why here: https://github.com/openwrt/packages/pull/16304#issuecomment-904097018 I too can see that package backports could get unnecessarily painful in the future without this in 21.02. Thanks, Andre On 10/08/2021 12:22, Andre Heider wrote: Debian and Ubuntu ship a python3-minimal package which does not include the distutils module. This is not supported by upstream and can be considered a broken python distribution. In practice, many scripts depend on said module, and this is a reoccuring pain point for building various OpenWrt packages. Require and check for said module, enough time has been wasted on this. A list of just the most recent issues: https://github.com/openwrt/packages/pull/16304 https://github.com/openwrt/packages/pull/16027 https://github.com/openwrt/packages/pull/15443 https://github.com/openwrt/packages/pull/14394 https://github.com/openwrt/packages/pull/12909 https://github.com/openwrt/packages/issues/12443 https://github.com/openwrt/packages/pull/11035 https://github.com/openwrt/packages/issues/10993 Signed-off-by: Andre Heider --- include/prereq-build.mk | 4 1 file changed, 4 insertions(+) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 8fbf6f22c4..922e7c544b 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -170,6 +170,10 @@ $(eval $(call SetupHostCommand,python3,Please install Python >= 3.6, \ python3.6 -V 2>&1 | grep 'Python 3', \ python3 -V 2>&1 | grep -E 'Python 3\.[6-9]\.?')) +$(eval $(call TestHostCommand,python3-distutils, \ + Please install the Python3 distutils module, \ + $(STAGING_DIR_HOST)/bin/python3 -c 'import distutils')) + $(eval $(call SetupHostCommand,git,Please install Git (git-core) >= 1.7.12.2, \ git --exec-path | xargs -I % -- grep -q -- --recursive %/git-submodule)) OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi, We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. On 7/17/21 5:45 PM, Hauke Mehrtens wrote: Currently we still have these problem: - IPv6 broken with flow offloading (according to reports, potentially related to hw flow offloading) - PPPoE allegedly broken (according to reports, not fully reproducible, likely related to hw flow offloading too) - https://bugs.openwrt.org/index.php?do=details&task_id=3909 - https://bugs.openwrt.org/index.php?do=details&task_id=3835 Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details&task_id=3373 https://bugs.openwrt.org/index.php?do=details&task_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. Should we just release with this as a known problem? Other than this problem I am not aware of any other critical problem. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] prereq-build: require python3-distutils
Hi Andre, I pushed this to 21.02 now. Hauke On 8/24/21 12:21 AM, Andre Heider wrote: Nice, sounds good, thanks! On 23/08/2021 23:12, Hauke Mehrtens wrote: Hi Andre, I will backport this to 21.02 in the next days. I want to wait if there are more problems showing up in master. Hauke On 8/23/21 10:47 PM, Andre Heider wrote: Hi Hauke, thanks for merging the patch! Can we also get this cherry-picked to the 21.02 branch, please? Jeffery makes some good points as to why here: https://github.com/openwrt/packages/pull/16304#issuecomment-904097018 I too can see that package backports could get unnecessarily painful in the future without this in 21.02. Thanks, Andre On 10/08/2021 12:22, Andre Heider wrote: Debian and Ubuntu ship a python3-minimal package which does not include the distutils module. This is not supported by upstream and can be considered a broken python distribution. In practice, many scripts depend on said module, and this is a reoccuring pain point for building various OpenWrt packages. Require and check for said module, enough time has been wasted on this. A list of just the most recent issues: https://github.com/openwrt/packages/pull/16304 https://github.com/openwrt/packages/pull/16027 https://github.com/openwrt/packages/pull/15443 https://github.com/openwrt/packages/pull/14394 https://github.com/openwrt/packages/pull/12909 https://github.com/openwrt/packages/issues/12443 https://github.com/openwrt/packages/pull/11035 https://github.com/openwrt/packages/issues/10993 Signed-off-by: Andre Heider --- include/prereq-build.mk | 4 1 file changed, 4 insertions(+) diff --git a/include/prereq-build.mk b/include/prereq-build.mk index 8fbf6f22c4..922e7c544b 100644 --- a/include/prereq-build.mk +++ b/include/prereq-build.mk @@ -170,6 +170,10 @@ $(eval $(call SetupHostCommand,python3,Please install Python >= 3.6, \ python3.6 -V 2>&1 | grep 'Python 3', \ python3 -V 2>&1 | grep -E 'Python 3\.[6-9]\.?')) +$(eval $(call TestHostCommand,python3-distutils, \ + Please install the Python3 distutils module, \ + $(STAGING_DIR_HOST)/bin/python3 -c 'import distutils')) + $(eval $(call SetupHostCommand,git,Please install Git (git-core) >= 1.7.12.2, \ git --exec-path | xargs -I % -- grep -q -- --recursive %/git-submodule)) OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kernel: Set CONFIG_RCU_CPU_STALL_TIMEOUT=21
The default value for CONFIG_RCU_CPU_STALL_TIMEOUT was changed from 60 seconds to 21 seconds in 2012 in the upstream kernel. Some targets already use 21 seconds. This patch changes the default value in the generic configuration to 21 seconds and removes the target specific configuration options. Signed-off-by: Hauke Mehrtens --- target/linux/gemini/config-5.10 | 1 - target/linux/gemini/config-5.4 | 1 - target/linux/generic/config-5.10 | 2 +- target/linux/generic/config-5.4 | 2 +- target/linux/ipq40xx/config-5.4 | 1 - target/linux/ipq806x/config-5.10 | 1 - target/linux/ipq806x/config-5.4 | 1 - target/linux/ipq807x/config-default | 1 - target/linux/layerscape/armv7/config-5.4 | 1 - target/linux/layerscape/armv8_64b/config-5.4 | 1 - target/linux/mediatek/mt7623/config-5.10 | 1 - target/linux/oxnas/ox820/config-default | 1 - target/linux/rockchip/armv8/config-5.10 | 1 - target/linux/rockchip/armv8/config-5.4 | 1 - target/linux/tegra/config-5.10 | 1 - target/linux/tegra/config-5.4| 1 - 16 files changed, 2 insertions(+), 16 deletions(-) diff --git a/target/linux/gemini/config-5.10 b/target/linux/gemini/config-5.10 index 319fb6abfd68..7fdcc075e621 100644 --- a/target/linux/gemini/config-5.10 +++ b/target/linux/gemini/config-5.10 @@ -332,7 +332,6 @@ CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPT_RCU=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_RATIONAL=y -CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RD_BZIP2=y CONFIG_RD_GZIP=y CONFIG_RD_LZ4=y diff --git a/target/linux/gemini/config-5.4 b/target/linux/gemini/config-5.4 index 8a4f8fb04cf2..fcb482aed7bb 100644 --- a/target/linux/gemini/config-5.4 +++ b/target/linux/gemini/config-5.4 @@ -368,7 +368,6 @@ CONFIG_PREEMPT_COUNT=y CONFIG_PREEMPT_RCU=y CONFIG_PROC_PAGE_MONITOR=y CONFIG_RATIONAL=y -CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RD_BZIP2=y CONFIG_RD_GZIP=y CONFIG_RD_LZ4=y diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index 02e8ce18d123..27d6fc5bf2ba 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -4628,7 +4628,7 @@ CONFIG_PWRSEQ_SIMPLE=y # CONFIG_RAW_DRIVER is not set # CONFIG_RBTREE_TEST is not set # CONFIG_RCU_BOOST is not set -CONFIG_RCU_CPU_STALL_TIMEOUT=60 +CONFIG_RCU_CPU_STALL_TIMEOUT=21 # CONFIG_RCU_EQS_DEBUG is not set # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_RCU_EXPERT is not set diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4 index 4e40b07b479d..ede4c5ce848b 100644 --- a/target/linux/generic/config-5.4 +++ b/target/linux/generic/config-5.4 @@ -4259,7 +4259,7 @@ CONFIG_PWRSEQ_SIMPLE=y # CONFIG_RAW_DRIVER is not set # CONFIG_RBTREE_TEST is not set # CONFIG_RCU_BOOST is not set -CONFIG_RCU_CPU_STALL_TIMEOUT=60 +CONFIG_RCU_CPU_STALL_TIMEOUT=21 # CONFIG_RCU_EQS_DEBUG is not set # CONFIG_RCU_EXPEDITE_BOOT is not set # CONFIG_RCU_EXPERT is not set diff --git a/target/linux/ipq40xx/config-5.4 b/target/linux/ipq40xx/config-5.4 index 0bcabd0582b2..79c6d6c6c267 100644 --- a/target/linux/ipq40xx/config-5.4 +++ b/target/linux/ipq40xx/config-5.4 @@ -378,7 +378,6 @@ CONFIG_QCOM_WDT=y # CONFIG_QRTR is not set CONFIG_RAS=y CONFIG_RATIONAL=y -CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_REFCOUNT_FULL=y CONFIG_REGMAP=y CONFIG_REGMAP_I2C=y diff --git a/target/linux/ipq806x/config-5.10 b/target/linux/ipq806x/config-5.10 index b4460af17a19..77d1bbda4252 100644 --- a/target/linux/ipq806x/config-5.10 +++ b/target/linux/ipq806x/config-5.10 @@ -404,7 +404,6 @@ CONFIG_QCOM_WDT=y # CONFIG_QCS_TURING_404 is not set CONFIG_RAS=y CONFIG_RATIONAL=y -CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_REGMAP=y CONFIG_REGMAP_MMIO=y CONFIG_REGULATOR=y diff --git a/target/linux/ipq806x/config-5.4 b/target/linux/ipq806x/config-5.4 index 4aecf7dd43f3..191806585da9 100644 --- a/target/linux/ipq806x/config-5.4 +++ b/target/linux/ipq806x/config-5.4 @@ -370,7 +370,6 @@ CONFIG_QCOM_WDT=y # CONFIG_QRTR is not set CONFIG_RAS=y CONFIG_RATIONAL=y -CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_REFCOUNT_FULL=y CONFIG_REGMAP=y CONFIG_REGMAP_MMIO=y diff --git a/target/linux/ipq807x/config-default b/target/linux/ipq807x/config-default index 383d57c4a1aa..ad4aca1b48b9 100644 --- a/target/linux/ipq807x/config-default +++ b/target/linux/ipq807x/config-default @@ -530,7 +530,6 @@ CONFIG_QUEUED_RWLOCKS=y CONFIG_QUEUED_SPINLOCKS=y # CONFIG_RANDOMIZE_BASE is not set CONFIG_RATIONAL=y -CONFIG_RCU_CPU_STALL_TIMEOUT=21 CONFIG_RD_GZIP=y CONFIG_REFCOUNT_FULL=y CONFIG_REGMAP=y diff --git a/target/linux/layerscape/armv7/config-5.4 b/target/linux/layerscape/armv7/config-5.4 index 2db242e85805..ed2e318cd632 100644 --- a/target/linux/layerscape/armv7/config-5.4 +++ b/target/linux/layerscape/armv7/config-5.4 @@ -504,7 +504,6 @@ CONFIG_QORIQ_CPUFREQ=y # CONFIG_QUICC_ENGINE is not set CONFIG_RAS=y CONFIG_RATIONAL=y
Re: OpenWrt 21.02: backport lantiq xrx200 DSA switch
On 7/1/21 10:06 AM, Martin Blumenstingl wrote: Hi Martin, On Thu, Jul 1, 2021 at 8:02 AM Martin Schiller wrote: Hello all! Now that the Lantiq xrx200 DSA switch has finally made it into the master, I would like to ask whether we also want to pack this switch into the 21.02 release. The DSA changes were tested on multiple devices (before the pull request was merged). Also I think backporting this to 21.02 would make many people in the Home Hub 5A community happy, as they've been waiting for this for some time now. The topic "DSA Support" is one of the key points of the 21.02 release and therefore this would fit very well. Any opinions? In general I am fine with backporting this. The part that I am not sure about is the OpenWrt release schedule for 21.02 - so I'll let others comment on this. Hi, I would prefer if we stay with swconfig for lantiq in 21.02 and use DSA on lantiq with the next release. If we would switch now probably more problems would show up shortly before the release. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 8/29/21 11:53 AM, Hauke Mehrtens wrote: Hi, We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. On 7/17/21 5:45 PM, Hauke Mehrtens wrote: Currently we still have these problem: - IPv6 broken with flow offloading (according to reports, potentially related to hw flow offloading) - PPPoE allegedly broken (according to reports, not fully reproducible, likely related to hw flow offloading too) - https://bugs.openwrt.org/index.php?do=details&task_id=3909 - https://bugs.openwrt.org/index.php?do=details&task_id=3835 Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details&task_id=3373 https://bugs.openwrt.org/index.php?do=details&task_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. Should we just release with this as a known problem? Other than this problem I am not aware of any other critical problem. Hauke Hi all, All people who answered agreed to do the release soon and keep this as a known bug. I plan to tag 21.02.0 on Wednesday, 1. September if no one objects. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 8/31/21 1:52 PM, Alexander E. Patrakov wrote: Hauke Mehrtens wrote: We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. ... Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details&task_id=3373 https://bugs.openwrt.org/index.php?do=details&task_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. There is no need to debug this problem. Just revert the patch, because the upstream kernel history looks like this: Jun 15, 2018, e97d940: flow offload pickup timeouts were changed to hard-coded values, 120 seconds for TCP and 30 seconds for UDP, because the author had a concern with the "established" timeout to be too huge for this purpose. Jun 3, 2021, 1d91d2e: sysctls are introduced so that the timeouts for picking up offloaded flows are configurable, because they were too low for some use cases. Aug 4, 2021, 4592ee7: the timeouts were bumped again to their old "established" values, sysctls are removed, the motivation is, essentially, that the pickup timeouts were effectively acting like the new version of established timeouts. I.e., the patch was effectively reverted upstream. Thanks for looking into this problem. I would prefer to not delay the release any further and will take care of this after the release. Did you test this and see improvements in your scenarios? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
On 9/1/21 4:15 AM, Andy Botting wrote: On Wed, 1 Sept 2021 at 11:56, Alexander E. Patrakov wrote: Hauke Mehrtens : On 8/31/21 1:52 PM, Alexander E. Patrakov wrote: Hauke Mehrtens wrote: We did the 21.02-rc4, but there is still a problem with flow offloading as this was not fixed. The other problems should be fixed now. ... Some more information can be found here: https://forum.openwrt.org/t/software-flow-offloading-and-conntrack-timeouts/74588 https://bugs.openwrt.org/index.php?do=details&task_id=3373 https://bugs.openwrt.org/index.php?do=details&task_id=3759 It could be that this change causes the problems: https://patchwork.ozlabs.org/project/netdev/patch/20180720130906.27687-3-pa...@netfilter.org/ I do not know how much time and interest I have in debugging and fixing this problem. If someone wants to have a closer look into this problem it would be really nice. even when you can make it easier to reproduce it in a test environment it would be nice. There is no need to debug this problem. Just revert the patch, because the upstream kernel history looks like this: Jun 15, 2018, e97d940: flow offload pickup timeouts were changed to hard-coded values, 120 seconds for TCP and 30 seconds for UDP, because the author had a concern with the "established" timeout to be too huge for this purpose. Jun 3, 2021, 1d91d2e: sysctls are introduced so that the timeouts for picking up offloaded flows are configurable, because they were too low for some use cases. Aug 4, 2021, 4592ee7: the timeouts were bumped again to their old "established" values, sysctls are removed, the motivation is, essentially, that the pickup timeouts were effectively acting like the new version of established timeouts. I.e., the patch was effectively reverted upstream. I'd be happy to try it soon if you could point me to the specific commit. I can reproduce the issue quite easily here. Thanks! Hi, The commits are in the mail. You could try to revert this one: https://git.kernel.org/linus/e97d9404d5e8aea1f91f4c00dbe7854008f3a1e1 in Linux 5.15 it will be more or less reverted again. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.0 - First Stable Release
Hi, The OpenWrt community is proud to announce the first stable release of the OpenWrt 21.02 stable version series. It incorporates over 5800 commits since branching the previous OpenWrt 19.07 release and has been under development for about one and a half year. Highlights in OpenWrt 21.02.0 - --- WPA3 support included by default WPA3 was already supported in 19.07 but it was not provided by the default set of packages in OpenWrt images. With 21.02, all packages necessary to provide WPA3 are installed by default in OpenWrt images. WPA3 is supported by most Wifi drivers in OpenWrt. - --- TLS and HTTPS support included by default TLS support is now provided by default in OpenWrt images including the trusted CA certificates from Mozilla. It means that wget and opkg now support fetching resources over HTTPS out-of-the-box. The opkg download server is accessed through HTTPS by default. OpenWrt switched from mbedTLS to wolfSSL as the default SSL library. mbedTLS and OpenSSL are still available and can be installed manually. In addition, LuCI is now available over HTTPS in addition to HTTP. There is no automatic redirection to HTTPS on a fresh OpenWrt 21.02 installation; however, redirection will be enabled after upgrading from OpenWrt 19.07 to OpenWrt 21.02. It is always possible to activate or deactivate the redirection to HTTPS like this: uci set uhttpd.main.redirect_https=1 # 1 to enable redirect, 0 to disable redirect uci commit uhttpd service uhttpd reload - --- Initial DSA support DSA stands for Distributed Switch Architecture and is the Linux standard to deal with configurable Ethernet switches. OpenWrt 21.02 comes with initial support for DSA, which replaces the swconfig system that OpenWrt was using up until now. Not all targets have been ported: some devices still use swconfig while some devices already switched to DSA. This is a significant change to how switch ports and VLANs are managed. As such, sysupgrade will not be able to convert existing swconfig configuration to DSA configuration (see “Upgrading” below). See the OpenWrt DSA Networking documentation for details. https://openwrt.org/docs/guide-user/network/dsa/start The following targets are using a switch managed with DSA in OpenWrt 21.02: * ath79 (only TP-Link TL-WR941ND) * bcm4908 * gemini * kirkwood * mediatek (most boards) * mvebu * octeon * ramips (mt7621 subtarget only) * realtek - --- Increased minimum hardware requirements: 8 MB flash, 64 MB RAM Due to new features being introduced and the general size increase of the Linux kernel, devices now need at least 8 MB of flash and 64 MB of RAM to run a default build of OpenWrt. More flash space is recommended for extensibility, see 8/64 warning: https://openwrt.org/supported_devices/864_warning It is still possible to build custom OpenWrt images (e.g. using the ImageBuilder) that may fit devices with 4 MB of flash or 32 MB of RAM. However, the level of functionality will be reduced and there is no guarantee to stability. See OpenWrt on 4/32 devices for more details and guidance. https://openwrt.org/supported_devices/openwrt_on_432_devices - --- New network configuration syntax and board.json change There have been several changes to the network configuration syntax in /etc/config/network: * in config interface, option ifname has been renamed to device (since it refers to a device section) * in config device of type bridge, ifname has been renamed to ports * for new installs, the generated configuration now creates separate sections for layer 2 (config device) and layer 3 (config interface) configuration The old syntax is still supported to facilitate transition, and there is no automated migration when upgrading. However, the LuCI web interface detects old-style configuration and will propose to migrate it to the new syntax. This is necessary to be able to edit network configuration through LuCI. New UCI syntax The new configuration style looks like this: config device option name 'br-lan' option type 'bridge' option macaddr '00:01:02:XX:XX:XX' list ports 'lan1' list ports 'lan2' list ports 'lan3' list ports 'lan4' config interface 'lan' option device 'br-lan' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' config device option name 'eth1' option macaddr '00:01:02:YY:YY:YY' config interface 'wan' option device 'eth1' option proto 'dhcp' config interface 'wan6' option device 'eth1' option proto 'dhcpv6' This example uses DSA with lanX interface names. A non-DSA device would use more classical ethX interface names. Changes to board.json In addition, network fields in board.json have also been renamed from “ifname” to “device”. In addition, DSA bridges no
Re: [PATCH v2] mvebu/kernel: promote 5.10 to stable
On 9/7/21 11:36 PM, Rui Salvaterra wrote: It's been brewing on my cortexa9 subtarget (Turris Omnia) for months. Perfectly stable. Signed-off-by: Rui Salvaterra Acked-by: Hauke Mehrtens --- v2: remove KERNEL_TESTING_PATCHVER altogether, as per dangole's suggestion. target/linux/mvebu/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/linux/mvebu/Makefile b/target/linux/mvebu/Makefile index 3737a4aa23..d629e0eb2b 100644 --- a/target/linux/mvebu/Makefile +++ b/target/linux/mvebu/Makefile @@ -9,8 +9,7 @@ BOARDNAME:=Marvell EBU Armada FEATURES:=fpu usb pci pcie gpio nand squashfs ramdisk boot-part rootfs-part legacy-sdcard SUBTARGETS:=cortexa9 cortexa53 cortexa72 -KERNEL_PATCHVER:=5.4 -KERNEL_TESTING_PATCHVER:=5.10 +KERNEL_PATCHVER:=5.10 include $(INCLUDE_DIR)/target.mk OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] x86: switch to 5.10 kernel
On 9/7/21 11:39 PM, Paul Spooren wrote: Seems to be working fine in Docker containers. Signed-off-by: Paul Spooren Acked-by: Hauke Mehrtens --- v2: Remove redundant TESTING_PATCHVER target/linux/x86/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/linux/x86/Makefile b/target/linux/x86/Makefile index 0ab322d8bc..fbad527e0a 100644 --- a/target/linux/x86/Makefile +++ b/target/linux/x86/Makefile @@ -10,8 +10,7 @@ BOARDNAME:=x86 FEATURES:=squashfs ext4 vdi vmdk pcmcia targz fpu boot-part rootfs-part SUBTARGETS:=generic legacy geode 64 -KERNEL_PATCHVER:=5.4 -KERNEL_TESTING_PATCHVER:=5.10 +KERNEL_PATCHVER:=5.10 KERNELNAME:=bzImage OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] base-files: make os-release symbolic link absolute
On 9/8/21 2:50 PM, Florian Eckert wrote: The file `/etc/os-release` is currently a relative link to `../usr/lib/os-release`. The follwing links on my `/etc` are also absolute: * localtime -> /tmp/localtime * resolv.conf -> /tmp/resolv.conf * /tmp/TZmtab -> /proc/mounts For consistency, this should also apply to `/usr/lib/os-release`. Is there any other reason than consistency to change this? I prefer relative links because they also work when the file system is accessed by the build system like Paul said. Hauke Signed-off-by: Florian Eckert --- package/base-files/files/etc/os-release | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/base-files/files/etc/os-release b/package/base-files/files/etc/os-release index c4c75b419c..d98fc7a7ac 12 --- a/package/base-files/files/etc/os-release +++ b/package/base-files/files/etc/os-release @@ -1 +1 @@ -../usr/lib/os-release \ No newline at end of file +/usr/lib/os-release \ No newline at end of file ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/6] at91: kernel: bump to 5.10
On 8/30/21 11:39 AM, Claudiu Beznea wrote: Bump at91 targets to kernel v5.10. With this patches and files for wb45n and wb50n were removed as they are now included in upstream kernel. Along with this: - the kernel config for sam9x targets has been refreshed (with make kernel_menuconfig + save); - CONFIG_ARCH_AT91 and specific sam9x SoCs (AT91RM9200, AT91SAM9, SAM9X60) has been enabled such that sam9x SoCs to be able to boot. Signed-off-by: Claudiu Beznea --- target/linux/at91/Makefile| 2 +- .../at91/files/arch/arm/boot/dts/wb45n.dts| 220 -- .../at91/files/arch/arm/boot/dts/wb50n.dts| 113 - .../at91/files/arch/arm/boot/dts/wb50n.dtsi | 205 target/linux/at91/image/sam9x.mk | 1 + target/linux/at91/image/sama5.mk | 1 + .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 + .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 - .../102-ARM-at91-build-dtb-for-wb45n.patch| 12 - ...2-ARM-at91-wb45n-fix-duplicate-label.patch | 20 -- .../103-ARM-at91-build-dtb-for-wb50n.patch| 12 - ...3-ARM-at91-wb50n-fix-duplicate-label.patch | 39 target/linux/at91/sam9x/config-default| 105 - 13 files changed, 57 insertions(+), 693 deletions(-) delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb45n.dts delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dts delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dtsi create mode 04 target/linux/at91/patches-5.10 create mode 100644 target/linux/at91/patches-5.10/101-ARM-at91-build-dtb-for-q5xr5.patch delete mode 04 target/linux/at91/patches-5.4 delete mode 100644 target/linux/at91/patches-5.4/101-ARM-at91-build-dtb-for-q5xr5.patch delete mode 100644 target/linux/at91/patches-5.4/102-ARM-at91-build-dtb-for-wb45n.patch delete mode 100644 target/linux/at91/patches-5.4/102-ARM-at91-wb45n-fix-duplicate-label.patch delete mode 100644 target/linux/at91/patches-5.4/103-ARM-at91-build-dtb-for-wb50n.patch delete mode 100644 target/linux/at91/patches-5.4/103-ARM-at91-wb50n-fix-duplicate-label.patch .. -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y -CONFIG_HAVE_RSEQ=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y -CONFIG_HAVE_UID16=y -CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y -CONFIG_HZ_FIXED=0 +CONFIG_HZ=128 +CONFIG_HZ_FIXED=128 CONFIG_HZ=100 is set in the generic configuration, do you really need 128? CONFIG_HZ_PERIODIC=y CONFIG_INITRAMFS_SOURCE="" CONFIG_IRQCHIP=y OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/6] at91: enable specific sam9x kernel config flags
On 8/30/21 11:39 AM, Claudiu Beznea wrote: Enable specific sam9x kernel config flags. Signed-off-by: Claudiu Beznea --- target/linux/at91/sam9x/config-default | 168 +++-- 1 file changed, 159 insertions(+), 9 deletions(-) @@ -39,6 +44,7 @@ CONFIG_CLONE_BACKWARDS=y CONFIG_COMMON_CLK=y CONFIG_COMMON_CLK_AT91=y CONFIG_COMPAT_32BIT_TIME=y +CONFIG_CONFIGFS_FS=m Please remove the config options setting something to =m. This should only be done by packages in package/kernel/. This was done in multiple places. CONFIG_CPU_32v4T=y CONFIG_CPU_32v5=y CONFIG_CPU_ABRT_EV4T=y @@ -57,17 +63,34 @@ CONFIG_CPU_PABRT_LEGACY=y OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/6] at91: kernel: bump to 5.10
On 8/30/21 11:39 AM, Claudiu Beznea wrote: Bump at91 targets to kernel v5.10. With this patches and files for wb45n and wb50n were removed as they are now included in upstream kernel. Along with this: - the kernel config for sam9x targets has been refreshed (with make kernel_menuconfig + save); - CONFIG_ARCH_AT91 and specific sam9x SoCs (AT91RM9200, AT91SAM9, SAM9X60) has been enabled such that sam9x SoCs to be able to boot. Signed-off-by: Claudiu Beznea --- target/linux/at91/Makefile| 2 +- .../at91/files/arch/arm/boot/dts/wb45n.dts| 220 -- .../at91/files/arch/arm/boot/dts/wb50n.dts| 113 - .../at91/files/arch/arm/boot/dts/wb50n.dtsi | 205 target/linux/at91/image/sam9x.mk | 1 + target/linux/at91/image/sama5.mk | 1 + .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 + .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 - .../102-ARM-at91-build-dtb-for-wb45n.patch| 12 - ...2-ARM-at91-wb45n-fix-duplicate-label.patch | 20 -- .../103-ARM-at91-build-dtb-for-wb50n.patch| 12 - ...3-ARM-at91-wb50n-fix-duplicate-label.patch | 39 target/linux/at91/sam9x/config-default| 105 - 13 files changed, 57 insertions(+), 693 deletions(-) delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb45n.dts delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dts delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dtsi create mode 04 target/linux/at91/patches-5.10 create mode 100644 target/linux/at91/patches-5.10/101-ARM-at91-build-dtb-for-q5xr5.patch delete mode 04 target/linux/at91/patches-5.4 delete mode 100644 target/linux/at91/patches-5.4/101-ARM-at91-build-dtb-for-q5xr5.patch delete mode 100644 target/linux/at91/patches-5.4/102-ARM-at91-build-dtb-for-wb45n.patch delete mode 100644 target/linux/at91/patches-5.4/102-ARM-at91-wb45n-fix-duplicate-label.patch delete mode 100644 target/linux/at91/patches-5.4/103-ARM-at91-build-dtb-for-wb50n.patch delete mode 100644 target/linux/at91/patches-5.4/103-ARM-at91-wb50n-fix-duplicate-label.patch diff --git a/target/linux/at91/Makefile b/target/linux/at91/Makefile index fe6a93244a5f..e4da7fb7e7da 100644 --- a/target/linux/at91/Makefile +++ b/target/linux/at91/Makefile @@ -10,7 +10,7 @@ BOARDNAME:=Microchip (Atmel AT91) FEATURES:=ext4 squashfs targz usb usbgadget ubifs SUBTARGETS:=sama5 sam9x -KERNEL_PATCHVER:=5.4 +KERNEL_PATCHVER:=5.10 include $(INCLUDE_DIR)/target.mk Hi, Is the sama5 subtarget still building after this change? I am surprise that there is no change to the target/linux/at91/sama5/config-default file done in this update from kernel 5.4 to 5.10. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] sunxi: bring up DSA b53 switch on Lamobo R1
Hi Daniel, Thanks for working on this. On 9/11/21 12:40 AM, Daniel Golle wrote: Build cortexa7 subtarget with DSA driver for MDIO-connected Broadcom BCM53xxx switches. This is needed for the Lamobo R1 aka. BananaPi BPi-R1 board which comes with such a switch IC. Remove old swconfig driver from target kernel config as the only board using it is now supported by the DSA driver. No changes to device tree are needed as upstream DTS already got a DSA switch definition and we are just using that upstream source. This patch removes the upstream DTS part for the switch: target/linux/sunxi/patches-5.4/310-Revert-ARM-dts-sun7i-Add-BCM53125-switch-nodes-to-th.patch I think you should remove it. Update default network config of the Lamobo R1 to create lan bridge with all 4 lan ports. Introduce DEVICE_COMPAT_VERSION for the board to inform users about having the re-create their network configuration and add device alias as Bananapi BPi-R1 while at it. Signed-off-by: Daniel Golle Currently the switch is broken, at least I saw multiple complains about this. Do you have the device and is the switch working? If so I would suggest to also backport this to 21.02 as it looks like the switch is not working in 21.01. --- target/linux/sunxi/base-files/etc/board.d/02_network | 3 +-- target/linux/sunxi/config-5.4| 4 target/linux/sunxi/cortexa7/config-5.4 | 12 target/linux/sunxi/image/cortexa7.mk | 5 - 4 files changed, 17 insertions(+), 7 deletions(-) OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 1/6] at91: kernel: bump to 5.10
On 9/10/21 11:56 AM, claudiu.bez...@microchip.com wrote: On 09.09.2021 22:52, Hauke Mehrtens wrote: Bump at91 targets to kernel v5.10. With this patches and files for wb45n and wb50n were removed as they are now included in upstream kernel. Along with this: - the kernel config for sam9x targets has been refreshed (with make kernel_menuconfig + save); - CONFIG_ARCH_AT91 and specific sam9x SoCs (AT91RM9200, AT91SAM9, SAM9X60) has been enabled such that sam9x SoCs to be able to boot. Signed-off-by: Claudiu Beznea --- target/linux/at91/Makefile | 2 +- .../at91/files/arch/arm/boot/dts/wb45n.dts | 220 -- .../at91/files/arch/arm/boot/dts/wb50n.dts | 113 - .../at91/files/arch/arm/boot/dts/wb50n.dtsi | 205 target/linux/at91/image/sam9x.mk | 1 + target/linux/at91/image/sama5.mk | 1 + .../101-ARM-at91-build-dtb-for-q5xr5.patch | 10 + .../101-ARM-at91-build-dtb-for-q5xr5.patch | 10 - .../102-ARM-at91-build-dtb-for-wb45n.patch | 12 - ...2-ARM-at91-wb45n-fix-duplicate-label.patch | 20 -- .../103-ARM-at91-build-dtb-for-wb50n.patch | 12 - ...3-ARM-at91-wb50n-fix-duplicate-label.patch | 39 target/linux/at91/sam9x/config-default | 105 - 13 files changed, 57 insertions(+), 693 deletions(-) delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb45n.dts delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dts delete mode 100644 target/linux/at91/files/arch/arm/boot/dts/wb50n.dtsi create mode 04 target/linux/at91/patches-5.10 create mode 100644 target/linux/at91/patches-5.10/101-ARM-at91-build-dtb-for-q5xr5.patch delete mode 04 target/linux/at91/patches-5.4 delete mode 100644 target/linux/at91/patches-5.4/101-ARM-at91-build-dtb-for-q5xr5.patch delete mode 100644 target/linux/at91/patches-5.4/102-ARM-at91-build-dtb-for-wb45n.patch delete mode 100644 target/linux/at91/patches-5.4/102-ARM-at91-wb45n-fix-duplicate-label.patch delete mode 100644 target/linux/at91/patches-5.4/103-ARM-at91-build-dtb-for-wb50n.patch delete mode 100644 target/linux/at91/patches-5.4/103-ARM-at91-wb50n-fix-duplicate-label.patch .. -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y -CONFIG_HAVE_RSEQ=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y -CONFIG_HAVE_UID16=y -CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y -CONFIG_HZ_FIXED=0 +CONFIG_HZ=128 +CONFIG_HZ_FIXED=128 CONFIG_HZ=100 is set in the generic configuration, do you really need 128? It is the result of doing make kernel_menuconfig + save as arch/arm/Kconfig from Linux kernel tree has these lines: config HZ_FIXED int default 128 if SOC_AT91RM9200 default 0 Since SOC_AT91RM9200 has been introduced in this commit (along with SOC_AT91SAM9, SOC_SAM9X60) as the targets were not able to boot without these config flags, the CONFIG_HZ_FIXED has been selected accordingly to 128. The Linux commit that introduces this is: commit 1164f672d71ac103d85207b0453f3127c0efefb3 Author: Alexandre Belloni Date: Fri Mar 13 22:57:24 2015 +0100 ARM: at91: drop AT91_TIMER_HZ Drop AT91_TIMER_HZ as this can be handled using HZ_FIXED. Initial help message was: On AT91rm9200 chips where you're using a system clock derived from the 32768 Hz hardware clock, this tick rate should divide it exactly: use a power-of-two value, such as 128 or 256, to reduce timing errors caused by rounding. Signed-off-by: Alexandre Belloni Signed-off-by: Nicolas Ferre From commit description seems better to keep it at 128. Thank you, Claudiu Beznea Hi Claudiu, Thank you for the explanation, I was not aware that there is a special handling for this SoC. Using CONFIG_HZ_FIXED=128 and CONFIG_HZ=128 is fine with me. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] build: Replace KERNEL_LOCKUP_DETECTOR with KERNEL_SOFTLOCKUP_DETECTOR
The LOCKUP_DETECTOR configuration option split into the
SOFTLOCKUP_DETECTOR and HARDLOCKUP_DETECTOR configuration option some
time ago. The HARDLOCKUP_DETECTOR option is only working on some
architectures, but SOFTLOCKUP_DETECTOR should work everywhere. Replace
KERNEL_LOCKUP_DETECTOR with KERNEL_SOFTLOCKUP_DETECTOR.
LOCKUP_DETECTOR will be selected by SOFTLOCKUP_DETECTOR automatically.
Fixes: b951f53fbae3 ("build: Add additional kernel debug options")
Signed-off-by: Hauke Mehrtens
---
config/Config-kernel.in | 20
1 file changed, 4 insertions(+), 16 deletions(-)
diff --git a/config/Config-kernel.in b/config/Config-kernel.in
index f71114b5daa8..d4648a506444 100644
--- a/config/Config-kernel.in
+++ b/config/Config-kernel.in
@@ -436,34 +436,22 @@ config KERNEL_PROVE_LOCKING
select KERNEL_DEBUG_KERNEL
default n
-config KERNEL_LOCKUP_DETECTOR
- bool "Compile the kernel with detect Hard and Soft Lockups"
+config KERNEL_SOFTLOCKUP_DETECTOR
+ bool "Compile the kernel with detect Soft Lockups"
depends on KERNEL_DEBUG_KERNEL
help
Say Y here to enable the kernel to act as a watchdog to detect
- hard and soft lockups.
+ soft lockups.
Softlockups are bugs that cause the kernel to loop in kernel
mode for more than 20 seconds, without giving other tasks a
chance to run. The current stack trace is displayed upon
detection and the system will stay locked up.
- Hardlockups are bugs that cause the CPU to loop in kernel mode
- for more than 10 seconds, without letting other interrupts have a
- chance to run. The current stack trace is displayed upon detection
- and the system will stay locked up.
-
- The overhead should be minimal. A periodic hrtimer runs to
- generate interrupts and kick the watchdog task every 4 seconds.
- An NMI is generated every 10 seconds or so to check for hardlockups.
-
- The frequency of hrtimer and NMI events and the soft and hard lockup
- thresholds can be controlled through the sysctl watchdog_thresh.
-
config KERNEL_DETECT_HUNG_TASK
bool "Compile the kernel with detect Hung Tasks"
depends on KERNEL_DEBUG_KERNEL
- default KERNEL_LOCKUP_DETECTOR
+ default KERNEL_SOFTLOCKUP_DETECTOR
help
Say Y here to enable the kernel to detect "hung tasks",
which are bugs that cause the task to be stuck in
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] kernel: Add missing kernel config options
These options are selectable when some of the kernel debug options like KERNEL_SOFTLOCKUP_DETECTOR are selected. Signed-off-by: Hauke Mehrtens --- target/linux/archs38/config-5.4 | 1 - target/linux/generic/config-5.10 | 3 +++ target/linux/generic/config-5.4 | 3 +++ target/linux/layerscape/armv7/config-5.4 | 2 -- target/linux/layerscape/armv8_64b/config-5.4 | 2 -- 5 files changed, 6 insertions(+), 5 deletions(-) diff --git a/target/linux/archs38/config-5.4 b/target/linux/archs38/config-5.4 index 7e529f763381..9847daa7692a 100644 --- a/target/linux/archs38/config-5.4 +++ b/target/linux/archs38/config-5.4 @@ -50,7 +50,6 @@ CONFIG_BLK_DEV_RAM_COUNT=16 CONFIG_BLK_DEV_RAM_SIZE=4096 CONFIG_BLK_DEV_SD=y CONFIG_BLK_SCSI_REQUEST=y -# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0 CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y CONFIG_CC_HAS_KASAN_GENERIC=y diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index a9160ee9b131..69544864804e 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -682,6 +682,8 @@ CONFIG_BLOCK=y # CONFIG_BONDING is not set # CONFIG_BOOKE_WDT is not set CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT=3 +# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set # CONFIG_BOOTTIME_TRACING is not set # CONFIG_BOOT_CONFIG is not set # CONFIG_BOOT_PRINTK_DELAY is not set @@ -1319,6 +1321,7 @@ CONFIG_DEBUG_KERNEL=y CONFIG_DEFAULT_CUBIC=y CONFIG_DEFAULT_DEADLINE=y CONFIG_DEFAULT_HOSTNAME="(none)" +CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 CONFIG_DEFAULT_INIT="" CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 # CONFIG_DEFAULT_NOOP is not set diff --git a/target/linux/generic/config-5.4 b/target/linux/generic/config-5.4 index a568a9ea7f4e..22921379c56f 100644 --- a/target/linux/generic/config-5.4 +++ b/target/linux/generic/config-5.4 @@ -645,6 +645,8 @@ CONFIG_BLOCK=y # CONFIG_BONDING is not set # CONFIG_BOOKE_WDT is not set CONFIG_BOOKE_WDT_DEFAULT_TIMEOUT=3 +# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set +# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set # CONFIG_BOOT_PRINTK_DELAY is not set CONFIG_BOOT_RAW=y CONFIG_BPF=y @@ -1239,6 +1241,7 @@ CONFIG_DEBUG_KERNEL=y CONFIG_DEFAULT_CUBIC=y CONFIG_DEFAULT_DEADLINE=y CONFIG_DEFAULT_HOSTNAME="(none)" +CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 CONFIG_DEFAULT_IOSCHED="deadline" CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 # CONFIG_DEFAULT_NOOP is not set diff --git a/target/linux/layerscape/armv7/config-5.4 b/target/linux/layerscape/armv7/config-5.4 index ed2e318cd632..d1577e9bbe2c 100644 --- a/target/linux/layerscape/armv7/config-5.4 +++ b/target/linux/layerscape/armv7/config-5.4 @@ -72,7 +72,6 @@ CONFIG_BLK_MQ_PCI=y CONFIG_BLK_MQ_VIRTIO=y CONFIG_BLK_PM=y CONFIG_BLK_SCSI_REQUEST=y -# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_BOUNCE=y CONFIG_BRCMSTB_GISB_ARB=y @@ -168,7 +167,6 @@ CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_LZO=y CONFIG_DECOMPRESS_XZ=y -CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 CONFIG_DETECT_HUNG_TASK=y # CONFIG_DEVFREQ_GOV_PASSIVE is not set # CONFIG_DEVFREQ_GOV_PERFORMANCE is not set diff --git a/target/linux/layerscape/armv8_64b/config-5.4 b/target/linux/layerscape/armv8_64b/config-5.4 index 9214bf9feadb..94a3539b030d 100644 --- a/target/linux/layerscape/armv8_64b/config-5.4 +++ b/target/linux/layerscape/armv8_64b/config-5.4 @@ -88,7 +88,6 @@ CONFIG_BLK_MQ_PCI=y CONFIG_BLK_MQ_VIRTIO=y CONFIG_BLK_PM=y CONFIG_BLK_SCSI_REQUEST=y -# CONFIG_BOOTPARAM_HUNG_TASK_PANIC is not set CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=0 CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y @@ -182,7 +181,6 @@ CONFIG_DECOMPRESS_GZIP=y CONFIG_DECOMPRESS_LZMA=y CONFIG_DECOMPRESS_LZO=y CONFIG_DECOMPRESS_XZ=y -CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120 CONFIG_DETECT_HUNG_TASK=y # CONFIG_DEVICE_THERMAL is not set CONFIG_DEVTMPFS=y -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/4] toolchain/musl: update to version 1.2.2
This updates musl to version 1.2.2 and removes some compatibility headers which are not needed any more. This was prepared by Rosen Penev and most changes for packages are already included in master. musl 1.2 changes time_t from 32 bit to 64 bit also on 32 bit architectures. This is needed to prepare for the year 2038 problem when the 32 bit time_t will overflow. We also have to update to continue to get updates. After applying these changes the toolchain has to get rebuild. When I did not rebuild the toolchain my system was crashing with random memory problems. I do not know how to enforce a rebuild of the toolchain. I would like to apply these patches in about 10 days if there are no objections. Thank you Rosen for working on this. Hauke Mehrtens (1): toolchain/musl: Remove extra format attribute patch Rosen Penev (3): toolchain/musl: update to 1.2.2 toolchain/musl: remove several GNU headers bpftools: fix compilation with musl 1.2.x .../utils/bpftools/patches/006-musl-120.patch | 20 + toolchain/musl/common.mk | 6 +- toolchain/musl/include/bits/wordsize.h| 1 - toolchain/musl/include/features.h | 48 --- toolchain/musl/include/sgidefs.h | 73 toolchain/musl/include/sys/cdefs.h| 378 -- toolchain/musl/include/sys/glibc-types.h | 35 -- .../musl/patches/100-add_glob_onlydir.patch | 11 - .../patches/110-read_timezone_from_fs.patch | 4 +- .../patches/200-add_libssp_nonshared.patch| 8 +- toolchain/musl/patches/300-relative.patch | 2 +- ...ribute-to-some-function-declarations.patch | 197 - ...ist-unlink-in-pthread_exit-after-all.patch | 51 --- ...hreads_minus_1-as-relaxed-atomic-for.patch | 69 ...own-size-of-some-libc-struct-members.patch | 25 -- ...pping-for-processes-that-return-to-s.patch | 90 - ...00-nftw-support-common-gnu-extension.patch | 12 +- .../700-wcsnrtombs-cve-2020-28928.diff| 63 --- .../musl/patches/901-crypt_size_hack.patch| 2 +- 19 files changed, 37 insertions(+), 1058 deletions(-) create mode 100644 package/network/utils/bpftools/patches/006-musl-120.patch delete mode 100644 toolchain/musl/include/bits/wordsize.h delete mode 100644 toolchain/musl/include/features.h delete mode 100644 toolchain/musl/include/sgidefs.h delete mode 100644 toolchain/musl/include/sys/cdefs.h delete mode 100644 toolchain/musl/include/sys/glibc-types.h delete mode 100644 toolchain/musl/patches/100-add_glob_onlydir.patch delete mode 100644 toolchain/musl/patches/400-Add-format-attribute-to-some-function-declarations.patch delete mode 100644 toolchain/musl/patches/500-0001-reorder-thread-list-unlink-in-pthread_exit-after-all.patch delete mode 100644 toolchain/musl/patches/500-0002-don-t-use-libc.threads_minus_1-as-relaxed-atomic-for.patch delete mode 100644 toolchain/musl/patches/500-0003-cut-down-size-of-some-libc-struct-members.patch delete mode 100644 toolchain/musl/patches/500-0004-restore-lock-skipping-for-processes-that-return-to-s.patch delete mode 100644 toolchain/musl/patches/700-wcsnrtombs-cve-2020-28928.diff -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/4] toolchain/musl: update to 1.2.2
From: Rosen Penev
This release introduces 64-bit time_t, which is needed to avoid the
year 2038 problem.
Remove upstream patches. Refreshed others.
Rebased features.h file based on latest musl.
Signed-off-by: Rosen Penev
---
toolchain/musl/common.mk | 6 +-
toolchain/musl/include/features.h | 10 ++-
.../patches/110-read_timezone_from_fs.patch | 4 +-
.../patches/200-add_libssp_nonshared.patch| 8 +-
toolchain/musl/patches/300-relative.patch | 2 +-
...ist-unlink-in-pthread_exit-after-all.patch | 51 ---
...hreads_minus_1-as-relaxed-atomic-for.patch | 69 --
...own-size-of-some-libc-struct-members.patch | 25 --
...pping-for-processes-that-return-to-s.patch | 90 ---
...00-nftw-support-common-gnu-extension.patch | 12 +--
.../700-wcsnrtombs-cve-2020-28928.diff| 63 -
.../musl/patches/901-crypt_size_hack.patch| 2 +-
12 files changed, 26 insertions(+), 316 deletions(-)
delete mode 100644
toolchain/musl/patches/500-0001-reorder-thread-list-unlink-in-pthread_exit-after-all.patch
delete mode 100644
toolchain/musl/patches/500-0002-don-t-use-libc.threads_minus_1-as-relaxed-atomic-for.patch
delete mode 100644
toolchain/musl/patches/500-0003-cut-down-size-of-some-libc-struct-members.patch
delete mode 100644
toolchain/musl/patches/500-0004-restore-lock-skipping-for-processes-that-return-to-s.patch
delete mode 100644 toolchain/musl/patches/700-wcsnrtombs-cve-2020-28928.diff
diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk
index 68098f5c6ab7..0f42a9eb603d 100644
--- a/toolchain/musl/common.mk
+++ b/toolchain/musl/common.mk
@@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk
include $(INCLUDE_DIR)/target.mk
PKG_NAME:=musl
-PKG_VERSION:=1.1.24
-PKG_RELEASE:=3
+PKG_VERSION:=1.2.2
+PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=https://musl.libc.org/releases/
-PKG_HASH:=1370c9a812b2cf2a7d92802510cca0058cc37e66a7bedd70051f0a34015022a3
+PKG_HASH:=9b969322012d796dc23dda27a35866034fa67d8fb67e0e2c45c913c3d43219dd
LIBC_SO_VERSION:=$(PKG_VERSION)
PATCH_DIR:=$(PATH_PREFIX)/patches
diff --git a/toolchain/musl/include/features.h
b/toolchain/musl/include/features.h
index edb8cc72d4cd..e801e2299a0d 100644
--- a/toolchain/musl/include/features.h
+++ b/toolchain/musl/include/features.h
@@ -1,10 +1,14 @@
#ifndef _FEATURES_H
#define _FEATURES_H
-#ifdef _ALL_SOURCE
+#if defined(_ALL_SOURCE) && !defined(_GNU_SOURCE)
#define _GNU_SOURCE 1
#endif
+#if defined(_DEFAULT_SOURCE) && !defined(_BSD_SOURCE)
+#define _BSD_SOURCE 1
+#endif
+
#if !defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE) \
&& !defined(_XOPEN_SOURCE) && !defined(_GNU_SOURCE) \
&& !defined(_BSD_SOURCE) && !defined(__STRICT_ANSI__)
@@ -20,6 +24,8 @@
#if __STDC_VERSION__ >= 199901L || defined(__cplusplus)
#define __inline inline
+#elif !defined(__GNUC__)
+#define __inline
#endif
#if __STDC_VERSION__ >= 201112L
@@ -29,6 +35,8 @@
#define _Noreturn
#endif
+#define __REDIR(x,y) __typeof__(x) x __asm__(#y)
+
/* Convenience macros to test the versions of glibc and gcc.
Use them like this:
#if __GNUC_PREREQ (2,8)
diff --git a/toolchain/musl/patches/110-read_timezone_from_fs.patch
b/toolchain/musl/patches/110-read_timezone_from_fs.patch
index f92781f7ed8a..a1f54db55199 100644
--- a/toolchain/musl/patches/110-read_timezone_from_fs.patch
+++ b/toolchain/musl/patches/110-read_timezone_from_fs.patch
@@ -1,6 +1,6 @@
--- a/src/time/__tz.c
+++ b/src/time/__tz.c
-@@ -25,6 +25,9 @@ static int r0[5], r1[5];
+@@ -31,6 +31,9 @@ static int r0[5], r1[5];
static const unsigned char *zi, *trans, *index, *types, *abbrevs,
*abbrevs_end;
static size_t map_size;
@@ -10,7 +10,7 @@
static char old_tz_buf[32];
static char *old_tz = old_tz_buf;
static size_t old_tz_size = sizeof old_tz_buf;
-@@ -125,6 +128,15 @@ static void do_tzset()
+@@ -132,6 +135,15 @@ static void do_tzset()
"/usr/share/zoneinfo/\0/share/zoneinfo/\0/etc/zoneinfo/\0";
s = getenv("TZ");
diff --git a/toolchain/musl/patches/200-add_libssp_nonshared.patch
b/toolchain/musl/patches/200-add_libssp_nonshared.patch
index 05bd2fe54a38..26a9bfebea48 100644
--- a/toolchain/musl/patches/200-add_libssp_nonshared.patch
+++ b/toolchain/musl/patches/200-add_libssp_nonshared.patch
@@ -7,7 +7,7 @@ Signed-off-by: Steven Barth
--- a/Makefile
+++ b/Makefile
-@@ -66,7 +66,7 @@ CRT_LIBS = $(addprefix lib/,$(notdir $(C
+@@ -67,7 +67,7 @@ CRT_LIBS = $(addprefix lib/,$(notdir $(C
STATIC_LIBS = lib/libc.a
SHARED_LIBS = lib/libc.so
TOOL_LIBS = lib/musl-gcc.specs
@@ -16,7 +16,7 @@ Signed-off-by: Steven Barth
ALL_TOOLS = obj/musl-gcc
WRAPCC_GCC = gcc
-@@ -86,7 +86,7 @@ else
+@@ -88,7 +88,7 @@ else
all: $(ALL_LIBS) $(ALL_TOOLS)
@@ -25,7 +25,7 @@ Signed-off-by: Steven Barth
$(ALL_LIBS) $(ALL_TOOLS) $(ALL_OBJS) $(ALL_OBJS:%.o=%.lo) $(GENH)
$(GENH_INT): | $(OBJ_DIRS)
-@@ -113,6 +11
[PATCH 2/4] toolchain/musl: remove several GNU headers
From: Rosen Penev Remove GLOB_ONLYDIR patch. Only fstools relies on it. fstools has been fixed separately. Remove woresize.h file. It seems to be for an old version of GCC. Remove features.h and glibc-types files. Same as above. Remove sys/cdefs.h. This is a deprecated header. Patches to fix packages that use it have already been patched. Tested with all packages in the base tree. They all compile. Signed-off-by: Rosen Penev --- toolchain/musl/include/bits/wordsize.h| 1 - toolchain/musl/include/features.h | 56 --- toolchain/musl/include/sgidefs.h | 73 toolchain/musl/include/sys/cdefs.h| 378 -- toolchain/musl/include/sys/glibc-types.h | 35 -- .../musl/patches/100-add_glob_onlydir.patch | 11 - 6 files changed, 554 deletions(-) delete mode 100644 toolchain/musl/include/bits/wordsize.h delete mode 100644 toolchain/musl/include/features.h delete mode 100644 toolchain/musl/include/sgidefs.h delete mode 100644 toolchain/musl/include/sys/cdefs.h delete mode 100644 toolchain/musl/include/sys/glibc-types.h delete mode 100644 toolchain/musl/patches/100-add_glob_onlydir.patch diff --git a/toolchain/musl/include/bits/wordsize.h b/toolchain/musl/include/bits/wordsize.h deleted file mode 100644 index 2d4cbe8317fc.. --- a/toolchain/musl/include/bits/wordsize.h +++ /dev/null @@ -1 +0,0 @@ -#include diff --git a/toolchain/musl/include/features.h b/toolchain/musl/include/features.h deleted file mode 100644 index e801e2299a0d.. --- a/toolchain/musl/include/features.h +++ /dev/null @@ -1,56 +0,0 @@ -#ifndef _FEATURES_H -#define _FEATURES_H - -#if defined(_ALL_SOURCE) && !defined(_GNU_SOURCE) -#define _GNU_SOURCE 1 -#endif - -#if defined(_DEFAULT_SOURCE) && !defined(_BSD_SOURCE) -#define _BSD_SOURCE 1 -#endif - -#if !defined(_POSIX_SOURCE) && !defined(_POSIX_C_SOURCE) \ - && !defined(_XOPEN_SOURCE) && !defined(_GNU_SOURCE) \ - && !defined(_BSD_SOURCE) && !defined(__STRICT_ANSI__) -#define _BSD_SOURCE 1 -#define _XOPEN_SOURCE 700 -#endif - -#if __STDC_VERSION__ >= 199901L -#define __restrict restrict -#elif !defined(__GNUC__) -#define __restrict -#endif - -#if __STDC_VERSION__ >= 199901L || defined(__cplusplus) -#define __inline inline -#elif !defined(__GNUC__) -#define __inline -#endif - -#if __STDC_VERSION__ >= 201112L -#elif defined(__GNUC__) -#define _Noreturn __attribute__((__noreturn__)) -#else -#define _Noreturn -#endif - -#define __REDIR(x,y) __typeof__(x) x __asm__(#y) - -/* Convenience macros to test the versions of glibc and gcc. - Use them like this: - #if __GNUC_PREREQ (2,8) - ... code requiring gcc 2.8 or later ... - #endif - Note - they won't work for gcc1 or glibc1, since the _MINOR macros - were not defined then. */ -#if defined __GNUC__ && defined __GNUC_MINOR__ -# define __GNUC_PREREQ(maj, min) \ - ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min)) -#else -# define __GNUC_PREREQ(maj, min) 0 -#endif - -#include - -#endif diff --git a/toolchain/musl/include/sgidefs.h b/toolchain/musl/include/sgidefs.h deleted file mode 100644 index 74509fdbd043.. --- a/toolchain/musl/include/sgidefs.h +++ /dev/null @@ -1,73 +0,0 @@ -/* Copyright (C) 1996, 1997, 1998, 2003, 2004 Free Software Foundation, Inc. - This file is part of the GNU C Library. - Contributed by Ralf Baechle . - - The GNU C Library is free software; you can redistribute it and/or - modify it under the terms of the GNU Lesser General Public - License as published by the Free Software Foundation; either - version 2.1 of the License, or (at your option) any later version. - - The GNU C Library is distributed in the hope that it will be useful, - but WITHOUT ANY WARRANTY; without even the implied warranty of - MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU - Lesser General Public License for more details. - - You should have received a copy of the GNU Lesser General Public - License along with the GNU C Library; if not, write to the Free - Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA - 02111-1307 USA. */ - -#ifndef _SGIDEFS_H -#define _SGIDEFS_H 1 - -/* - * A crude hack to stop - */ -#undef __ASM_SGIDEFS_H -#define __ASM_SGIDEFS_H - -/* - * And remove any damage it might have already done - */ -#undef _MIPS_ISA_MIPS1 -#undef _MIPS_ISA_MIPS2 -#undef _MIPS_ISA_MIPS3 -#undef _MIPS_ISA_MIPS4 -#undef _MIPS_ISA_MIPS5 -#undef _MIPS_ISA_MIPS32 -#undef _MIPS_ISA_MIPS64 - -#undef _MIPS_SIM_ABI32 -#undef _MIPS_SIM_NABI32 -#undef _MIPS_SIM_ABI64 - -/* - * Definitions for the ISA level - */ -#define _MIPS_ISA_MIPS1 1 -#define _MIPS_ISA_MIPS2 2 -#define _MIPS_ISA_MIPS3 3 -#define _MIPS_ISA_MIPS4 4 -#define _MIPS_ISA_MIPS5 5 -#define _MIPS_ISA_MIPS32 6 -#define _MIPS_ISA_MIPS64 7 - -/* - * Subprogram calling convention - */ -#ifndef _ABIO32 -# define _ABIO32 1 -#endif -#define _MIPS_SIM_ABI32_ABIO32 - -#ifnd
[PATCH 3/4] bpftools: fix compilation with musl 1.2.x
From: Rosen Penev A definition for __maybe_inline is needed. Refreshed patches. Signed-off-by: Rosen Penev --- .../utils/bpftools/patches/006-musl-120.patch | 20 +++ 1 file changed, 20 insertions(+) create mode 100644 package/network/utils/bpftools/patches/006-musl-120.patch diff --git a/package/network/utils/bpftools/patches/006-musl-120.patch b/package/network/utils/bpftools/patches/006-musl-120.patch new file mode 100644 index ..53be466f0bb6 --- /dev/null +++ b/package/network/utils/bpftools/patches/006-musl-120.patch @@ -0,0 +1,20 @@ +--- a/tools/bpf/bpftool/btf_dumper.c b/tools/bpf/bpftool/btf_dumper.c +@@ -5,6 +5,7 @@ + #include /* for (FILE *) used by json_writer */ + #include + #include ++#include + #include + #include + #include +--- a/tools/bpf/bpftool/map_perf_ring.c b/tools/bpf/bpftool/map_perf_ring.c +@@ -16,6 +16,7 @@ + #include + #include + #include ++#include + #include + #include + #include -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/4] toolchain/musl: Remove extra format attribute patch
This patch never went upstream so remove it. GCC should already add such
a check to the common functions.
Signed-off-by: Hauke Mehrtens
---
...ribute-to-some-function-declarations.patch | 197 --
1 file changed, 197 deletions(-)
delete mode 100644
toolchain/musl/patches/400-Add-format-attribute-to-some-function-declarations.patch
diff --git
a/toolchain/musl/patches/400-Add-format-attribute-to-some-function-declarations.patch
b/toolchain/musl/patches/400-Add-format-attribute-to-some-function-declarations.patch
deleted file mode 100644
index 06aeb34ced02..
---
a/toolchain/musl/patches/400-Add-format-attribute-to-some-function-declarations.patch
+++ /dev/null
@@ -1,197 +0,0 @@
-From e6683d001a95d7c3d4d992496f00f77e01fcd268 Mon Sep 17 00:00:00 2001
-From: Hauke Mehrtens
-Date: Sun, 22 Nov 2015 15:04:23 +0100
-Subject: [PATCH v2] Add format attribute to some function declarations
-
-GCC and Clang are able to check the format arguments given to a
-function and warn the user if there is a error in the format arguments
-or if there is a potential uncontrolled format string security problem
-in the code. GCC does this automatically for some functions like
-printf(), but it is also possible to annotate other functions in a way
-that it will check them too. This feature is used by glibc for many
-functions. This patch adds the attribute to the some functions of musl
-expect for these functions where gcc automatically adds it.
-
-GCC automatically adds checks for these functions: printf, fprintf,
-sprintf, scanf, fscanf, sscanf, strftime, vprintf, vfprintf and
-vsprintf.
-
-The documentation from gcc is here:
-https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html
-
-The documentation from Clang is here:
-http://clang.llvm.org/docs/AttributeReference.html#format-gnu-format
-
-Signed-off-by: Hauke Mehrtens
- include/err.h | 26 +-
- include/monetary.h | 12 ++--
- include/stdio.h| 29 -
- include/syslog.h | 12 ++--
- 4 files changed, 57 insertions(+), 22 deletions(-)
-
a/include/err.h
-+++ b/include/err.h
-@@ -8,15 +8,23 @@
- extern "C" {
- #endif
-
--void warn(const char *, ...);
--void vwarn(const char *, va_list);
--void warnx(const char *, ...);
--void vwarnx(const char *, va_list);
-+#if __GNUC__ >= 3
-+#define __fp(x, y) __attribute__ ((__format__ (__printf__, x, y)))
-+#else
-+#define __fp(x, y)
-+#endif
-+
-+void warn(const char *, ...) __fp(1, 2);
-+void vwarn(const char *, va_list) __fp(1, 0);
-+void warnx(const char *, ...) __fp(1, 2);
-+void vwarnx(const char *, va_list) __fp(1, 0);
-+
-+_Noreturn void err(int, const char *, ...) __fp(2, 3);
-+_Noreturn void verr(int, const char *, va_list) __fp(2, 0);
-+_Noreturn void errx(int, const char *, ...) __fp(2, 3);
-+_Noreturn void verrx(int, const char *, va_list) __fp(2, 0);
-
--_Noreturn void err(int, const char *, ...);
--_Noreturn void verr(int, const char *, va_list);
--_Noreturn void errx(int, const char *, ...);
--_Noreturn void verrx(int, const char *, va_list);
-+#undef __fp
-
- #ifdef __cplusplus
- }
a/include/monetary.h
-+++ b/include/monetary.h
-@@ -13,8 +13,16 @@ extern "C" {
-
- #include
-
--ssize_t strfmon(char *__restrict, size_t, const char *__restrict, ...);
--ssize_t strfmon_l(char *__restrict, size_t, locale_t, const char *__restrict,
...);
-+#if __GNUC__ >= 3
-+#define __fsfm(x, y) __attribute__ ((__format__ (__strfmon__, x, y)))
-+#else
-+#define __fsfm(x, y)
-+#endif
-+
-+ssize_t strfmon(char *__restrict, size_t, const char *__restrict, ...)
__fsfm(3, 4);
-+ssize_t strfmon_l(char *__restrict, size_t, locale_t, const char *__restrict,
...) __fsfm(4, 5);
-+
-+#undef __fsfm
-
- #ifdef __cplusplus
- }
a/include/stdio.h
-+++ b/include/stdio.h
-@@ -25,6 +25,14 @@ extern "C" {
-
- #include
-
-+#if __GNUC__ >= 3
-+#define __fp(x, y) __attribute__ ((__format__ (__printf__, x, y)))
-+#define __fs(x, y) __attribute__ ((__format__ (__scanf__, x, y)))
-+#else
-+#define __fp(x, y)
-+#define __fs(x, y)
-+#endif
-+
- #ifdef __cplusplus
- #define NULL 0L
- #else
-@@ -107,19 +115,19 @@ int puts(const char *);
- int printf(const char *__restrict, ...);
- int fprintf(FILE *__restrict, const char *__restrict, ...);
- int sprintf(char *__restrict, const char *__restrict, ...);
--int snprintf(char *__restrict, size_t, const char *__restrict, ...);
-+int snprintf(char *__restrict, size_t, const char *__restrict, ...) __fp(3,
4);
-
- int vprintf(const char *__restrict, __isoc_va_list);
- int vfprintf(FILE *__restrict, const char *__restrict, __isoc_va_list);
- int vsprintf(char *__restrict, const char *__restrict, __isoc_va_list);
--int vsnprintf(char *__restrict, size_t, const char *__restrict,
__isoc_va_list);
-+int vsnprintf(char *__restrict, size_t, const char *__restrict,
__isoc_va_list) __fp(3, 0);
-
- int scanf(const char *__restrict, ...);
- int fscanf(F
Re: [PATCH 0/2] Bump WolfSSL and libtool
On 7/22/21 9:44 PM, Eneas U de Queiroz wrote: WolfSSL has decided it needs at least libtool 2.4.2 to build. From their commit 92854a5dd message: advance LT_PREREQ from 2.2 (2008) to 2.4.2 (2011) to reflect current automated testing coverage. We could easily patch our way out of it, but I decided to try the upgrade first. It appears to work just fine. I've just rebuilt the whole tree for my Linksys E8450 (mt7622), and tested the WolfSSL update with hostapd and uhttpd. I've had no hickups, but of course ymmv. My major concern while bumping a core building tool was how it could affect the changes we have in place. I've looked at both our patches, and at what was changed upstream. The major changes were related to getting the gnulib sources from git, and refreshing them when running bootstrap. Since we are applying patches, getting fresh copies are not viable, but there's a command-line option to avoid doing it. I'm not so sure what to do about 21.02. 1. Patch WolfSSL to accept building with libtool 2.4; 2. Bump libtool to 2.4.2: 11 *relevant* files changed from 2.4, 424 insertions(+), 198 deletions(-). This was before the gnulib changes. For a comparison, there are 71 files changed, 17143 insertions(+), 5697 deletions(-), when going from 2.4 to 2.4.6. 3. Bump both to keep in sync with master. My vote: do 1 now, and wait for possible fallout from master. Then, perhaps try to keep them in sync, at the following point release. Cheers Eneas U de Queiroz (2): libtool: bump to 2.4.6 wolfssl: bump to v4.8.0-stable Hi Eneas U de Queiroz, libtool was updated to version 2.4.2 in this commmit: https:/git.openwrt.org/cdc646c03282b91d7e9518bb726f29c1de5d24fc The wolfssl update was applied here: https://git.openwrt.org/7d92bb0509615550b98e2dc71091073c8258d564 I would also like to get libtool to 2.4.6 in master, could you please rebase your patch on top of current master please. @Jow: Do you have any objections to updating libtool in master to version 2.4.6? I would prefer to patch wolfssl in 21.02 to work with older libtool. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] arm-trusted-firmware-mvebu: CZ.NIC's Secure Firmware bump to v2021.09.07
On 9/14/21 10:50 AM, sean lee wrote: bump version and remove patches that have been applied 176d701 wtmi: Wait 1s after putting PHYs INTn pin low 2eeccfe wtmi: Change comment describing reset workaround e8c94a5 wtmi: Count RAM size from both CS0 and CS1 995979e wtmi: Rename macro e29eb29 wtmi: soc: Fix start_ap_workaround() for TF-A with debug 81245ed wtmi: Use constant name PLAT_MARVELL_MAILBOX_BASE 18ccb83 wtmi: Do a proper UART reset with clock change as described in spec 15ff106 avs: Validate VDD value from OTP 3f33626 fix: clock: a3700: change pwm clock for 600/600 and 1200/750 preset fb5e436 wtmi: uart: fix UART baudrate divisor calculation Signed-off-by: sean lee --- .../boot/arm-trusted-firmware-mvebu/Makefile | 4 +- ...ix-UART-baudrate-divisor-calculation.patch | 66 --- ...change-pwm-clock-for-600-600-and-120.patch | 48 -- .../102-avs-Validate-VDD-value-from-OTP.patch | 52 --- 4 files changed, 2 insertions(+), 168 deletions(-) delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/100-wtmi-uart-fix-UART-baudrate-divisor-calculation.patch delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/101-fix-clock-a3700-change-pwm-clock-for-600-600-and-120.patch delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/102-avs-Validate-VDD-value-from-OTP.patch Hi, This is a little bit unrelated. Is the source code of image/a3700-utils/wtptp/linux/tbb_linux available somewhere? I wanted to build mvebu/cortex53 on an aarch64 host system and this file is only available for x86_64 and the compilation fails. Building flash image /bin/sh: 1: /home/ubuntu/openwrt/openwrt/staging_dir/target-aarch64_cortex-a53_musl/image/a3700-utils/wtptp/linux/tbb_linux: Exec format error make[4]: *** [plat/marvell/armada/a3k/common/a3700_common.mk:186: /home/ubuntu/openwrt/openwrt/build_dir/target-aarch64_cortex-a53_musl/trusted-firmware-a-espressobin-512mb/trusted-firmware-a-2.5/build/a3700/release/flash-image.bin] Error 2 ubuntu@instance-20210910-2105:~/openwrt/openwrt$ file /home/ubuntu/openwrt/openwrt/staging_dir/target-aarch64_cortex-a53_musl/image/a3700-utils/wtptp/linux/tbb_linux /home/ubuntu/openwrt/openwrt/staging_dir/target-aarch64_cortex-a53_musl/image/a3700-utils/wtptp/linux/tbb_linux: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.24, BuildID[sha1]=8169eedf6eef4b1993a65a180baee3d31660c000, with debug_info, not stripped ubuntu@instance-20210910-2105:~/openwrt/openwrt$ uname -a Linux instance-20210910-2105 5.11.0-1017-oracle #18~20.04.1-Ubuntu SMP Fri Aug 27 11:09:43 UTC 2021 aarch64 aarch64 aarch64 GNU/Linux ubuntu@instance-20210910-2105:~/openwrt/openwrt$ Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 21.02] mac80211: Update to backports-5.10.64
Refresh all patches. The removed patches were integrated upstream. Signed-off-by: Hauke Mehrtens --- This is based on backports-5.10.64-test1.tar.xz, If this works fine I will create a official backports release and update this patch. package/kernel/mac80211/Makefile | 6 +-- .../patches/ath/400-ath_move_debug_code.patch | 2 +- .../patches/ath/542-ath9k_debugfs_diag.patch | 4 +- .../ath/551-ath9k_ubnt_uap_plus_hsr.patch | 4 +- .../ath/930-ath10k_add_tpt_led_trigger.patch | 4 +- ...75-ath10k-use-tpt-trigger-by-default.patch | 2 +- ...62-brcmfmac-Disable-power-management.patch | 2 +- .../mac80211/patches/brcm/998-survey.patch| 8 +-- .../110-mac80211_keep_keys_on_stop_ap.patch | 2 +- .../mac80211/patches/subsys/210-ap_scan.patch | 2 +- ...ort-immediate-reconnect-request-hint.patch | 14 ++--- ...-driver-based-disconnect-with-reconn.patch | 32 ++-- ...port-to-configure-SAE-PWE-value-to-d.patch | 2 +- ...-get_default_func-move-default-flow-.patch | 2 +- ...ot-maintain-a-backlog-sorted-list-of.patch | 2 +- ...add-rx-decapsulation-offload-support.patch | 18 +++ ...le-QoS-support-for-nl80211-ctrl-port.patch | 6 +-- ...pply-flow-control-on-management-fram.patch | 2 +- ...set-sk_pacing_shift-for-802.3-txpath.patch | 2 +- ...MPDU-session-check-from-minstrel_ht-.patch | 12 ++--- ...eee80211_tx_h_rate_ctrl-when-dequeue.patch | 8 +-- ...te-control-support-for-encap-offload.patch | 2 +- ...11-minstrel_ht-fix-sample-time-check.patch | 2 +- ...iwlwifi-specific-workaround-that-bro.patch | 51 --- ...rting-aggregation-sessions-on-mesh-i.patch | 2 +- .../500-mac80211_configure_antenna_gain.patch | 4 +- 26 files changed, 73 insertions(+), 124 deletions(-) delete mode 100644 package/kernel/mac80211/patches/subsys/378-mac80211-remove-iwlwifi-specific-workaround-that-bro.patch diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile index dd9ec172ca..23711802e2 100644 --- a/package/kernel/mac80211/Makefile +++ b/package/kernel/mac80211/Makefile @@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=mac80211 -PKG_VERSION:=5.10.42-1 +PKG_VERSION:=5.10.64-test1 PKG_RELEASE:=1 -PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v5.10.42/ -PKG_HASH:=6876520105240844fdb32d1dcdf2bfdea291a37a96f16c892fda3776ba714fcb +PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/ +PKG_HASH:=4b2e9e5a61cd0a4d766eb9859cc96719f0746954eca20d5f402d2f50fc7eb4af PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION) diff --git a/package/kernel/mac80211/patches/ath/400-ath_move_debug_code.patch b/package/kernel/mac80211/patches/ath/400-ath_move_debug_code.patch index db10c45104..eacc72776e 100644 --- a/package/kernel/mac80211/patches/ath/400-ath_move_debug_code.patch +++ b/package/kernel/mac80211/patches/ath/400-ath_move_debug_code.patch @@ -14,7 +14,7 @@ CFLAGS_trace.o := -I$(src) --- a/drivers/net/wireless/ath/ath.h +++ b/drivers/net/wireless/ath/ath.h -@@ -316,14 +316,7 @@ void _ath_dbg(struct ath_common *common, +@@ -317,14 +317,7 @@ void _ath_dbg(struct ath_common *common, #endif /* CPTCFG_ATH_DEBUG */ /** Returns string describing opmode, or NULL if unknown mode. */ diff --git a/package/kernel/mac80211/patches/ath/542-ath9k_debugfs_diag.patch b/package/kernel/mac80211/patches/ath/542-ath9k_debugfs_diag.patch index f93a6fe5cd..138739cdd3 100644 --- a/package/kernel/mac80211/patches/ath/542-ath9k_debugfs_diag.patch +++ b/package/kernel/mac80211/patches/ath/542-ath9k_debugfs_diag.patch @@ -84,7 +84,7 @@ bool reset_power_on; bool htc_reset_init; -@@ -1076,6 +1084,7 @@ void ath9k_hw_check_nav(struct ath_hw *a +@@ -1077,6 +1085,7 @@ void ath9k_hw_check_nav(struct ath_hw *a bool ath9k_hw_check_alive(struct ath_hw *ah); bool ath9k_hw_setpower(struct ath_hw *ah, enum ath9k_power_mode mode); @@ -125,7 +125,7 @@ REG_SET_BIT(ah, AR_BTCOEX_WL_LNADIV, AR_BTCOEX_WL_LNADIV_FORCE_ON); --- a/drivers/net/wireless/ath/ath9k/main.c +++ b/drivers/net/wireless/ath/ath9k/main.c -@@ -531,6 +531,11 @@ irqreturn_t ath_isr(int irq, void *dev) +@@ -536,6 +536,11 @@ irqreturn_t ath_isr(int irq, void *dev) if (test_bit(ATH_OP_HW_RESET, &common->op_flags)) return IRQ_HANDLED; diff --git a/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch b/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch index acb9ad443c..c98222781d 100644 --- a/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch +++ b/package/kernel/mac80211/patches/ath/551-ath9k_ubnt_uap_plus_hsr.patch @@ -339,7 +339,7 @@ static void ath9k_flush(struct ieee80211_hw *hw, struct ieee80211_vif *vif, u32 queues, bool drop); -@@ -652,6 +653,7 @@ void ath_reset_work(struct work_struct * +@@ -657,6 +658,7 @@ void ath_reset_work(struct work
[PATCH] mac80211: Update to backports-5.10.64
Refresh all patches. The removed patches were integrated upstream. Signed-off-by: Hauke Mehrtens --- This is based on backports-5.10.64-test1.tar.xz, If this works fine I will create a official backports release and update this patch. package/kernel/mac80211/Makefile | 6 +- .../patches/ath/400-ath_move_debug_code.patch | 2 +- .../patches/ath/402-ath_regd_optional.patch | 2 +- .../ath10k/080-ath10k_thermal_config.patch| 2 +- .../930-ath10k_add_tpt_led_trigger.patch | 4 +- ...rolling-support-for-various-chipsets.patch | 2 +- ...75-ath10k-use-tpt-trigger-by-default.patch | 2 +- ...h10k-Try-to-get-mac-address-from-dts.patch | 7 +- .../ath9k/410-ath9k_allow_adhoc_and_ap.patch | 2 +- ...abled-MFP-capability-unconditionally.patch | 4 +- .../patches/ath9k/501-ath9k_ahb_init.patch| 2 +- .../patches/ath9k/530-ath9k_extra_leds.patch | 2 +- .../ath9k/542-ath9k_debugfs_diag.patch| 4 +- .../ath9k/543-ath9k_entropy_from_adc.patch| 6 +- .../550-ath9k-disable-bands-via-dt.patch | 2 +- .../ath9k/551-ath9k_ubnt_uap_plus_hsr.patch | 6 +- .../ath9k/553-ath9k_of_gpio_mask.patch| 4 +- ...62-brcmfmac-Disable-power-management.patch | 2 +- .../mac80211/patches/brcm/998-survey.patch| 8 +-- .../602-rt2x00-introduce-rt2x00eeprom.patch | 6 +- ...isabling_bands_through_platform_data.patch | 2 +- ...00-allow_disabling_bands_through_dts.patch | 2 +- .../611-rt2x00-add-AP+STA-support.patch | 2 +- .../612-rt2x00-led-tpt-trigger-support.patch | 4 +- ...ave-survey-for-every-channel-visited.patch | 4 +- .../110-mac80211_keep_keys_on_stop_ap.patch | 2 +- .../mac80211/patches/subsys/210-ap_scan.patch | 2 +- ...ort-immediate-reconnect-request-hint.patch | 14 ++-- ...-driver-based-disconnect-with-reconn.patch | 32 - ...port-to-configure-SAE-PWE-value-to-d.patch | 2 +- ...-get_default_func-move-default-flow-.patch | 2 +- ...ot-maintain-a-backlog-sorted-list-of.patch | 2 +- ...add-rx-decapsulation-offload-support.patch | 18 ++--- ...le-QoS-support-for-nl80211-ctrl-port.patch | 6 +- ...320-mac80211_hwsim-add-6GHz-channels.patch | 4 +- ...211_hwsim-make-6-GHz-channels-usable.patch | 8 +-- ...pply-flow-control-on-management-fram.patch | 2 +- ...set-sk_pacing_shift-for-802.3-txpath.patch | 2 +- ...MPDU-session-check-from-minstrel_ht-.patch | 12 ++-- ...eee80211_tx_h_rate_ctrl-when-dequeue.patch | 8 +-- ...te-control-support-for-encap-offload.patch | 4 +- ...11-minstrel_ht-fix-sample-time-check.patch | 2 +- ...iwlwifi-specific-workaround-that-bro.patch | 51 - ...rting-aggregation-sessions-on-mesh-i.patch | 2 +- ...introduce-aql_enable-node-in-debugfs.patch | 4 +- ...to-a-virtual-time-based-airtime-sche.patch | 20 +++--- ...bling-4-address-mode-on-a-sta-vif-af.patch | 72 --- ...on-API-to-configure-SAR-power-limita.patch | 4 +- ...eck-per-vif-offload_flags-in-Tx-path.patch | 2 +- 49 files changed, 119 insertions(+), 247 deletions(-) delete mode 100644 package/kernel/mac80211/patches/subsys/378-mac80211-remove-iwlwifi-specific-workaround-that-bro.patch delete mode 100644 package/kernel/mac80211/patches/subsys/383-mac80211-fix-enabling-4-address-mode-on-a-sta-vif-af.patch diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile index dd39c2d06932..e8073a51cb88 100644 --- a/package/kernel/mac80211/Makefile +++ b/package/kernel/mac80211/Makefile @@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=mac80211 -PKG_VERSION:=5.10.42-1 +PKG_VERSION:=5.10.64-test1 PKG_RELEASE:=1 -PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v5.10.42/ -PKG_HASH:=6876520105240844fdb32d1dcdf2bfdea291a37a96f16c892fda3776ba714fcb +PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/ +PKG_HASH:=4b2e9e5a61cd0a4d766eb9859cc96719f0746954eca20d5f402d2f50fc7eb4af PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION) diff --git a/package/kernel/mac80211/patches/ath/400-ath_move_debug_code.patch b/package/kernel/mac80211/patches/ath/400-ath_move_debug_code.patch index db10c45104d7..eacc72776e0f 100644 --- a/package/kernel/mac80211/patches/ath/400-ath_move_debug_code.patch +++ b/package/kernel/mac80211/patches/ath/400-ath_move_debug_code.patch @@ -14,7 +14,7 @@ CFLAGS_trace.o := -I$(src) --- a/drivers/net/wireless/ath/ath.h +++ b/drivers/net/wireless/ath/ath.h -@@ -316,14 +316,7 @@ void _ath_dbg(struct ath_common *common, +@@ -317,14 +317,7 @@ void _ath_dbg(struct ath_common *common, #endif /* CPTCFG_ATH_DEBUG */ /** Returns string describing opmode, or NULL if unknown mode. */ diff --git a/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch b/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch index 3c9180b1137c..bf87d3551a18 100644 --- a/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch +++ b/package/kernel/mac80211/patches
Re: [PATCH v3] arm-trusted-firmware-mvebu: CZ.NIC's Secure Firmware bump to v2021.09.07
On 9/14/21 8:42 PM, Josef Schlehofer wrote: On 14. 09. 21 20:21, Andre Heider wrote: On 14/09/2021 19:59, Hauke Mehrtens wrote: On 9/14/21 10:50 AM, sean lee wrote: bump version and remove patches that have been applied 176d701 wtmi: Wait 1s after putting PHYs INTn pin low 2eeccfe wtmi: Change comment describing reset workaround e8c94a5 wtmi: Count RAM size from both CS0 and CS1 995979e wtmi: Rename macro e29eb29 wtmi: soc: Fix start_ap_workaround() for TF-A with debug 81245ed wtmi: Use constant name PLAT_MARVELL_MAILBOX_BASE 18ccb83 wtmi: Do a proper UART reset with clock change as described in spec 15ff106 avs: Validate VDD value from OTP 3f33626 fix: clock: a3700: change pwm clock for 600/600 and 1200/750 preset fb5e436 wtmi: uart: fix UART baudrate divisor calculation Signed-off-by: sean lee --- .../boot/arm-trusted-firmware-mvebu/Makefile | 4 +- ...ix-UART-baudrate-divisor-calculation.patch | 66 --- ...change-pwm-clock-for-600-600-and-120.patch | 48 -- .../102-avs-Validate-VDD-value-from-OTP.patch | 52 --- 4 files changed, 2 insertions(+), 168 deletions(-) delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/100-wtmi-uart-fix-UART-baudrate-divisor-calculation.patch delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/101-fix-clock-a3700-change-pwm-clock-for-600-600-and-120.patch delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/102-avs-Validate-VDD-value-from-OTP.patch Hi, This is a little bit unrelated. Is the source code of image/a3700-utils/wtptp/linux/tbb_linux available somewhere? I wanted to build mvebu/cortex53 on an aarch64 host system and this file is only available for x86_64 and the compilation fails. Yeah, its source is bundled, and actually atf upstream recently switched to building it instead of using the checked in binary. TBH, it was outdated, buggy and recent changes were not included in the bundled library as said here https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/commit/f014428f4bf7feafec1dcc4c37506d847718649a Building it requires cryptocpp though, which doesn't yet exists as package. We don't really care about crypto since we're building just an untrusted firmware, so I opted to revert to using the binary instead. This is on top of the x86_64 binary toolchain too anyway. This one: https://github.com/BKPepe/openwrt/commit/42322bebc5804a99b60a5bb54200eeba0587076d worked for me. But I didn't send it yet as I didn't do run-time testing yet. I will do it soon. Thank you, I will build test this out later today. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] arm-trusted-firmware-mvebu: Add hash for aarch64 cm3-gcc
This adds the hash also for the aarch64 toolchain in addition for the x86_64 toolchain. This gets the build on a Linux aarch64 host one step further. Signed-off-by: Hauke Mehrtens --- package/boot/arm-trusted-firmware-mvebu/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/package/boot/arm-trusted-firmware-mvebu/Makefile b/package/boot/arm-trusted-firmware-mvebu/Makefile index 2369a1930a0b..ebbf1ef5b8b7 100644 --- a/package/boot/arm-trusted-firmware-mvebu/Makefile +++ b/package/boot/arm-trusted-firmware-mvebu/Makefile @@ -166,7 +166,11 @@ CM3_GCC_SOURCE=$(CM3_GCC_NAME)-$(CM3_GCC_RELEASE)-$(CM3_GCC_VERSION).tar.xz define Download/cm3-gcc FILE:=$(CM3_GCC_SOURCE) URL:=https://developer.arm.com/-/media/Files/downloads/gnu-a/$(CM3_GCC_RELEASE)/binrel +ifeq ($(HOST_ARCH),aarch64) + HASH:=1a42eecafa03dc6f32b8ae49ffcd15114dc818efbd72292fa6bab58233940bb9 +else HASH:=bf7ee185936d22d787b80c8da573f72ead5675695331fb8b590f0133ef1f6bb9 +endif endef define Build/Clean -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] arm-trusted-firmware-mvebu: CZ.NIC's Secure Firmware bump to v2021.09.07
On 9/15/21 2:41 PM, Hauke Mehrtens wrote: On 9/14/21 8:42 PM, Josef Schlehofer wrote: On 14. 09. 21 20:21, Andre Heider wrote: On 14/09/2021 19:59, Hauke Mehrtens wrote: On 9/14/21 10:50 AM, sean lee wrote: bump version and remove patches that have been applied 176d701 wtmi: Wait 1s after putting PHYs INTn pin low 2eeccfe wtmi: Change comment describing reset workaround e8c94a5 wtmi: Count RAM size from both CS0 and CS1 995979e wtmi: Rename macro e29eb29 wtmi: soc: Fix start_ap_workaround() for TF-A with debug 81245ed wtmi: Use constant name PLAT_MARVELL_MAILBOX_BASE 18ccb83 wtmi: Do a proper UART reset with clock change as described in spec 15ff106 avs: Validate VDD value from OTP 3f33626 fix: clock: a3700: change pwm clock for 600/600 and 1200/750 preset fb5e436 wtmi: uart: fix UART baudrate divisor calculation Signed-off-by: sean lee --- .../boot/arm-trusted-firmware-mvebu/Makefile | 4 +- ...ix-UART-baudrate-divisor-calculation.patch | 66 --- ...change-pwm-clock-for-600-600-and-120.patch | 48 -- .../102-avs-Validate-VDD-value-from-OTP.patch | 52 --- 4 files changed, 2 insertions(+), 168 deletions(-) delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/100-wtmi-uart-fix-UART-baudrate-divisor-calculation.patch delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/101-fix-clock-a3700-change-pwm-clock-for-600-600-and-120.patch delete mode 100644 package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/102-avs-Validate-VDD-value-from-OTP.patch Hi, This is a little bit unrelated. Is the source code of image/a3700-utils/wtptp/linux/tbb_linux available somewhere? I wanted to build mvebu/cortex53 on an aarch64 host system and this file is only available for x86_64 and the compilation fails. Yeah, its source is bundled, and actually atf upstream recently switched to building it instead of using the checked in binary. TBH, it was outdated, buggy and recent changes were not included in the bundled library as said here https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/commit/f014428f4bf7feafec1dcc4c37506d847718649a Building it requires cryptocpp though, which doesn't yet exists as package. We don't really care about crypto since we're building just an untrusted firmware, so I opted to revert to using the binary instead. This is on top of the x86_64 binary toolchain too anyway. This one: https://github.com/BKPepe/openwrt/commit/42322bebc5804a99b60a5bb54200eeba0587076d worked for me. But I didn't send it yet as I didn't do run-time testing yet. I will do it soon. Thank you, I will build test this out later today. Hauke With this change it build for me on a Linux host system with aarch64 architecture. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Release goals for 22.XX
Hi, The OpenWrt 21.02 release is done and we should plan the next release. We already talked about this in the last meeting, see https://openwrt.org/meetings/20210920 To monitor the current state I created this wiki page based on the wiki page from the previous release: https://openwrt.org/docs/guide-developer/releases/goals/22.xx I would like to get an overview about the "big" changes, if an additional board is added or something is improved we do not need to plan it. I would like to get the following: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel version for all targets: Kernel 5.10 (only): bmips Kernel 5.10 (5.4 still present): bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86 Testing 5.10: apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra Kernel 5.4 only: arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap pistachio uml zynq toolchain: We already updated the toolchain in master to GCC 11.2, binutils 2.37 and musl 1.2.2. This looks good to me. Minor version updates of musl libc later should be ok. gdb and glibc could also be update later if someone wants to do it. mac80211: I would like to update the mac80211 version we use to match the code from kernel 5.15 or whatever will be the next LTS kernel. I haven't started yet. DSA: We will migrate some more boards to DSA, the lantiq/xrx200 target is using DSA in master now. It looks like some boards with qca8k would switch. These changes should be local to one target or even board anyway. The infrastructure is already provided. This can continue without much coordination and we can see what is finished when we branch. firewall4: OpenWrt master contains firewall4 optionally which uses nftables instead of iptables. It uses the same configuration as firewall3, the old configuration should still work. Custom iptables extensions should also still work when we use iptables-nft which supports the iptables user interface and generates nftables rules, even Debian stable uses iptables-nft by default. Flow offloading (software and hardware) is supported by upstream kernel when nftables is used, we are currently using a patch to make it "work" with iptables too. We have to activate it by default and deactivate firewall3. We probably need some minor modifications to LuCi to show the current nftables firewall status. This is not device depended like DSA, we can easily test this on one device and it should work the same way on all others. LuCi: What is still needed in LuCi? Is there anything else which is blocking, should be added or needs a discussion? Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 9/29/21 10:43 PM, Stijn Segers wrote: Hi Hauke, Op woensdag 29 september 2021 om 22u28 schreef Hauke Mehrtens : Hi, The OpenWrt 21.02 release is done and we should plan the next release. We already talked about this in the last meeting, see https://openwrt.org/meetings/20210920 To monitor the current state I created this wiki page based on the wiki page from the previous release: https://openwrt.org/docs/guide-developer/releases/goals/22.xx I would like to get an overview about the "big" changes, if an additional board is added or something is improved we do not need to plan it. I would like to get the following: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel version for all targets: Kernel 5.10 (only): bmips Kernel 5.10 (5.4 still present): bcm27xx bcm53xx gemini ipq806x mediatek mvebu x86 Testing 5.10: apm821xx armvirt ath79 bcm63xx imx6 ipq40xx kirkwood lantiq malta mpc85xx mxs octeon octeontx oxnas ramips realtek rockchip sunxi tegra Kernel 5.4 only: arc770 archs38 at91 ath25 bcm47xx bcm4908 ipq807x layerscape omap pistachio uml zynq Not sure if you missed this, but there's a 5.10 for OMAP: https://github.com/openwrt/openwrt/pull/4539. There's a 5.10 PR for lantiq as well, and lantiq is in your 'Testing 5.10' list, so mentioning just it in case. Cheers Stijn Hi Stijn, I only listed the status which is already committed to master. When there is already a testing 5.10 kernel in master it will probably be switched soon. I am aware of the lantiq pull request, but there are still some problems. There are also patches on the mailing list for at91: https://patchwork.ozlabs.org/project/openwrt/list/?series=263092 I think the kernel 5.10 status in OpenWrt looks good as all major targets at least have a testing kernel 5.10. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 9/30/21 10:40 PM, Paul Spooren wrote: On 9/30/21 10:01, Nick wrote: On 9/30/21 21:43, Daniel Golle wrote: On Thu, Sep 30, 2021 at 09:18:06PM +0300, Stijn Tintel wrote: On 30/09/2021 01:19, Nick wrote: On 9/29/21 22:28, Hauke Mehrtens wrote: kernel 5.10: We should get all targets to kernel 5.10. All targets which are not on kernel 5.10 when we branch off should get removed. Kernel 5.15 could be also a LTS Kernel that should be released in the end of October? Why not aiming for it if we plan to release in 2022? This would undoubtedly delay the next release, as we've seen in the past. We don't even have all targets on 5.10, which was released roughly 9 months ago. You do the math. If we target 5.15, I doubt we'll even see a release in 2022. I also believe we should do the next release based on Linux 5.10 and try branching still this year (which I believe is realistic to make all targets build with 5.10 till then), so we can target April 2022 as time of release. I agree with you Daniel and think this timeline is reasonable. Sounds good, so we can go on with 5.15 when it is released? Some targets already moved to 5.10 as default, feel free to add 5.15 as the new TESTING kernel there. I am against adding support for kernel 5.15 now, we should better wait till after we branched the relase off. I think the most problematic thing is if we want to have DSA support for all targets as requirement. Not sure if this is possible. It seems fine found a okay'ish middle ground between DSA and non-DSA, so I'd not make DSA blocking for the next release but continue to integrate it where ever possible (and stable). I think we will never convert all swconfig drivers to DSA. I do not think anyone will invest the time to write a DSA driver for the ADM6996L chip for example. It could be that we just remove support for the last boards which still use swconfig in some years. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 9/30/21 3:34 AM, Rich Brown wrote: Hauke: My thanks also for writing up those note. My desire would be to name our next release "22.03", with a target release date in March 2022. And we should name the following release "22.09" with a release date in September. And so on - every six months (or whatever interval we believe we can sustain for the long term.) I would decide about the name when we branch, currently I would also target to branch end of the year and then do the release in March. This all depends on how much time people have. I would prefer to not do more then one release per year, at least I do not have the resources to manage that. If more people take over maintaining and also fixing bugs it would be nice and possible. The problem in the past was not that we didn't had the good plan to make more releases, but the lack of man power. For each release, we need to work backwards, and make the feature freeze for the March release in, say, early January so the first RC can come out in January, we can have a few RCs leading up to a final release sometime within 60-75 days. The reasons to do this: - Some people can only use stable releases because of their business needs or their personality. (Or because we tell them "Only Use Stable!") Regular releases let them use the newest features. - Contrarily, a long release cycle "traps" new stuff behind something that "isn't quite done." - We don't waste time producing and testing patched versions of the previous release. There were seven patch releases in the 19.07 series (running from January 2020 through August 2021). A regular release schedule could have avoided many of these. - Having a firm feature freeze date decreases stress. If a particular feature is done/substantially working, it goes in. If it's not quite ready, it can skip this release, and get into the next release. (The alternative is what I think happened with DSA. It was a big change: there were a large number of problems that took a long time to iron out. That kept pushing out the date...) What happens if some parts are already in master and the rest is missing? Some targets already used DSA, but the configuration was not really supported in UCI and LuCI last time. With a fixed feature freeze we would have released without Luci support to configure some switches. - Customers (our users, our industry partners) gain confidence in projects that can meet their deadlines. Imre noted that "industry is using the snapshots..." but I suspect the extended schedule just worries other vendors. Does this need a vote? Thanks. I would not do a vote about this. The problem is not coming to a decision, but finding people who execute this. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 0/6] at91: add support for sama5d2 icp, sama5d27 wlsom1 ek and sam9x60ek
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Hi, This series adds support for SAMA5D2 ICP, SAMA5D27-WLSOM1-EK and SAM9X60EK boards. Since SAM9X60's kernel support is included in 5.10 but not on 5.4 1st (patch 1/6) switches to kernel 5.10. Patches 2/6, 5/6 updates the kernel config for sam9x SoCs and sam9x60. Patch 3/6, 4/6, 6/6 adds the boards support. Thank you, Claudiu Beznea Hi, I am getting this error: - touch /home/hauke/openwrt/openwrt/staging_dir/target-arm_arm926ej-s_musl_eabi/root-at91/stamp/.kernel_installed ERROR: module '/home/hauke/openwrt/openwrt/build_dir/target-arm_arm926ej-s_musl_eabi/linux-at91_sam9x/linux-5.10.70/drivers/usb/gadget/at91_udc.ko' is missing. make[3]: *** [/home/hauke/openwrt/openwrt/target/linux/at91/modules.mk:67: /home/hauke/openwrt/openwrt/bin/targets/at91/sam9x/packages/kmod-at91-udc_5.10.70-1_arm_arm926ej-s.ipk] Error 1 make[3]: Leaving directory '/home/hauke/openwrt/openwrt/package/kernel/linux' time: package/kernel/linux/compile#1.54#0.07#1.61 ERROR: package/kernel/linux failed to build. When building with this configuration: CONFIG_TARGET_at91=y CONFIG_TARGET_at91_sam9x=y CONFIG_TARGET_at91_sam9x_DEVICE_atmel_at91sam9263ek=y CONFIG_DISPLAY_SUPPORT=y CONFIG_PACKAGE_kmod-usb-ehci=y CONFIG_PACKAGE_kmod-usb2=y The at91_udc driver is compiled into the kernel image with CONFIG_USB_AT91=y, but still selected as a default package Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 1/6] at91: kernel: bump to 5.10
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Bump at91 targets to kernel v5.10. With this patches and files for wb45n and wb50n were removed as they are now included in upstream kernel. Along with: - this the kernel config for sam9x targets has been refreshed (with make kernel_menuconfig + save); - CONFIG_ARCH_AT91 and specific sam9x SoCs (AT91RM9200, AT91SAM9, SAM9X60) has been enabled such that sam9x SoCs to be able to boot. Signed-off-by: Claudiu Beznea --- target/linux/at91/Makefile| 2 +- .../at91/files/arch/arm/boot/dts/wb45n.dts| 220 -- .../at91/files/arch/arm/boot/dts/wb50n.dts| 113 - .../at91/files/arch/arm/boot/dts/wb50n.dtsi | 205 target/linux/at91/image/sam9x.mk | 1 + target/linux/at91/image/sama5.mk | 1 + .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 + .../101-ARM-at91-build-dtb-for-q5xr5.patch| 10 - .../102-ARM-at91-build-dtb-for-wb45n.patch| 12 - ...2-ARM-at91-wb45n-fix-duplicate-label.patch | 20 -- .../103-ARM-at91-build-dtb-for-wb50n.patch| 12 - ...3-ARM-at91-wb50n-fix-duplicate-label.patch | 39 target/linux/at91/sam9x/config-default| 105 - The target/linux/at91/sama5/config-default probably also needs some updates. When I compile the sama5 subtaregt the kernel find the folowing new symbols: Enable firmware caching during suspend (FW_CACHE) [Y/n/?] (NEW) ATMEL Image Sensor Controller (ISC) support (VIDEO_ATMEL_ISC) [N/m/y/?] (NEW) Microchip ASoC driver for boards using S/PDIF TX (SND_MCHP_SOC_SPDIFTX) [N/m/y/?] (NEW) Microchip ASoC driver for boards using S/PDIF RX (SND_MCHP_SOC_SPDIFRX) [N/m/y/?] (NEW) Special Function Registers support (AT91_SOC_SFR) [N/m/y/?] (NEW) Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 2/6] at91: enable specific sam9x kernel config flags
On 9/20/21 11:27 AM, Claudiu Beznea wrote: Enable specific sam9x kernel config flags. Signed-off-by: Claudiu Beznea --- target/linux/at91/sam9x/config-default | 168 +++-- 1 file changed, 159 insertions(+), 9 deletions(-) diff --git a/target/linux/at91/sam9x/config-default b/target/linux/at91/sam9x/config-default index d8b5c31dc7e5..a9f66766b1f2 100644 --- a/target/linux/at91/sam9x/config-default +++ b/target/linux/at91/sam9x/config-default @@ -1,7 +1,6 @@ . CONFIG_INITRAMFS_SOURCE="" +CONFIG_INPUT=y +CONFIG_INPUT_KEYBOARD=y Do you really need keyboard support in OpenWrt? OpenWrt uses some patches to hanlde buttons like a wifi on / off switch. CONFIG_IRQCHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_IRQ_WORK=y +CONFIG_JBD2=y +CONFIG_LEDS_GPIO=y +CONFIG_LEDS_PWM=y +CONFIG_LEDS_TRIGGER_CPU=y +CONFIG_LEDS_TRIGGER_GPIO=y . +CONFIG_USB=y +CONFIG_USB_ACM=y +CONFIG_USB_AT91=y +CONFIG_USB_ATMEL_USBA=y +CONFIG_USB_COMMON=y +CONFIG_USB_CONFIGFS=y I would prefer if you put the USB gadget stuff into a optional openwrt kmod kernel package instead of compiling this into the kernel. +CONFIG_USB_CONFIGFS_ACM=y +# CONFIG_USB_CONFIGFS_ECM is not set +# CONFIG_USB_CONFIGFS_ECM_SUBSET is not set +# CONFIG_USB_CONFIGFS_EEM is not set +# CONFIG_USB_CONFIGFS_F_FS is not set +# CONFIG_USB_CONFIGFS_F_HID is not set +# CONFIG_USB_CONFIGFS_F_LB_SS is not set +# CONFIG_USB_CONFIGFS_F_PRINTER is not set +CONFIG_USB_CONFIGFS_MASS_STORAGE=y +# CONFIG_USB_CONFIGFS_NCM is not set +# CONFIG_USB_CONFIGFS_OBEX is not set +# CONFIG_USB_CONFIGFS_RNDIS is not set +# CONFIG_USB_CONFIGFS_SERIAL is not set +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_HCD_AT91=y +# CONFIG_USB_EHCI_HCD_PLATFORM is not set +CONFIG_USB_ETH=y +# CONFIG_USB_ETH_EEM is not set +CONFIG_USB_ETH_RNDIS=y +CONFIG_USB_F_ACM=y +CONFIG_USB_F_ECM=y +CONFIG_USB_F_MASS_STORAGE=y +CONFIG_USB_F_RNDIS=y +CONFIG_USB_F_SUBSET=y +CONFIG_USB_GADGET=y +CONFIG_USB_LIBCOMPOSITE=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_HCD_AT91=y +CONFIG_USB_OHCI_HCD_PLATFORM=y +CONFIG_USB_SERIAL=y +# CONFIG_USB_SERIAL_CONSOLE is not set +CONFIG_USB_SERIAL_FTDI_SIO=y . ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uci] cmake: Allow overwrite of install directories
On 10/2/21 2:41 PM, Paul D wrote: Overwrite or override? Seems like override - distinction here is important... Hi, I can change this to override, I am not a native speaker. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 10/6/21 12:33 AM, Robert Marko wrote: On Wed, 6 Oct 2021 at 00:08, Paul Spooren wrote: Hi all, based on my overview[1] things are moving forward and being tested, great! What about the targets that did not see any 5.10 ambitions yet? Specifically: - arc770 - archs38 - ath25 - bcm47xx - bcm4908 - ipq807x I can say that Ansuel Smith and I have been working on the IPQ807x support. It's still rough when it comes to networking but I have been trying to upstream other stuff slowly. We were planning to make a PR adding support for most stuff soon and it would be 5.10 only or even better 5.15 if that lands into OpenWrt soon. Regards, Robert Hi Robert, It would be really nice to have ipq807x in the next release and thanks for also getting this integrated upstream. Is this NSS firmware mandatory or will networking also work without it? https://github.com/robimarko/nss-packages Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX - procd-seccomp and procd-ujail
On 10/7/21 8:51 AM, Paul Spooren wrote: On 9/29/21 10:28, Hauke Mehrtens wrote: Hi, The OpenWrt 21.02 release is done and we should plan the next release. We already talked about this in the last meeting, see https://openwrt.org/meetings/20210920 To monitor the current state I created this wiki page based on the wiki page from the previous release: https://openwrt.org/docs/guide-developer/releases/goals/22.xx I would like to get an overview about the "big" changes, if an additional board is added or something is improved we do not need to plan it. I would like to get the following: --- %< Is there anything else which is blocking, should be added or needs a discussion? I'd like to se procd-seccomp and procd-ujail land per default on !SMALL_FLASH targets. The two patches have been in Daniels[1] staging tree since forever. Hi, This looks good to me, but we will probably see more bug reports regarding this, see this patch for example: https://patchwork.ozlabs.org/project/openwrt/patch/mailman.3978.1633613302.1923571.openwrt-de...@lists.openwrt.org/ I would not activate it shortly before the release, but now is a good time. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
Hi Paul, On 10/8/21 11:13 AM, Paul Spooren wrote: Hi, - bcm47xx - bcm4908 Will these two targets be replaced by bmips? bmips is for big endian BCM33xx, BCM63xx and BCM7xxx MIPS chips. bcm47xx is little endian MIPS form a different product line. bcm4908 is ARM based. When I find some time I will have a look at bcm47xx, I have some devices, but they are all old and low powered. These boards need about 3 minutes to boot up now. - layerscape - pistachio - uml Might be dropped if nobody takes care? I have the board for the pistachio target, when I will try to look into this in the next weeks. Hauke OpenPGP_0x93DD20630910B515.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 10/10/21 2:44 AM, Sergey Ryazanov wrote: Hello Rui, On Fri, Oct 8, 2021 at 4:40 PM Rui Salvaterra wrote: On Fri, 8 Oct 2021 at 11:09, Rui Salvaterra wrote: Nothing in this target has more than 32 MiB of RAM (most devices have 16 MiB) [1]. Just put it out of its misery. :) Scratch that. After chatting with dangole, there may be some life in it, after all. I have an ath25 device (FON2200) and didn't even remember it. I am in the process of migrating ath25 to the 5.10 kernel. Initial build was trivial. But I need to restore the Marvel swconfig driver that was lost during the initial 5.10 kernel introduction, and carefully run-time test it. Hi, Does it make sense to directly convert this board to the upstream DSA driver for the Marvell 88E6060 switch: https://elixir.bootlin.com/linux/v5.10.72/source/drivers/net/dsa/mv88e6060.c It looks like our swconfig driver creates a bridge over all ports and the DSA driver only allows communication between the individual port and the CPU port. I do not know how much effort this is and if you have the device for testing. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
On 10/14/21 12:03 AM, Sergey Ryazanov wrote: On Mon, Oct 11, 2021 at 12:12 AM Hauke Mehrtens wrote: On 10/10/21 2:44 AM, Sergey Ryazanov wrote: On Fri, Oct 8, 2021 at 4:40 PM Rui Salvaterra wrote: On Fri, 8 Oct 2021 at 11:09, Rui Salvaterra wrote: Nothing in this target has more than 32 MiB of RAM (most devices have 16 MiB) [1]. Just put it out of its misery. :) Scratch that. After chatting with dangole, there may be some life in it, after all. I have an ath25 device (FON2200) and didn't even remember it. I am in the process of migrating ath25 to the 5.10 kernel. Initial build was trivial. But I need to restore the Marvel swconfig driver that was lost during the initial 5.10 kernel introduction, and carefully run-time test it. Does it make sense to directly convert this board to the upstream DSA driver for the Marvell 88E6060 switch: https://elixir.bootlin.com/linux/v5.10.72/source/drivers/net/dsa/mv88e6060.c It looks like our swconfig driver creates a bridge over all ports and the DSA driver only allows communication between the individual port and the CPU port. I do not know how much effort this is and if you have the device for testing. I do not think that migration to DSA without DT support will be a practical step. Let's keep it as is until we are able to run new kernels with it. Hi, You are right as ath25 doesn't use device tree using DSA drivers would be hard. It is probably easier to stay with the swconfig driver. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] iw: sync nl80211 with kernel backports
The nl80211 was out of sync with the version used in our backports. This
broke the configuration of the antenna gain.
Fixes: 2bfac61483db ("mac80211: backport support for BSS color changes")
Signed-off-by: Hauke Mehrtens
---
.../utils/iw/patches/001-nl80211_h_sync.patch | 69 +++
1 file changed, 56 insertions(+), 13 deletions(-)
diff --git a/package/network/utils/iw/patches/001-nl80211_h_sync.patch
b/package/network/utils/iw/patches/001-nl80211_h_sync.patch
index 1d6ea0fae0f3..2f724b61ff77 100644
--- a/package/network/utils/iw/patches/001-nl80211_h_sync.patch
+++ b/package/network/utils/iw/patches/001-nl80211_h_sync.patch
@@ -20,27 +20,50 @@
*
* @NL80211_CMD_SET_MULTICAST_TO_UNICAST: Configure if this AP should perform
*multicast to unicast conversion. When enabled, all multicast packets
-@@ -1177,6 +1181,10 @@
+@@ -1177,6 +1181,25 @@
*includes the contents of the frame. %NL80211_ATTR_ACK flag is included
*if the recipient acknowledged the frame.
*
+ * @NL80211_CMD_SET_SAR_SPECS: SAR power limitation configuration is
+ *passed using %NL80211_ATTR_SAR_SPEC. %NL80211_ATTR_WIPHY is used to
+ *specify the wiphy index to be applied to.
++ *
++ * @NL80211_CMD_OBSS_COLOR_COLLISION: This notification is sent out whenever
++ *mac80211/drv detects a bss color collision.
++ *
++ * @NL80211_CMD_COLOR_CHANGE_REQUEST: This command is used to indicate that
++ *userspace wants to change the BSS color.
++ *
++ * @NL80211_CMD_COLOR_CHANGE_STARTED: Notify userland, that a color change has
++ *started
++ *
++ * @NL80211_CMD_COLOR_CHANGE_ABORTED: Notify userland, that the color change
has
++ *been aborted
++ *
++ * @NL80211_CMD_COLOR_CHANGE_COMPLETED: Notify userland that the color change
++ *has completed
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
-@@ -1407,6 +1415,8 @@ enum nl80211_commands {
+@@ -1407,6 +1430,16 @@ enum nl80211_commands {
NL80211_CMD_CONTROL_PORT_FRAME_TX_STATUS,
+ NL80211_CMD_SET_SAR_SPECS,
++
++ NL80211_CMD_OBSS_COLOR_COLLISION,
++
++ NL80211_CMD_COLOR_CHANGE_REQUEST,
++
++ NL80211_CMD_COLOR_CHANGE_STARTED,
++ NL80211_CMD_COLOR_CHANGE_ABORTED,
++ NL80211_CMD_COLOR_CHANGE_COMPLETED,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
-@@ -1750,8 +1760,9 @@ enum nl80211_commands {
+@@ -1750,8 +1783,9 @@ enum nl80211_commands {
*specify just a single bitrate, which is to be used for the beacon.
*The driver must also specify support for this with the extended
*features NL80211_EXT_FEATURE_BEACON_RATE_LEGACY,
@@ -52,7 +75,7 @@
*
* @NL80211_ATTR_FRAME_MATCH: A binary attribute which typically must contain
*at least one byte, currently used with @NL80211_CMD_REGISTER_FRAME.
-@@ -1955,8 +1966,15 @@ enum nl80211_commands {
+@@ -1955,8 +1989,15 @@ enum nl80211_commands {
* @NL80211_ATTR_PROBE_RESP: Probe Response template data. Contains the entire
*probe-response frame. The DA field in the 802.11 header is zero-ed out,
*to be filled by the FW.
@@ -70,7 +93,7 @@
* @NL80211_ATTR_HT_CAPABILITY_MASK: Specify which bits of the
* ATTR_HT_CAPABILITY to which attention should be paid.
* Currently, only mac80211 NICs support this feature.
-@@ -2077,7 +2095,8 @@ enum nl80211_commands {
+@@ -2077,7 +2118,8 @@ enum nl80211_commands {
*until the channel switch event.
* @NL80211_ATTR_CH_SWITCH_BLOCK_TX: flag attribute specifying that
transmission
*must be blocked on the current channel (before the channel switch
@@ -80,7 +103,7 @@
* @NL80211_ATTR_CSA_IES: Nested set of attributes containing the IE
information
*for the time while performing a channel switch.
* @NL80211_ATTR_CNTDWN_OFFS_BEACON: An array of offsets (u16) to the channel
-@@ -2527,6 +2546,23 @@ enum nl80211_commands {
+@@ -2527,6 +2569,33 @@ enum nl80211_commands {
*override mask. Used with NL80211_ATTR_S1G_CAPABILITY in
*NL80211_CMD_ASSOCIATE or NL80211_CMD_CONNECT.
*
@@ -98,13 +121,23 @@
+ *disassoc events to indicate that an immediate reconnect to the AP
+ *is desired.
+ *
++ * @NL80211_ATTR_OBSS_COLOR_BITMAP: bitmap of the u64 BSS colors for the
++ *%NL80211_CMD_OBSS_COLOR_COLLISION event.
++ *
++ * @NL80211_ATTR_COLOR_CHANGE_COUNT: u8 attribute specifying the number of
TBTT's
++ *until the color switch event.
++ * @NL80211_ATTR_COLOR_CHANGE_COLOR: u8 attribute specifying the color that
we are
++ *switching to
++ * @NL80211_ATTR_COLOR_CHANGE_ELEMS: Nested set of attributes containing the
IE
++ *information for the time while performing a color switch.
++ *
+ * @NL80211_ATTR_WIPHY_ANTENNA_GAIN: Configured antenna gain. Used to reduce
+ *transmit power to stay within regulatory limits. u32, dBi.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_
[RFC PATCH 0/6] mac80211: Update to version 5.15-rc6
This updates the wireless drivers to the code from kernel 5.15. This is updating the wifi drivers to test versions of the wireless backports. If there are no serious problems found I will also release official versions and update the versions used in OpenWrt. I need some more testing, please try this code in your environments and report back if you see any regressions. I intentionally added the version steps, it should be easy to see which version caused a problem. This depends on the patch "iw: sync nl80211 with kernel backports" These patches are also in my feature branch, see here: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/mac80211-5.15 The wireless backports tar.xz files were created from this code: https://github.com/hauke/backports/tree/devel-5.15-2 Hauke Mehrtens (6): mac80211: Update to version 5.10.70-test12 mac80211: Update to version 5.11.22-test12 mac80211: Update to version 5.12.19-test12 mac80211: Update to version 5.13.19-test12 mac80211: Update to version 5.14.13-test12 mac80211: Update to version 5.15-rc6-test13 package/kernel/mac80211/Makefile | 21 +- .../patches/ath/402-ath_regd_optional.patch |8 +- .../patches/ath/404-regd_no_assoc_hints.patch |4 +- .../ath/406-ath_relax_default_regd.patch |2 +- .../ath10k/080-ath10k_thermal_config.patch|2 +- ...21-ath10k_init_devices_synchronously.patch |2 +- ...h10k-increase-rx-buffer-size-to-2048.patch | 37 - .../930-ath10k_add_tpt_led_trigger.patch |4 +- ...rolling-support-for-various-chipsets.patch | 20 +- ...75-ath10k-use-tpt-trigger-by-default.patch |8 +- ...980-ath10k-fix-max-antenna-gain-unit.patch |6 +- ...-power-reduction-for-US-regulatory-d.patch |8 +- ...h10k-Try-to-get-mac-address-from-dts.patch |2 +- .../ath5k/411-ath5k_allow_adhoc_and_ap.patch |6 +- .../ath5k/440-ath5k_channel_bw_debugfs.patch |2 +- ...w-reset-AHB-WMAC-interface-on-AR91xx.patch |2 +- ..._hw-issue-external-reset-for-QCA955x.patch |4 +- ...erpret-requested-txpower-in-EIRP-dom.patch |4 +- ...power-reduction-for-US-regulatory-do.patch |2 +- .../ath9k/401-ath9k_blink_default.patch |2 +- .../ath9k/410-ath9k_allow_adhoc_and_ap.patch |4 +- ...abled-MFP-capability-unconditionally.patch |4 +- .../patches/ath9k/501-ath9k_ahb_init.patch|2 +- .../510-ath9k_intr_mitigation_tweak.patch |2 +- .../patches/ath9k/513-ath9k_add_pci_ids.patch |2 +- .../patches/ath9k/530-ath9k_extra_leds.patch |8 +- .../ath9k/542-ath9k_debugfs_diag.patch|4 +- .../ath9k/543-ath9k_entropy_from_adc.patch| 10 +- ...544-ath9k-ar933x-usb-hang-workaround.patch | 10 +- .../ath9k/545-ath9k_ani_ws_detect.patch |2 +- .../ath9k/548-ath9k_enable_gpio_chip.patch|4 +- .../ath9k/549-ath9k_enable_gpio_buttons.patch |2 +- .../550-ath9k-disable-bands-via-dt.patch |2 +- .../ath9k/551-ath9k_ubnt_uap_plus_hsr.patch |2 +- .../patches/ath9k/552-ath9k-ahb_of.patch |2 +- .../ath9k/553-ath9k_of_gpio_mask.patch|4 +- .../brcm/812-b43-add-antenna-control.patch|8 +- ...-register-wiphy-s-during-module_init.patch | 18 +- ...62-brcmfmac-Disable-power-management.patch |2 +- ...-in-driver-tables-with-country-codes.patch | 12 +- .../mac80211/patches/brcm/998-survey.patch| 12 +- .../build/003-remove_bogus_modparams.patch|2 +- .../build/004-kconfig_backport_fix.patch | 28 - .../patches/build/010-disable_rfkill.patch| 15 - .../patches/build/060-no_local_ssb_bcma.patch | 10 +- ...700-mwl8k-missing-pci-id-for-WNR854T.patch |2 +- ...940-mwl8k_init_devices_synchronously.patch |4 +- ...define-RF5592-in-init_eeprom-routine.patch |2 +- .../602-rt2x00-introduce-rt2x00eeprom.patch | 10 +- ...isabling_bands_through_platform_data.patch |4 +- ...07-rt2x00-add_platform_data_mac_addr.patch |2 +- ...00-allow_disabling_bands_through_dts.patch |2 +- ...0-rt2x00-change-led-polarity-from-OF.patch |2 +- .../611-rt2x00-add-AP+STA-support.patch |2 +- .../612-rt2x00-led-tpt-trigger-support.patch |4 +- ...dd-support-for-external-PA-on-MT7620.patch |6 +- ...-rt2x00-add-rf-self-txdc-calibration.patch |4 +- .../rt2x00/983-rt2x00-add-r-calibration.patch |4 +- .../984-rt2x00-add-rxdcoc-calibration.patch |4 +- .../985-rt2x00-add-rxiq-calibration.patch |4 +- .../986-rt2x00-add-TX-LOFT-calibration.patch |4 +- ...-differentiate-based-on-SoC-CHIP_VER.patch | 16 +- ...ave-survey-for-every-channel-visited.patch | 183 --- ...ent-set_tim-by-update-beacon-content.patch | 118 -- .../patches/subsys/010-sync-nl80211_h.patch | 297 .../110-mac80211_keep_keys_on_stop_ap.patch |2 +- .../120-cfg80211_allow_perm_addr_change.patch |2 +- .../subsys/150-disable_addr_notifier.patch| 12 +- ..
[RFC PATCH 1/6] mac80211: Update to version 5.10.70-test12
This version removed patches and headers needed for kernel < 4.0
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile | 6 ++--
.../patches/ath/402-ath_regd_optional.patch | 2 +-
.../ath10k/080-ath10k_thermal_config.patch| 4 +--
...h10k-increase-rx-buffer-size-to-2048.patch | 2 +-
...rolling-support-for-various-chipsets.patch | 2 +-
.../ath9k/551-ath9k_ubnt_uap_plus_hsr.patch | 2 +-
.../build/003-remove_bogus_modparams.patch| 2 +-
.../build/004-kconfig_backport_fix.patch | 28 ---
.../patches/build/010-disable_rfkill.patch| 15 --
.../patches/build/050-lib80211_option.patch | 4 +--
.../patches/build/060-no_local_ssb_bcma.patch | 4 +--
.../602-rt2x00-introduce-rt2x00eeprom.patch | 2 +-
.../subsys/150-disable_addr_notifier.patch| 6 ++--
...ort-immediate-reconnect-request-hint.patch | 10 +++
...port-to-configure-SAE-PWE-value-to-d.patch | 2 +-
...add-rx-decapsulation-offload-support.patch | 8 +++---
...-Rx-timestamp-calculation-for-all-pr.patch | 2 +-
...to-a-virtual-time-based-airtime-sche.patch | 10 +++
...on-API-to-configure-SAR-power-limita.patch | 6 ++--
...nl80211-add-support-for-BSS-coloring.patch | 6 ++--
...211-add-support-for-BSS-color-change.patch | 4 +--
...ce-individual-TWT-support-in-AP-mode.patch | 14 +-
.../500-mac80211_configure_antenna_gain.patch | 6 ++--
23 files changed, 52 insertions(+), 95 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/build/004-kconfig_backport_fix.patch
delete mode 100644
package/kernel/mac80211/patches/build/010-disable_rfkill.patch
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 0cbcc03d64fe..82c353e12337 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mac80211
-PKG_VERSION:=5.10.68-1
+PKG_VERSION:=5.10.70-test12
PKG_RELEASE:=1
-PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v5.10.68/
-PKG_HASH:=bba161b0084590c677a84b80993709e388a3c478f29ed0c475d4fce1b9162968
+PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/
+PKG_HASH:=0ae25cbadb9b375a1e0e5177cf1e7ce1beb1f8983b66fa2ba7b4d272c96bf676
PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)
diff --git a/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch
b/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch
index bf87d3551a18..aab60e2a5a40 100644
--- a/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch
+++ b/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch
@@ -82,7 +82,7 @@
help
--- a/local-symbols
+++ b/local-symbols
-@@ -85,6 +85,7 @@ ADM8211=
+@@ -77,6 +77,7 @@ ADM8211=
ATH_COMMON=
WLAN_VENDOR_ATH=
ATH_DEBUG=
diff --git
a/package/kernel/mac80211/patches/ath10k/080-ath10k_thermal_config.patch
b/package/kernel/mac80211/patches/ath10k/080-ath10k_thermal_config.patch
index d183419a47bd..d7f9d7f1385f 100644
--- a/package/kernel/mac80211/patches/ath10k/080-ath10k_thermal_config.patch
+++ b/package/kernel/mac80211/patches/ath10k/080-ath10k_thermal_config.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
-@@ -86,6 +86,12 @@ config ATH10K_TRACING
+@@ -85,6 +85,12 @@ config ATH10K_TRACING
help
Select this to ath10k use tracing infrastructure.
@@ -37,7 +37,7 @@
void ath10k_thermal_event_temperature(struct ath10k *ar, int temperature);
--- a/local-symbols
+++ b/local-symbols
-@@ -144,6 +144,7 @@ ATH10K_SNOC=
+@@ -136,6 +136,7 @@ ATH10K_SNOC=
ATH10K_DEBUG=
ATH10K_DEBUGFS=
ATH10K_SPECTRAL=
diff --git
a/package/kernel/mac80211/patches/ath10k/922-ath10k-increase-rx-buffer-size-to-2048.patch
b/package/kernel/mac80211/patches/ath10k/922-ath10k-increase-rx-buffer-size-to-2048.patch
index 8f7a60eec81e..abce361673d5 100644
---
a/package/kernel/mac80211/patches/ath10k/922-ath10k-increase-rx-buffer-size-to-2048.patch
+++
b/package/kernel/mac80211/patches/ath10k/922-ath10k-increase-rx-buffer-size-to-2048.patch
@@ -26,7 +26,7 @@ Forwarded: https://patchwork.kernel.org/patch/11367055/
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
-@@ -2243,7 +2243,7 @@ struct htt_rx_chan_info {
+@@ -2242,7 +2242,7 @@ struct htt_rx_chan_info {
* Should be: sizeof(struct htt_host_rx_desc) + max rx MSDU size,
* rounded up to a cache line size.
*/
diff --git
a/package/kernel/mac80211/patches/ath10k/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
b/package/kernel/mac80211/patches/ath10k/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
index ce8effe3c3d8..cdff1d1b5cad 100644
---
a/package/kernel/mac80211/patches/ath10k/974-ath10k_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch
+++
b/pack
[RFC PATCH 4/6] mac80211: Update to version 5.13.19-test12
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile | 4 +-
.../930-ath10k_add_tpt_led_trigger.patch | 4 +-
...75-ath10k-use-tpt-trigger-by-default.patch | 2 +-
...erpret-requested-txpower-in-EIRP-dom.patch | 4 +-
...power-reduction-for-US-regulatory-do.patch | 2 +-
.../ath9k/542-ath9k_debugfs_diag.patch| 4 +-
...544-ath9k-ar933x-usb-hang-workaround.patch | 4 +-
...ent-set_tim-by-update-beacon-content.patch | 118
.../patches/subsys/010-sync-nl80211_h.patch | 71 -
.../110-mac80211_keep_keys_on_stop_ap.patch | 2 +-
.../subsys/150-disable_addr_notifier.patch| 10 +-
.../mac80211/patches/subsys/210-ap_scan.patch | 2 +-
...l_ht-rework-rate-downgrade-code-and-.patch | 10 +-
...pply-flow-control-on-management-fram.patch | 60
...set-sk_pacing_shift-for-802.3-txpath.patch | 21 --
...MPDU-session-check-from-minstrel_ht-.patch | 14 +-
...eee80211_tx_h_rate_ctrl-when-dequeue.patch | 12 +-
...te-control-support-for-encap-offload.patch | 4 +-
...rting-aggregation-sessions-on-mesh-i.patch | 2 +-
...to-a-virtual-time-based-airtime-sche.patch | 30 +-
...eck-per-vif-offload_flags-in-Tx-path.patch | 2 +-
...nl80211-add-support-for-BSS-coloring.patch | 16 +-
...211-add-support-for-BSS-color-change.patch | 42 +--
...eee80211-add-TWT-element-definitions.patch | 6 +-
...ce-individual-TWT-support-in-AP-mode.patch | 20 +-
.../500-mac80211_configure_antenna_gain.patch | 14 +-
...the-dst-buffer-to-of_get_mac_address.patch | 263 ++
...n-some-HE-capabilities-with-the-spec.patch | 79 ++
...E-capabilities-A-MPDU-Length-Exponen.patch | 44 +++
...pelling-of-A-MSDU-in-HE-capabilities.patch | 65 +
30 files changed, 320 insertions(+), 611 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/rtl/002-v5.13-rtlwifi-implement-set_tim-by-update-beacon-content.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/010-sync-nl80211_h.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/371-mac80211-don-t-apply-flow-control-on-management-fram.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/372-mac80211-set-sk_pacing_shift-for-802.3-txpath.patch
create mode 100644
package/kernel/mt76/patches/001-wireless-align-some-HE-capabilities-with-the-spec.patch
create mode 100644
package/kernel/mt76/patches/002-wireless-align-HE-capabilities-A-MPDU-Length-Exponen.patch
create mode 100644
package/kernel/mt76/patches/003-wireless-fix-spelling-of-A-MSDU-in-HE-capabilities.patch
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 6323193ea22a..c54ff088ea43 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mac80211
-PKG_VERSION:=5.12.19-test12
+PKG_VERSION:=5.13.19-test12
PKG_RELEASE:=1
PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/
-PKG_HASH:=58fe4ce7d0c7c60b24a6d6f3a880a0fbfcc4ea1e050166e691b2d1fc204fd233
+PKG_HASH:=1165a2f38d72717c1225c390b2547ad2b6f82a4e787905880b83204648147785
PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)
diff --git
a/package/kernel/mac80211/patches/ath10k/930-ath10k_add_tpt_led_trigger.patch
b/package/kernel/mac80211/patches/ath10k/930-ath10k_add_tpt_led_trigger.patch
index c3a28a361cb9..e4e72786fe36 100644
---
a/package/kernel/mac80211/patches/ath10k/930-ath10k_add_tpt_led_trigger.patch
+++
b/package/kernel/mac80211/patches/ath10k/930-ath10k_add_tpt_led_trigger.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
-@@ -9818,6 +9818,21 @@ static int ath10k_mac_init_rd(struct ath
+@@ -9820,6 +9820,21 @@ static int ath10k_mac_init_rd(struct ath
return 0;
}
@@ -22,7 +22,7 @@
int ath10k_mac_register(struct ath10k *ar)
{
static const u32 cipher_suites[] = {
-@@ -10170,6 +10185,12 @@ int ath10k_mac_register(struct ath10k *a
+@@ -10172,6 +10187,12 @@ int ath10k_mac_register(struct ath10k *a
ar->hw->weight_multiplier = ATH10K_AIRTIME_WEIGHT_MULTIPLIER;
diff --git
a/package/kernel/mac80211/patches/ath10k/975-ath10k-use-tpt-trigger-by-default.patch
b/package/kernel/mac80211/patches/ath10k/975-ath10k-use-tpt-trigger-by-default.patch
index e4699f323bc3..1f1e8d958d03 100644
---
a/package/kernel/mac80211/patches/ath10k/975-ath10k-use-tpt-trigger-by-default.patch
+++
b/package/kernel/mac80211/patches/ath10k/975-ath10k-use-tpt-trigger-by-default.patch
@@ -42,7 +42,7 @@ Signed-off-by: Mathias Kresin
if (ret)
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
-@@ -10187,7 +10187,7 @@ int ath10k_mac_register(struct ath10k *a
+@@ -10189,7 +10189,7 @@ int ath10k_mac_register(struct ath10k *a
ar->hw->weight_multiplier = ATH10K_AIRTIME_WEIGHT_MULTIPLIER;
[RFC PATCH 5/6] mac80211: Update to version 5.14.13-test12
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile |4 +-
...62-brcmfmac-Disable-power-management.patch |2 +-
...-in-driver-tables-with-country-codes.patch | 12 +-
.../mac80211/patches/brcm/998-survey.patch| 10 +-
.../subsys/150-disable_addr_notifier.patch|6 +-
.../mac80211/patches/subsys/210-ap_scan.patch |2 +-
...211_hwsim-make-6-GHz-channels-usable.patch |8 +-
...l_ht-rework-rate-downgrade-code-and-.patch |4 +-
...MPDU-session-check-from-minstrel_ht-.patch | 126 --
...eee80211_tx_h_rate_ctrl-when-dequeue.patch | 114 --
...te-control-support-for-encap-offload.patch | 126 --
...rting-aggregation-sessions-on-mesh-i.patch | 112 --
...ange-struct-txq_info-for-fewer-holes.patch | 39 -
...to-a-virtual-time-based-airtime-sche.patch | 1277 -
...eck-per-vif-offload_flags-in-Tx-path.patch | 26 -
...nl80211-add-support-for-BSS-coloring.patch | 24 +-
...211-add-support-for-BSS-color-change.patch | 30 +-
...eee80211-add-TWT-element-definitions.patch |6 +-
...ce-individual-TWT-support-in-AP-mode.patch | 82 +-
.../patches/subsys/400-allow-ibss-mixed.patch |2 +-
.../500-mac80211_configure_antenna_gain.patch | 14 +-
21 files changed, 117 insertions(+), 1909 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/subsys/374-mac80211-move-A-MPDU-session-check-from-minstrel_ht-.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/375-mac80211-call-ieee80211_tx_h_rate_ctrl-when-dequeue.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/376-mac80211-add-rate-control-support-for-encap-offload.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/379-mac80211-fix-starting-aggregation-sessions-on-mesh-i.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/381-mac80211-rearrange-struct-txq_info-for-fewer-holes.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/382-mac80211-Switch-to-a-virtual-time-based-airtime-sche.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/386-mac80211-check-per-vif-offload_flags-in-Tx-path.patch
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index c54ff088ea43..2e55dc79e088 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mac80211
-PKG_VERSION:=5.13.19-test12
+PKG_VERSION:=5.14.13-test12
PKG_RELEASE:=1
PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/
-PKG_HASH:=1165a2f38d72717c1225c390b2547ad2b6f82a4e787905880b83204648147785
+PKG_HASH:=f536d179e3067f1a17e5b1a12af649e834350a831daef7249dfad676af0584fa
PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)
diff --git
a/package/kernel/mac80211/patches/brcm/862-brcmfmac-Disable-power-management.patch
b/package/kernel/mac80211/patches/brcm/862-brcmfmac-Disable-power-management.patch
index 774656f1fdee..2e22ec793b0a 100644
---
a/package/kernel/mac80211/patches/brcm/862-brcmfmac-Disable-power-management.patch
+++
b/package/kernel/mac80211/patches/brcm/862-brcmfmac-Disable-power-management.patch
@@ -14,7 +14,7 @@ Signed-off-by: Phil Elwell
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c
-@@ -2961,6 +2961,10 @@ brcmf_cfg80211_set_power_mgmt(struct wip
+@@ -2966,6 +2966,10 @@ brcmf_cfg80211_set_power_mgmt(struct wip
* preference in cfg struct to apply this to
* FW later while initializing the dongle
*/
diff --git
a/package/kernel/mac80211/patches/brcm/863-brcmfmac-add-in-driver-tables-with-country-codes.patch
b/package/kernel/mac80211/patches/brcm/863-brcmfmac-add-in-driver-tables-with-country-codes.patch
index 9658bda1c178..835c870a6577 100644
---
a/package/kernel/mac80211/patches/brcm/863-brcmfmac-add-in-driver-tables-with-country-codes.patch
+++
b/package/kernel/mac80211/patches/brcm/863-brcmfmac-add-in-driver-tables-with-country-codes.patch
@@ -12,9 +12,9 @@ Signed-off-by: Rafał Miłecki
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/of.c
-@@ -12,6 +12,36 @@
- #include "common.h"
- #include "of.h"
+@@ -58,6 +58,36 @@ static int brcmf_of_get_country_codes(st
+ return 0;
+ }
+/* TODO: FIXME: Use DT */
+static void brcmf_of_probe_cc(struct device *dev,
@@ -49,12 +49,12 @@ Signed-off-by: Rafał Miłecki
void brcmf_of_probe(struct device *dev, enum brcmf_bus_type bus_type,
struct brcmf_mp_device *settings)
{
-@@ -43,6 +73,8 @@ void brcmf_of_probe(struct device *dev,
+@@ -90,6 +120,8 @@ void brcmf_of_probe(struct device *dev,
of_node_put(root);
}
+ brcmf_of_probe_cc(dev, settings);
+
- if (!np || bus_type != BRCMF_BUSTYPE_SDIO ||
- !of_device_is_compatib
[RFC PATCH 6/6] mac80211: Update to version 5.15-rc6-test13
The Cisco Aironet 802.11b driver was removed from backports, remove
it also from OpenWrt.
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile | 19 +-
.../patches/ath/404-regd_no_assoc_hints.patch | 4 +-
.../ath10k/080-ath10k_thermal_config.patch| 2 +-
...rolling-support-for-various-chipsets.patch | 2 +-
...-register-wiphy-s-during-module_init.patch | 16 +-
...62-brcmfmac-Disable-power-management.patch | 2 +-
.../mac80211/patches/brcm/998-survey.patch| 8 +-
.../patches/build/060-no_local_ssb_bcma.patch | 4 +-
.../602-rt2x00-introduce-rt2x00eeprom.patch | 2 +-
.../110-mac80211_keep_keys_on_stop_ap.patch | 2 +-
.../mac80211/patches/subsys/210-ap_scan.patch | 2 +-
...nl80211-add-support-for-BSS-coloring.patch | 492 --
...211-add-support-for-BSS-color-change.patch | 524 ---
...eee80211-add-TWT-element-definitions.patch | 112
...ce-individual-TWT-support-in-AP-mode.patch | 604 --
.../500-mac80211_configure_antenna_gain.patch | 2 +-
.../utils/iw/patches/001-nl80211_h_sync.patch | 42 +-
17 files changed, 61 insertions(+), 1778 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/subsys/387-nl80211-add-support-for-BSS-coloring.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/388-mac80211-add-support-for-BSS-color-change.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/389-ieee80211-add-TWT-element-definitions.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/390-mac80211-introduce-individual-TWT-support-in-AP-mode.patch
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 2e55dc79e088..bb3369833d87 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mac80211
-PKG_VERSION:=5.14.13-test12
+PKG_VERSION:=5.15-rc6-test13
PKG_RELEASE:=1
PKG_SOURCE_URL:=https://hauke-m.de/files/backports-test/
-PKG_HASH:=f536d179e3067f1a17e5b1a12af649e834350a831daef7249dfad676af0584fa
+PKG_HASH:=9cd5b3c51e761e0268e8d5039be7f38e49ec48150a60d01d42b8298655546179
PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)
@@ -23,7 +23,6 @@ PKG_MAINTAINER:=Felix Fietkau
PKG_DRIVERS = \
adm8211 \
- airo \
hermes hermes-pci hermes-pcmcia hermes-plx\
lib80211 \
mac80211-hwsim \
@@ -174,18 +173,6 @@ define KernelPackage/adm8211
AUTOLOAD:=$(call AutoProbe,adm8211)
endef
-define KernelPackage/airo
- $(call KernelPackage/mac80211/Default)
- TITLE:=Cisco Aironet driver
- DEPENDS+=@PCI_SUPPORT +@DRIVER_WEXT_SUPPORT +kmod-cfg80211 @TARGET_x86
@BROKEN
- FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/cisco/airo.ko
- AUTOLOAD:=$(call AutoProbe,airo)
-endef
-
-define KernelPackage/airo/description
- Kernel support for Cisco Aironet cards
-endef
-
define KernelPackage/hermes
$(call KernelPackage/mac80211/Default)
TITLE:=Hermes 802.11b chipset support
@@ -406,8 +393,6 @@ endif
config-$(call config_package,lib80211) += LIB80211 LIB80211_CRYPT_WEP
LIB80211_CRYPT_CCMP LIB80211_CRYPT_TKIP
-config-$(call config_package,airo) += AIRO
-
config-$(call config_package,mac80211-hwsim) += MAC80211_HWSIM
config-$(call config_package,mt7601u) += MT7601U
config-y += WL_MEDIATEK
diff --git a/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch
b/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch
index bda710d5c043..833e2411c485 100644
--- a/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch
+++ b/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch
@@ -1,6 +1,6 @@
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
-@@ -3292,6 +3292,8 @@ void regulatory_hint_country_ie(struct w
+@@ -3299,6 +3299,8 @@ void regulatory_hint_country_ie(struct w
enum environment_cap env = ENVIRON_ANY;
struct regulatory_request *request = NULL, *lr;
@@ -9,7 +9,7 @@
/* IE len must be evenly divisible by 2 */
if (country_ie_len & 0x01)
return;
-@@ -3543,6 +3545,7 @@ static bool is_wiphy_all_set_reg_flag(en
+@@ -3550,6 +3552,7 @@ static bool is_wiphy_all_set_reg_flag(en
void regulatory_hint_disconnect(void)
{
diff --git
a/package/kernel/mac80211/patches/ath10k/080-ath10k_thermal_config.patch
b/package/kernel/mac80211/patches/ath10k/080-ath10k_thermal_config.patch
index c17001eecbba..0886fd688ac5 100644
--- a/package/kernel/mac80211/patches/ath10k/080-ath10k_thermal_config.patch
+++ b/package/kernel/mac80211/patches/ath10k/080-ath10k_thermal_config.patch
@@ -1,6 +1,6 @@
--- a/drivers/net/wireless/ath/ath10k/Kconfig
+++ b/drivers/net/wireless/ath/ath10k/Kconfig
-@@ -85,6 +85,12 @@ config ATH10K_TRACING
+@@ -86,6 +86,12 @@ config ATH10K_TRACING
help
Select this to ath10k use tracing infrastructure.
diff --git
a/package/ke
Re: ath11k - pci - backports/.config issue
On 10/21/21 6:52 PM, Robert Marko wrote: On Thu, 21 Oct 2021 at 18:30, Janusz Dziedzic wrote: czw., 21 paź 2021 o 17:54 Robert Marko napisał(a): For PCI/USB bus level support there are per target feature flags that are set and then you can check if those are set so that you cant even select usb wlan driver if the target doesnt even have usb support enabled. OK I see. Seems I can select all required kernel parts except: QCOM_QMI_HELPERS - which is slected when ath11k/mac80211 - and we get this from backports :) ATH11K [=n] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_ATH [=y] && MAC80211 [=n] && HAS_DMA [=y] && CRYPTO_MICHAEL_MIC [=y] Seems kernel patch required to choose it manaully. Yes, I had to add text to the tristate as otherwise its hidden. Regards, Robert You can create kmod packages for the kernel modules build by MHI_BUS, QRTR, QCOM_QMI_HELPERS and whatever you need. Then the ath11k package in OpenWrt selects them and it should build on all targets. We already added a title text to other configuration symbols, see target/linux/generic/hack-5.10/251-kconfig.patch The hard part is known which patches to backport in addition. ;-) Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] 21.02.1 backports
On 10/21/21 1:01 AM, Paul Spooren wrote: Hi all, Hauke an me plan to tag 21.02.1 this Friday. Motivation is the recent breakage (and fix) of HTTPS secured by Let's Encrypt certificates. More information is available in the commit message[0] of the fix. Please post your backport requests here so we can determine what's possible to include in the next point release. Sunshine, Paul Hi, Wolfssl has some known security problems, see here: https://www.wolfssl.com/docs/security-vulnerabilities/ I think they are not really relevant for us. OpenWrt master uses version 3.8.1 and OpenWrt 21.02 uses version 3.7.0, should we upgrade the version used in OpenWrt 21.02 too? Here is already a patch: https://patchwork.ozlabs.org/project/openwrt/list/?series=262295 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 21.02.1 First service release
Hi, The OpenWrt community is proud to announce the first service release of OpenWrt 21.02. It fixes security issues, improves device support, and brings a few bug fixes. Main changes from OpenWrt 21.02.0 Major bug fixes * Fix Let's Encrypt certificate handling in WolfSSL * Fix sysupgrade for Mikrotik targets * Fix sysupgrade for Rockchip target when using squashfs Device support * Add support for iEi Puzzle-M901/Puzzle-M902 Various fixes and improvements * Add build system support for Python 3.10 * Fix which handling on Fedora and MacOS build systems * Add Tmux terminfo Core components * Update Linux kernel from 5.4.143 to 5.4.154 * Update mac80211 from 5.10.42 to 5.10.68 * Update ath10k-ct to 2021-09-22 * Update wolfssl from 4.7.0 to 4.8.1 Known issues * Some IPv6 packets are dropped when software flow offloading is used: FS#3373 * As a workaround, do not activate software flow offloading, it is deactivate by default. * The menu bar in LuCI is wrongly aligned * If this is a real problem for you update the LuCI theme: opkg upgrade luci-theme-bootstrap Full release notes and upgrade instructions are available at https://openwrt.org/releases/21.02/notes-21.02.1 In particular, make sure to read the regressions and known issues before upgrading: https://openwrt.org/releases/21.02/notes-21.02.1#known_issues For a detailed list of all changes since 21.02.0, refer to https://openwrt.org/releases/21.02/changelog-21.02.1 To download the 21.02.0-rc4 images, navigate to: https://downloads.openwrt.org/releases/21.02.1/ - --- To stay informed of new OpenWrt releases and security advisories, there are new channels available: * a low-volume mailing list for important announcements: https://lists.openwrt.org/mailman/listinfo/openwrt-announce * a dedicated "announcements" section in the forum: https://forum.openwrt.org/c/announcements/14 * other announcement channels (such as RSS feeds) might be added in the future, they will be listed at https://openwrt.org/contact As always, a big thank you goes to all our active package maintainers, testers, documenters, and supporters. Have fun! The OpenWrt Community ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mac80211: ath10k: Fix crash of QCA9984
This backports an upstream fix which is currently pending in
the ath git repository for inclusion into the mainline kernel.
This was reported in the forum:
https://forum.openwrt.org/t/build-for-netgear-r7800/316/3211
Signed-off-by: Hauke Mehrtens
---
I have only compile tested this patch, could someone test it with a
QCA9984 and report back if this fixes the crash.
...e-load-regression-with-iram-recovery.patch | 121 ++
...21-ath10k_init_devices_synchronously.patch | 2 +-
...rolling-support-for-various-chipsets.patch | 6 +-
...h10k-Try-to-get-mac-address-from-dts.patch | 2 +-
4 files changed, 126 insertions(+), 5 deletions(-)
create mode 100644
package/kernel/mac80211/patches/ath10k/090-ath10k-fix-module-load-regression-with-iram-recovery.patch
diff --git
a/package/kernel/mac80211/patches/ath10k/090-ath10k-fix-module-load-regression-with-iram-recovery.patch
b/package/kernel/mac80211/patches/ath10k/090-ath10k-fix-module-load-regression-with-iram-recovery.patch
new file mode 100644
index ..8984d879cccb
--- /dev/null
+++
b/package/kernel/mac80211/patches/ath10k/090-ath10k-fix-module-load-regression-with-iram-recovery.patch
@@ -0,0 +1,121 @@
+From 6f8c8bf4c7c9be1c42088689fd4370e06b46608a Mon Sep 17 00:00:00 2001
+From: Abinaya Kalaiselvan
+Date: Wed, 20 Oct 2021 11:59:07 +0300
+Subject: [PATCH] ath10k: fix module load regression with iram-recovery feature
+
+Commit 9af7c32ceca8 ("ath10k: add target IRAM recovery feature support")
+introduced a new firmware feature flag ATH10K_FW_FEATURE_IRAM_RECOVERY. But
+this caused ath10k_pci module load to fail if ATH10K_FW_CRASH_DUMP_RAM_DATA bit
+was not enabled in the ath10k coredump_mask module parameter:
+
+[ 2209.328190] ath10k_pci :02:00.0: qca9984/qca9994 hw1.0 target
0x0100 chip_id 0x sub 168c:cafe
+[ 2209.434414] ath10k_pci :02:00.0: kconfig debug 1 debugfs 1 tracing 1
dfs 1 testmode 1
+[ 2209.547191] ath10k_pci :02:00.0: firmware ver 10.4-3.9.0.2-00099 api 5
features
no-p2p,mfp,peer-flow-ctrl,btcoex-param,allows-mesh-bcast,no-ps,peer-fixed-rate,iram-recovery
crc32 cbade90a
+[ 2210.896485] ath10k_pci :02:00.0: board_file api 1 bmi_id 0:1 crc32
a040efc2
+[ 2213.603339] ath10k_pci :02:00.0: failed to copy target iram contents:
-12
+[ 2213.839027] ath10k_pci :02:00.0: could not init core (-12)
+[ 2213.933910] ath10k_pci :02:00.0: could not probe fw (-12)
+
+And by default coredump_mask does not have ATH10K_FW_CRASH_DUMP_RAM_DATA
+enabled so anyone using a firmware with iram-recovery feature would fail. To my
+knowledge only QCA9984 firmwares starting from release 10.4-3.9.0.2-00099
+enabled the feature.
+
+The reason for regression was that ath10k_core_copy_target_iram() used
+ath10k_coredump_get_mem_layout() to get the memory layout, but when
+ATH10K_FW_CRASH_DUMP_RAM_DATA was disabled it would get just NULL and bail out
+with an error.
+
+While looking at all this I noticed another bug: if CONFIG_DEV_COREDUMP is
+disabled but the firmware has iram-recovery enabled the module load fails with
+similar error messages. I fixed that by returning 0 from
+ath10k_core_copy_target_iram() when _ath10k_coredump_get_mem_layout() returns
+NULL.
+
+Tested-on: QCA9984 hw2.0 PCI 10.4-3.9.0.2-00139
+
+Fixes: 9af7c32ceca8 ("ath10k: add target IRAM recovery feature support")
+Signed-off-by: Abinaya Kalaiselvan
+Signed-off-by: Jouni Malinen
+Signed-off-by: Kalle Valo
+Link: https://lore.kernel.org/r/20211020075054.23061-1-kv...@codeaurora.org
+---
+ drivers/net/wireless/ath/ath10k/core.c | 11 +--
+ drivers/net/wireless/ath/ath10k/coredump.c | 11 ---
+ drivers/net/wireless/ath/ath10k/coredump.h | 7 +++
+ 3 files changed, 24 insertions(+), 5 deletions(-)
+
+--- a/drivers/net/wireless/ath/ath10k/core.c
b/drivers/net/wireless/ath/ath10k/core.c
+@@ -2690,9 +2690,16 @@ static int ath10k_core_copy_target_iram(
+ int i, ret;
+ u32 len, remaining_len;
+
+- hw_mem = ath10k_coredump_get_mem_layout(ar);
++ /* copy target iram feature must work also when
++ * ATH10K_FW_CRASH_DUMP_RAM_DATA is disabled, so
++ * _ath10k_coredump_get_mem_layout() to accomplist that
++ */
++ hw_mem = _ath10k_coredump_get_mem_layout(ar);
+ if (!hw_mem)
+- return -ENOMEM;
++ /* if CONFIG_DEV_COREDUMP is disabled we get NULL, then
++ * just silently disable the feature by doing nothing
++ */
++ return 0;
+
+ for (i = 0; i < hw_mem->region_table.size; i++) {
+ tmp = &hw_mem->region_table.regions[i];
+--- a/drivers/net/wireless/ath/ath10k/coredump.c
b/drivers/net/wireless/ath/ath10k/coredump.c
+@@ -1447,11 +1447,17 @@ static u32 ath10k_coredump_get_ramdump_s
+
+ const struct ath10k_hw_mem_layout *ath10k_coredump_get_mem_layout(struct
ath10k *ar)
+ {
+- int i;
+-
+ if (!test_bit(ATH10K_FW_CRASH_DUM
[PATCH 2/5] pistachio: Fix FIT image configuration name
The pistachio U-Boot expects a default configuration with the name
config@1 in the FIT image. The default was changed in OpenWrt some
months ago.
This makes the board boot again.
Fixes: 9f714398e060 ("build: use config-1 instead of config@1 as default")
Signed-off-by: Hauke Mehrtens
---
target/linux/pistachio/image/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/linux/pistachio/image/Makefile
b/target/linux/pistachio/image/Makefile
index 7f4e2236c5d2..2e15005ac230 100644
--- a/target/linux/pistachio/image/Makefile
+++ b/target/linux/pistachio/image/Makefile
@@ -15,6 +15,7 @@ define Device/Default
KERNEL_SUFFIX := -kernel.itb
KERNEL_INSTALL := 1
KERNEL_IN_UBI := 1
+ DEVICE_DTS_CONFIG := config@1
IMAGES := factory.ubi sysupgrade.tar
IMAGE/factory.ubi := append-ubi
IMAGE/sysupgrade.tar := sysupgrade-tar
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 5/5] pistachio: Take bootargs from device tree
The boot arguments are copied into the device tree by the boot loader and taken from the device tree by the kernel. The code which takes the boot arguments from the different sources was reworked with kernel 5.5. We have to activate CONFIG_MIPS_CMDLINE_DTB_EXTEND to take the boot arguments from the device tree. This makes the system boot on the board again. Signed-off-by: Hauke Mehrtens --- target/linux/pistachio/config-5.10 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/pistachio/config-5.10 b/target/linux/pistachio/config-5.10 index f510b389a890..f3042b1d32c3 100644 --- a/target/linux/pistachio/config-5.10 +++ b/target/linux/pistachio/config-5.10 @@ -141,8 +141,8 @@ CONFIG_MIPS_ASID_BITS=8 CONFIG_MIPS_ASID_SHIFT=0 CONFIG_MIPS_CLOCK_VSYSCALL=y CONFIG_MIPS_CM=y -# CONFIG_MIPS_CMDLINE_DTB_EXTEND is not set -CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER=y +CONFIG_MIPS_CMDLINE_DTB_EXTEND=y +# CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER is not set # CONFIG_MIPS_CMDLINE_FROM_DTB is not set CONFIG_MIPS_CPC=y CONFIG_MIPS_CPS=y -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/5] pistachio: Make kernel 5.10 patches apply
Make the patches apply on kernel 5.10 and refresh the patches and the kernel configuration on top of kernel 5.10. Signed-off-by: Hauke Mehrtens --- target/linux/pistachio/config-5.10| 77 +++ ...mg-spfi-Implement-dual-and-quad-mode.patch | 18 ++--- ...-device-0-configuration-for-all-devi.patch | 4 +- ...i-RX-maximum-burst-size-for-DMA-is-8.patch | 4 +- ...g-spfi-finish-every-transfer-cleanly.patch | 12 +-- ...or-support-mtd-name-from-device-tree.patch | 16 ++-- 6 files changed, 37 insertions(+), 94 deletions(-) diff --git a/target/linux/pistachio/config-5.10 b/target/linux/pistachio/config-5.10 index a6625d82548f..f510b389a890 100644 --- a/target/linux/pistachio/config-5.10 +++ b/target/linux/pistachio/config-5.10 @@ -1,22 +1,8 @@ CONFIG_ARCH_32BIT_OFF_T=y -CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y -CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y -CONFIG_ARCH_HAS_DMA_WRITE_COMBINE=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y -CONFIG_ARCH_HAS_UNCACHED_SEGMENT=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_MMAP_RND_BITS_MAX=15 CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 -CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_USE_MEMREMAP_PROT=y -CONFIG_ARCH_USE_QUEUED_RWLOCKS=y -CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y -CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_SD=y CONFIG_BLK_SCSI_REQUEST=y @@ -26,20 +12,20 @@ CONFIG_CEVT_R4K=y CONFIG_CLKDEV_LOOKUP=y CONFIG_CLKSRC_MIPS_GIC=y CONFIG_CLKSRC_PISTACHIO=y +CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_CLONE_BACKWARDS=y CONFIG_COMMON_CLK=y # CONFIG_COMMON_CLK_BOSTON is not set CONFIG_COMPAT_32BIT_TIME=y CONFIG_CONNECTOR=y CONFIG_CPU_GENERIC_DUMP_TLB=y -CONFIG_CPU_HAS_LOAD_STORE_LR=y +CONFIG_CPU_HAS_DIEI=y CONFIG_CPU_HAS_PREFETCH=y CONFIG_CPU_HAS_RIXI=y CONFIG_CPU_HAS_SYNC=y CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y -CONFIG_CPU_LITTLE_ENDIAN=y CONFIG_CPU_MIPS32=y CONFIG_CPU_MIPS32_R2=y CONFIG_CPU_MIPSR2=y @@ -54,21 +40,15 @@ CONFIG_CPU_SUPPORTS_HIGHMEM=y CONFIG_CPU_SUPPORTS_MSA=y CONFIG_CRC16=y CONFIG_CRC_CCITT=y -CONFIG_CRYPTO_ACOMP2=y -CONFIG_CRYPTO_AEAD=y -CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_DEFLATE=y -CONFIG_CRYPTO_HASH=y -CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_HASH_INFO=y +CONFIG_CRYPTO_LIB_POLY1305_RSIZE=2 CONFIG_CRYPTO_LIB_SHA256=y CONFIG_CRYPTO_LZO=y -CONFIG_CRYPTO_MANAGER=y -CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_MD5=y -CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y @@ -79,21 +59,16 @@ CONFIG_CSRC_R4K=y CONFIG_DMADEVICES=y CONFIG_DMA_ENGINE=y CONFIG_DMA_NONCOHERENT=y -CONFIG_DMA_NONCOHERENT_CACHE_SYNC=y CONFIG_DMA_OF=y CONFIG_DMA_VIRTUAL_CHANNELS=y CONFIG_DTC=y CONFIG_DWMAC_GENERIC=y CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_8250=y -CONFIG_EFI_EARLYCON=y CONFIG_EXT4_FS=y CONFIG_EXT4_FS_POSIX_ACL=y CONFIG_EXT4_FS_SECURITY=y CONFIG_FIXED_PHY=y -CONFIG_FONT_8x16=y -CONFIG_FONT_AUTOSELECT=y -CONFIG_FONT_SUPPORT=y CONFIG_FS_IOMAP=y CONFIG_FS_MBCACHE=y CONFIG_FS_POSIX_ACL=y @@ -107,7 +82,6 @@ CONFIG_GENERIC_GETTIMEOFDAY=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y -CONFIG_GENERIC_IRQ_IPI=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_LIB_ASHLDI3=y CONFIG_GENERIC_LIB_ASHRDI3=y @@ -129,41 +103,6 @@ CONFIG_HARDWARE_WATCHPOINTS=y CONFIG_HAS_DMA=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT_MAP=y -CONFIG_HAVE_ARCH_COMPILER_H=y -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -CONFIG_HAVE_ASM_MODVERSIONS=y -CONFIG_HAVE_CBPF_JIT=y -CONFIG_HAVE_CLK=y -CONFIG_HAVE_CLK_PREPARE=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_COPY_THREAD_TLS=y -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DEBUG_STACKOVERFLOW=y -CONFIG_HAVE_DMA_CONTIGUOUS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_FAST_GUP=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_GENERIC_VDSO=y -CONFIG_HAVE_IDE=y -CONFIG_HAVE_IOREMAP_PROT=y -CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y -CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y -CONFIG_HAVE_KVM=y -CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION=y -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE_NET_DSA=y -CONFIG_HAVE_OPROFILE=y -CONFIG_HAVE_PERF_EVENTS=y -CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y -CONFIG_HAVE_RSEQ=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y CONFIG_HOTPLUG_CPU=y CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y @@ -182,6 +121,7 @@ CONFIG_LEDS_GPIO=y CONFIG_LEDS_PWM=y CONFIG_LIBFDT=y CONFIG_LKDTM=y +CONFIG_LLD_VERSION=0 CONFIG_LOCK_DEBUGGING_SUPPORT=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_LZO_COMPRESS=y @@ -191,6 +131,7 @@ CONFIG_MAGIC_SYSRQ=y
[PATCH 1/5] kernel: Set some options in generic configuration
Add CONFIG_USB_ETH and CONFIG_PWM_JZ4740 to generic kernel configuration. Signed-off-by: Hauke Mehrtens --- target/linux/at91/sam9x/config-default | 1 - target/linux/at91/sama5/config-default | 1 - target/linux/bcm27xx/bcm2709/config-5.10 | 1 - target/linux/bcm27xx/bcm2711/config-5.10 | 1 - target/linux/generic/config-5.10 | 2 ++ target/linux/imx6/config-5.10| 1 - target/linux/mediatek/mt7623/config-5.10 | 1 - target/linux/mxs/config-5.10 | 1 - target/linux/sunxi/config-5.10 | 1 - target/linux/zynq/config-5.10| 1 - 10 files changed, 2 insertions(+), 9 deletions(-) diff --git a/target/linux/at91/sam9x/config-default b/target/linux/at91/sam9x/config-default index 95c229880bb9..bd9d106f5b24 100644 --- a/target/linux/at91/sam9x/config-default +++ b/target/linux/at91/sam9x/config-default @@ -296,7 +296,6 @@ CONFIG_USB_COMMON=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_HCD_AT91=y # CONFIG_USB_EHCI_HCD_PLATFORM is not set -# CONFIG_USB_ETH is not set CONFIG_USB_GADGET=y CONFIG_USB_OHCI_HCD=y CONFIG_USB_OHCI_HCD_AT91=y diff --git a/target/linux/at91/sama5/config-default b/target/linux/at91/sama5/config-default index 20fb90502a60..852e5c95b7a6 100644 --- a/target/linux/at91/sama5/config-default +++ b/target/linux/at91/sama5/config-default @@ -456,7 +456,6 @@ CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_HCD_AT91=y # CONFIG_USB_EHCI_HCD_PLATFORM is not set # CONFIG_USB_EHCI_ROOT_HUB_TT is not set -# CONFIG_USB_ETH is not set CONFIG_USB_GADGET=y CONFIG_USB_HID=y CONFIG_USB_OHCI_HCD=y diff --git a/target/linux/bcm27xx/bcm2709/config-5.10 b/target/linux/bcm27xx/bcm2709/config-5.10 index 928f17c974cc..7a645e6025af 100644 --- a/target/linux/bcm27xx/bcm2709/config-5.10 +++ b/target/linux/bcm27xx/bcm2709/config-5.10 @@ -435,7 +435,6 @@ CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_COMMON=y CONFIG_USB_DWCOTG=y -# CONFIG_USB_ETH is not set CONFIG_USB_GADGET=y CONFIG_USB_LAN78XX=y CONFIG_USB_NET_DRIVERS=y diff --git a/target/linux/bcm27xx/bcm2711/config-5.10 b/target/linux/bcm27xx/bcm2711/config-5.10 index 861dd1e58d5a..bdbf093dd5f3 100644 --- a/target/linux/bcm27xx/bcm2711/config-5.10 +++ b/target/linux/bcm27xx/bcm2711/config-5.10 @@ -437,7 +437,6 @@ CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y CONFIG_USB_COMMON=y CONFIG_USB_DWCOTG=y -# CONFIG_USB_ETH is not set CONFIG_USB_GADGET=y CONFIG_USB_PCI=y CONFIG_USB_PHY=y diff --git a/target/linux/generic/config-5.10 b/target/linux/generic/config-5.10 index 69d9ddd0f4de..7b952e8ca895 100644 --- a/target/linux/generic/config-5.10 +++ b/target/linux/generic/config-5.10 @@ -4578,6 +4578,7 @@ CONFIG_PROC_SYSCTL=y # CONFIG_PWM is not set # CONFIG_PWM_DEBUG is not set # CONFIG_PWM_FSL_FTM is not set +# CONFIG_PWM_JZ4740 is not set # CONFIG_PWM_PCA9685 is not set CONFIG_PWRSEQ_EMMC=y # CONFIG_PWRSEQ_SD8787 is not set @@ -6442,6 +6443,7 @@ CONFIG_USB_EHCI_TT_NEWSCHED=y # CONFIG_USB_EMI26 is not set # CONFIG_USB_EMI62 is not set # CONFIG_USB_EPSON2888 is not set +# CONFIG_USB_ETH is not set # CONFIG_USB_EZUSB_FX2 is not set # CONFIG_USB_FEW_INIT_RETRIES is not set # CONFIG_USB_FOTG210_HCD is not set diff --git a/target/linux/imx6/config-5.10 b/target/linux/imx6/config-5.10 index 9238678258f5..126652cf980e 100644 --- a/target/linux/imx6/config-5.10 +++ b/target/linux/imx6/config-5.10 @@ -470,7 +470,6 @@ CONFIG_USB_COMMON=y CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_HCD_PLATFORM is not set # CONFIG_USB_EHCI_MXC is not set -# CONFIG_USB_ETH is not set CONFIG_USB_GADGET=y CONFIG_USB_MXS_PHY=y CONFIG_USB_OTG=y diff --git a/target/linux/mediatek/mt7623/config-5.10 b/target/linux/mediatek/mt7623/config-5.10 index d21fe2cdb2bd..917e34608b9a 100644 --- a/target/linux/mediatek/mt7623/config-5.10 +++ b/target/linux/mediatek/mt7623/config-5.10 @@ -587,7 +587,6 @@ CONFIG_UNINLINE_SPIN_UNLOCK=y CONFIG_UNWINDER_ARM=y CONFIG_USB=y CONFIG_USB_COMMON=y -# CONFIG_USB_ETH is not set CONFIG_USB_F_ACM=y CONFIG_USB_F_ECM=y CONFIG_USB_F_MASS_STORAGE=y diff --git a/target/linux/mxs/config-5.10 b/target/linux/mxs/config-5.10 index 2fdb51238cdb..8bc075a916cd 100644 --- a/target/linux/mxs/config-5.10 +++ b/target/linux/mxs/config-5.10 @@ -231,7 +231,6 @@ CONFIG_USB_CHIPIDEA_UDC=y CONFIG_USB_COMMON=y CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_HCD_PLATFORM is not set -# CONFIG_USB_ETH is not set CONFIG_USB_GADGET=y CONFIG_USB_MXS_PHY=y CONFIG_USB_OTG=y diff --git a/target/linux/sunxi/config-5.10 b/target/linux/sunxi/config-5.10 index 3f6f849e81e2..59d873154335 100644 --- a/target/linux/sunxi/config-5.10 +++ b/target/linux/sunxi/config-5.10 @@ -484,7 +484,6 @@ CONFIG_USB_DWC2=y CONFIG_USB_DWC2_HOST=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_HCD_PLATFORM=y -# CONFIG_USB_ETH is not set CONFIG_USB_GADGET=y CONFIG_USB_NET_DRIVERS=y CONFIG_USB_OHCI_HCD=y diff --git a/target/linux/zynq/config-5.10 b/target/linux/zynq/config-5.10 index d18bb39d8d34..d30b4f8467a2 100644 --- a/target/linux/zynq/config
[PATCH 3/5] pistachio: Copy kernel 5.4 patches to 5.10
This just copies the patches and the configuration from kernel 5.4 to kernel 5.10. Signed-off-by: Hauke Mehrtens --- target/linux/pistachio/Makefile | 1 + target/linux/pistachio/config-5.10| 372 ++ ...ine-img-mdc-Handle-early-status-read.patch | 68 ...mg-spfi-Implement-dual-and-quad-mode.patch | 198 ++ ...-device-0-configuration-for-all-devi.patch | 64 +++ ...i-RX-maximum-burst-size-for-DMA-is-8.patch | 59 +++ ...g-spfi-finish-every-transfer-cleanly.patch | 120 ++ ...istachio-Fix-wrong-SDHost-card-speed.patch | 49 +++ ...-img-marduk-switch-mmc-to-1-bit-mode.patch | 47 +++ ...or-support-mtd-name-from-device-tree.patch | 54 +++ ...PS-DTS-img-marduk-Add-SPI-NAND-flash.patch | 30 ++ ...mg-marduk-Add-Cascoda-CA8210-6LoWPAN.patch | 43 ++ ...-DTS-img-marduk-Add-NXP-SC16IS752IPW.patch | 81 ...PS-DTS-img-marduk-Add-partition-name.patch | 27 ++ ...-MIPS-DTS-img-marduk-Add-led-aliases.patch | 27 ++ 15 files changed, 1240 insertions(+) create mode 100644 target/linux/pistachio/config-5.10 create mode 100644 target/linux/pistachio/patches-5.10/101-dmaengine-img-mdc-Handle-early-status-read.patch create mode 100644 target/linux/pistachio/patches-5.10/102-spi-img-spfi-Implement-dual-and-quad-mode.patch create mode 100644 target/linux/pistachio/patches-5.10/104-spi-img-spfi-use-device-0-configuration-for-all-devi.patch create mode 100644 target/linux/pistachio/patches-5.10/105-spi-img-spfi-RX-maximum-burst-size-for-DMA-is-8.patch create mode 100644 target/linux/pistachio/patches-5.10/106-spi-img-spfi-finish-every-transfer-cleanly.patch create mode 100644 target/linux/pistachio/patches-5.10/108-clk-pistachio-Fix-wrong-SDHost-card-speed.patch create mode 100644 target/linux/pistachio/patches-5.10/109-MIPS-DTS-img-marduk-switch-mmc-to-1-bit-mode.patch create mode 100644 target/linux/pistachio/patches-5.10/401-mtd-nor-support-mtd-name-from-device-tree.patch create mode 100644 target/linux/pistachio/patches-5.10/901-MIPS-DTS-img-marduk-Add-SPI-NAND-flash.patch create mode 100644 target/linux/pistachio/patches-5.10/902-MIPS-DTS-img-marduk-Add-Cascoda-CA8210-6LoWPAN.patch create mode 100644 target/linux/pistachio/patches-5.10/903-MIPS-DTS-img-marduk-Add-NXP-SC16IS752IPW.patch create mode 100644 target/linux/pistachio/patches-5.10/904-MIPS-DTS-img-marduk-Add-partition-name.patch create mode 100644 target/linux/pistachio/patches-5.10/905-MIPS-DTS-img-marduk-Add-led-aliases.patch diff --git a/target/linux/pistachio/Makefile b/target/linux/pistachio/Makefile index 962871af1311..09bdf4d6b6ef 100644 --- a/target/linux/pistachio/Makefile +++ b/target/linux/pistachio/Makefile @@ -12,6 +12,7 @@ CPU_TYPE:=24kc CPU_SUBTYPE:=24kf KERNEL_PATCHVER:=5.4 +KERNEL_TESTING_PATCHVER:=5.10 include $(INCLUDE_DIR)/target.mk diff --git a/target/linux/pistachio/config-5.10 b/target/linux/pistachio/config-5.10 new file mode 100644 index ..a6625d82548f --- /dev/null +++ b/target/linux/pistachio/config-5.10 @@ -0,0 +1,372 @@ +CONFIG_ARCH_32BIT_OFF_T=y +CONFIG_ARCH_CLOCKSOURCE_DATA=y +CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y +CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y +CONFIG_ARCH_HAS_DMA_WRITE_COMBINE=y +CONFIG_ARCH_HAS_ELF_RANDOMIZE=y +CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y +CONFIG_ARCH_HAS_UNCACHED_SEGMENT=y +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MMAP_RND_BITS_MAX=15 +CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=15 +CONFIG_ARCH_SUPPORTS_UPROBES=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_MEMREMAP_PROT=y +CONFIG_ARCH_USE_QUEUED_RWLOCKS=y +CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y +CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_SD=y +CONFIG_BLK_SCSI_REQUEST=y +CONFIG_BOARD_SCACHE=y +CONFIG_BOOT_ELF32=y +CONFIG_CEVT_R4K=y +CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLKSRC_MIPS_GIC=y +CONFIG_CLKSRC_PISTACHIO=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_COMMON_CLK=y +# CONFIG_COMMON_CLK_BOSTON is not set +CONFIG_COMPAT_32BIT_TIME=y +CONFIG_CONNECTOR=y +CONFIG_CPU_GENERIC_DUMP_TLB=y +CONFIG_CPU_HAS_LOAD_STORE_LR=y +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_CPU_HAS_RIXI=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_CPU_IDLE=y +CONFIG_CPU_IDLE_GOV_LADDER=y +CONFIG_CPU_IDLE_GOV_MENU=y +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPS32_R2=y +CONFIG_CPU_MIPSR2=y +CONFIG_CPU_MIPSR2_IRQ_EI=y +CONFIG_CPU_MIPSR2_IRQ_VI=y +CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y +CONFIG_CPU_PM=y +CONFIG_CPU_R4K_CACHE_TLB=y +CONFIG_CPU_RMAP=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CPU_SUPPORTS_MSA=y +CONFIG_CRC16=y +CONFIG_CRC_CCITT=y +CONFIG_CRYPTO_ACOMP2=y +CONFIG_CRYPTO_AEAD=y +CONFIG_CRYPTO_AEAD2=y +CONFIG_CRYPTO_CBC=y +CONFIG_CRYPTO_CRC32C=y +CONFIG_CRYPTO_DEFLATE=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_HASH_INFO=y +CONFIG_CRYPTO_LIB_SHA256=y +CONFIG_CRYPTO_LZO=y +CONFIG_CRYPTO_MANAGER=y
[PATCH 1/2] jail: elf: Use 64 bit variables for elf offsets
The members p_offset, p_filesz and p_vaddr of the structure Elf64_Phdr
are all uint64_t. This structure is used for 64 bit applications.
Without this change we would convert the 64 bit values into 32 bit
values and an overflow could happen in this conversion.
On MIPS 64 BE the variable load_vaddr has the value 0x12000 which
sets the 32th bit which will overflow when converted to a 32 bit value.
On 32 bit systems Elf32_Phdr is used with uint32_t, converting this to
64 bit values too should not cause problems as this is not in the hot
path.
Without this fix I am getting error messages like this at bootup on MIPS 64 BE:
[ 16.622602] do_page_fault(): sending SIGSEGV to ujail for invalid read
access from 0100f37251e3
[ 16.622907] epc = 00aaab4ed0e0 in ujail[aaab4e+18000]
[ 16.623237] ra = 00aaab4ed694 in ujail[aaab4e+18000]
Signed-off-by: Hauke Mehrtens
---
jail/elf.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/jail/elf.c b/jail/elf.c
index f67515b..18a7b7c 100644
--- a/jail/elf.c
+++ b/jail/elf.c
@@ -102,7 +102,7 @@ const char* find_lib(const char *file)
return l->path;
}
-static int elf64_find_section(const char *map, unsigned int type, unsigned int
*offset, unsigned int *size, unsigned int *vaddr)
+static int elf64_find_section(const char *map, unsigned int type, unsigned
long *offset, unsigned long *size, unsigned long *vaddr)
{
Elf64_Ehdr *e;
Elf64_Phdr *ph;
@@ -125,7 +125,7 @@ static int elf64_find_section(const char *map, unsigned int
type, unsigned int *
return -1;
}
-static int elf32_find_section(const char *map, unsigned int type, unsigned int
*offset, unsigned int *size, unsigned int *vaddr)
+static int elf32_find_section(const char *map, unsigned int type, unsigned
long *offset, unsigned long *size, unsigned long *vaddr)
{
Elf32_Ehdr *e;
Elf32_Phdr *ph;
@@ -148,7 +148,7 @@ static int elf32_find_section(const char *map, unsigned int
type, unsigned int *
return -1;
}
-static int elf_find_section(const char *map, unsigned int type, unsigned int
*offset, unsigned int *size, unsigned int *vaddr)
+static int elf_find_section(const char *map, unsigned int type, unsigned long
*offset, unsigned long *size, unsigned long *vaddr)
{
int clazz = map[EI_CLASS];
@@ -162,7 +162,7 @@ static int elf_find_section(const char *map, unsigned int
type, unsigned int *of
return -1;
}
-static int elf32_scan_dynamic(const char *map, int dyn_offset, int dyn_size,
int load_offset)
+static int elf32_scan_dynamic(const char *map, unsigned long dyn_offset,
unsigned long dyn_size, long load_offset)
{
Elf32_Dyn *dynamic = (Elf32_Dyn *) (map + dyn_offset);
const char *strtab = NULL;
@@ -196,7 +196,7 @@ static int elf32_scan_dynamic(const char *map, int
dyn_offset, int dyn_size, int
return 0;
}
-static int elf64_scan_dynamic(const char *map, int dyn_offset, int dyn_size,
int load_offset)
+static int elf64_scan_dynamic(const char *map, unsigned long dyn_offset,
unsigned long dyn_size, long load_offset)
{
Elf64_Dyn *dynamic = (Elf64_Dyn *) (map + dyn_offset);
const char *strtab = NULL;
@@ -232,9 +232,9 @@ static int elf64_scan_dynamic(const char *map, int
dyn_offset, int dyn_size, int
int elf_load_deps(const char *path, const char *map)
{
- unsigned int dyn_offset, dyn_size;
- unsigned int load_offset, load_vaddr;
- unsigned int interp_offset;
+ unsigned long dyn_offset, dyn_size;
+ unsigned long load_offset, load_vaddr;
+ unsigned long interp_offset;
#if defined(__mips__) && (__mips == 64)
static int gcc_mips64_bug_work_around;
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] jail: elf: Remove MIPS 64 warning
The procd jails are working fine on MIPS64 too now.
I saw this error message when add_path_and_deps() was called which calls
elf_load_deps() again under some conditions. This is happening because
gcc_mips64_bug_work_around is stored in the data segment.
We have a call trace like this:
elf_load_deps()
gcc_mips64_bug_work_around = 1;
call add_path_and_deps()
call elf_load_deps()
gcc_mips64_bug_work_around = 1;
error if gcc_mips64_bug_work_around =! 1
gcc_mips64_bug_work_around = 0;
return;
return;
error if gcc_mips64_bug_work_around =! 1
return;
I got the same error messages on MIPS 32 BE, when I removed the compile
check.
This was tested in qemu on MIPS 64 BE and MIPS64 LE.
Signed-off-by: Hauke Mehrtens
---
jail/elf.c | 12
1 file changed, 12 deletions(-)
diff --git a/jail/elf.c b/jail/elf.c
index 18a7b7c..176d046 100644
--- a/jail/elf.c
+++ b/jail/elf.c
@@ -235,11 +235,7 @@ int elf_load_deps(const char *path, const char *map)
unsigned long dyn_offset, dyn_size;
unsigned long load_offset, load_vaddr;
unsigned long interp_offset;
-#if defined(__mips__) && (__mips == 64)
- static int gcc_mips64_bug_work_around;
- gcc_mips64_bug_work_around = 1;
-#endif
if (elf_find_section(map, PT_LOAD, &load_offset, NULL, &load_vaddr)) {
ERROR("failed to load the .load section from %s\n", path);
return -1;
@@ -256,14 +252,6 @@ int elf_load_deps(const char *path, const char *map)
int clazz = map[EI_CLASS];
-#if defined(__mips__) && (__mips == 64)
- if (gcc_mips64_bug_work_around != 1) {
- ERROR("compiler bug: GCC for MIPS64 should be fixed!\n");
- return -1;
- }
- gcc_mips64_bug_work_around = 0;
-#endif
-
if (clazz == ELFCLASS32)
return elf32_scan_dynamic(map, dyn_offset, dyn_size, load_vaddr
- load_offset);
else if (clazz == ELFCLASS64)
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/6] Update some development tools
This updates some of the development tools to their recent versions. Hauke Mehrtens (6): toolchain: gdb: Update to version 11.1 gdb: Update to version 11.1 valgrind: Update to version 3.18.1 valgrind: Activate also on MIPS 64 strace: Update to version 5.14 binutils: Update to version 2.37 package/devel/binutils/Makefile | 4 +- package/devel/gdb/Makefile| 6 +- .../devel/gdb/patches/110-shared_libgcc.patch | 12 +- .../devel/gdb/patches/130-gdb-ctrl-c.patch| 2 +- package/devel/strace/Makefile | 9 +- package/devel/strace/patches/010-m4.patch | 8 +- package/devel/valgrind/Makefile | 6 +- .../010-mips-Fix-new-syscall-numbers.patch| 131 ++ .../patches/130-mips_fix_soft_float.patch | 12 +- toolchain/gdb/Makefile| 7 +- .../patches/100-fix-elf-support-check.patch | 20 --- 11 files changed, 166 insertions(+), 51 deletions(-) create mode 100644 package/devel/valgrind/patches/010-mips-Fix-new-syscall-numbers.patch delete mode 100644 toolchain/gdb/patches/100-fix-elf-support-check.patch -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 6/6] binutils: Update to version 2.37
This matches the version used in the toolchain. Signed-off-by: Hauke Mehrtens --- package/devel/binutils/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/devel/binutils/Makefile b/package/devel/binutils/Makefile index ca1099349c12..5fdb83036ea3 100644 --- a/package/devel/binutils/Makefile +++ b/package/devel/binutils/Makefile @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk PKG_NAME:=binutils -PKG_VERSION:=2.35.2 +PKG_VERSION:=2.37 PKG_RELEASE:=1 PKG_SOURCE_URL:=@GNU/binutils PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_VERSION:=$(PKG_VERSION) -PKG_HASH:=dcd5b0416e7b0a9b24bed76cd8c6c132526805761863150a26d016415b8bdc7b +PKG_HASH:=820d9724f020a3e69cb337893a0b63c2db161dadcb0e06fc11dc29eb1e84a32c PKG_FIXUP:=autoreconf PKG_LIBTOOL_PATHS:=. gas bfd opcodes gprof binutils ld libiberty gold intl -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/6] valgrind: Activate also on MIPS 64
This activates valgrind also on mips64 and mips64el. This was working fine in a basic test in qemu. Signed-off-by: Hauke Mehrtens --- package/devel/valgrind/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/devel/valgrind/Makefile b/package/devel/valgrind/Makefile index 4f0e0fd49351..e6ebff4b3003 100644 --- a/package/devel/valgrind/Makefile +++ b/package/devel/valgrind/Makefile @@ -33,7 +33,7 @@ include $(INCLUDE_DIR)/kernel.mk define Package/valgrind SECTION:=devel CATEGORY:=Development - DEPENDS:=@mips||mipsel||i386||x86_64||powerpc||arm_v7||aarch64 +libpthread +librt + DEPENDS:=@mips||mipsel||mips64||mips64el||i386||x86_64||powerpc||arm_v7||aarch64 +libpthread +librt TITLE:=debugging and profiling tools for Linux URL:=http://www.valgrind.org endef -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 5/6] strace: Update to version 5.14
Explicitly deactivate libselinux, otherwise we get a hard dependency to libselinux. Signed-off-by: Hauke Mehrtens --- package/devel/strace/Makefile | 9 + package/devel/strace/patches/010-m4.patch | 8 2 files changed, 9 insertions(+), 8 deletions(-) diff --git a/package/devel/strace/Makefile b/package/devel/strace/Makefile index 8c4a26b63b25..527b3e01d83e 100644 --- a/package/devel/strace/Makefile +++ b/package/devel/strace/Makefile @@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_NAME:=strace -PKG_VERSION:=5.10 -PKG_RELEASE:=2 +PKG_VERSION:=5.14 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=https://strace.io/files/$(PKG_VERSION) -PKG_HASH:=fe3982ea4cd9aeb3b4ba35f6279f0b577a37175d3282be24b9a5537b56b8f01c +PKG_HASH:=901bee6db5e17debad4530dd9ffb4dc9a96c4a656edbe1c3141b7cb307b11e73 PKG_MAINTAINER:=Felix Fietkau PKG_LICENSE:=LGPL-2.1-or-later @@ -70,7 +70,8 @@ endef CONFIGURE_ARGS += \ --with-libdw=$(if $(CONFIG_STRACE_LIBDW),yes,no) \ --with-libunwind=$(if $(CONFIG_STRACE_LIBUNWIND),yes,no) \ - --enable-mpers=no + --enable-mpers=no \ + --without-libselinux MAKE_FLAGS := \ CCOPT="$(TARGET_CFLAGS)" diff --git a/package/devel/strace/patches/010-m4.patch b/package/devel/strace/patches/010-m4.patch index 478961ce26e4..32584e11806f 100644 --- a/package/devel/strace/patches/010-m4.patch +++ b/package/devel/strace/patches/010-m4.patch @@ -1,10 +1,10 @@ --- a/Makefile.am +++ b/Makefile.am -@@ -408,7 +408,6 @@ strace_LDADD += $(libiberty_LIBS) - endif - endif +@@ -21,7 +21,6 @@ man_MANS = doc/strace.1 doc/strace-log-m + + ACLOCAL_AMFLAGS = -I m4 -I src/xlat -@CODE_COVERAGE_RULES@ CODE_COVERAGE_BRANCH_COVERAGE = 1 CODE_COVERAGE_GENHTML_OPTIONS = $(CODE_COVERAGE_GENHTML_OPTIONS_DEFAULT) \ - --prefix $(shell cd $(abs_top_srcdir)/.. && pwd || echo .) + --title "$(PACKAGE_NAME)-$(PACKAGE_VERSION)" \ -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/6] valgrind: Update to version 3.18.1
This version has some improvements for musl. This version works fine for me on MIPS 32 BE without MIPS16 even on musl. The additional patch is needed to make valgrind use the correct syscall numbers for new syscalls like clock_gettime64. The MIPS architecture uses special syscall ranges which are different from most other systems. The patch is pending upstream: https://bugs.kde.org/show_bug.cgi?id=444781 Signed-off-by: Hauke Mehrtens --- On MIPS BE 32 bit with glibc valgrind does not work for me any more. I am getting this: root@OpenWrt:/# valgrind uname -a ==1371== Memcheck, a memory error detector ==1371== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==1371== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright info ==1371== Command: uname -a ==1371== valgrind: Fatal error at startup: a function redirection valgrind: which is mandatory for this platform-tool combination valgrind: cannot be set up. Details of the redirection are: valgrind: valgrind: A must-be-redirected function valgrind: whose name matches the pattern: index valgrind: in an object with soname matching: ld.so.1 valgrind: was not found whilst processing valgrind: symbols from the object with soname: ld.so.1 valgrind: valgrind: Possible fixes: (1, short term): install glibc's debuginfo valgrind: package on this machine. (2, longer term): ask the packagers valgrind: for your Linux distribution to please in future ship a non- valgrind: stripped ld.so (or whatever the dynamic linker .so is called) valgrind: that exports the above-named function using the standard valgrind: calling conventions for this platform. The package you need valgrind: to install for fix (1) is called valgrind: valgrind:On Debian, Ubuntu: libc6-dbg valgrind:On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo valgrind: valgrind: Note that if you are debugging a 32 bit process on a valgrind: 64 bit system, you will need a corresponding 32 bit debuginfo valgrind: package (e.g. libc6-dbg:i386). valgrind: valgrind: Cannot continue -- exiting now. Sorry. root@OpenWrt:/# package/devel/valgrind/Makefile | 4 +- .../010-mips-Fix-new-syscall-numbers.patch| 131 ++ .../patches/130-mips_fix_soft_float.patch | 12 +- 3 files changed, 139 insertions(+), 8 deletions(-) create mode 100644 package/devel/valgrind/patches/010-mips-Fix-new-syscall-numbers.patch diff --git a/package/devel/valgrind/Makefile b/package/devel/valgrind/Makefile index 829f37569e9b..4f0e0fd49351 100644 --- a/package/devel/valgrind/Makefile +++ b/package/devel/valgrind/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=valgrind -PKG_VERSION:=3.16.1 +PKG_VERSION:=3.18.1 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://sourceware.org/pub/valgrind/ -PKG_HASH:=c91f3a2f7b02db0f3bc99479861656154d241d2fdb265614ba918cc6720a33ca +PKG_HASH:=00859aa13a772eddf785f4b46ee0d39afbe071d32778da4d99984081f7f5 PKG_MAINTAINER:=Felix Fietkau PKG_LICENSE:=GPL-2.0+ diff --git a/package/devel/valgrind/patches/010-mips-Fix-new-syscall-numbers.patch b/package/devel/valgrind/patches/010-mips-Fix-new-syscall-numbers.patch new file mode 100644 index ..e84273c97322 --- /dev/null +++ b/package/devel/valgrind/patches/010-mips-Fix-new-syscall-numbers.patch @@ -0,0 +1,131 @@ +From 86ab9452bd10f08dbfa22d94e1155838f6f9f2e0 Mon Sep 17 00:00:00 2001 +From: Hauke Mehrtens +Date: Sun, 31 Oct 2021 23:11:11 +0100 +Subject: [PATCH] mips: Fix new syscall numbers + +The MIPS32 and MIPS64 O32 ABI are adding 4000 to all syscall numbers. +The MIPS64 N64 ABI adds 5000 to each syscall and the MIPS64 N32 ABI adds +6000 to each syscall number. We can not sue the shared file for MIPS and +have to define this for each sycall separately. + +Without this change valgrind is not able to detect new syscalls like +clock_gettime64 correctly. + +Signed-off-by: Hauke Mehrtens +--- + include/pub_tool_vkiscnums_asm.h | 3 --- + include/vki/vki-scnums-mips32-linux.h | 36 +++ + include/vki/vki-scnums-mips64-linux.h | 32 + 3 files changed, 68 insertions(+), 3 deletions(-) + +--- a/include/pub_tool_vkiscnums_asm.h b/include/pub_tool_vkiscnums_asm.h +@@ -63,15 +63,12 @@ + # include "vki/vki-scnums-arm64-linux.h" + + #elif defined(VGP_mips32_linux) +-# include "vki/vki-scnums-shared-linux.h" +-# include "vki/vki-scnums-32bit-linux.h" + # include "vki/vki-scnums-mips32-linux.h" + + #elif defined(VGP_nanomips_linux) + # include "vki/vki-scnums-nanomips-linux.h" + + #elif defined(VGP_mips64_linux) +-# include "vki/vki-scnums-shared-linux.h" + # include "vki/vki-scnums-mips64-linux.h" + + #elif defined(VGP_x86_fre
[PATCH 1/6] toolchain: gdb: Update to version 11.1
The removed patch was already applied upstream. gdb now mandatory depends on gmp, tell configure where to find it explicitly. We already build gmp in the tools directory for gcc. Also make it use mpfr and mpc as we also build both of them. Signed-off-by: Hauke Mehrtens --- Debian ships a gdb multi arch, we can probably also move gdb to the tools directory and build it only once for all targets. This should be done in a separate patch. toolchain/gdb/Makefile| 7 +-- .../patches/100-fix-elf-support-check.patch | 20 --- 2 files changed, 5 insertions(+), 22 deletions(-) delete mode 100644 toolchain/gdb/patches/100-fix-elf-support-check.patch diff --git a/toolchain/gdb/Makefile b/toolchain/gdb/Makefile index e769a3be3ece..2adb7d165aed 100644 --- a/toolchain/gdb/Makefile +++ b/toolchain/gdb/Makefile @@ -7,12 +7,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=gdb -PKG_VERSION:=10.1 +PKG_VERSION:=11.1 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@GNU/gdb -PKG_HASH:=f82f1eceeec14a3afa2de8d9b0d3c91d5a3820e23e0a01bbb70ef9f0276b62c0 +PKG_HASH:=cccfcc407b20d343fb320d4a9a2110776dd3165118ffd41f4b1b162340333f94 GDB_DIR:=$(PKG_NAME)-$(PKG_VERSION) HOST_BUILD_DIR:=$(BUILD_DIR_TOOLCHAIN)/$(GDB_DIR) @@ -30,6 +30,9 @@ HOST_CONFIGURE_ARGS = \ --build=$(GNU_HOST_NAME) \ --host=$(GNU_HOST_NAME) \ --target=$(REAL_GNU_TARGET_NAME) \ + --with-gmp=$(TOPDIR)/staging_dir/host \ + --with-mpfr=$(TOPDIR)/staging_dir/host \ + --with-mpc=$(TOPDIR)/staging_dir/host \ --disable-werror \ --without-uiout \ --enable-tui --disable-gdbtk --without-x \ diff --git a/toolchain/gdb/patches/100-fix-elf-support-check.patch b/toolchain/gdb/patches/100-fix-elf-support-check.patch deleted file mode 100644 index fe612c38db38.. --- a/toolchain/gdb/patches/100-fix-elf-support-check.patch +++ /dev/null @@ -1,20 +0,0 @@ a/gdb/configure -+++ b/gdb/configure -@@ -16818,6 +16818,7 @@ else - cat confdefs.h - <<_ACEOF >conftest.$ac_ext - /* end confdefs.h. */ - #include -+#include - #include "bfd.h" - #include "elf-bfd.h" - a/gdb/acinclude.m4 -+++ b/gdb/acinclude.m4 -@@ -362,6 +362,7 @@ AC_DEFUN([GDB_AC_CHECK_BFD], [ - AC_CACHE_CHECK([$1], [$2], - [AC_TRY_LINK( - [#include -+ #include - #include "bfd.h" - #include "$4" - ], -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/6] gdb: Update to version 11.1
GDB 11.1 now depends on gmp.
Signed-off-by: Hauke Mehrtens
---
package/devel/gdb/Makefile| 6 +++---
package/devel/gdb/patches/110-shared_libgcc.patch | 12 ++--
package/devel/gdb/patches/130-gdb-ctrl-c.patch| 2 +-
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/package/devel/gdb/Makefile b/package/devel/gdb/Makefile
index a3579969917e..9e20644b04fb 100644
--- a/package/devel/gdb/Makefile
+++ b/package/devel/gdb/Makefile
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=gdb
-PKG_VERSION:=10.2
+PKG_VERSION:=11.1
PKG_RELEASE:=$(AUTORELEASE)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_URL:=@GNU/gdb
-PKG_HASH:=aaa1223d534c9b700a8bec952d9748ee1977513f178727e1bee520ee000b4f29
+PKG_HASH:=cccfcc407b20d343fb320d4a9a2110776dd3165118ffd41f4b1b162340333f94
PKG_BUILD_PARALLEL:=1
PKG_INSTALL:=1
@@ -26,7 +26,7 @@ include $(INCLUDE_DIR)/nls.mk
define Package/gdb/Default
SECTION:=devel
CATEGORY:=Development
- DEPENDS:=+!USE_MUSL:libthread-db $(ICONV_DEPENDS) $(INTL_DEPENDS)
+ DEPENDS:=+!USE_MUSL:libthread-db $(ICONV_DEPENDS) $(INTL_DEPENDS) +libgmp
URL:=https://www.gnu.org/software/gdb/
endef
diff --git a/package/devel/gdb/patches/110-shared_libgcc.patch
b/package/devel/gdb/patches/110-shared_libgcc.patch
index de92a1f945cb..3979ccd26ba7 100644
--- a/package/devel/gdb/patches/110-shared_libgcc.patch
+++ b/package/devel/gdb/patches/110-shared_libgcc.patch
@@ -1,6 +1,6 @@
--- a/configure.ac
+++ b/configure.ac
-@@ -1302,13 +1302,13 @@ if test -z "$LD"; then
+@@ -1300,13 +1300,13 @@ if test -z "$LD"; then
fi
fi
@@ -17,7 +17,7 @@
AC_LANG_PUSH(C++)
AC_LINK_IFELSE([AC_LANG_SOURCE([
#if (__GNUC__ < 4) || (__GNUC__ == 4 && __GNUC_MINOR__ < 5)
-@@ -1648,7 +1648,7 @@ AC_ARG_WITH(stage1-ldflags,
+@@ -1705,7 +1705,7 @@ AC_ARG_WITH(stage1-ldflags,
# trust that they are doing what they want.
if test "$with_static_standard_libraries" = yes -a "$stage1_libs" = "" \
-a "$have_static_libs" = yes; then
@@ -26,7 +26,7 @@
fi])
AC_SUBST(stage1_ldflags)
-@@ -1677,7 +1677,7 @@ AC_ARG_WITH(boot-ldflags,
+@@ -1734,7 +1734,7 @@ AC_ARG_WITH(boot-ldflags,
# statically. But if the user explicitly specified the libraries to
# use, trust that they are doing what they want.
if test "$poststage1_libs" = ""; then
@@ -37,7 +37,7 @@
--- a/configure
+++ b/configure
-@@ -5075,14 +5075,14 @@ if test -z "$LD"; then
+@@ -5257,14 +5257,14 @@ if test -z "$LD"; then
fi
fi
@@ -56,7 +56,7 @@
ac_ext=cpp
ac_cpp='$CXXCPP $CPPFLAGS'
ac_compile='$CXX -c $CXXFLAGS $CPPFLAGS conftest.$ac_ext >&5'
-@@ -5883,7 +5883,7 @@ else
+@@ -6149,7 +6149,7 @@ else
# trust that they are doing what they want.
if test "$with_static_standard_libraries" = yes -a "$stage1_libs" = "" \
-a "$have_static_libs" = yes; then
@@ -65,7 +65,7 @@
fi
fi
-@@ -5919,7 +5919,7 @@ else
+@@ -6185,7 +6185,7 @@ else
# statically. But if the user explicitly specified the libraries to
# use, trust that they are doing what they want.
if test "$poststage1_libs" = ""; then
diff --git a/package/devel/gdb/patches/130-gdb-ctrl-c.patch
b/package/devel/gdb/patches/130-gdb-ctrl-c.patch
index 88b5de9d8c4b..72b7273434d2 100644
--- a/package/devel/gdb/patches/130-gdb-ctrl-c.patch
+++ b/package/devel/gdb/patches/130-gdb-ctrl-c.patch
@@ -24,7 +24,7 @@ Signed-off-by: Khem Raj
--- a/gdbserver/linux-low.cc
+++ b/gdbserver/linux-low.cc
-@@ -5714,7 +5714,7 @@ linux_process_target::request_interrupt
+@@ -5733,7 +5733,7 @@ linux_process_target::request_interrupt
{
/* Send a SIGINT to the process group. This acts just like the user
typed a ^C on the controlling terminal. */
--
2.30.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] toolchain: Allow sanitizer on mips and mipsel
Support for libsanitizer on MIPS 32 and MIPSEL 32 was added with GCC 9. MIPS 64 and ARC are still not supported. Signed-off-by: Hauke Mehrtens --- package/libs/toolchain/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/libs/toolchain/Makefile b/package/libs/toolchain/Makefile index 52a4cda19f6a..dea99060f954 100644 --- a/package/libs/toolchain/Makefile +++ b/package/libs/toolchain/Makefile @@ -115,7 +115,7 @@ define Package/libasan $(call Package/gcc/Default) NAME:=libasan TITLE:=Runtime library for AddressSanitizer in GCC - DEPENDS:=@USE_GLIBC +librt +libstdcpp @!mips @!mipsel @!mips64 @!mips64el @!arc + DEPENDS:=@USE_GLIBC +librt +libstdcpp @!mips64 @!mips64el @!arc ABI_VERSION:=5 endef @@ -202,7 +202,7 @@ define Package/libubsan $(call Package/gcc/Default) NAME:=libubsan TITLE:=Runtime library for UndefinedBehaviorSanitizer in GCC - DEPENDS:=@USE_GLIBC +librt +libstdcpp @!mips @!mipsel @!mips64 @!mips64el @!arc + DEPENDS:=@USE_GLIBC +librt +libstdcpp @!mips64 @!mips64el @!arc ABI_VERSION:=1 endef -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] config: Activate SECCOMP also on MIPS 64
This activates SECCOMP also on mips64 and mips64el. This was working fine in a basic test in qemu. Signed-off-by: Hauke Mehrtens --- I only did very basic testing, why was this not activated in the beginning? config/Config-build.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/Config-build.in b/config/Config-build.in index a028ebfbc37a..9bef36e53ea1 100644 --- a/config/Config-build.in +++ b/config/Config-build.in @@ -376,7 +376,7 @@ menu "Global build settings" bool "Enable SECCOMP" select KERNEL_SECCOMP select PACKAGE_procd-seccomp - depends on (aarch64 || arm || armeb || mips || mipsel || i386 || powerpc || x86_64) + depends on (aarch64 || arm || armeb || mips || mipsel || mips64 || mips64el || i386 || powerpc || x86_64) depends on !TARGET_uml default y help -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: RFC: layerscape: update to kernel 5.10
On 11/2/21 11:49 AM, Martin Schiller wrote: I have now found the cause of my boot problems with linux 5.10. (see [1] for reference) By changing the TEXT_OFFSET to 0x0 (instead of 0x8 before) in the upstream commit [2] and deactivated kernel option CONFIG_RELOCATABLE the system could not boot. Thus, we now need to set the KERNEL_LOADADDR to 0x8000 in the layerscape target for kernel >= 5.8. (ATTENTION: but then kernel 5.4 can no longer boot). You could set this depending on the config option CONFIG_LINUX_5_10. In addition, we should think about enabling CONFIG_RELOCATABLE in general to avoid being completely in the dark in case of similar problems in the future. Activating CONFIG_RELOCATABLE for layerscape should be ok, but I would not activate it for all targets. We tried to make a MIPS target use kASLR which is CONFIG_RELOCATABLE, and it was not easy to make it boot up again. We ran into many problems with the early boot process and the memory relocation. On ARM64 devices with a lot of memory this should be easier. The MIPS KConfig help also says this: > The relocations make the kernel binary about 15% larger, but are > discarded at runtime Also, I am currently very unhappy with how the kernel patches are handled in the layerscape target. So far they seem to be taken "1 to 1" from the NXP LSDK. This pile of patches is totally unmanageable and it is impossible to understand what is really needed and what is not. There was already a small discussion about this [3]. I would like to make a clear CUT here and work as far as possible with the linux upstream state. What is your opinion about this? (maybe any performance drawbacks, missing features etc.) I am not a user of this target. I also do not like all these layerscape patches and would support following upstream with only very few patches. Doing the cut with the kernel 5.10 update is a good idea. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
awk problem on pistachio (24kc+24kf)
Hi,
On pistachio sysupgrade in master fails and I got down to a problem with
awk. This command returns different results on pistachio compared to
other targets:
echo "mtd2: 2000 1000 \"uEnv\"" | awk -F: '{print $1}'
When I execute this on an lantiq/xrx200 or mt7622 device I get this:
mtd2
When I execute this command on pistachio in master I get this:
mtd2: 2000 1000 "uEnv"
This is part of the find_mtd_index() function used for sysupgrade.
The pistachio target is MIPS 32 little Endian with hardware floating
point activated. This target is not much used, nobody complained that it
did not boot for multiple months, but I am interested why it fails.
I also see this problem with OpenWrt master from August 2020 which was
still on the board.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uboot-lantiq: danube: fix hanging lzma kernel uncompression
On 11/2/21 11:35 PM, Mathias Kresin wrote: At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the assembly of LzmaProps_Decode. The instructions are using unaligned access, which locks up danube boards using memory mapped NOR flash. It isn't clear whether it is a limitation of the flash chip or a limitation of the EBU. Moving the pointer to the next int position and accessing accessing just the first byte, let gcc use sll instead of lwr/lwl and prevents the unaligned access. Signed-off-by: Mathias Kresin --- .../0030-lzma-fix-unaligned-access.patch | 32 +++ 1 file changed, 32 insertions(+) create mode 100644 package/boot/uboot-lantiq/patches/0030-lzma-fix-unaligned-access.patch diff --git a/package/boot/uboot-lantiq/patches/0030-lzma-fix-unaligned-access.patch b/package/boot/uboot-lantiq/patches/0030-lzma-fix-unaligned-access.patch new file mode 100644 index 00..de9afe0bf5 --- /dev/null +++ b/package/boot/uboot-lantiq/patches/0030-lzma-fix-unaligned-access.patch @@ -0,0 +1,32 @@ +From a335c4c0532cf0d09b31e73f8461d3b4d0ce6f9a Mon Sep 17 00:00:00 2001 +From: Mathias Kresin +Date: Sun, 31 Oct 2021 23:04:54 +0100 +Subject: [PATCH] lzma: fix unaligned access + +At least since gcc 7.3.0 (OpenWrt 18.06) lwr/lwl are used in the +assembly of LzmaProps_Decode. The instructions are using unaligned +access, which locks up danube boards using memory mapped NOR flash. + +It isn't clear whether it is a limitation of the flash chip or a +limitation of the EBU. + +Moving the pointer to the next int position and accessing accessing just +the first byte, let gcc use sll instead of lwr/lwl and prevents the +unaligned access. + +Signed-off-by: Mathias Kresin +--- + lib/lzma/LzmaDec.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/lib/lzma/LzmaDec.c b/lib/lzma/LzmaDec.c +@@ -929,7 +929,7 @@ SRes LzmaProps_Decode(CLzmaProps *p, con + if (size < LZMA_PROPS_SIZE) + return SZ_ERROR_UNSUPPORTED; + else +-dicSize = data[1] | ((UInt32)data[2] << 8) | ((UInt32)data[3] << 16) | ((UInt32)data[4] << 24); ++dicSize = data[1] | ((UInt32)data[2] << 8) | ((UInt32)data[3] << 16) | ((UInt32)(data+1)[0] << 24); Please add a small comment on top of this line in case someone applies these patches to a git tree and looks only at this code. + + if (dicSize < LZMA_DIC_MIN) + dicSize = LZMA_DIC_MIN; ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: awk problem on pistachio (24kc+24kf)
On 11/5/21 2:24 PM, Daniel Golle wrote:
On Tue, Nov 02, 2021 at 11:49:02PM +0100, Hauke Mehrtens wrote:
Hi,
On pistachio sysupgrade in master fails and I got down to a problem with
awk. This command returns different results on pistachio compared to other
targets:
echo "mtd2: 2000 1000 \"uEnv\"" | awk -F: '{print $1}'
When I execute this on an lantiq/xrx200 or mt7622 device I get this:
mtd2
When I execute this command on pistachio in master I get this:
mtd2: 2000 1000 "uEnv"
So the separator doesn't match. Maybe another integer bitwidth issue,
ie. comparing char aka. uint8 with uint16 or uint32 having their upper
bits not zero'd because only the first 8 bit of the register were
loaded, leaving old value in the remaining 8 or 24 bits?
Another interesting thing would be to try moving the position of the
':' as any variation in the result would be a clear hint towards
MIPS unaligned access being the problem...
Moving the position of the ":" did not help.
There are also hints on kernel mailing lists that Ingenic
implementation of MIPS interAptiv somehow differs in how cpu cache has
to be dealt with in combination with some memory access instructions
(I didn't get into the details and can't find it again atm)
I tried this on the InterAptiv core used by Maxlinear in MIPS BE mode
with an OpenWrt 19.07 user space and do not see the problem there.
When I build OpenWrt without floating point and use it on the pistachio
it still fails.
Does this also happen when using `cut -d: -f1` instead of the `awk`
call (not that this would solve anything, but if it happens also when
using `cut` it would be easier to debug as `cut` is much less complex
than `awk`, both are busybox applets).
With cut I do not see the problem:
root@OpenWrt:/# echo "mtd2: 2000 1000 \"uEnv\"" | cut -d: -f1
mtd2
This is part of the find_mtd_index() function used for sysupgrade.
The pistachio target is MIPS 32 little Endian with hardware floating point
activated. This target is not much used, nobody complained that it did not
boot for multiple months, but I am interested why it fails.
Unfortunately my pistachio board got stolen from my car 2 years ago
(among with tons of other equipment I had boxed up there).
I also see this problem with OpenWrt master from August 2020 which was still
on the board.
So at least this is not due to recent GCC or musl updates...
(that doesn't make it better though)
This could be a CPU problem. I will just ignore this problem for now and
take care of other stuff as pistachio is not used much.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
OpenWrt 19.07 end of life on 4. March 2022
Hi, The OpenWrt 19.07 stable branch will be end of life on 4. March 2022. Till then it is in security maintenance mode, we will provide updates for security problems and will also do point releases when necessary. After this date we will not even fix severe security problems any more. We encourage every user of the 19.07 stable series to upgrade to the OpenWrt 21.02 stable series. We plan to do a final point release from the 19.07 stable branch in March 2022 containing the last fixes which are in the branch at the time. For more details about our support policy see our security wiki page: https://openwrt.org/docs/guide-developer/security#support_status Have fun! The OpenWrt Community ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] bcm47xx: relocate LZMA loader
On 11/7/21 10:37 AM, Rafał Miłecki wrote: From: Rafał Miłecki This allows loader to handle kernel 5.10 that grew bigger than 5.4. Variations tested on BCM4706: BAD: BZ_TEXT_START := 0x8060 BZ_STACK_START := 0x8070 GOOD: BZ_TEXT_START := 0x8070 BZ_STACK_START := 0x8070 BAD: BZ_TEXT_START := 0x8060 BZ_STACK_START := 0x8080 GOOD: BZ_TEXT_START := 0x8070 BZ_STACK_START := 0x8080 I did some changes to these values 4 years ago here and explained the boot process a little bit: https://git.openwrt.org/2909a4b78e2bce5f6b9c35361866d5e9477a1bdc https://git.openwrt.org/d5cf4a5aa4a3211012967748569d9a631ee19466 Cc: Hauke Mehrtens Signed-off-by: Rafał Miłecki --- target/linux/bcm47xx/image/lzma-loader/src/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/bcm47xx/image/lzma-loader/src/Makefile b/target/linux/bcm47xx/image/lzma-loader/src/Makefile index a08fc05b9f..94b78254b8 100644 --- a/target/linux/bcm47xx/image/lzma-loader/src/Makefile +++ b/target/linux/bcm47xx/image/lzma-loader/src/Makefile @@ -18,7 +18,7 @@ # TEXT_START := 0x80001000 -BZ_TEXT_START := 0x8060 +BZ_TEXT_START := 0x8070 BZ_STACK_START:= 0x8070 We should also increase BZ_STACK_START. The code sets the stack pointer to BZ_STACK_START and then relocates itself to BZ_TEXT_START. If they are pointing to the same address the relocation process would overwrite the stack. We store the fw boot arguments on the stack and probably also use it for the LZMA code. All devices have at least 16MB RAM and we should be able to access this RAM from this code, we can also use this all for the decompression. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
