Re: [PATCH 1/5] firmware-utils: mkmerakifw-old: replace GPL-2.0-only boilerplate with SPDX
On 2021-08-08 14:37, Christian Lamparter wrote: On 06/08/2021 12:59, Rafał Miłecki wrote: From: Rafał Miłecki This was missed because scancode license scanner was confused by a comment about Cisco's GPL code github repository. Cc: Christian Lamparter Signed-off-by: Rafał Miłecki Acked-by: Christian Lamparter Does this help? Yes, thank you ___ 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: mvebu: armada 3720 cpufreq reverts
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
[sdwalker/sdwalker.github.io] a71dce: This week's update
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: a71dce40a9de73aff6ef342d56c3e0d2ab6acc55 https://github.com/sdwalker/sdwalker.github.io/commit/a71dce40a9de73aff6ef342d56c3e0d2ab6acc55 Author: Stephen Walker Date: 2021-08-08 (Sun, 08 Aug 2021) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.html M uscan/index-21.02.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v6 2/3] mvebu: add dts files for iEi Puzzle-M901/Puzzle-M902
On Tue, Aug 03, 2021 at 11:35:58AM +0800, eveans2...@gmail.com wrote:
> From: Ian Chang
>
> Signed-off-by: Ian Chang
> ---
> .../boot/dts/marvell/cn9131-puzzle-m901.dts | 319
> .../boot/dts/marvell/cn9132-puzzle-m902.dts | 481 ++
> 2 files changed, 800 insertions(+)
> 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
>
> diff --git
> a/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-puzzle-m901.dts
> b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-puzzle-m901.dts
> new file mode 100644
> index 00..58e749490a
> --- /dev/null
> +++
> b/target/linux/mvebu/files/arch/arm64/boot/dts/marvell/cn9131-puzzle-m901.dts
> @@ -0,0 +1,319 @@
> +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> +/*
> + * Copyright (C) 2019 Marvell International Ltd.
> + *
> + * Device tree for the CN9131-DB board.
> + */
> +
> +#include "cn9130.dtsi"
> +
> +#include
> +
> +/ {
> + model = "iEi Puzzle-M901";
> + compatible = "iei,puzzle-m901",
> + "marvell,armada-ap807-quad", "marvell,armada-ap807";
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + aliases {
> + i2c0 = _i2c0;
> + i2c1 = _i2c0;
> + ethernet0 = _eth0;
> + ethernet1 = _eth1;
> + ethernet2 = _eth2;
> + ethernet3 = _eth0;
> + ethernet4 = _eth1;
> + ethernet5 = _eth2;
> + gpio1 = _gpio1;
> + gpio2 = _gpio2;
> + gpio3 = _gpio1;
> + gpio4 = _gpio2;
> + };
> +
> + memory@ {
> + device_type = "memory";
> + reg = <0x0 0x0 0x0 0x8000>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_uart0 {
> + status = "okay";
> +};
> +
> +/* on-board eMMC - U9 */
> +_sdhci0 {
> + pinctrl-names = "default";
> + bus-width = <8>;
> + status = "okay";
> + mmc-ddr-1_8v;
> + mmc-hs400-1_8v;
> +};
> +
> +_crypto {
> + status = "okay";
> +};
> +
> +_xmdio {
> + status = "okay";
> + cp0_nbaset_phy0: ethernet-phy@0 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <2>;
> + };
> + cp0_nbaset_phy1: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <0>;
> + };
> + cp0_nbaset_phy2: ethernet-phy@2 {
> + compatible = "ethernet-phy-ieee802.3-c45";
> + reg = <8>;
> + };
> +};
> +
> +_ethernet {
> + status = "okay";
> +};
> +
> +/* SLM-1521-V2, CON9 */
> +_eth0 {
> + status = "okay";
> + phy-mode = "2500base-x";
> + phys = <_comphy2 0>;
> + managed = "in-band-status";
> +};
> +
> +_eth1 {
> + status = "okay";
> + phy-mode = "2500base-x";
> + phys = <_comphy4 1>;
> + managed = "in-band-status";
> +};
> +
> +_eth2 {
> + status = "okay";
> + phy-mode = "2500base-x";
> + phys = <_comphy5 2>;
> + managed = "in-band-status";
> +};
> +
> +_gpio1 {
> + status = "okay";
> +};
> +
> +_gpio2 {
> + status = "okay";
> +};
> +
> +_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c0_pins>;
> + status = "okay";
> + clock-frequency = <10>;
> + rtc@32 {
> + compatible = "epson,rx8130";
> + reg = <0x32>;
> + wakeup-source;
> + };
> +};
> +
> +/* SLM-1521-V2, CON6 */
> +_pcie0 {
> + status = "okay";
> + num-lanes = <2>;
> + num-viewport = <8>;
> + phys = <_comphy0 0>, <_comphy1 0>;
> +};
> +
> +/* U55 */
> +_spi1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi0_pins>;
> + reg = <0x700680 0x50>, /* control */
> + <0x200 0x100>;/* CS0 */
> + status = "okay";
> + spi-flash@0 {
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + compatible = "jedec,spi-nor";
> + reg = <0x0>;
> + spi-max-frequency = <4000>;
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + partition@0 {
> + label = "U-Boot";
> + reg = <0x0 0x1f>;
> + };
> + partition@1f {
> + label = "U-Boot ENV Factory";
> + reg = <0x1f 0x1>;
> + };
> + partition@20 {
> + label = "Reserved";
> + reg = <0x20 0x1f>;
> + };
> + partition@3f {
> + label = "U-Boot ENV";
> +
Re: [PATCH] base-files: add option to make /var persistent
On 07/08/21 10:40, Stijn Tintel wrote: On 7/08/2021 10:05, Alberto Bursi wrote: On 07/08/21 02:46, Stijn Tintel wrote: On 7/08/2021 02:56, Alberto Bursi wrote: On 06/08/21 21:27, Stijn Tintel wrote: In OpenWrt, /var is symlinked to /tmp by default. This is done to reduce the amount of writes to the flash chip, which often don't have the greatest durability. As a result, things like DHCP or UPnP lease files, are not persistent across reboots. Since OpenWrt can run on devices with more durable storage, it makes sense to have an option for a persistent /var. Add an option to make /var persistent. When enabled, /var will no longer be symlinked to /tmp, but /var/run will be symlink to /tmp/run, as it should contain only files that should not be kept during reboot. The option is off by default, to maintain the current behaviour. Since it does not really need to recompile anything, I think it can/should be handled as a package, not as a compile option. When you install the package these operations are executed, if you remove the package they are undone. Removing /var at runtime, which basically happens when you remove the symlink, is very ugly and has a huge potential for breakage. Having it as a build option also avoids users from accidentally installing it as a package. If you disagree, please elaborate further, including measures to avoid random breakage caused by removing /var at runtime. My focus was more on "not using a compile option", I don't think it's necessary to do this at runtime. A simple measure to avoid breakage would be to add something that runs on boot (either initscript or preinitscript) to do these changes before any other service that needs that folder is started. So you install the package and then reboot. This approach also allows to make this a permanent change (not an optional package) and control this function with UCI config, just change the setting and reboot. IMHO this is good enough for most users, and much better than having to recompile or do the change manually. For the sake of completeness, (also shameless plug about my project): A more complex way to do it at runtime that avoids breakage is bind mounting the original folder somewhere else so you can sync the contents with the new/empty folder, then restarting all services that need it. See https://github.com/bobafetthotmail/folder2ram/blob/master/debian_package/sbin/folder2ram#L658 (the service restart is not included in that script since it has no way of knowing what services need the folders, this operation is left to the user or for OpenMediaVault it's handled by the plugin that also writes the configuration) Appreciate the input. It still sounds overly complex compared to my suggestion, especially for something that most users will probably not use. I don't feel comfortable implementing something like that. I'll just keep using my patch locally then, as I have done for almost five years. I'm not stopping you, I'm just voicing my opinion. Having this as a compile option is still better than nothing, please don't drop this just because of my feedback. -Alberto ___ 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
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Removing openwrt-announce from the distribution :-) Am Sonntag, 8. August 2021, 13:43:39 CEST schrieb Arınç ÜNAL: > 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ç -- Rainer Dorsch Beatus-Widmann-Str. 5 72138 Kirchentellinsfurt 07157/734133 --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/5] firmware-utils: mkmerakifw-old: replace GPL-2.0-only boilerplate with SPDX
On 06/08/2021 12:59, Rafał Miłecki wrote: From: Rafał Miłecki This was missed because scancode license scanner was confused by a comment about Cisco's GPL code github repository. Cc: Christian Lamparter Signed-off-by: Rafał Miłecki Acked-by: Christian Lamparter Does this help? Cheers, Christian ___ 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
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ç ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
