[sdwalker/sdwalker.github.io] d27cd0: 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: d27cd00b5e2473728cd0fb913a6927f384d721dd https://github.com/sdwalker/sdwalker.github.io/commit/d27cd00b5e2473728cd0fb913a6927f384d721dd Author: Stephen Walker Date: 2021-05-23 (Sun, 23 May 2021) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.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 v2] ath79: add support for Ubiquiti PowerBeam M (XW)
Just as a side-note:
There are 5 different versions of the PowerBeam with different
device IDs...
Source:
https://github.com/freifunk-gluon/gluon/issues/94#issuecomment-510831878
-- PowerBeam M5
-- ERP 26 dBm according to datasheet
'e3e5' = { -- PBE-M5-300
pa_gain = 4
ant_gain = 22
},
'e4e5' = { -- PBE-M5-400
pa_gain = 4
ant_gain = 25
},
'e6e5' = { -- PBE-M5-400 ISO!!
pa_gain = 4
ant_gain = 25
},
'e885' = { -- PBE-M5-620
pa_gain = 4
ant_gain = 29
},
-- Powerbeam M2 400?
-- ERP 28 dBm according to datasheet
'e6c2' = { -- PBE-M2-400
pa_gain = 6
ant_gain = 18 dBi
},
While I think there shouldn't be different DTS files for them, there is
a script missing that respects the antenna and external PA gain of these
devices.
Best,
Vincent
On 5/23/21 1:59 PM, Russell Senior wrote:
This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM5HP
Changes since v1:
* renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 36 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 46 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
new file mode 100644
index 00..edcb06acef
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ mtd-mac-address = < 0x0>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 1990353394..35ce90aeb4 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index
[PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM5HP
Changes since v1:
* renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 36 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 46 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
new file mode 100644
index 00..edcb06acef
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ mtd-mac-address = < 0x0>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 1990353394..35ce90aeb4 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4133b9d7d3..6e31cdac69 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -85,6 +85,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+ ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m|\
ubnt,unifiac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 733d803d7a..5948e059e8 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
+define Device/ubnt_powerbeam-m-xw
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := PowerBeam M
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m-xw
+
define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
SOC := ar7241
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] base-files: fix configuration generation of network if "bridge" exists
After the commit 43fc720657c6e3b30c6ed89d7227ee6e646c158b
("base-files: generate "device UCI type section for bridge"), the wrong
network configuration is generated for the devices that already have the
bridge device section for VLAN, such as the devices in realtek target.
As a result, the bridge device by additional "device" section is
specified to the "ports" option in the "bridge-vlan" section and netifd
shuts down the switch and the ethernet when the network service started.
--- generated config ---
config device 'switch'
option name 'switch'
option type 'bridge'
option macaddr '34:76:c5:xx:xx:a8'
config device
option name 'br-wan'
option type 'bridge'
list ports 'lan1'
... (truncated)
list ports 'lan9'
config bridge-vlan 'wan_vlan'
option device 'switch'
option vlan '1'
option ports 'br-wan'
--- config end ---
--- log ---
root@OpenWrt:/# /etc/init.d/network start
root@OpenWrt:/# [ 159.752015] Using MAC 3476c5d9f0a8
[ 159.756993] RESETTING 8380, CPU_PORT 28
[ 159.961309] rtl838x-eth bb00a300.ethernet eth0: configuring for
fixed/internal link mode
[ 159.970338] In rtl838x_mac_config, mode 1
[ 159.975095] device eth0 left promiscuous mode
[ 159.980356] In rtl838x_mac_config, mode 1
[ 159.984896] rtl838x-eth bb00a300.ethernet eth0: Link is Up - 1Gbps/Full -
flow control off
[ 160.005785] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 160.283111] device eth0 entered promiscuous mode
[ 160.288322] rtl83xx-switch switch@bb00 lan1: configuring for phy/qsgmii
link mode
[ 160.308034] 8021q: adding VLAN 0 to HW filter on device lan1
[ 160.340250] br-wan: port 1(lan1) entered blocking state
[ 160.346104] br-wan: port 1(lan1) entered disabled state
[ 160.352724] device lan1 entered promiscuous mode
... (truncated)
[ 162.123430] rtl83xx-switch switch@bb00 lan9: configuring for
phy/internal link mode
[ 162.143153] 8021q: adding VLAN 0 to HW filter on device lan9
[ 162.175597] br-wan: port 24(lan9) entered blocking state
[ 162.181669] br-wan: port 24(lan9) entered disabled state
[ 162.188327] device lan9 entered promiscuous mode
[ 162.209932] device lan1 left promiscuous mode
[ 162.215216] br-wan: port 1(lan1) entered disabled state
... (truncated)
[ 162.827566] device lan9 left promiscuous mode
[ 162.832938] br-wan: port 24(lan9) entered disabled state
[ 162.844314] in rtl838x_eth_stop
[ 162.847955] rtl838x-eth bb00a300.ethernet eth0: Link is Down
[ 163.754337] Using MAC 3476c5d9f0a8
[ 163.779357] RESETTING 8380, CPU_PORT 28
[ 163.983666] rtl838x-eth bb00a300.ethernet eth0: configuring for
fixed/internal link mode
[ 163.992695] In rtl838x_mac_config, mode 1
[ 163.997434] device eth0 left promiscuous mode
[ 164.002670] In rtl838x_mac_config, mode 1
[ 164.007209] rtl838x-eth bb00a300.ethernet eth0: Link is Up - 1Gbps/Full -
flow control off
[ 164.044261] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 164.534390] device eth0 entered promiscuous mode
[ 164.539704] rtl83xx-switch switch@bb00 lan1: configuring for phy/qsgmii
link mode
[ 164.559826] 8021q: adding VLAN 0 to HW filter on device lan1
[ 164.592421] br-wan: port 1(lan1) entered blocking state
[ 164.598270] br-wan: port 1(lan1) entered disabled state
[ 164.604910] device lan1 entered promiscuous mode
... (truncated)
[ 166.601998] rtl83xx-switch switch@bb00 lan9: configuring for
phy/internal link mode
[ 166.622328] 8021q: adding VLAN 0 to HW filter on device lan9
[ 166.653459] br-wan: port 24(lan9) entered blocking state
[ 166.659530] br-wan: port 24(lan9) entered disabled state
[ 166.666195] device lan9 entered promiscuous mode
[ 166.688759] device lan1 left promiscuous mode
[ 166.694131] br-wan: port 1(lan1) entered disabled state
... (truncated)
[ 167.310359] device lan9 left promiscuous mode
[ 167.315636] br-wan: port 24(lan9) entered disabled state
[ 167.326988] in rtl838x_eth_stop
[ 167.331006] rtl838x-eth bb00a300.ethernet eth0: Link is Down
--- log end ---
root@OpenWrt:/# ifconfig
loLink encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:448 errors:0 dropped:0 overruns:0 frame:0
TX packets:448 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:34944 (34.1 KiB) TX bytes:34944 (34.1 KiB)
root@OpenWrt:/#
This patch fixes this issue.
Fixes: 43fc720657 ("base-files: generate "device" UCI type section for
bridge")
Signed-off-by: INAGAKI Hiroshi
---
package/base-files/files/bin/config_generate | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/base-files/files/bin/config_generate
b/package/base-files/files/bin/config_generate
index efcd734242..2d20ead152 100755
--- a/package/base-files/files/bin/config_generate
+++
[PATCH] ath79: increase ZyXEL NBG6716 kernel partition to 6MiB
The bootloader happily accepts this.
But devices need a fresh reinstall because of resulting ubi partition
changes. Therefore a sysupgrade will brick your device.
Please install a fresh factory image via bootloader.
Alternatively, you can flash sysupgrade-6M-Kernel.bin with
zcat sysupgrade-6M-Kernel.bin | mtd -r -e /dev/mtd 3 write - /dev/mtd3
This may thow an error, because it is a 256M image. There are
devices out there with this flash size.
Notice that you will always loose configuration.
This also fixes a bug in the image generation enables the device by
default again.
Signed-off-by: André Valentin
---
.../linux/ath79/dts/qca9558_zyxel_nbg6716.dts | 4 +--
.../etc/uci-defaults/05_fix-compat-version| 3 +-
target/linux/ath79/image/nand.mk | 34 ---
3 files changed, 26 insertions(+), 15 deletions(-)
diff --git a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
index 9aee8c362c..411b086188 100644
--- a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
+++ b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
@@ -147,12 +147,12 @@
partition@50 {
label = "kernel";
- reg = <0x50 0x40>;
+ reg = <0x50 0x60>;
};
partition@90 {
label = "ubi";
- reg = <0x90 0x770>;
+ reg = <0xb0 0x750>;
};
};
};
diff --git
a/target/linux/ath79/generic/base-files/etc/uci-defaults/05_fix-compat-version
b/target/linux/ath79/generic/base-files/etc/uci-defaults/05_fix-compat-version
index a6b7fa3162..f7c8412614 100644
---
a/target/linux/ath79/generic/base-files/etc/uci-defaults/05_fix-compat-version
+++
b/target/linux/ath79/generic/base-files/etc/uci-defaults/05_fix-compat-version
@@ -2,7 +2,8 @@
case "$(board_name)" in
meraki,mr12|\
- meraki,mr16)
+ meraki,mr16|\
+ zyxel,nbg6716)
uci set system.@system[0].compat_version="2.0"
uci commit system
;;
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index caaa01c92d..b582192244 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -1,13 +1,13 @@
# attention: only zlib compression is allowed for the boot fs
define Build/zyxel-buildkerneljffs
- rm -rf $(KDIR_TMP)/zyxelnbg6716
- mkdir -p $(KDIR_TMP)/zyxelnbg6716/image/boot
- cp $@ $(KDIR_TMP)/zyxelnbg6716/image/boot/vmlinux.lzma.uImage
+ rm -rf $@.tmp
+ mkdir -p $@.tmp/image/boot
+ cp $@ $@.tmp/image/boot/vmlinux.lzma.uImage
$(STAGING_DIR_HOST)/bin/mkfs.jffs2 \
--big-endian --squash-uids -v -e 128KiB -q -f -n -x lzma -x
rtime \
-o $@ \
- -d $(KDIR_TMP)/zyxelnbg6716/image
- rm -rf $(KDIR_TMP)/zyxelnbg6716
+ -d $@.tmp/image
+ rm -rf $@.tmp
endef
define Build/zyxel-factory
@@ -236,6 +236,15 @@ TARGET_DEVICES += netgear_wndr4500-v3
define Device/zyxel_nbg6716
SOC := qca9558
+ DEVICE_COMPAT_VERSION := 2.0
+ DEVICE_COMPAT_MESSAGE := Kernel partition has been resized to 6M. \
+ A sysupgrade will brick your device. \
+ Please install a fresh factory image via bootloader. \
+ Alternatively, you can flash sysupgrade-6M-Kernel.bin with \
+ zcat sysupgrade-6M-Kernel.bin | mtd -r -e /dev/mtd3 write - /dev/mtd3 .\
+ This may thow an error, because it is a 256M image. There are \
+ devices out there with this flash size. \
+ Notice that you will always loose configuration.
DEVICE_VENDOR := ZyXEL
DEVICE_MODEL := NBG6716
DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct \
@@ -243,19 +252,20 @@ define Device/zyxel_nbg6716
RAS_BOARD := NBG6716
RAS_ROOTFS_SIZE := 29696k
RAS_VERSION := "OpenWrt Linux-$(LINUX_VERSION)"
- KERNEL_SIZE := 4096k
+ KERNEL_SIZE := 6144k
BLOCKSIZE := 128k
PAGESIZE := 2048
KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs | \
- check-size 4096k
- IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin
+ check-size 6144k
+ KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none | \
+ zyxel-buildkerneljffs | zyxel-factory
+ IMAGES := sysupgrade.tar sysupgrade-6M-Kernel.bin factory.bin
IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to (BLOCKSIZE) | \
sysupgrade-tar rootfs=@ | append-metadata
- IMAGE/sysupgrade-4M-Kernel.bin/squashfs := append-kernel | \
+ IMAGE/sysupgrade-6M-Kernel.bin/squashfs := append-kernel | \
pad-to (KERNEL_SIZE) | append-ubi | pad-to 263192576 | gzip
- IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | append-ubi |
\
- zyxel-factory
+ IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | \
+
RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config
Hi again, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Adrian Schmutzler > Sent: Sonntag, 23. Mai 2021 12:05 > To: 'Stijn Segers' > Cc: openwrt-devel@lists.openwrt.org > Subject: RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config > > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Stijn Segers > > Sent: Freitag, 8. Januar 2021 17:30 > > To: Adrian Schmutzler > > Cc: openwrt-devel@lists.openwrt.org > > Subject: RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network > > config > > > > Hi Adrian, > > > > Op vrijdag 8 januari 2021 om 13u30 schreef Adrian Schmutzler > > : > > > Hi, > > > > > >> -Original Message- > > >> From: openwrt-devel [mailto:openwrt-devel- > > boun...@lists.openwrt.org] > > >> On Behalf Of Stijn Segers > > >> Sent: Freitag, 8. Januar 2021 11:28 > > >> To: openwrt-devel@lists.openwrt.org > > >> Subject: [PATCH 2/2] octeon: add EdgeRouter Lite specific network > > >> config > > >> > > >> The Ubiquiti EdgeRouter Lite has three network interfaces. Add a > > >> specific match in /etc/board.d/01_network so they all get set up. > > >> Default to eth0 for WAN and an eth1 + eth2 bridge for LAN. > > > > > > Why this particular assignment? > > > > > > The EdgeRouter 4 (same Octeon target) uses a similar set-up; the PC > > Engines APU has a similar setup as well: 3 Ethernet ports, eth0 being > > set as WAN - see [2]. > > > > I can invert it and set eth2 as WAN port, if you'd like. The fallback > > setup for Octeon at this point is just as weird, to set eth0 as LAN > > (which is logical) and > > eth1 as WAN, and leave other ports unconfigured. > > > > There's no perfect solution, but I think leaving a port unused makes > > even less sense than this. > > Coming back to this old discussion as well. > > From the generic config, we have eth1 as WAN port. Changing that to eth0 > now could break some existing configurations (though I doubt this will affect > many people). So, in order to have all three ports working, I'd prefer: > > ucidef_set_interfaces_lan_wan "eth0 eth2" "eth1" > > I'm aware this is not nice, but it won't break anything. If you think having > eth0 > or eth2 as WAN is superior, please prepare a patch where compat_version is > set to 1.1 to enforce config wiping. If we decide to stick to eth1 now on the > other hand, I'm not really inclined to reorder it again in half a year ... Please ignore my previous mail, it's pure nonsense. board.d will only affect _new_ installations or those which are reset, so existing users are completely irrelevant here as nothing will change for them. Therefore, just resend your patch (with wan as you wish) bundled with the compatible rename. Best Adrian > > Best > > Adrian > > > > > Stijn > > > > [1] > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/o > > ct > > eon/base- > > > files/etc/board.d/01_network;h=749d99be1d11802fbc442a11b1d3312b806ea > > 9fb;hb=HEAD > > [2] > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x > > 86 > > /base- > > > files/etc/board.d/02_network;h=c6e381b946d03887cb941e90db2ccbb2f918fc > > a4;hb=HEAD > > > > > > > > Best > > > > > > Adrian > > > > > >> > > >> Signed-off-by: Stijn Segers > > >> --- > > >> target/linux/octeon/base-files/etc/board.d/01_network | 3 +++ > > >> 1 file changed, 3 insertions(+) > > >> > > >> diff --git a/target/linux/octeon/base-files/etc/board.d/01_network > > >> b/target/linux/octeon/base-files/etc/board.d/01_network > > >> index 749d99be1d..4ad5f95598 100755 > > >> --- a/target/linux/octeon/base-files/etc/board.d/01_network > > >> +++ b/target/linux/octeon/base-files/etc/board.d/01_network > > >> @@ -14,6 +14,9 @@ itus,shield-router) > > >> ubnt,edgerouter-4) > > >> ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "lan0" > > >> ;; > > >> +ubnt,erlite) > > >> + ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0" > > >> + ;; > > >> *) > > >> ucidef_set_interfaces_lan_wan "eth0" "eth1" > > >> ;; > > >> -- > > >> 2.20.1 > > >> > > >> > > >> ___ > > >> 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 openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: Resize of ath79 / ZyXEL NBG6716 kernel partition
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 --- Hi! Am 23.05.21 um 11:05 schrieb Adrian Schmutzler: > Hi, > >> -Original Message- >> From: Andre Valentin [mailto:a.valen...@ddimension.net] >> Sent: Dienstag, 18. Mai 2021 20:11 >> To: OpenWrt Development List >> Subject: Resize of ath79 / ZyXEL NBG6716 kernel partition >> >> Hi! >> >> The NBG6716 has recently been disabled because of size problems with the >> kernel partition. >> I'm thinking about extending it to 8MB, shouldn't be a problem. > > Interesting. > > https://github.com/openwrt/openwrt/commit/5d8ea6d34f9f23d4dfff4ffcac8c9599d842c3a8 > > I was not aware that we are > 4 MiB for kernel already. Is there anything > special about this device (or probably ath79/nand) that causes bigger kernel? It's a bit more interesting here. ZyXELs bootloader supports uimage lzma but only with a kernel size < ~4MB uncompressed or so.. The trick now is to use a uncompressed uimage and let now do jffs2 compress the image, which the bootloader supports. That works, bit is way more unoptimized. This is the reason why we hit that limit earlier here. Kind regards, André --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Stijn Segers > Sent: Freitag, 8. Januar 2021 17:30 > To: Adrian Schmutzler > Cc: openwrt-devel@lists.openwrt.org > Subject: RE: [PATCH 2/2] octeon: add EdgeRouter Lite specific network config > > Hi Adrian, > > Op vrijdag 8 januari 2021 om 13u30 schreef Adrian Schmutzler > : > > Hi, > > > >> -Original Message- > >> From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > >> On Behalf Of Stijn Segers > >> Sent: Freitag, 8. Januar 2021 11:28 > >> To: openwrt-devel@lists.openwrt.org > >> Subject: [PATCH 2/2] octeon: add EdgeRouter Lite specific network > >> config > >> > >> The Ubiquiti EdgeRouter Lite has three network interfaces. Add a > >> specific match in /etc/board.d/01_network so they all get set up. > >> Default to eth0 for WAN and an eth1 + eth2 bridge for LAN. > > > > Why this particular assignment? > > > The EdgeRouter 4 (same Octeon target) uses a similar set-up; the PC Engines > APU has a similar setup as well: 3 Ethernet ports, eth0 being set as WAN - see > [2]. > > I can invert it and set eth2 as WAN port, if you'd like. The fallback setup > for > Octeon at this point is just as weird, to set eth0 as LAN (which is logical) > and > eth1 as WAN, and leave other ports unconfigured. > > There's no perfect solution, but I think leaving a port unused makes even less > sense than this. Coming back to this old discussion as well. From the generic config, we have eth1 as WAN port. Changing that to eth0 now could break some existing configurations (though I doubt this will affect many people). So, in order to have all three ports working, I'd prefer: ucidef_set_interfaces_lan_wan "eth0 eth2" "eth1" I'm aware this is not nice, but it won't break anything. If you think having eth0 or eth2 as WAN is superior, please prepare a patch where compat_version is set to 1.1 to enforce config wiping. If we decide to stick to eth1 now on the other hand, I'm not really inclined to reorder it again in half a year ... Best Adrian > > Stijn > > [1] > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/oct > eon/base- > files/etc/board.d/01_network;h=749d99be1d11802fbc442a11b1d3312b806ea > 9fb;hb=HEAD > [2] > https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/x86 > /base- > files/etc/board.d/02_network;h=c6e381b946d03887cb941e90db2ccbb2f918fc > a4;hb=HEAD > > > > > Best > > > > Adrian > > > >> > >> Signed-off-by: Stijn Segers > >> --- > >> target/linux/octeon/base-files/etc/board.d/01_network | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/target/linux/octeon/base-files/etc/board.d/01_network > >> b/target/linux/octeon/base-files/etc/board.d/01_network > >> index 749d99be1d..4ad5f95598 100755 > >> --- a/target/linux/octeon/base-files/etc/board.d/01_network > >> +++ b/target/linux/octeon/base-files/etc/board.d/01_network > >> @@ -14,6 +14,9 @@ itus,shield-router) > >> ubnt,edgerouter-4) > >>ucidef_set_interfaces_lan_wan "lan1 lan2 lan3" "lan0" > >>;; > >> +ubnt,erlite) > >> + ucidef_set_interfaces_lan_wan "eth1 eth2" "eth0" > >> + ;; > >> *) > >>ucidef_set_interfaces_lan_wan "eth0" "eth1" > >>;; > >> -- > >> 2.20.1 > >> > >> > >> ___ > >> 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 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: [PATCH v2] octeon: rename erlite to ubnt,edgerouter-lite
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stijn Segers
> Sent: Freitag, 8. Januar 2021 22:08
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH v2] octeon: rename erlite to ubnt,edgerouter-lite
>
> Rename EdgeRouter Lite board_name value and prefix it with vendor
> abbreviation UBNT, as done for other Ubiquiti devices in the tree. Ensure
> backward sysupgrade compatibility as well.
Just found this "old" patch on patchwork. Comments below.
>
> Signed-off-by: Stijn Segers
> ---
> .../octeon/base-files/lib/preinit/01_sysinfo | 2 +-
> .../octeon/base-files/lib/preinit/79_move_config | 2 +-
> .../octeon/base-files/lib/upgrade/platform.sh| 16
> target/linux/octeon/image/Makefile | 1 +
> 4 files changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
> b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
> index d66618b0cf..3512bd7321 100644
> --- a/target/linux/octeon/base-files/lib/preinit/01_sysinfo
> +++ b/target/linux/octeon/base-files/lib/preinit/01_sysinfo
> @@ -6,7 +6,7 @@ do_sysinfo_octeon() {
>
> case "$machine" in
> "UBNT_E100"*)
> - name="erlite"
> + name="ubnt,edgerouter-lite"
> ;;
>
> "UBNT_E200"*)
> diff --git a/target/linux/octeon/base-files/lib/preinit/79_move_config
> b/target/linux/octeon/base-files/lib/preinit/79_move_config
> index 5a84e6f18a..07b6585470 100644
> --- a/target/linux/octeon/base-files/lib/preinit/79_move_config
> +++ b/target/linux/octeon/base-files/lib/preinit/79_move_config
> @@ -15,7 +15,7 @@ octeon_move_config() {
> . /lib/functions.sh
>
> case "$(board_name)" in
> - erlite)
> + ubnt,edgerouter-lite)
> move_config "/dev/sda1"
> ;;
> itus,shield-router)
> diff --git a/target/linux/octeon/base-files/lib/upgrade/platform.sh
> b/target/linux/octeon/base-files/lib/upgrade/platform.sh
> index ad5baef4a1..11e598c10b 100755
> --- a/target/linux/octeon/base-files/lib/upgrade/platform.sh
> +++ b/target/linux/octeon/base-files/lib/upgrade/platform.sh
> @@ -19,11 +19,6 @@ platform_get_rootfs() {
>
> platform_copy_config() {
> case "$(board_name)" in
> - erlite)
> - mount -t vfat /dev/sda1 /mnt
> - cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
> - umount /mnt
> - ;;
> itus,shield-router)
> mount -t vfat /dev/mmcblk1p1 /mnt
> cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
> @@ -34,6 +29,11 @@ platform_copy_config() {
> cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
> umount /mnt
> ;;
> + ubnt,edgerouter-lite)
> + mount -t vfat /dev/sda1 /mnt
> + cp -af "$UPGRADE_BACKUP" "/mnt/$BACKUP_FILE"
> + umount /mnt
> + ;;
This needs to be rebased due to my recent patch.
> esac
> }
>
> @@ -87,7 +87,7 @@ platform_do_upgrade() {
> ubnt,edgerouter-4)
> kernel=mmcblk0p1
> ;;
> - erlite)
> + ubnt,edgerouter-lite)
> kernel=sda1
> ;;
> itus,shield-router)
> @@ -112,9 +112,9 @@ platform_check_image() {
>
> case "$board" in
> er | \
> - erlite | \
> itus,shield-router | \
> - ubnt,edgerouter-4)
> + ubnt,edgerouter-4 | \
> + ubnt,edgerouter-lite)
> local kernel_length=$(tar xf $tar_file $board_dir/kernel -O |
> wc -c 2> /dev/null)
> local rootfs_length=$(tar xf $tar_file $board_dir/root -O | wc
> -c 2> /dev/null)
> [ "$kernel_length" = 0 -o "$rootfs_length" = 0 ] && { diff --git
> a/target/linux/octeon/image/Makefile
> b/target/linux/octeon/image/Makefile
> index b91c262447..83a3274587 100644
> --- a/target/linux/octeon/image/Makefile
> +++ b/target/linux/octeon/image/Makefile
> @@ -71,6 +71,7 @@ define Device/ubnt_edgerouter-lite
>DEVICE_MODEL := EdgeRouter Lite
>BOARD_NAME := erlite
>CMDLINE := $(ERLITE_CMDLINE)
> +SUPPORTED_DEVICES := erlite ubnt,edgerouter-lite
This can be simplified to
SUPPORTED_DEVICES += erlite
since the other value is the global default now. Note that indent is broken
here as well.
If this is properly tested, I'm inclined to merge an updated version. Consider
combining this into a patchset with the ethX patch for which I will write
comments in just a minute.
Best
Adrian
> endef
> TARGET_DEVICES += ubnt_edgerouter-lite
>
> --
> 2.20.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
RE: [PATCH v3 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of André Valentin
> Sent: Dienstag, 18. Mai 2021 22:45
> To: openwrt-devel@lists.openwrt.org; a.valen...@ddimension.net
> Cc: avalen...@marcant.net
> Subject: [PATCH v3 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
Thanks for updating. Still a few comments below.
>
> The ZyXEL LTE3301-Plus is an 4G indoor CPE with 2 external LTE antennas.
>
> Specifications:
>
> - SoC: MediaTek MT7621AT
> - RAM: 256 MB
> - Flash: 128 MB MB NAND (MX30LF1G18AC)
> - WiFi: MediaTek MT7615E
> - Switch: 4 LAN ports (Gigabit)
> - LTE: Quectel EG506 connected by USB3 to SoC
> - SIM: 1 micro-SIM slot
> - USB: USB3 port
> - Buttons: Reset, WPS
> - LEDs: Multicolour power, internet, LTE, signal, Wifi, USB
> - Power: 12V, 1.5A
>
> The device is built as an indoor ethernet to LTE bridge or router with Wifi.
>
> UART Serial:
>
> 57600N1
> Located on populated 5 pin header J5:
>
> [o] GND
> [ ] key - no pin
> [o] 3.3V Vcc
> [o] RX
> [o] TX
>
> MAC assignment:
> lan: 98:0d:67:ee:85:54 (base, on the device back)
> wlan: 98:0d:67:ee:85:55
>
> For more details about flashing see commit
> 2449a632084b29632605e5a79ce5d73028eb15dd .
You don't provide _any_ details about flashing, so "for more details" is a bit
of irony here.
Jokes aside, please provide a very condensed flashing info here, and then it's
perfectly fine to link to the other commit.
But the user should get a general idea about flashing without following any
links (you may choose whether you prefer just providing one method and then use
the link for the other, or just give an overview of available methods etc.).
>
> Signed-off-by: André Valentin
> ---
> package/boot/uboot-envtools/files/ramips | 1 +
> .../ramips/dts/mt7621_zyxel_lte3301-plus.dts | 213 ++
> target/linux/ramips/image/mt7621.mk | 19 ++
> .../mt7621/base-files/etc/board.d/01_leds | 3 +
> .../mt7621/base-files/etc/board.d/02_network | 3 +-
> .../base-files/etc/board.d/03_gpio_switches | 4 +
> .../mt7621/base-files/etc/init.d/bootcount| 1 +
> .../mt7621/base-files/lib/upgrade/platform.sh | 1 +
> 8 files changed, 244 insertions(+), 1 deletion(-) create mode 100644
> target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
>
> diff --git a/package/boot/uboot-envtools/files/ramips
> b/package/boot/uboot-envtools/files/ramips
> index bce2e5f0fb..4d0e608911 100644
> --- a/package/boot/uboot-envtools/files/ramips
> +++ b/package/boot/uboot-envtools/files/ramips
> @@ -53,6 +53,7 @@ xiaomi,mi-router-ac2100|\
> xiaomi,redmi-router-ac2100)
> ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x2"
> ;;
> +zyxel,lte3301-plus|\
> zyxel,nr7101)
> idx="$(find_mtd_index Config)"
> [ -n "$idx" ] && \
> diff --git a/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> new file mode 100644
> index 00..af2e792cb8
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
> @@ -0,0 +1,213 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "mt7621.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "zyxel,lte3301-plus", "mediatek,mt7621-soc";
> + model = "ZyXEL LTE3301-PLUS";
> +
> + aliases {
> + label-mac-device =
> + led-boot = _power;
> + led-failsafe = _power;
> + led-running = _power;
> + led-upgrade = _power;
> + };
> +
> + gpio_export {
> + compatible = "gpio-export";
> +
> + lte_power {
> + gpio-export,name = "lte_power";
> + gpio-export,output = <1>;
> + gpios = < 27 GPIO_ACTIVE_LOW>;
> + };
> +
> + usb_power {
> + gpio-export,name = "usb_power";
> + gpio-export,output = <1>;
> + gpios = < 7 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "white:power";
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + };
> +
> + wifi {
> + label = "white:wifi";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + internet {
> + label = "white:internet";
> + gpios = < 23 GPIO_ACTIVE_LOW>;
> + };
> +
> + usb {
> + label = "white:usb";
> + gpios = < 24 GPIO_ACTIVE_LOW>;
> + trigger-sources = <_ehci_port1>,
> <_port2>;
> + linux,default-trigger = "usbport";
> + };
> +
> + lte {
> + label = "white:lte";
> +
RE: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and reenable again
Hi, the 3rd,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of André Valentin
> Sent: Samstag, 22. Mai 2021 17:01
> To: openwrt-devel@lists.openwrt.org
> Cc: André Valentin
> Subject: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and
> reenable again
proper commit title requires just "ath79:" prefix, e.g. "ath79: increase ZyXEL
NBG6716 kernel to 6M" ...
Best
Adrian
>
> The bootloader happily accepts this.
> But devices need a fresh reinstall because of resulting ubi partition changes.
> Therefore a sysupgrade will brick your device.
>
> Please install a fresh factory image via bootloader.
> Alternatively, you can flash sysupgrade-6M-Kernel.bin with zcat sysupgrade-
> 6M-Kernel.bin | mtd -r -e /dev/mtd 3 write - /dev/mtd3
>
> This may thow an error, because it is a 256M image. There are devices out
> there with this flash size.
>
> Notice that you will always loose configuration.
>
> Signed-off-by: André Valentin
> ---
> .../linux/ath79/dts/qca9558_zyxel_nbg6716.dts | 4 ++--
> target/linux/ath79/image/nand.mk | 24 +--
> 2 files changed, 19 insertions(+), 9 deletions(-)
>
> diff --git a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> index 9aee8c362c..411b086188 100644
> --- a/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> +++ b/target/linux/ath79/dts/qca9558_zyxel_nbg6716.dts
> @@ -147,12 +147,12 @@
>
> partition@50 {
> label = "kernel";
> - reg = <0x50 0x40>;
> + reg = <0x50 0x60>;
> };
>
> partition@90 {
> label = "ubi";
> - reg = <0x90 0x770>;
> + reg = <0xb0 0x750>;
> };
> };
> };
> diff --git a/target/linux/ath79/image/nand.mk
> b/target/linux/ath79/image/nand.mk
> index caaa01c92d..37a5713ff1 100644
> --- a/target/linux/ath79/image/nand.mk
> +++ b/target/linux/ath79/image/nand.mk
> @@ -236,6 +236,15 @@ TARGET_DEVICES += netgear_wndr4500-v3
>
> define Device/zyxel_nbg6716
>SOC := qca9558
> + DEVICE_COMPAT_VERSION := 2.0
> + DEVICE_COMPAT_MESSAGE := Kernel partition has been resized to 6M. \
> + A sysupgrade will brick your device. \
> + Please install a fresh factory image via bootloader. \
> + Alternatively, you can flash sysupgrade-6M-Kernel.bin with \
> + zcat sysupgrade-6M-Kernel.bin | mtd -r -e /dev/mtd3 write -
> /dev/mtd3 .\
> + This may thow an error, because it is a 256M image. There are \
> + devices out there with this flash size. \
> + Notice that you will always loose configuration.
>DEVICE_VENDOR := ZyXEL
>DEVICE_MODEL := NBG6716
>DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-
> ct \ @@ -243,19 +252,20 @@ define Device/zyxel_nbg6716
>RAS_BOARD := NBG6716
>RAS_ROOTFS_SIZE := 29696k
>RAS_VERSION := "OpenWrt Linux-$(LINUX_VERSION)"
> - KERNEL_SIZE := 4096k
> + KERNEL_SIZE := 6144k
>BLOCKSIZE := 128k
>PAGESIZE := 2048
>KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs |
> \
> - check-size 4096k
> - IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin
> + check-size 6144k
> + KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none | \
> + zyxel-buildkerneljffs | zyxel-factory
> + IMAGES := sysupgrade.tar sysupgrade-6M-Kernel.bin factory.bin
>IMAGE/sysupgrade.tar/squashfs := append-rootfs | pad-to
> (BLOCKSIZE) | \
> sysupgrade-tar rootfs=@ | append-metadata
> - IMAGE/sysupgrade-4M-Kernel.bin/squashfs := append-kernel | \
> + IMAGE/sysupgrade-6M-Kernel.bin/squashfs := append-kernel | \
> pad-to (KERNEL_SIZE) | append-ubi | pad-to 263192576 | gzip
> - IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) |
> append-ubi | \
> - zyxel-factory
> + IMAGE/factory.bin := append-kernel | pad-to (KERNEL_SIZE) | \
> + append-ubi | zyxel-factory
>UBINIZE_OPTS := -E 5
> - DEFAULT := n
> endef
> TARGET_DEVICES += zyxel_nbg6716
> --
> 2.20.1
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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: [PATCH] base-files: migrate old UCI network sections defining bridges
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rafal Milecki
> Sent: Dienstag, 18. Mai 2021 23:42
> To: Jo-Philipp Wich ; Hans Dedecker ;
> John Crispin ; Felix Fietkau ;
> openwrt-devel@lists.openwrt.org
> Cc: Rafał Miłecki
> Subject: [PATCH] base-files: migrate old UCI network sections defining
> bridges
>
> From: Rafał Miłecki
>
> Old "interface" sections for bridges were mixing layer 2 and layer 3.
> That syntax got deprecated and UCI section "device" is used for bridge
> configuration now.
>
> Backward compatibility may be dropped from netifd soon now so migrate old
> configs using uci-defaults script.
>
> Signed-off-by: Rafał Miłecki
> ---
> That "soon" is relative, I'm not planning to push this patch yet. We may give
> updated /etc/config/network few months to receive proper testing.
> ---
> .../uci-defaults/11_network-migrate-bridges | 24 +++
> 1 file changed, 24 insertions(+)
>
> diff --git a/package/base-files/files/etc/uci-defaults/11_network-migrate-
> bridges b/package/base-files/files/etc/uci-defaults/11_network-migrate-
> bridges
> index 745648531f..7188c06ce3 100644
> --- a/package/base-files/files/etc/uci-defaults/11_network-migrate-bridges
> +++ b/package/base-files/files/etc/uci-defaults/11_network-migrate-bridg
> +++ es
> @@ -17,7 +17,31 @@ migrate_ports() {
> uci delete network.$config.ifname
> }
>
> +migrate_bridge() {
> + local config="$1"
> + local type ifname
> +
> + config_get type "$config" type
> + [ "$type" != "bridge" ] && return
> +
> + config_get ifname "$config" ifname
> +
> + uci -q batch <<-EOF
> + add network device
> + set network.@device[-1].name='br-$config'
> + set network.@device[-1].type='bridge'
> + EOF
> + for port in $ifname; do uci add_list
> +network.@device[-1].ports="$port"; done
> +
> + uci -q batch <<-EOF
> + delete network.$config.type
> + set network.$config.ifname='br-$config'
> + EOF
> +}
> +
> config_load network
> config_foreach migrate_ports device
> +config_foreach migrate_bridge interface uci commit network
>
> exit 1
Just to document it somewhere on the list as well:
I don't think putting "exit 1" here is a good solution. The uci-defaults script
are by design meant to be run only once and then deleted.
We should either choose a "big" number for the uci-defaults file name, so the
script is run _after_ the others and deals with custom config, or use some
init.d/rc.d-based script instead that runs for every boot.
From a conceptual perspective, I'd prefer uci-defaults since we should be able
to do the migration "in one step" for practical reasons and consistency.
Apart from that, thanks for taking care of this subject and trying to make
network config more understandable.
Best
Adrian
> --
> 2.26.2
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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: Resize of ath79 / ZyXEL NBG6716 kernel partition
Hi, > -Original Message- > From: Andre Valentin [mailto:a.valen...@ddimension.net] > Sent: Dienstag, 18. Mai 2021 20:11 > To: OpenWrt Development List > Subject: Resize of ath79 / ZyXEL NBG6716 kernel partition > > Hi! > > The NBG6716 has recently been disabled because of size problems with the > kernel partition. > I'm thinking about extending it to 8MB, shouldn't be a problem. Interesting. https://github.com/openwrt/openwrt/commit/5d8ea6d34f9f23d4dfff4ffcac8c9599d842c3a8 I was not aware that we are > 4 MiB for kernel already. Is there anything special about this device (or probably ath79/nand) that causes bigger kernel? Best Adrian > > But I'm afraid users will brick their device when doing a sysupgrade to the > new flash layout. > First time / in upgrade case it must be installed via manufacturer webif or > via > bootloader. > > What do you propose in these cases? > > Kind regards, > > André 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: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Denis Kalashnikov
> Sent: Freitag, 21. Mai 2021 13:05
> To: openwrt-devel@lists.openwrt.org
> Cc: Gabor Juhos ; Koen Vandeputte
> ; Sergey Ryazanov
>
> Subject: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G
Thanks for the update. Some additional comments below.
>
> This board has been supported in the ar71xx.
>
> Links:
> * https://mikrotik.com/product/RB912UAG-2HPnD
> * https://mikrotik.com/product/RB912UAG-5HPnD
> * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-2hpnd
> * https://openwrt.org/toh/hwdata/mikrotik/mikrotik_rb912uag-5hpnd
>
> Hardware:
> * SoC: Atheros AR9342,
> * RAM: DDR 64MB,
> * SPI NOR: 64KB,
> * NAND: 128MB,
> * Ethernet: x1 10/100/1000 port with passive POE in,
> * Wi-Fi: 802.11bgn,
> * PCIe,
> * USB: 2.0 EHCI controller, connected to mPCIe slot and a Type-A
> port -- both can be used for LTE modem. But only one can be used.
> * LEDs: 5 general purpose LEDs (led1..led5), power LED, user LED,
> Ethernet phy LED,
> * Button,
> * Beeper.
>
> Not working:
> * Button: it shares gpio line 15 with NAND ALE and NAND IO7,
> and current drivers doesn't easily support this configuration,
> * Beeper: it is connected to bit 5 of a serial shift register
> (tested with sysfs led trigger timer). But kmod-gpio-beeper
> doesn't work -- we left this as is for now.
>
> You can flash image by sysupgrade utility or load it by net (by DHCP/TFTP,
> hold the button while booting).
>
> Co-Developed-by: Koen Vandeputte
> Signed-off-by: Denis Kalashnikov
> ---
>
> Changelog:
>
> v1->v2:
> - Delete uneeded comments from DTS,
> - Delete ascii-art of board scheme near NAND latch from DTS,
> - Rewrite gpio_latch and nand_gpio nodes to be consistent with the
> new versions of drivers,
> - Fix SPI NOR flash and SPI serial shift register maximum speeds
> (thanks to Koen Vandeputte),
> - Add UART, PCIe, USB support and gpio exports (thanks to Koen
> Vandeputte),
> - Fix Ethernet node (thanks to Koen Vandeputte),
> - Add key and beeper nodes in disabled state just to be documented.
>
> ---
> .../dts/ar9342_mikrotik_routerboard-912g.dts | 233 ++
> target/linux/ath79/image/mikrotik.mk | 9 +
> .../base-files/etc/board.d/02_network | 2 +
> .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
> .../base-files/lib/upgrade/platform.sh| 1 +
> 5 files changed, 246 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9342_mikrotik_routerboard-
> 912g.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> new file mode 100644
> index 00..a23fc04a99
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
> @@ -0,0 +1,233 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +
> +#include "ar9344.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + compatible = "mikrotik,routerboard-912g", "qca,ar9342";
> + model = "Mikrotik RouterBoard 912G";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power {
> + label = "green:power";
> + gpios = <_latch 1 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
Since you have a GPIO-controlled power-led, you should use the led-* aliases in
the aliases block to indicate boot states (just look into one of the other
ath79 DTS files.)
> +
> + led_user {
> + label = "green:user";
> + gpios = <_latch 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led1 {
> + label = "green:led1";
> + gpios = < 0 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led2 {
> + label = "green:led2";
> + gpios = < 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led3 {
> + label = "green:led3";
> + gpios = < 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led4 {
> + label = "green:led4";
> + gpios = < 3 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led5 {
> + label = "green:led5";
> + gpios = < 4 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + beeper {
> + status = "disabled";
> + compatible = "gpio-beeper";
> + gpios = < 5 GPIO_ACTIVE_HIGH>;
> + };
If it's broken, I'd not add it here but just name the correct GPIO number in
the commit message.
> +
> + keys {
> + status = "disabled";
Like above: If it's broken, remove it, so nobody enables it accidentally and
causes harm.
(But document how to set it up in the commit message, as you mostly did already
...)
> +
RE: [PATCH] ath79: add support for Ubiquiti PowerBeam M (XW)
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Russell Senior
> Sent: Sonntag, 23. Mai 2021 07:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Russell Senior
> Subject: [PATCH] ath79: add support for Ubiquiti PowerBeam M (XW)
>
> This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-
> 400, a 802.11n wireless with a feed+dish form factor. This device was
> previously supported by the ar71xx loco-m-xw firmware.
this looks good in general. Somebody else should have a look at the network
config, as this is the first non-wa ubnt device set up with rgmii-id.
Apart from that, please use "ubnt-powerbeam-m-xw" for the compatible. This is
in line with the other xw devices, and actually it would have been better for
the xm devices as well in the first place, so I don't count "There is no 'xm'
powerbeam" as an argument :-)
Best
Adrian
>
> Specifications:
> - Atheros AR9342 SoC
> - 64 MB RAM
> - 8 MB SPI flash
> - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> - Power and LAN green LEDs
> - 4x RSSI LEDs (red, orange, green, green)
> - UART (115200 8N1)
>
> Flashing via stock GUI:
> - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
>device! Read the wiki for more info.
> - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> - Upload the factory image via AirOS web GUI.
>
> Flashing via TFTP:
> - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
>device! Read the wiki for more info.
> - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> - Use a pointy tool (e.g., unbent paperclip) to keep the
>reset button pressed.
> - Power on the device (keep reset button pressed).
> - Keep pressing until LEDs flash alternatively LED1+LED3 =>
>LED2+LED4 => LED1+LED3, etc.
> - Release reset button.
> - The device starts a TFTP server at 192.168.1.20.
> - Set a static IP on the computer (e.g., 192.168.1.21/24).
> - Upload via tftp the factory image:
> $ tftp 192.168.1.20
> tftp> bin
> tftp> trace
> tftp> put openwrt-ath79-generic-x-ubnt_powerbeam-m-squashfs-
> factory.bin
>
> WARNING: so far, no non-destructive method has been discovered for
> opening the enclosure to reach the serial console. Internal photos are
> available here: https://fcc.io/SWX-NBM5HP
>
> Signed-off-by: Russell Senior
> ---
> .../ath79/dts/ar9342_ubnt_powerbeam-m.dts | 36
> +++
> .../generic/base-files/etc/board.d/01_leds| 1 +
> .../generic/base-files/etc/board.d/02_network | 1 +
> target/linux/ath79/image/generic-ubnt.mk | 8 +
> 4 files changed, 46 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-
> m.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
> b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
> new file mode 100644
> index 00..1a2ce428f2
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
> @@ -0,0 +1,36 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "ar9342_ubnt_xw.dtsi"
> +
> +/ {
> + compatible = "ubnt,powerbeam-m", "ubnt,xw", "qca,ar9342";
> + model = "Ubiquiti PowerBeam M (XW)";
> +};
> +
> + {
> + status = "okay";
> +
> + phy-mask = <4>;
> +
> + phy4: ethernet-phy@4 {
> + reg = <4>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + /* default for ar934x, except for 1000M and 10M */
> + pll-data = <0x0200 0x0101 0x1313>;
> +
> + mtd-mac-address = < 0x0>;
> +
> + phy-mode = "rgmii-id";
> + phy-handle = <>;
> +
> + gmac-config {
> + device = <>;
> + rxd-delay = <3>;
> + rxdv-delay = <3>;
> + };
> +};
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> index 1990353394..3bf120b92b 100644
> --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> @@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\ ubnt,nanostation-
> m|\ ubnt,nanostation-m-xw|\ ubnt,picostation-m|\
> +ubnt,powerbeam-m|\
> ubnt,powerbridge-m|\
> ubnt,rocket-m)
> ucidef_set_rssimon "wlan0" "20" "1"
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> index 4133b9d7d3..2b4ab946e1 100644
> --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> @@ -85,6 +85,7 @@ ath79_setup_interfaces()
> ubnt,picostation-m|\
> ubnt,powerbeam-5ac-500|\
> ubnt,powerbeam-5ac-gen2|\
> + ubnt,powerbeam-m|\
> ubnt,powerbridge-m|\
> ubnt,rocket-m|\
> ubnt,unifiac-lite|\
> diff --git a/target/linux/ath79/image/generic-ubnt.mk
>
Re: SquashFS mixed errors (decompression failed and others)
On 5/23/21 10:21 AM, Ibrahim Tachijian wrote: Is your firmware (sysupgrade) bigger than 16MB? No, the sysupgrade file is currently 13MB. So maybe it has to do with switching to 4-address-mode... What is this exactly? The 4-"byte"-address mode is used on 32 MiB flash chips. We had similar issues with other 32 MiB devices in the past which were fixed at some point by Felix Fietkau. My guess is that the error already happens when reading the flash. At least we know that the flash is not being written to incorrectly since after a reboot the flash is intact and does not produce any errors. It's simply random if the system boots into this "faulty state" or not (happens approx 1-2% of the time). Does anyone maybe know how I can re-read the squashfs partition and verify the integrity while the system is booted to see if I encounter the squashfs errors. I'm really at a loss here - no idea where to even look into diagnosing the issue. I guess the reset line of the flash chip is not hold long enough so that it is in an unclean state. I think the reset duration during booting needs to be increased. But I don't know the code and can't point you there. It's just a guess... On Fri, May 21, 2021 at 6:16 PM Vincent Wiemann wrote: On 5/21/21 3:58 PM, Koen Vandeputte wrote: On 21.05.21 13:19, Ibrahim Tachijian wrote: Hello, We use approximately 10k IPQ40XX devices and we have noticed that every time we run "sysupgrade -n" we lose approximately 1% of the routers in the process. After further investigation I'm almost confident that it is not the sysupgrade process that is the culprit - so what I did was that I put one test router into a reboot loop. This is what I do; Boot the router in a fresh state after a newly installed image. The image contains a reboot loop that consists of a shell script that runs every minute. The shell script tries to run a php-script which simply echoes "Hello World". If the php-script exists normally then we reboot the router. However the php-script exists abnormally then the router stops and does nothing other than informing me that there was a bus-error making php not able to process the hello world script. When this process runs the router reboots approximately 50 times before it boots into a state which is faulty where I see bus-errors when I try to run php scripts for example. Looking into dmesg you can see some errors such as, [10985.209438] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11045.218685] SQUASHFS error: xz decompression failed, data probably corrupt [11045.218731] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e [11105.228157] SQUASHFS error: xz decompression failed, data probably corrupt [11105.228203] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e or [26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a] [26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 10234 [26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a] [26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 10234 or [62745.801178] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62773.347234] SQUASHFS error: xz decompression failed, data probably corrupt [62773.347281] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.132661] SQUASHFS error: xz decompression failed, data probably corrupt [62790.132706] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62790.216746] SQUASHFS error: xz decompression failed, data probably corrupt [62790.216792] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62800.810525] SQUASHFS error: xz decompression failed, data probably corrupt [62800.810570] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2 [62828.336267] SQUASHFS error: xz decompression failed, data probably corrupt Now, you would assume that the squashfs-partition is broken - but if this was the case then a reboot should not help. It does. Rebooting the router after it boots in this faulty state fixes the issue. So approximately 1-2% of my reboots make the router go into this faulty state. I am clueless on how to further investigate this issue. For now my work around is restarting the router via a bash script should it notice there are bus-errors or i/o errors. Thanks In the next kernel bump, following patch is also present: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.38=2ed1d90162a0c0683ecbe0c4802187fa22d641c3 I think it's worth a shot to retry the tests once it's bumped. Koen My guess is that the error already happens when reading the flash. Is your firmware (sysupgrade) bigger than 16MB? So maybe it has to do
RE: [PATCH] ath79/zyxel_nbg6716: resize kernel partition to 6MiB and reenable again
Hi again, >KERNEL := kernel-bin | append-dtb | uImage none | zyxel-buildkerneljffs | > \ > - check-size 4096k > - IMAGES := sysupgrade.tar sysupgrade-4M-Kernel.bin factory.bin > + check-size 6144k One should use (KERNEL_SIZE) here instead of a literal value. Best Adrian 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: SquashFS mixed errors (decompression failed and others)
> Is your firmware (sysupgrade) bigger than 16MB? No, the sysupgrade file is currently 13MB. > So maybe it has to do with switching to 4-address-mode... What is this exactly? > My guess is that the error already happens when reading the flash. At least we know that the flash is not being written to incorrectly since after a reboot the flash is intact and does not produce any errors. It's simply random if the system boots into this "faulty state" or not (happens approx 1-2% of the time). Does anyone maybe know how I can re-read the squashfs partition and verify the integrity while the system is booted to see if I encounter the squashfs errors. I'm really at a loss here - no idea where to even look into diagnosing the issue. On Fri, May 21, 2021 at 6:16 PM Vincent Wiemann wrote: > > > > On 5/21/21 3:58 PM, Koen Vandeputte wrote: > > > > On 21.05.21 13:19, Ibrahim Tachijian wrote: > >> Hello, > >> > >> We use approximately 10k IPQ40XX devices and we have noticed that > >> every time we run "sysupgrade -n" we lose approximately 1% of the > >> routers in the process. > >> After further investigation I'm almost confident that it is not the > >> sysupgrade process that is the culprit - so what I did was that I put > >> one test router into a reboot loop. > >> > >> This is what I do; > >> > >> Boot the router in a fresh state after a newly installed image. > >> The image contains a reboot loop that consists of a shell script that > >> runs every minute. > >> > >> The shell script tries to run a php-script which simply echoes "Hello > >> World". If the php-script exists normally then we reboot the router. > >> > >> However the php-script exists abnormally then the router stops and > >> does nothing other than informing me that there was a bus-error making > >> php not able to process the hello world script. > >> > >> When this process runs the router reboots approximately 50 times > >> before it boots into a state which is faulty where I see bus-errors > >> when I try to run php scripts for example. > >> > >> > >> Looking into dmesg you can see some errors such as, > >> > >> [10985.209438] SQUASHFS error: squashfs_read_data failed to read block > >> 0x3a803e > >> [11045.218685] SQUASHFS error: xz decompression failed, data probably > >> corrupt > >> [11045.218731] SQUASHFS error: squashfs_read_data failed to read block > >> 0x3a803e > >> [11105.228157] SQUASHFS error: xz decompression failed, data probably > >> corrupt > >> [11105.228203] SQUASHFS error: squashfs_read_data failed to read block > >> 0x3a803e > >> > >> or > >> > >> [26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size > >> 10234 > >> [26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a] > >> [26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size > >> 10234 > >> [26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a] > >> [26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size > >> 10234 > >> [26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a] > >> [26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size > >> 10234 > >> > >> or > >> > >> [62745.801178] SQUASHFS error: squashfs_read_data failed to read block > >> 0x732ae2 > >> [62773.347234] SQUASHFS error: xz decompression failed, data probably > >> corrupt > >> [62773.347281] SQUASHFS error: squashfs_read_data failed to read block > >> 0x732ae2 > >> [62790.132661] SQUASHFS error: xz decompression failed, data probably > >> corrupt > >> [62790.132706] SQUASHFS error: squashfs_read_data failed to read block > >> 0x732ae2 > >> [62790.216746] SQUASHFS error: xz decompression failed, data probably > >> corrupt > >> [62790.216792] SQUASHFS error: squashfs_read_data failed to read block > >> 0x732ae2 > >> [62800.810525] SQUASHFS error: xz decompression failed, data probably > >> corrupt > >> [62800.810570] SQUASHFS error: squashfs_read_data failed to read block > >> 0x732ae2 > >> [62828.336267] SQUASHFS error: xz decompression failed, data probably > >> corrupt > >> > >> > >> > >> Now, you would assume that the squashfs-partition is broken - but if > >> this was the case then a reboot should not help. It does. > >> Rebooting the router after it boots in this faulty state fixes the issue. > >> > >> So approximately 1-2% of my reboots make the router go into this > >> faulty state. > >> > >> I am clueless on how to further investigate this issue. For now my > >> work around is restarting the router via a bash script should it > >> notice there are bus-errors or i/o errors. > >> > >> Thanks > >> > > In the next kernel bump, following patch is also present: > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.38=2ed1d90162a0c0683ecbe0c4802187fa22d641c3 > > > > > > I think it's worth a shot to retry the tests once it's bumped. > > > > Koen > > > > My guess is that the error already happens when reading the flash. > Is your firmware (sysupgrade) bigger than 16MB? >
