From b254bd697d02c1daa809bf831060ebed0c8a44f9 Mon Sep 17 00:00:00 2001 From: Josef Schlehofer Date: Tue, 27 Jul 2021 13:22:30 +0200 Subject: [PATCH 1/5] Revert "mvebu: 5.4 fix DVFS caused random boot crashes" MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Based on the discussion on the mailing list [1], the patch which was reverted, it reverts only one patch without the subsequent ones. This leads to the SoC scaling issue not using a CPU parent clock, but it uses DDR clock. This is done for all variants, and it's wrong because commits (hacks) that were using the DDR clock are no longer in the mainline kernel. If someone has stability issues on 1.2 GHz, it should not affect all routers (1 GHz, 800 MHz) and it should be rather consulted with guys, who are trying to improve the situation in the kernel and not making the situation worse. There are two solutions in cases of instability: a) disable cpufreq b) underclock it up to 1 GHz This reverts commit 080a0b74e39d159eecf69c468debec42f28bf4d8. [1] https://lists.openwrt.org/pipermail/openwrt-devel/2021-June/035702.html CC: Pali Rohár Signed-off-by: Josef Schlehofer (cherry picked from commit 7b868fe04a8961048feec1143e72fe47bde52a12) --- ...rmada-37xx-Fix-setting-TBG-parent-fo.patch | 107 ------------------ 1 file changed, 107 deletions(-) delete mode 100644 target/linux/mvebu/patches-5.4/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch diff --git a/target/linux/mvebu/patches-5.4/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch b/target/linux/mvebu/patches-5.4/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch deleted file mode 100644 index 65184df584..0000000000 --- a/target/linux/mvebu/patches-5.4/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch +++ /dev/null @@ -1,107 +0,0 @@ -From 35639bac13927d1476398b740b11cbed0ee3ddb2 Mon Sep 17 00:00:00 2001 -From: Robert Marko -Date: Tue, 18 May 2021 13:24:30 +0200 -Subject: [PATCH] Revert "cpufreq: armada-37xx: Fix setting TBG parent for load - levels" - -This reverts commit a13b110e7c9e0dc2edcc7a19d4255fc88abd83cc. - -This patch actually corrects the things so that 1 or 1.2GHz models would -actually get scaled to their native frequency. - -However, due to a AVS setting voltages too low this will cause random -crashes on 1.2GHz models. - -So, until a new safe for everybody voltage is agreed on -lets revert the patch. - -Signed-off-by: Robert Marko ---- - drivers/cpufreq/armada-37xx-cpufreq.c | 35 +++++++++------------------ - 1 file changed, 12 insertions(+), 23 deletions(-) - ---- a/drivers/cpufreq/armada-37xx-cpufreq.c -+++ b/drivers/cpufreq/armada-37xx-cpufreq.c -@@ -25,10 +25,6 @@ - - #include "cpufreq-dt.h" - --/* Clk register set */ --#define ARMADA_37XX_CLK_TBG_SEL 0 --#define ARMADA_37XX_CLK_TBG_SEL_CPU_OFF 22 -- - /* Power management in North Bridge register set */ - #define ARMADA_37XX_NB_L0L1 0x18 - #define ARMADA_37XX_NB_L2L3 0x1C -@@ -126,15 +122,10 @@ static struct armada_37xx_dvfs *armada_3 - * will be configured then the DVFS will be enabled. - */ - static void __init armada37xx_cpufreq_dvfs_setup(struct regmap *base, -- struct regmap *clk_base, u8 *divider) -+ struct clk *clk, u8 *divider) - { -- u32 cpu_tbg_sel; - int load_lvl; -- -- /* Determine to which TBG clock is CPU connected */ -- regmap_read(clk_base, ARMADA_37XX_CLK_TBG_SEL, &cpu_tbg_sel); -- cpu_tbg_sel >>= ARMADA_37XX_CLK_TBG_SEL_CPU_OFF; -- cpu_tbg_sel &= ARMADA_37XX_NB_TBG_SEL_MASK; -+ struct clk *parent; - - for (load_lvl = 0; load_lvl < LOAD_LEVEL_NR; load_lvl++) { - unsigned int reg, mask, val, offset = 0; -@@ -153,11 +144,6 @@ static void __init armada37xx_cpufreq_dv - mask = (ARMADA_37XX_NB_CLK_SEL_MASK - << ARMADA_37XX_NB_CLK_SEL_OFF); - -- /* Set TBG index, for all levels we use the same TBG */ -- val = cpu_tbg_sel << ARMADA_37XX_NB_TBG_SEL_OFF; -- mask = (ARMADA_37XX_NB_TBG_SEL_MASK -- << ARMADA_37XX_NB_TBG_SEL_OFF); -- - /* - * Set cpu divider based on the pre-computed array in - * order to have balanced step. -@@ -176,6 +162,14 @@ static void __init armada37xx_cpufreq_dv - - regmap_update_bits(base, reg, mask, val); - } -+ -+ /* -+ * Set cpu clock source, for all the level we keep the same -+ * clock source that the one already configured. For this one -+ * we need to use the clock framework -+ */ -+ parent = clk_get_parent(clk); -+ clk_set_parent(clk, parent); - } - - /* -@@ -401,16 +395,11 @@ static int __init armada37xx_cpufreq_dri - struct platform_device *pdev; - unsigned long freq; - unsigned int cur_frequency, base_frequency; -- struct regmap *nb_clk_base, *nb_pm_base, *avs_base; -+ struct regmap *nb_pm_base, *avs_base; - struct device *cpu_dev; - int load_lvl, ret; - struct clk *clk, *parent; - -- nb_clk_base = -- syscon_regmap_lookup_by_compatible("marvell,armada-3700-periph-clock-nb"); -- if (IS_ERR(nb_clk_base)) -- return -ENODEV; -- - nb_pm_base = - syscon_regmap_lookup_by_compatible("marvell,armada-3700-nb-pm"); - -@@ -487,7 +476,7 @@ static int __init armada37xx_cpufreq_dri - armada37xx_cpufreq_avs_configure(avs_base, dvfs); - armada37xx_cpufreq_avs_setup(avs_base, dvfs); - -- armada37xx_cpufreq_dvfs_setup(nb_pm_base, nb_clk_base, dvfs->divider); -+ armada37xx_cpufreq_dvfs_setup(nb_pm_base, clk, dvfs->divider); - clk_put(clk); - - for (load_lvl = ARMADA_37XX_DVFS_LOAD_0; load_lvl < LOAD_LEVEL_NR; From f407b2f43c27a7b35c4f96d3efcee2cc440f8efe Mon Sep 17 00:00:00 2001 From: Josef Schlehofer Date: Tue, 27 Jul 2021 13:22:31 +0200 Subject: [PATCH 2/5] mvebu: armada-37xx: add patch to forbid cpufreq for 1.2 GHz This patch is backported from linux-arm-kernel [1] to improve situation, when it was reported that 1.2 GHz variant is unstable with DFS. It waits to be accepted upstream, however, it waits for Marvell people to respond. [1] https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210630225601.6372-1-kabel@kernel.org/ Signed-off-by: Josef Schlehofer (cherry picked from commit d3794768177293f584cc74f90c921276793da1e7) --- ...x-forbid-cpufreq-for-1.2-GHz-variant.patch | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 target/linux/mvebu/patches-5.4/100-cpufreq-armada-37xx-forbid-cpufreq-for-1.2-GHz-variant.patch diff --git a/target/linux/mvebu/patches-5.4/100-cpufreq-armada-37xx-forbid-cpufreq-for-1.2-GHz-variant.patch b/target/linux/mvebu/patches-5.4/100-cpufreq-armada-37xx-forbid-cpufreq-for-1.2-GHz-variant.patch new file mode 100644 index 0000000000..6a5b8220f8 --- /dev/null +++ b/target/linux/mvebu/patches-5.4/100-cpufreq-armada-37xx-forbid-cpufreq-for-1.2-GHz-variant.patch @@ -0,0 +1,39 @@ +From: =?utf-8?q?Marek_Beh=C3=BAn?= +Subject: [PATCH v2] cpufreq: armada-37xx: forbid cpufreq for 1.2 GHz variant +Date: Thu, 1 Jul 2021 00:56:01 +0200 + +The 1.2 GHz variant of the Armada 3720 SOC is unstable with DVFS: when +the SOC boots, the WTMI firmware sets clocks and AVS values that work +correctly with 1.2 GHz CPU frequency, but random crashes occur once +cpufreq driver starts scaling. + +We do not know currently what is the reason: +- it may be that the voltage value for L0 for 1.2 GHz variant provided + by the vendor in the OTP is simply incorrect when scaling is used, +- it may be that some delay is needed somewhere, +- it may be something else. + +The most sane solution now seems to be to simply forbid the cpufreq +driver on 1.2 GHz variant. + +Signed-off-by: Marek Behún +Fixes: 92ce45fb875d ("cpufreq: Add DVFS support for Armada 37xx") +--- + drivers/cpufreq/armada-37xx-cpufreq.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/cpufreq/armada-37xx-cpufreq.c ++++ b/drivers/cpufreq/armada-37xx-cpufreq.c +@@ -102,7 +102,11 @@ struct armada_37xx_dvfs { + }; + + static struct armada_37xx_dvfs armada_37xx_dvfs[] = { +- {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} }, ++ /* ++ * The cpufreq scaling for 1.2 GHz variant of the SOC is currently ++ * unstable because we do not know how to configure it properly. ++ */ ++ /* {.cpu_freq_max = 1200*1000*1000, .divider = {1, 2, 4, 6} }, */ + {.cpu_freq_max = 1000*1000*1000, .divider = {1, 2, 4, 5} }, + {.cpu_freq_max = 800*1000*1000, .divider = {1, 2, 3, 4} }, + {.cpu_freq_max = 600*1000*1000, .divider = {2, 4, 5, 6} }, From d9be07169eccab26c62c87c7ac18bdd22b18036e Mon Sep 17 00:00:00 2001 From: Rosen Penev Date: Tue, 13 Jul 2021 13:27:09 -0700 Subject: [PATCH 3/5] mbedtls: update to 2.16.11 Switched to AUTORELEASE to avoid manual increments. Release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 Signed-off-by: Rosen Penev (cherry picked from commit fcfd741eb83520e496eb09de5f8b2f2b62792a80) --- package/libs/mbedtls/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/libs/mbedtls/Makefile b/package/libs/mbedtls/Makefile index 7f6bf4e4c0..58a60c3226 100644 --- a/package/libs/mbedtls/Makefile +++ b/package/libs/mbedtls/Makefile @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk PKG_NAME:=mbedtls -PKG_VERSION:=2.16.10 -PKG_RELEASE:=1 +PKG_VERSION:=2.16.11 +PKG_RELEASE:=$(AUTORELEASE) PKG_USE_MIPS16:=0 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://codeload.github.com/ARMmbed/mbedtls/tar.gz/v$(PKG_VERSION)? -PKG_HASH:=96257bb03b30300b2f35f861ffe204ed957e9fd0329d80646fe57fc49f589b29 +PKG_HASH:=c18e7e9abf95e69e425260493720470021384a1728417042060a35d0b7b18b41 PKG_BUILD_PARALLEL:=1 PKG_LICENSE:=GPL-2.0-or-later From 94efa1c61247830b2e1190933e665eb3adcc66d5 Mon Sep 17 00:00:00 2001 From: Daniel Kestrel Date: Sun, 25 Jul 2021 20:32:05 +0200 Subject: [PATCH 4/5] fritz-tools: fix returning wrong values due to strncmp usage When having two keys that start with the same characters and the second key just has one character more nand_tffs_read and tffs_read return the wrong value for the longer key. This is due to the usage of strncmp in combination with the length of the shorter key which is usually first in the list before the longer key and when strncmp matches, the search is stopped. The problem only occurs when the length of the two keys is different, not if just the last character is different. The fix is to use strcmp and as such it will only return the value if the key (name) and the key to look for (namefilter) have the same value and length. A sample case returning wrong values is when keys macwlan and macwlan2 are defined and querying macwlan2 returns the value for macwlan. Signed-off-by: Daniel Kestrel (cherry picked from commit 12564c5b860f9849c9a2fb7026c2c11150b9a4fc) --- package/utils/fritz-tools/src/fritz_tffs_nand_read.c | 2 +- package/utils/fritz-tools/src/fritz_tffs_read.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/package/utils/fritz-tools/src/fritz_tffs_nand_read.c b/package/utils/fritz-tools/src/fritz_tffs_nand_read.c index ded0577cf3..22b27336f8 100644 --- a/package/utils/fritz-tools/src/fritz_tffs_nand_read.c +++ b/package/utils/fritz-tools/src/fritz_tffs_nand_read.c @@ -340,7 +340,7 @@ static int show_matching_key_value(struct tffs_key_name_table *key_names) for (uint32_t i = 0; i < key_names->size; i++) { name = key_names->entries[i].val; - if (strncmp(name, name_filter, strlen(name)) == 0) { + if (strcmp(name, name_filter) == 0) { if (find_entry(key_names->entries[i].id, &tmp)) { print_entry_value(&tmp); printf("\n"); diff --git a/package/utils/fritz-tools/src/fritz_tffs_read.c b/package/utils/fritz-tools/src/fritz_tffs_read.c index d1b3038e63..256c34c414 100644 --- a/package/utils/fritz-tools/src/fritz_tffs_read.c +++ b/package/utils/fritz-tools/src/fritz_tffs_read.c @@ -204,7 +204,7 @@ static int show_matching_key_value(uint8_t *buffer, for (i = 0; i < key_names->size; i++) { name = key_names->entries[i].val; - if (strncmp(name, name_filter, strlen(name)) == 0) { + if (strcmp(name, name_filter) == 0) { id = to_entry_header_id(*key_names->entries[i].id); if (find_entry(buffer, id, &tmp)) { From 750b966866b098a2e9a8693d313111ed1e892ab6 Mon Sep 17 00:00:00 2001 From: Edgar Su Date: Mon, 12 Jul 2021 21:22:48 +0800 Subject: [PATCH 5/5] x86: kernel: set NR_CPUS to 512 NR_CPUS limits the number of CPUs supported to 8. This makes total sense on hardware-restircted platforms, but not on x86_64, where CPUs with more than 8 cores can be easily acquired and with less physical limitaions. see also: https://forum.openwrt.org/t/x86-64-8-cpu-limitation-on-vanilla-release/100946 Signed-off-by: Edgar Su (cherry picked from commit df554e6fcab171ec499d8fb2ed10a0da328323f3) --- target/linux/x86/64/config-5.4 | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/target/linux/x86/64/config-5.4 b/target/linux/x86/64/config-5.4 index 348165a209..434cde5d86 100644 --- a/target/linux/x86/64/config-5.4 +++ b/target/linux/x86/64/config-5.4 @@ -310,8 +310,8 @@ CONFIG_ND_CLAIM=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NET_FAILOVER=y CONFIG_NET_FLOW_LIMIT=y -CONFIG_NR_CPUS=8 -CONFIG_NR_CPUS_DEFAULT=64 +CONFIG_NR_CPUS=512 +CONFIG_NR_CPUS_DEFAULT=512 CONFIG_NR_CPUS_RANGE_BEGIN=2 CONFIG_NR_CPUS_RANGE_END=512 # CONFIG_NUMA is not set