[PATCH v5] mvebu: add support for iEi Puzzle-M901/Puzzle-M902
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/cortexa72/base-files/etc/board.d/02_network
b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
index 9ab3c8174d..e0a4bc3015 100755
--- a/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
+++ b/target/linux/mvebu/cortexa72/base-files/etc/board.d/02_network
@@ -11,6 +11,12 @@ board_config_update
board=$(board_name)
case "$board" in
+iei,puzzle-m901)
+ ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5" "eth0"
+ ;;
+iei,puzzle-m902)
+ ucidef_set_interfaces_lan_wan "eth1 eth2 eth3 eth4 eth5 eth10 eth11
eth12" "eth0"
+ ;;
marvell,armada8040-mcbin-doubleshot|\
marvell,armada8040-mcbin-singleshot)
ucidef_set_interfaces_lan_wan "eth0 eth1 eth3" "eth2"
diff --git a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
new file mode 100644
index 00..5e5c356ed6
--- /dev/null
+++ b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/emmc.sh
@@ -0,0 +1,36 @@
+platform_do_upgrade_emmc() {
+ local board=$(board_name)
+ local diskdev partdev
+
+ export_bootdevice && export_partdevice diskdev 0 || {
+ v "Unable to determine upgrade device"
+ return 1
+ }
+ sync
+ if [ "$UPGRADE_OPT_SAVE_PARTITIONS" = "1" ]; then
+ get_partitions "/dev/$diskdev" bootdisk
+ v "Extract boot sector from the image"
+ get_image_dd "$1" of=/tmp/image.bs count=1 bs=512b
+ get_partitions /tmp/image.bs image
+ fi
+
+ #iterate over each partition from the image and write it to the boot
disk
+ while read part start size; do
+ if export_partdevice partdev $part; then
+ if [ "$partdev" = "mmcblk0p2" ]; then
+ v "Writing image mmcblk0p3 for /dev/$partdev
$start $size"
+ get_image_dd "$1" of="/dev/mmcblk0p3" ibs="512"
obs=1M skip="$start" count="$size" conv=fsync
+ elif [ "$partdev" = "mmcblk0p1" ]; then
+ v "Writing image mmcblk0p1 for /dev/$partdev
$start $size"
+ get_image_dd "$1" of="/dev/$partdev" ibs="512"
obs=1M skip="$start" count="$size" conv=fsync
+ fi
+ else
+ v "Unable to find partition $part device, skipped."
+ fi
+ done < /tmp/partmap.image
+
+ v "Writing new UUID to /dev/$diskdev..."
+ get_image_dd "$1" of="/dev/$diskdev" bs=1 skip=440 count=4 seek=440
conv=fsync
+
+ sleep 1
+}
diff --git a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
index 04ea634097..9a89768d14 100755
--- a/target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
+++ b/target/linux/mvebu/cortexa72/base-files/lib/upgrade/platform.sh
@@ -9,6 +9,8 @@ REQUIRE_IMAGE_METADATA=1
platform_check_image() {
case "$(board_name)" in
+ iei,puzzle-m901|\
+ iei,puzzle-m902|\
marvell,armada8040-mcbin-doubleshot|\
marvell,armada8040-mcbin-singleshot)
platform_check_image_sdcard
Re: OpenWrt 21.02 status
On 19/07/21 21:11, Luiz Angelo Daros de Luca wrote: This is not a migration script but a mitigation. A 21.02 image should detect during boot if the current network config was for swconfig in a system using DSA. It could happen during early boot stages, after FS are mounted, before services are started, something similar to uci-defaults, but not in a "run once" way. It would cover both upgrades with confs and restores. We are asking the user to upgrade without saving confs but nothing will prevent them from keeping settings while using "sysupgrade -F" nor restoring an 19.07 backup "manually" into a 21.02. I think an expert dev could solve this one with a 5 line script ;-) It's a 5 line script if you are migrating default switch config to new default switch config and assuming the user did not touch much. With smart switch you could do some pretty elaborate setups and making a script that can actually migrate more than very basic configs is not easy at all. -Alberto ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: OpenWrt 21.02 status
> It could happen during early boot stages, after FS are mounted, before > services are started, something similar to uci-defaults, but not in a "run > once" > way. > It would cover both upgrades with confs and restores. We are asking the > user to upgrade without saving confs but nothing will prevent them from > keeping settings while using "sysupgrade -F" nor restoring an 19.07 backup > "manually" into a 21.02. I think an expert dev could solve this one with a 5 > line > script That's what everybody believes until he tries. The problem is how to detect whether the config is old or new. This might be hacked somehow for specific cases, but it's impossible to do in an acceptable way for a generic case. Note that compat 1.0->1.1 does not necessarily mean swconfig->DSA, so we have no general variable that will define which state we are in. There is a reason why nobody provided a DSA migration script (or even tried AFAIK). This horse is dead. (Doing -f without -n is a real world problem. They might pseudo-brick their devices. However, we have no better solution about that at the moment.) Best Adrian > ;-) > > Regards, openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi Hauke, On Mon, Jul 19, 2021 at 8:05 PM Hauke Mehrtens wrote: > > Hi Hans, > > On 7/17/21 5:45 PM, Hauke Mehrtens wrote: > > Hi, > > > > In general the 21.02-rc3 looks good, but we still have some problems. > > > > Currently we still have these problem: > > > > > - DHCPv6 broken if lease times < 12h chosen > >- > > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 > >- > > https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 > > > Should this commit fix the "DHCPv6 broken if lease times < 12h chosen" > problem? > https://git.openwrt.org/4633471d74589c761a3849bd63935b42ac3cea73 Correct this fixes the issue if the leasetime is smaller than the preferred lifetime of an address Hans > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: OpenWrt 21.02 status
> -Original Message- > From: Daniel Golle [mailto:dan...@makrotopia.org] > Sent: Montag, 19. Juli 2021 10:13 > To: Adrian Schmutzler > Cc: 'Luiz Angelo Daros de Luca'; 'Hauke Mehrtens'; 'Rich Brown'; 'OpenWrt > Development List'; 'Jo-Philipp Wich'; 'Kevin 'ldir' Darbyshire-Bryant'; 'John > Crispin'; 'Rafał Miłecki' > Subject: Re: OpenWrt 21.02 status > > On Sun, Jul 18, 2021 at 10:30:20PM +0200, Adrian Schmutzler wrote: > > > The last time I tried it was very confusing. When I first read about > > > "new fresh installation", I thought: "install without keeping settings". > > > However, OpenWrt returned an image check failure, even when I did > > > not keep the settings (sysupgrade -n). It was the same type of error > > > (image validation failed) that would happen if I selected the wrong > > > firmware (but maybe with a different content). The only way to > > > install it was forcing the operation, which might also allow an > > > incompatible image to be installed (bricking the device). Please > > > reconsider some form of upgrade path that validates the image and > > > allows the user to upgrade without a force or going back to factory > > > before reinstalling OpenWrt with DSA. Something like "update package > > > foo to version n.m.z or upgrade to 19.07.9 before installing > > > 21.02 for proper image validation". Most users will not be confident to > apply > > > a forced installation. > > > > That would be nice, but unfortunately it's not so easy. The problem is that > the upgrade mechanism is baked into the _old_ image. > > Any upgrade can only do what the old firmware supported. Thus, I was > really glad that I was able to hack this message into the device detection > mechanism at all. Otherwise, we would not have any message at all for old > installations. > > I believe what he meant to say was to make another 19.07.x point release > with an updated sysupgrade mechanism which would improve the situation > when upgrading to 21.02.x and, for example, allow flashing with non- > matching DEVICE_COMPAT_VERSION already when specifying the '-n' flag to > not keep configuration, but not require the '-F' flag which is scary for > regular > users (for good reasons). I see the point of this approach, and I also considered it already when I started this thing. It should work like that if done properly. However, I really do not like to backport fundamental features/feature changes like that. It probably wouldn't even be much work as the code changes itself are few; but changing the sysupgrade mechanism in a .8 point release that might be the last one really does not feel right to me. I will give it a few days of thought... Best Adrian > > > > > > > > > From wiki upgrading to 21.02 page: > > > > > > "Don't worry - If you try to upgrade with the wrong target, > > > sysupgrade will refuse to proceed with an error message like this: > > > Image version mismatch. image 1.1 device 1.0 Please wipe config > > > during upgrade (force required) or reinstall. Config cannot be > > > migrated from swconfig to DSA Image check failed" > > > > > > My experience and the message content indicates that it will show > > > for all migrations from "swconfig" to "DSA" and not only for "wrong > target". > > > > Yes. For the old sysupgrade, we simply match two strings (the board name > from the device against SUPPORTED_DEVICES from the image). Either it's > successful, or it's not. If it's not, the message displays the name of the > SUPPORTED_DEVICES. That's what we got. So I have to hack all of the > message into the SUPPORTED_DEVICES string. > > > > > > > > I tried to start a discussion about it in an email "Usability issues > > > for DSA upgrade" (jun/28) but I got no answer. > > > > We can discuss this for the future, i.e. for updates starting at 21.xx, and > > we > can discuss the exact wording of the message. > > Not saying that I'm fond of it, neither that I'm volunteering to do it, but we > **could** also update 19.07.x > > > > > > > > > It would also be great if we could detect a config from a pre-dsa > > > system and restore everything but skipping or renaming DSA relevant > > > files (nework, > > > wifi?) DSA) with a suffix like '.pre-dsa'. > > > > We had a very long delay due to DSA and nobody was even slightly > interested in creating a migration script. > > For partial migration, I suspect that implementing something here that is > general will be much more complicated than just having the user select what > he wants/needs. > > > > Best > > > > Adrian > > > > > > > > DSA is missing a lot of docs. For example: is there a simple, secure > > > way to detect a system is using DSA for a specific switch (or device)? > > > Is it possible to exist a device with two switches and only one of > > > them uses DSA? > > > > > > Regards, > > > > > > ___ > > > openwrt-devel mailing list > > > openwrt-devel@lists.openwrt.org > > >
Re: OpenWrt 21.02 status
> I believe what he meant to say was to make another 19.07.x point > release with an updated sysupgrade mechanism which would improve the > situation when upgrading to 21.02.x and, for example, allow > flashing with non-matching DEVICE_COMPAT_VERSION already when > specifying the '-n' flag to not keep configuration, but not require > the '-F' flag which is scary for regular users (for good reasons). That is exactly what I propose. We should somehow make sysupgrade in 19.07 be able to understand a DSA image and allow an upgrade '-n' without warning and forces. I think a package upgrade or a new package installation might be able to do that. It touches the image validation, which I guess happens before switch_root. It does not invalidate the use of -F for older images but it allows a safer path. We could have a new 19.07 point release with that update, but it is just another way to install the new/updated package. I think all involved files in image validation are in base-files. I think they should be in an individual package to help upgrade them without touching the rest of the system. This will not be the last time OpenWrt will need to prepare an old version to deal with a new release image. > > We can discuss this for the future, i.e. for updates starting at 21.xx, and > > we can discuss the exact wording of the message. First we need a solution to offer the user. > > > It would also be great if we could detect a config from a pre-dsa system > > > and > > > restore everything but skipping or renaming DSA relevant files (nework, > > > wifi?) DSA) with a suffix like '.pre-dsa'. > > > > We had a very long delay due to DSA and nobody was even slightly interested > > in creating a migration script. > > For partial migration, I suspect that implementing something here that is > > general will be much more complicated than just having the user select what > > he wants/needs. This is not a migration script but a mitigation. A 21.02 image should detect during boot if the current network config was for swconfig in a system using DSA. It could happen during early boot stages, after FS are mounted, before services are started, something similar to uci-defaults, but not in a "run once" way. It would cover both upgrades with confs and restores. We are asking the user to upgrade without saving confs but nothing will prevent them from keeping settings while using "sysupgrade -F" nor restoring an 19.07 backup "manually" into a 21.02. I think an expert dev could solve this one with a 5 line script ;-) Regards, ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status
Hi Hans, On 7/17/21 5:45 PM, Hauke Mehrtens wrote: Hi, In general the 21.02-rc3 looks good, but we still have some problems. Currently we still have these problem: - DHCPv6 broken if lease times < 12h chosen - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 - https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 Should this commit fix the "DHCPv6 broken if lease times < 12h chosen" problem? https://git.openwrt.org/4633471d74589c761a3849bd63935b42ac3cea73 Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: convert mtd-mac-address to nvmem implementation
Am 19.07.2021 um 16:41 schrieb Ansuel Smith:
The dts has been migrated with a script and we decided to remove the
dtsi that caused some compilation problem.
We still need to take a decision for the device that have dtsi that
declare mtd-mac-address using partition tag declared in user dts
(dtsi use partition declared in the dts)
For testing, I shifted the uboot partition definition from user dts file to the
main dtsi file. Uboot partition definition is in all user dts files the same.
MAC address's and partition layout looks fine.
Regards,
Hartmut
diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c.dtsi
b/target/linux/ath79/dts/qca9558_tplink_archer-c.dtsi
index 3f965f5b95..1c72047a3a 100644
--- a/target/linux/ath79/dts/qca9558_tplink_archer-c.dtsi
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c.dtsi
@@ -146,10 +147,19 @@
};
};
+ {
+ uboot: partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x02>;
+ read-only;
+ };
+};
+
{
status = "okay";
- mtd-mac-address = < 0x1fc00>;
+ nvmem-cells = <_uboot_1fc00>;
+ nvmem-cell-names = "mac-address";
mac-address-increment = <1>;
phy-handle = <>;
pll-data = <0x5600 0x0101 0x1616>;
@@ -163,7 +173,8 @@
{
status = "okay";
- mtd-mac-address = < 0x1fc00>;
+ nvmem-cells = <_uboot_1fc00>;
+ nvmem-cell-names = "mac-address";
pll-data = <0x03000101 0x0101 0x1616>;
fixed-link {
@@ -176,5 +187,17 @@
status = "okay";
mtd-cal-data = < 0x1000>;
- mtd-mac-address = < 0x1fc00>;
+ nvmem-cells = <_uboot_1fc00>;
+ nvmem-cell-names = "mac-address";
};
+
+ {
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_uboot_1fc00: macaddr@1fc00 {
+ reg = <0x1fc00 0x6>;
+ };
+};
+
diff --git a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
index be99b8e3e4..785b4f8675 100644
--- a/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
+++ b/target/linux/ath79/dts/qca9558_tplink_archer-c7-v2.dts
@@ -25,12 +25,6 @@
};
{
- uboot: partition@0 {
- label = "u-boot";
- reg = <0x00 0x02>;
- read-only;
- };
-
partition@2 {
label = "firmware";
reg = <0x02 0xfd>;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: convert mtd-mac-address to nvmem implementation
JFY, this series of commits broke Gl.Inet mt-1300 beryl(mt7621) - I've had to revert it in my local build. So basically the problem is that device cannot read it's mac from partition and every reboot it generates a new one. пн, 19 июл. 2021 г. в 17:32, Ansuel Smith : > > hi, > some dtsi still use the old implementation as they have to be manually > migrated. Does it cause any problem ? > > > Hi, it looks like, that qca9558_tplink_archer-c.dtsi is missing in commit > > abc17bf (ath79: convert mtd-mac-address to nvmem implementation). Regards, > > Hartmut > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
convert mtd-mac-address to nvmem implementation
The dts has been migrated with a script and we decided to remove the dtsi that caused some compilation problem. We still need to take a decision for the device that have dtsi that declare mtd-mac-address using partition tag declared in user dts (dtsi use partition declared in the dts) > I don't see a problem. I did check the dtsi files of the two routers which > I'm using. One is migrated and the other one was still missing. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: convert mtd-mac-address to nvmem implementation
Am 19.07.2021 um 16:24 schrieb Ansuel Smith: hi, some dtsi still use the old implementation as they have to be manually migrated. Does it cause any problem ? I don't see a problem. I did check the dtsi files of the two routers which I'm using. One is migrated and the other one was still missing. Hi, it looks like, that qca9558_tplink_archer-c.dtsi is missing in commit abc17bf (ath79: convert mtd-mac-address to nvmem implementation). Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: dsa: change default interface configuration at first install on architectures using DSA driver
This method of configuring the switch would also make it substantially easier to make a migration script for migrating from swconfig to DSA. On Wed, Jul 7, 2021 at 11:45 PM Arınç ÜNAL wrote: > > This is the proper way of managing the switch ports and VLANs on the > DSA driver. All of the switch ports must be in the same bridge. The > steps to configuring VLANs on ports and configuring the interfaces are > also a lot similar to with swconfig. > > Wireless interfaces are also included in the bridge properly. > > Images are in the attachments. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
convert mtd-mac-address to nvmem implementation
hi, some dtsi still use the old implementation as they have to be manually migrated. Does it cause any problem ? > Hi, it looks like, that qca9558_tplink_archer-c.dtsi is missing in commit > abc17bf (ath79: convert mtd-mac-address to nvmem implementation). Regards, > Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
convert mtd-mac-address to nvmem implementation
Hi, it looks like, that qca9558_tplink_archer-c.dtsi is missing in commit abc17bf (ath79: convert mtd-mac-address to nvmem implementation). Regards, Hartmut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] Revert "mvebu: 5.10 fix DVFS caused random boot crashes"
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
---
...rmada-37xx-Fix-setting-TBG-parent-fo.patch | 107 --
...rmada-37xx-Fix-setting-TBG-parent-fo.patch | 107 --
2 files changed, 214 deletions(-)
delete mode 100644
target/linux/mvebu/patches-5.10/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch
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.10/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch
b/target/linux/mvebu/patches-5.10/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch
deleted file mode 100644
index 65184df584..00
---
a/target/linux/mvebu/patches-5.10/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, _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;
-
[PATCH] toolchain/binutils: add binutils 2.37
Tested on ath79/generic, without issues.
Signed-off-by: Rui Salvaterra
---
toolchain/binutils/Config.in | 4 ++
toolchain/binutils/Config.version | 4 ++
toolchain/binutils/Makefile | 4 ++
.../2.37/300-001_ld_makefile_patch.patch | 22 +++
.../400-mips_no_dynamic_linking_sym.patch | 18 +
...e-default-emulation-for-mips64-linux.patch | 38 +++
6 files changed, 90 insertions(+)
create mode 100644
toolchain/binutils/patches/2.37/300-001_ld_makefile_patch.patch
create mode 100644
toolchain/binutils/patches/2.37/400-mips_no_dynamic_linking_sym.patch
create mode 100644
toolchain/binutils/patches/2.37/500-Change-default-emulation-for-mips64-linux.patch
diff --git a/toolchain/binutils/Config.in b/toolchain/binutils/Config.in
index b436a66c98..4b9579379c 100644
--- a/toolchain/binutils/Config.in
+++ b/toolchain/binutils/Config.in
@@ -21,6 +21,10 @@ choice
config BINUTILS_USE_VERSION_2_36_1
bool "Binutils 2.36.1"
select BINUTILS_VERSION_2_36_1
+
+ config BINUTILS_USE_VERSION_2_37
+ bool "Binutils 2.37"
+ select BINUTILS_VERSION_2_37
endchoice
config EXTRA_BINUTILS_CONFIG_OPTIONS
diff --git a/toolchain/binutils/Config.version
b/toolchain/binutils/Config.version
index 82ef9b8fc3..985e3b1b32 100644
--- a/toolchain/binutils/Config.version
+++ b/toolchain/binutils/Config.version
@@ -11,9 +11,13 @@ config BINUTILS_VERSION_2_35_2
config BINUTILS_VERSION_2_36_1
bool
+config BINUTILS_VERSION_2_37
+ bool
+
config BINUTILS_VERSION
string
default "2.32" if BINUTILS_VERSION_2_32
default "2.34" if BINUTILS_VERSION_2_34
default "2.35.2"if BINUTILS_VERSION_2_35_2
default "2.36.1"if BINUTILS_VERSION_2_36_1
+ default "2.37" if BINUTILS_VERSION_2_37
diff --git a/toolchain/binutils/Makefile b/toolchain/binutils/Makefile
index 5d1b518343..d58f6662bb 100644
--- a/toolchain/binutils/Makefile
+++ b/toolchain/binutils/Makefile
@@ -31,6 +31,10 @@ ifeq ($(PKG_VERSION),2.36.1)
PKG_HASH:=e81d9edf373f193af428a0f256674aea62a9d74dfe93f65192d4eae030b0f3b0
endif
+ifeq ($(PKG_VERSION),2.37)
+ PKG_HASH:=820d9724f020a3e69cb337893a0b63c2db161dadcb0e06fc11dc29eb1e84a32c
+endif
+
HOST_BUILD_PARALLEL:=1
PATCH_DIR:=./patches/$(PKG_VERSION)
diff --git a/toolchain/binutils/patches/2.37/300-001_ld_makefile_patch.patch
b/toolchain/binutils/patches/2.37/300-001_ld_makefile_patch.patch
new file mode 100644
index 00..f1cbb8198b
--- /dev/null
+++ b/toolchain/binutils/patches/2.37/300-001_ld_makefile_patch.patch
@@ -0,0 +1,22 @@
+--- a/ld/Makefile.am
b/ld/Makefile.am
+@@ -50,7 +50,7 @@ AM_CFLAGS = $(WARN_CFLAGS) $(ELF_CLFAGS)
+ # We put the scripts in the directory $(scriptdir)/ldscripts.
+ # We can't put the scripts in $(datadir) because the SEARCH_DIR
+ # directives need to be different for native and cross linkers.
+-scriptdir = $(tooldir)/lib
++scriptdir = $(libdir)
+
+ EMUL = @EMUL@
+ EMULATION_OFILES = @EMULATION_OFILES@
+--- a/ld/Makefile.in
b/ld/Makefile.in
+@@ -561,7 +561,7 @@ AM_CFLAGS = $(WARN_CFLAGS) $(ELF_CLFAGS)
+ # We put the scripts in the directory $(scriptdir)/ldscripts.
+ # We can't put the scripts in $(datadir) because the SEARCH_DIR
+ # directives need to be different for native and cross linkers.
+-scriptdir = $(tooldir)/lib
++scriptdir = $(libdir)
+ BASEDIR = $(srcdir)/..
+ BFDDIR = $(BASEDIR)/bfd
+ INCDIR = $(BASEDIR)/include
diff --git
a/toolchain/binutils/patches/2.37/400-mips_no_dynamic_linking_sym.patch
b/toolchain/binutils/patches/2.37/400-mips_no_dynamic_linking_sym.patch
new file mode 100644
index 00..070247ecf0
--- /dev/null
+++ b/toolchain/binutils/patches/2.37/400-mips_no_dynamic_linking_sym.patch
@@ -0,0 +1,18 @@
+--- a/bfd/elfxx-mips.c
b/bfd/elfxx-mips.c
+@@ -8057,6 +8057,7 @@ _bfd_mips_elf_create_dynamic_sections (b
+
+ name = SGI_COMPAT (abfd) ? "_DYNAMIC_LINK" : "_DYNAMIC_LINKING";
+ bh = NULL;
++ if (0) {
+ if (!(_bfd_generic_link_add_one_symbol
+ (info, abfd, name, BSF_GLOBAL, bfd_abs_section_ptr, 0,
+NULL, false, get_elf_backend_data (abfd)->collect, )))
+@@ -8069,6 +8070,7 @@ _bfd_mips_elf_create_dynamic_sections (b
+
+ if (! bfd_elf_link_record_dynamic_symbol (info, h))
+ return false;
++ }
+
+ if (! mips_elf_hash_table (info)->use_rld_obj_head)
+ {
diff --git
a/toolchain/binutils/patches/2.37/500-Change-default-emulation-for-mips64-linux.patch
b/toolchain/binutils/patches/2.37/500-Change-default-emulation-for-mips64-linux.patch
new file mode 100644
index 00..c59843766e
--- /dev/null
+++
b/toolchain/binutils/patches/2.37/500-Change-default-emulation-for-mips64-linux.patch
@@ -0,0 +1,38 @@
+--- a/bfd/config.bfd
b/bfd/config.bfd
+@@ -891,12 +891,12 @@ case
Re: OpenWrt 21.02 status
On Sun, Jul 18, 2021 at 10:30:20PM +0200, Adrian Schmutzler wrote: > > The last time I tried it was very confusing. When I first read about "new > > fresh > > installation", I thought: "install without keeping settings". > > However, OpenWrt returned an image check failure, even when I did not > > keep the settings (sysupgrade -n). It was the same type of error (image > > validation failed) that would happen if I selected the wrong firmware (but > > maybe with a different content). The only way to install it was forcing the > > operation, which might also allow an incompatible image to be installed > > (bricking the device). Please reconsider some form of upgrade path that > > validates the image and allows the user to upgrade without a force or going > > back to factory before reinstalling OpenWrt with DSA. Something like > > "update package foo to version n.m.z or upgrade to 19.07.9 before installing > > 21.02 for proper image validation". Most users will not be confident to > > apply > > a forced installation. > > That would be nice, but unfortunately it's not so easy. The problem is that > the upgrade mechanism is baked into the _old_ image. > Any upgrade can only do what the old firmware supported. Thus, I was really > glad that I was able to hack this message into the device detection mechanism > at all. Otherwise, we would not have any message at all for old installations. I believe what he meant to say was to make another 19.07.x point release with an updated sysupgrade mechanism which would improve the situation when upgrading to 21.02.x and, for example, allow flashing with non-matching DEVICE_COMPAT_VERSION already when specifying the '-n' flag to not keep configuration, but not require the '-F' flag which is scary for regular users (for good reasons). > > > > > From wiki upgrading to 21.02 page: > > > > "Don't worry - If you try to upgrade with the wrong target, sysupgrade will > > refuse to proceed with an error message like this: > > Image version mismatch. image 1.1 device 1.0 Please wipe config during > > upgrade (force required) or reinstall. Config cannot be migrated from > > swconfig to DSA Image check failed" > > > > My experience and the message content indicates that it will show for all > > migrations from "swconfig" to "DSA" and not only for "wrong target". > > Yes. For the old sysupgrade, we simply match two strings (the board name from > the device against SUPPORTED_DEVICES from the image). Either it's successful, > or it's not. If it's not, the message displays the name of the > SUPPORTED_DEVICES. That's what we got. So I have to hack all of the message > into the SUPPORTED_DEVICES string. > > > > > I tried to start a discussion about it in an email "Usability issues for DSA > > upgrade" (jun/28) but I got no answer. > > We can discuss this for the future, i.e. for updates starting at 21.xx, and > we can discuss the exact wording of the message. Not saying that I'm fond of it, neither that I'm volunteering to do it, but we **could** also update 19.07.x > > > > > It would also be great if we could detect a config from a pre-dsa system and > > restore everything but skipping or renaming DSA relevant files (nework, > > wifi?) DSA) with a suffix like '.pre-dsa'. > > We had a very long delay due to DSA and nobody was even slightly interested > in creating a migration script. > For partial migration, I suspect that implementing something here that is > general will be much more complicated than just having the user select what > he wants/needs. > > Best > > Adrian > > > > > DSA is missing a lot of docs. For example: is there a simple, secure way to > > detect a system is using DSA for a specific switch (or device)? > > Is it possible to exist a device with two switches and only one of them uses > > DSA? > > > > Regards, > > > > ___ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt DSA Mini-Tutorial
On Sun, 18 Jul 2021, at 20:45, Rich Brown wrote:
> I have updated the DSA Mini-tutorial in the playground:
> https://openwrt.org/playground/richb/dsa-mini-tutorial
>
> I finished the first section ("Bridging all LAN ports"), and I am going
> to stop editing now, because:
>
> 1) I need someone else to look at the overall format of the document
> 2) I made some bold assertions and simplifications of the language in
> the document. But because I don't really understand DSA, I may be
> totally wrong...
> 3) If it's not right, we won't have to patch up the remainder, that is
> substantially unchanged from the Forum post.
>
> Please check it out and either change it, or let me know what needs to
> be fixed. Thanks.
Hi Rich,
Thank you for putting this together.
I had a skim through it, and was rather confused when I got to bridge-vlan,
but ended up learning more.
Could we please introduce bridge-vlan in the guide,
and also document it in throughout the wiki:
https://openwrt.org/docs/guide-user/network/ucicheatsheet
https://openwrt.org/docs/guide-user/base-system/basic-networking?s[]=bridge-vlan#switch_configuration_dsabridge-vlan
I found good resources in an early cover letter, and a RedHat blog:
https://lwn.net/Articles/532128/
https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge#with_vlan_filtering
Guessing if I wanted to display or modify the bridge vlan configuration
at the linux level I would need to install additional packages?
Maybe: ip-bridge ip-full
My situation:
I have mt7621 devices. They use DSA; there is a linux network device for
each port of the device switch in `ls /sys/class/net` or `ip link show`,
but they don't use bridge-vlan (or vlan_filtering) in the default config.
Without having seen bridge-vlan, I was using the OpenWrt configuration
of multiple bridge devices (and interfaces) to isolate networks,
and using device bridge `list ports 'portname.vlan'` to force VLAN tags for
ports.
It looks like bridge-vlan allows finer control and many more options.
Cheers,
--
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
