[PATCH-22.03 2/2] sunxi: ensure NanoPi R1 has unique MAC address
Ensure the MAC address for all NanoPi R1 boards is assigned uniquely for
each board.
The vendor ships the device in two variants; one with and one without
eMMC; but both without static mac-addresses.
In order to assign both board types unique MAC addresses, fall back on
the same method used for the NanoPi R2S and R4S in case the EEPROM
chip is not present by generating the board MAC from the SD card CID.
[0] https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R1#Hardware_Spec
Similar too and based on:
commit b5675f500daf ("rockchip: ensure NanoPi R4S has unique MAC address")
Co-authored-by: David Bauer
Signed-off-by: Jan-Niklas Burfeind
(cherry picked from commit c7d3bbb909bdcccd4f26f18b18cc1cb00500a874)
---
.../base-files/files/lib/functions/system.sh | 8 ++
.../armv8/base-files/etc/board.d/02_network | 13 ++
.../sunxi/base-files/etc/board.d/02_network | 25 +++
3 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/package/base-files/files/lib/functions/system.sh
b/package/base-files/files/lib/functions/system.sh
index c17354d945..db9732a782 100644
--- a/package/base-files/files/lib/functions/system.sh
+++ b/package/base-files/files/lib/functions/system.sh
@@ -185,6 +185,14 @@ macaddr_add() {
echo $oui:$nic
}
+macaddr_generate_from_mmc_cid() {
+ local mmc_dev=$1
+
+ local sd_hash=$(sha256sum /sys/class/block/$mmc_dev/device/cid)
+ local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1
count=12 2>/dev/null)")
+ echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
+}
+
macaddr_geteui() {
local mac=$1
local sep=$2
diff --git a/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
b/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
index b0e6479947..816045a480 100644
--- a/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
+++ b/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
@@ -17,15 +17,6 @@ rockchip_setup_interfaces()
esac
}
-generate_mac_from_mmc_cid()
-{
- local mmc_dev=$1
-
- local sd_hash=$(sha256sum /sys/class/block/$mmc_dev/device/cid)
- local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1
count=12 2>/dev/null)")
- echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
-}
-
nanopi_r4s_get_mac()
{
local interface=$1
@@ -38,7 +29,7 @@ nanopi_r4s_get_mac()
address=$(macaddr_setbit_la "$address")
fi
else
- address=$(generate_mac_from_mmc_cid mmcblk1)
+ address=$(macaddr_generate_from_mmc_cid mmcblk1)
if [ "$interface" = "lan" ]; then
address=$(macaddr_add "$address" 1)
fi
@@ -56,7 +47,7 @@ rockchip_setup_macs()
case "$board" in
friendlyarm,nanopi-r2s)
- wan_mac=$(generate_mac_from_mmc_cid mmcblk0)
+ wan_mac=$(macaddr_generate_from_mmc_cid mmcblk0)
lan_mac=$(macaddr_add "$wan_mac" 1)
;;
friendlyarm,nanopi-r4s)
diff --git a/target/linux/sunxi/base-files/etc/board.d/02_network
b/target/linux/sunxi/base-files/etc/board.d/02_network
index 46ace1f67c..b295dc7daa 100644
--- a/target/linux/sunxi/base-files/etc/board.d/02_network
+++ b/target/linux/sunxi/base-files/etc/board.d/02_network
@@ -29,6 +29,27 @@ sunxi_setup_interfaces()
esac
}
+nanopi_r1_get_mac()
+{
+ local interface=$1
+ local eeprom_path="/sys/bus/i2c/devices/2-0051/eeprom"
+ local address
+
+ if [ -f "$eeprom_path" ]; then
+ address=$(get_mac_binary "$eeprom_path" 0xfa)
+ if [ "$interface" = "lan" ]; then
+ address=$(macaddr_setbit_la "$address")
+ fi
+ else
+ address=$(macaddr_generate_from_mmc_cid mmcblk1)
+ if [ "$interface" = "lan" ]; then
+ address=$(macaddr_add "$address" 1)
+ fi
+ fi
+
+ echo "$address"
+}
+
sunxi_setup_macs()
{
local board="$1"
@@ -37,6 +58,10 @@ sunxi_setup_macs()
local label_mac=""
case "$board" in
+ friendlyarm,nanopi-r1)
+ wan_mac=$(nanopi_r1_get_mac wan)
+ lan_mac=$(nanopi_r1_get_mac lan)
+ ;;
friendlyarm,nanopi-r1s-h5)
lan_mac=$(get_mac_binary "/sys/bus/i2c/devices/0-0051/eeprom"
0xfa)
;;
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03 1/2] uboot-sunxi: use UUID of bootdev and bootpart
Several sunxi devices come with multiple mmc devices. On such devices,
the mmc device order is unpredictable, so using /dev/mmcblk0p2 as root
device doesn't always work, which results in unbootable devices.
For the Banana Pi BPI-R3 in the mediatek target, this has been solved by
defining aliases for the mmc devices in the DTS. Ideally we would do the
same here, but for sunxi-a64 we already use UUID probing, so let's start
with that (5f2ff607e286 ("uboot-sunxi: a64: allow booting directly from
eMMC")).
Since we're building and including u-boot in each supported device
image, and this method has been proven to work fine for a64, let's just
change the default u-boot env file to do the same.
Fixes: #10080
Fixes: e6d9f6fdff ("sunxi: add support for FriendlyARM NanoPi R1")
Co-authored-by: Karl Palsson
Signed-off-by: Jan-Niklas Burfeind
[use UUID in default u-boot env, rewrite commit message]
Signed-off-by: Stijn Tintel
(cherry picked from commit bf06a7c865531cf20735cbdfac46d4947fcc18a6)
---
package/boot/uboot-sunxi/uEnv-default.txt | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/package/boot/uboot-sunxi/uEnv-default.txt
b/package/boot/uboot-sunxi/uEnv-default.txt
index e024954516..36e41c59b1 100644
--- a/package/boot/uboot-sunxi/uEnv-default.txt
+++ b/package/boot/uboot-sunxi/uEnv-default.txt
@@ -1,6 +1,8 @@
setenv fdt_high
-setenv loadkernel fatload mmc 0 \$kernel_addr_r uImage
-setenv loaddtb fatload mmc 0 \$fdt_addr_r dtb
-setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait
+setenv mmc_rootpart 2
+part uuid mmc ${mmc_bootdev}:${mmc_rootpart} uuid
+setenv loadkernel fatload mmc \$mmc_bootdev \$kernel_addr_r uImage
+setenv loaddtb fatload mmc \$mmc_bootdev \$fdt_addr_r dtb
+setenv bootargs console=ttyS0,115200 earlyprintk root=PARTUUID=${uuid} rootwait
setenv uenvcmd run loadkernel \&\& run loaddtb \&\& bootm \$kernel_addr_r -
\$fdt_addr_r
run uenvcmd
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] ramips: add support for D-Link DAP-X1860 A1
mod-mt7915e rssileds
+endef
+TARGET_DEVICES += dlink_dap-x1860-a1
+
define Device/dlink_dir-8xx-a1
$(Device/dsa-migration)
IMAGE_SIZE := 16000k
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
index 42e50451e3..626f048a85 100644
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/01_leds
@@ -50,6 +50,13 @@ jcg,y2|\
xzwifi,creativebox-v1)
ucidef_set_led_netdev "internet" "internet" "blue:internet" "wan"
;;
+dlink,dap-x1860-a1)
+ ucidef_set_rssimon "wlan1" "20" "1"
+ ucidef_set_led_rssi "rssilow" "RSSILOW" "orange:rssilow" "wlan1" "1"
"25"
+ ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMLOW" "green:rssilow" "wlan1" "26"
"100"
+ ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "green:rssimedium" "wlan1"
"51" "100"
+ ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "green:rssihigh" "wlan1" "76"
"100"
+ ;;
dlink,dir-1960-a1|\
dlink,dir-2640-a1|\
dlink,dir-2660-a1)
diff --git a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
index b7121db64f..40afa5879a 100644
--- a/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/mt7621/base-files/etc/board.d/02_network
@@ -11,6 +11,7 @@ ramips_setup_interfaces()
ampedwireless,ally-00x19k|\
asus,rp-ac56|\
asus,rp-ac87|\
+ dlink,dap-x1860-a1|\
edimax,re23s|\
mikrotik,ltap-2hnd|\
mikrotik,routerboard-m11g|\
diff --git
a/target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
b/target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
index 69ecaefd27..161bd942db 100644
---
a/target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
+++
b/target/linux/ramips/mt7621/base-files/etc/hotplug.d/ieee80211/10_fix_wifi_mac
@@ -22,6 +22,13 @@ case "$board" in
hw_mac_addr="$(mtd_get_mac_binary factory 0x4)"
macaddr_add $hw_mac_addr "$PHYNBR" > /sys${DEVPATH}/macaddress
;;
+ dlink,dap-x1860-a1)
+ hw_mac_addr="$(mtd_get_mac_binary factory 0x4)"
+ [ "$PHYNBR" = "0" ] && \
+ macaddr_add $hw_mac_addr 1 > /sys${DEVPATH}/macaddress
+ [ "$PHYNBR" = "1" ] && \
+ macaddr_add $hw_mac_addr 4 > /sys${DEVPATH}/macaddress
+ ;;
dlink,dir-853-a3)
[ "$PHYNBR" = "0" ] && \
macaddr_setbit_la "$(mtd_get_mac_binary factory
0xe000)" \
diff --git a/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
index 06a35077dc..15bab1958a 100755
--- a/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/mt7621/base-files/lib/upgrade/platform.sh
@@ -59,6 +59,7 @@ platform_do_upgrade() {
beeline,smartbox-giga|\
beeline,smartbox-turbo|\
belkin,rt1800|\
+ dlink,dap-x1860-a1|\
dlink,dir-1960-a1|\
dlink,dir-2640-a1|\
dlink,dir-2660-a1|\
I tested the patch on tonights master. Does work as described in his
message. Whoever merges this can add:
Jan-Niklas Burfeind
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH-22.03] lantiq-xrx200: fix wan LED on o2 box 6431
From: Florian Maurer The WIFI LED already worked for me with the latest openwrt 22.03 version. Wifi LED did not with an older 22.x version (in gluon - there phy0radio did nothing but phy0tpt did show activity the WAN interface has the name "wan" and not "pppoe-wan" on this device fixes #7757 (and FS#2987) Signed-off-by: Florian Maurer (cherry picked from commit 0820d620123a03b6db6642acb6e950d22ffb030f) Signed-off-by: Jan-Niklas Burfeind --- target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds b/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds index bac3ed2b53..8f59538b83 100644 --- a/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds +++ b/target/linux/lantiq/xrx200/base-files/etc/board.d/01_leds @@ -28,7 +28,10 @@ arcadyan,arv7519rw22) ucidef_set_led_netdev "lan" "lan" "green:lan" "eth0.1" ;; arcadyan,vgv7510kw22-nor|\ -arcadyan,vgv7510kw22-brn|\ +arcadyan,vgv7510kw22-brn) + ucidef_set_led_netdev "internet" "internet" "$led_internet" "wan" + ucidef_set_led_wlan "wifi" "wifi" "green:wlan" "phy0radio" + ;; zyxel,p-2812hnu-f1|\ zyxel,p-2812hnu-f3) ucidef_set_led_wlan "wifi" "wifi" "green:wlan" "phy0radio" -- 2.39.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] sunxi: enable CONFIG_NVMEM_SYSFS
in both the stable and the testing kernel h2+/h3/h5 devices have a Secure ID that can be read from `/sys/bus/nvmem/devices/sunxi-sid0/nvmem`. Enabling CONFIG_NVMEM_SYSFS grants sysfs access from userspace. Signed-off-by: Jan-Niklas Burfeind --- Hauke suggested enabling it for the whole sunxi target, as all devices either have enough onboard or external memory to cope with the additional 5KB. @robimarko I split off the the changes into two commits which can be found here: https://github.com/openwrt/openwrt/compare/master...AiyionPrime:openwrt:sunxi-nvmem_sysfs I've left the first commit including all unrelated kernel settings aside, due to build failures. It works as expected, tested on a NanoPi R1. Path exists and is readable. Thanks again for all the help, I hope this is done correctly. Jan-Niklas target/linux/sunxi/config-5.10 | 1 + target/linux/sunxi/config-5.15 | 1 + target/linux/sunxi/cortexa53/config-5.15 | 1 - 3 files changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/sunxi/config-5.10 b/target/linux/sunxi/config-5.10 index caac9e1436..84645141fb 100644 --- a/target/linux/sunxi/config-5.10 +++ b/target/linux/sunxi/config-5.10 @@ -301,6 +301,7 @@ CONFIG_NO_HZ_IDLE=y CONFIG_NR_CPUS=8 CONFIG_NVMEM=y CONFIG_NVMEM_SUNXI_SID=y +CONFIG_NVMEM_SYSFS=y CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y diff --git a/target/linux/sunxi/config-5.15 b/target/linux/sunxi/config-5.15 index c7dbc5a9f1..17c4d910c8 100644 --- a/target/linux/sunxi/config-5.15 +++ b/target/linux/sunxi/config-5.15 @@ -307,6 +307,7 @@ CONFIG_NO_HZ_IDLE=y CONFIG_NR_CPUS=8 CONFIG_NVMEM=y CONFIG_NVMEM_SUNXI_SID=y +CONFIG_NVMEM_SYSFS=y CONFIG_OF=y CONFIG_OF_ADDRESS=y CONFIG_OF_EARLY_FLATTREE=y diff --git a/target/linux/sunxi/cortexa53/config-5.15 b/target/linux/sunxi/cortexa53/config-5.15 index b93abf0765..85ace5d928 100644 --- a/target/linux/sunxi/cortexa53/config-5.15 +++ b/target/linux/sunxi/cortexa53/config-5.15 @@ -52,7 +52,6 @@ CONFIG_MUSB_PIO_ONLY=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_NOP_USB_XCEIV=y CONFIG_NO_IOPORT_MAP=y -CONFIG_NVMEM_SYSFS=y CONFIG_PARTITION_PERCPU=y CONFIG_PHY_SUN50I_USB3=y CONFIG_PINCTRL_SUN50I_A100=y -- 2.39.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] sunxi: ensure NanoPi R1 has unique MAC address
Ensure the MAC address for all NanoPi R1 boards is assigned uniquely for
each board.
The vendor ships the device in two variants; one with and one without
eMMC; but both without static mac-addresses.
In order to assign both board types unique MAC addresses, fall back on
the same method used for the NanoPi R2S and R4S in case the EEPROM
chip is not present by generating the board MAC from the SD card CID.
[0] https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R1#Hardware_Spec
Similar too and based on:
commit b5675f500daf ("rockchip: ensure NanoPi R4S has unique MAC address")
Co-authored-by: David Bauer
Signed-off-by: Jan-Niklas Burfeind
---
.../base-files/files/lib/functions/system.sh | 8 ++
.../armv8/base-files/etc/board.d/02_network | 13 ++
.../sunxi/base-files/etc/board.d/02_network | 25 +++
3 files changed, 35 insertions(+), 11 deletions(-)
diff --git a/package/base-files/files/lib/functions/system.sh
b/package/base-files/files/lib/functions/system.sh
index 29de2e5dd6..176c10d065 100644
--- a/package/base-files/files/lib/functions/system.sh
+++ b/package/base-files/files/lib/functions/system.sh
@@ -204,6 +204,14 @@ macaddr_add() {
echo $oui:$nic
}
+macaddr_generate_from_mmc_cid() {
+ local mmc_dev=$1
+
+ local sd_hash=$(sha256sum /sys/class/block/$mmc_dev/device/cid)
+ local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1
count=12 2>/dev/null)")
+ echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
+}
+
macaddr_geteui() {
local mac=$1
local sep=$2
diff --git a/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
b/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
index b0e6479947..816045a480 100644
--- a/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
+++ b/target/linux/rockchip/armv8/base-files/etc/board.d/02_network
@@ -17,15 +17,6 @@ rockchip_setup_interfaces()
esac
}
-generate_mac_from_mmc_cid()
-{
- local mmc_dev=$1
-
- local sd_hash=$(sha256sum /sys/class/block/$mmc_dev/device/cid)
- local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1
count=12 2>/dev/null)")
- echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
-}
-
nanopi_r4s_get_mac()
{
local interface=$1
@@ -38,7 +29,7 @@ nanopi_r4s_get_mac()
address=$(macaddr_setbit_la "$address")
fi
else
- address=$(generate_mac_from_mmc_cid mmcblk1)
+ address=$(macaddr_generate_from_mmc_cid mmcblk1)
if [ "$interface" = "lan" ]; then
address=$(macaddr_add "$address" 1)
fi
@@ -56,7 +47,7 @@ rockchip_setup_macs()
case "$board" in
friendlyarm,nanopi-r2s)
- wan_mac=$(generate_mac_from_mmc_cid mmcblk0)
+ wan_mac=$(macaddr_generate_from_mmc_cid mmcblk0)
lan_mac=$(macaddr_add "$wan_mac" 1)
;;
friendlyarm,nanopi-r4s)
diff --git a/target/linux/sunxi/base-files/etc/board.d/02_network
b/target/linux/sunxi/base-files/etc/board.d/02_network
index 46ace1f67c..b295dc7daa 100644
--- a/target/linux/sunxi/base-files/etc/board.d/02_network
+++ b/target/linux/sunxi/base-files/etc/board.d/02_network
@@ -29,6 +29,27 @@ sunxi_setup_interfaces()
esac
}
+nanopi_r1_get_mac()
+{
+ local interface=$1
+ local eeprom_path="/sys/bus/i2c/devices/2-0051/eeprom"
+ local address
+
+ if [ -f "$eeprom_path" ]; then
+ address=$(get_mac_binary "$eeprom_path" 0xfa)
+ if [ "$interface" = "lan" ]; then
+ address=$(macaddr_setbit_la "$address")
+ fi
+ else
+ address=$(macaddr_generate_from_mmc_cid mmcblk1)
+ if [ "$interface" = "lan" ]; then
+ address=$(macaddr_add "$address" 1)
+ fi
+ fi
+
+ echo "$address"
+}
+
sunxi_setup_macs()
{
local board="$1"
@@ -37,6 +58,10 @@ sunxi_setup_macs()
local label_mac=""
case "$board" in
+ friendlyarm,nanopi-r1)
+ wan_mac=$(nanopi_r1_get_mac wan)
+ lan_mac=$(nanopi_r1_get_mac lan)
+ ;;
friendlyarm,nanopi-r1s-h5)
lan_mac=$(get_mac_binary "/sys/bus/i2c/devices/0-0051/eeprom"
0xfa)
;;
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] sunxi: ensure NanoPi R1 has unique MAC address
Ensure the MAC address for all NanoPi R1 boards is assigned unique for
each board.
The venor ships the device in two variants; one with and one without
eMMC; but both without static mac-addresses.
In order to assign both board types unique MAC addresses, fall back on
the same method used for the NanoPi R2S and R4S in case the EEPROM
chip is not present by generating the board MAC from the SD card CID.
[0] https://wiki.friendlyelec.com/wiki/index.php/NanoPi_R1#Hardware_Spec
Similar too and based on:
commit b5675f500daf ("rockchip: ensure NanoPi R4S has unique MAC address")
Co-authored-by: David Bauer
Signed-off-by: Jan-Niklas Burfeind
---
.../sunxi/base-files/etc/board.d/02_network | 34 +++
1 file changed, 34 insertions(+)
diff --git a/target/linux/sunxi/base-files/etc/board.d/02_network
b/target/linux/sunxi/base-files/etc/board.d/02_network
index 46ace1f67c..311699dfb5 100644
--- a/target/linux/sunxi/base-files/etc/board.d/02_network
+++ b/target/linux/sunxi/base-files/etc/board.d/02_network
@@ -29,6 +29,36 @@ sunxi_setup_interfaces()
esac
}
+generate_mac_from_mmc_cid()
+{
+ local mmc_dev=$1
+
+ local sd_hash=$(sha256sum /sys/class/block/$mmc_dev/device/cid)
+ local mac_base=$(macaddr_canonicalize "$(echo "${sd_hash}" | dd bs=1
count=12 2>/dev/null)")
+ echo "$(macaddr_unsetbit_mc "$(macaddr_setbit_la "${mac_base}")")"
+}
+
+nanopi_r1_get_mac()
+{
+ local interface=$1
+ local eeprom_path="/sys/bus/i2c/devices/2-0051/eeprom"
+ local address
+
+ if [ -f "$eeprom_path" ]; then
+ address=$(get_mac_binary "$eeprom_path" 0xfa)
+ if [ "$interface" = "lan" ]; then
+ address=$(macaddr_setbit_la "$address")
+ fi
+ else
+ address=$(generate_mac_from_mmc_cid mmcblk1)
+ if [ "$interface" = "lan" ]; then
+ address=$(macaddr_add "$address" 1)
+ fi
+ fi
+
+ echo "$address"
+}
+
sunxi_setup_macs()
{
local board="$1"
@@ -37,6 +67,10 @@ sunxi_setup_macs()
local label_mac=""
case "$board" in
+ friendlyarm,nanopi-r1)
+ wan_mac=$(nanopi_r1_get_mac wan)
+ lan_mac=$(nanopi_r1_get_mac lan)
+ ;;
friendlyarm,nanopi-r1s-h5)
lan_mac=$(get_mac_binary "/sys/bus/i2c/devices/0-0051/eeprom"
0xfa)
;;
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] uboot-sunxi: use UUID of bootdev and bootpart
for the NanoPi R1 instead of the hardcoded `mmcblk0p2` to support its
multiple mmcs.
Fixes: e6d9f6fdff ("sunxi: add support for FriendlyARM NanoPi R1")
Co-authored-by: Karl Palsson
Signed-off-by: Jan-Niklas Burfeind
---
package/boot/uboot-sunxi/Makefile| 1 +
package/boot/uboot-sunxi/uEnv-anymmc.txt | 8
2 files changed, 9 insertions(+)
create mode 100644 package/boot/uboot-sunxi/uEnv-anymmc.txt
diff --git a/package/boot/uboot-sunxi/Makefile
b/package/boot/uboot-sunxi/Makefile
index 5c27407d15..e4e4089015 100644
--- a/package/boot/uboot-sunxi/Makefile
+++ b/package/boot/uboot-sunxi/Makefile
@@ -184,6 +184,7 @@ define U-Boot/nanopi_r1
BUILD_SUBTARGET:=cortexa7
NAME:=U-Boot for NanoPi R1 (H3)
BUILD_DEVICES:=friendlyarm_nanopi-r1
+ UENV:=anymmc
endef
define U-Boot/orangepi_r1
diff --git a/package/boot/uboot-sunxi/uEnv-anymmc.txt
b/package/boot/uboot-sunxi/uEnv-anymmc.txt
new file mode 100644
index 00..36e41c59b1
--- /dev/null
+++ b/package/boot/uboot-sunxi/uEnv-anymmc.txt
@@ -0,0 +1,8 @@
+setenv fdt_high
+setenv mmc_rootpart 2
+part uuid mmc ${mmc_bootdev}:${mmc_rootpart} uuid
+setenv loadkernel fatload mmc \$mmc_bootdev \$kernel_addr_r uImage
+setenv loaddtb fatload mmc \$mmc_bootdev \$fdt_addr_r dtb
+setenv bootargs console=ttyS0,115200 earlyprintk root=PARTUUID=${uuid} rootwait
+setenv uenvcmd run loadkernel \&\& run loaddtb \&\& bootm \$kernel_addr_r -
\$fdt_addr_r
+run uenvcmd
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] uboot-sunxi: use UUID of bootdev and bootpart
On 12/15/22 15:18, Jan-Niklas Burfeind wrote:
instead of the hardcoded `mmcblk0p2` to support devices with multiple
mmcs, like the NanoPi R1.
Fixes: e6d9f6fdff ("sunxi: add support for FriendlyARM NanoPi R1")
Signed-off-by: Jan-Niklas Burfeind
---
Good afternoon.
I just had a discussion with karlp in openwrt-devel, where we talked
about the problem and our potential solutions to it.
For starters, this resolves #11104 and likely both #10080 and #11469 as
well.
The NanoPi R1 comes with an internal emmc, which is identified as
mmcblk0 about half the time. This breaks the boot process and results
often enough in a reboot, which is likely part of the reason this did not get
attention earlier, as booting does often just take longer but only
rarely fails completely.
Anyway. This is one of two discussed approaches to eliminate the
problem. There is another by karlp referenced below [1].
There are two core treats,the two patches differ in:
- this patch relies on UUIDs, karlps does use labels
- this patch changes default bootscript to match the a64 variant more,
his does add a uenv, which I really like
I'd like to know, whether it would be worthwhile to take his patch or
mine, or combine the two and have a uenv `anymmc` that introduces UUIDs.
Looking for previous uboot-sunxi contributors I found ynezz did the very
same thing for a64 in
5f2ff607e2 ("uboot-sunxi: a64: allow booting directly from eMMC")
Thanks and have a nice afternoon
Jan-Niklas
package/boot/uboot-sunxi/uEnv-default.txt | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/package/boot/uboot-sunxi/uEnv-default.txt
b/package/boot/uboot-sunxi/uEnv-default.txt
index e024954516..36e41c59b1 100644
--- a/package/boot/uboot-sunxi/uEnv-default.txt
+++ b/package/boot/uboot-sunxi/uEnv-default.txt
@@ -1,6 +1,8 @@
setenv fdt_high
-setenv loadkernel fatload mmc 0 \$kernel_addr_r uImage
-setenv loaddtb fatload mmc 0 \$fdt_addr_r dtb
-setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait
+setenv mmc_rootpart 2
+part uuid mmc ${mmc_bootdev}:${mmc_rootpart} uuid
+setenv loadkernel fatload mmc \$mmc_bootdev \$kernel_addr_r uImage
+setenv loaddtb fatload mmc \$mmc_bootdev \$fdt_addr_r dtb
+setenv bootargs console=ttyS0,115200 earlyprintk root=PARTUUID=${uuid} rootwait
setenv uenvcmd run loadkernel \&\& run loaddtb \&\& bootm \$kernel_addr_r -
\$fdt_addr_r
run uenvcmd
Sorry. Forgot to actually ammend karlp's draft:
[1]
https://github.com/openwrt/openwrt/commit/3f8a3fc40c2195410cf2214d45a948ad95c4247a
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] uboot-sunxi: use UUID of bootdev and bootpart
instead of the hardcoded `mmcblk0p2` to support devices with multiple
mmcs, like the NanoPi R1.
Fixes: e6d9f6fdff ("sunxi: add support for FriendlyARM NanoPi R1")
Signed-off-by: Jan-Niklas Burfeind
---
Good afternoon.
I just had a discussion with karlp in openwrt-devel, where we talked
about the problem and our potential solutions to it.
For starters, this resolves #11104 and likely both #10080 and #11469 as
well.
The NanoPi R1 comes with an internal emmc, which is identified as
mmcblk0 about half the time. This breaks the boot process and results
often enough in a reboot, which is likely part of the reason this did not get
attention earlier, as booting does often just take longer but only
rarely fails completely.
Anyway. This is one of two discussed approaches to eliminate the
problem. There is another by karlp referenced below [1].
There are two core treats,the two patches differ in:
- this patch relies on UUIDs, karlps does use labels
- this patch changes default bootscript to match the a64 variant more,
his does add a uenv, which I really like
I'd like to know, whether it would be worthwhile to take his patch or
mine, or combine the two and have a uenv `anymmc` that introduces UUIDs.
Looking for previous uboot-sunxi contributors I found ynezz did the very
same thing for a64 in
5f2ff607e2 ("uboot-sunxi: a64: allow booting directly from eMMC")
Thanks and have a nice afternoon
Jan-Niklas
package/boot/uboot-sunxi/uEnv-default.txt | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/package/boot/uboot-sunxi/uEnv-default.txt
b/package/boot/uboot-sunxi/uEnv-default.txt
index e024954516..36e41c59b1 100644
--- a/package/boot/uboot-sunxi/uEnv-default.txt
+++ b/package/boot/uboot-sunxi/uEnv-default.txt
@@ -1,6 +1,8 @@
setenv fdt_high
-setenv loadkernel fatload mmc 0 \$kernel_addr_r uImage
-setenv loaddtb fatload mmc 0 \$fdt_addr_r dtb
-setenv bootargs console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait
+setenv mmc_rootpart 2
+part uuid mmc ${mmc_bootdev}:${mmc_rootpart} uuid
+setenv loadkernel fatload mmc \$mmc_bootdev \$kernel_addr_r uImage
+setenv loaddtb fatload mmc \$mmc_bootdev \$fdt_addr_r dtb
+setenv bootargs console=ttyS0,115200 earlyprintk root=PARTUUID=${uuid} rootwait
setenv uenvcmd run loadkernel \&\& run loaddtb \&\& bootm \$kernel_addr_r -
\$fdt_addr_r
run uenvcmd
--
2.39.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] sunxi: remove frequency for NanoPi R1
The frequency appears as unlisted initial frequency. Removed it as Hauke suggested. Signed-off-by: Jan-Niklas Burfeind --- This resolves part of the problem in #11104 on GitHub [1]. The "Waiting for root device /dev/mmcblk0p2..."-issue still remains and leaves the device unbootable about half the time. Without this the device boots less often. [1] https://github.com/openwrt/openwrt/issues/11104 .../patches/252-sunxi-h3-add-support-for-nanopi-r1.patch | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/package/boot/uboot-sunxi/patches/252-sunxi-h3-add-support-for-nanopi-r1.patch b/package/boot/uboot-sunxi/patches/252-sunxi-h3-add-support-for-nanopi-r1.patch index 0db7be5421..058b29d95b 100644 --- a/package/boot/uboot-sunxi/patches/252-sunxi-h3-add-support-for-nanopi-r1.patch +++ b/package/boot/uboot-sunxi/patches/252-sunxi-h3-add-support-for-nanopi-r1.patch @@ -173,7 +173,7 @@ Signed-off-by: Jayantajit Gogoi +}; --- /dev/null +++ b/configs/nanopi_r1_defconfig -@@ -0,0 +1,22 @@ +@@ -0,0 +1,21 @@ +CONFIG_ARM=y +CONFIG_ARCH_SUNXI=y +CONFIG_SPL=y @@ -186,7 +186,6 @@ Signed-off-by: Jayantajit Gogoi +CONFIG_NR_DRAM_BANKS=1 +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set +CONFIG_CONSOLE_MUX=y -+CONFIG_SYS_CLK_FREQ=48000 +# CONFIG_CMD_FLASH is not set +# CONFIG_SPL_DOS_PARTITION is not set +# CONFIG_SPL_EFI_PARTITION is not set -- 2.38.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[BACKPORT 22.03 v2 1/2] comgt-ncm: add support for quectel modem EC200T-EU
context_type is an integer mapping of pdptype:
1: IPV4
2: IPV6
3: IPV4V6
Signed-off-by: Jan-Niklas Burfeind
(cherry picked from commit 13f82ce264ed2d02c66cb2cae8f013c8f64a979f)
---
I sent the patch a few hours eatlier, but missed the development list.
Commit-ID changed as I wrongly changed the commit-title earlier.
Sorry for the noise Arınç and thanks to David.
package/network/utils/comgt/files/ncm.json | 16
package/network/utils/comgt/files/ncm.sh | 6 ++
2 files changed, 22 insertions(+)
diff --git a/package/network/utils/comgt/files/ncm.json
b/package/network/utils/comgt/files/ncm.json
index b6ad717529..7d9a38fe36 100644
--- a/package/network/utils/comgt/files/ncm.json
+++ b/package/network/utils/comgt/files/ncm.json
@@ -75,6 +75,22 @@
"finalize": "AT+CGDATA=\\\"M-MBIM\\\",${profile},1",
"disconnect": "AT+CGACT=0,${profile}"
},
+ "quectel": {
+ "initialize": [
+ "AT+CFUN=1"
+ ],
+ "configure": [
+
"at+qicsgp=${profile},${context_type},\\\"${apn}\\\",\\\"${username}\\\",\\\"${password}\\\",0"
+ ],
+ "modes": {
+ "lte": "AT+QCFG=\\\"nwscanmode\\\",3",
+ "umts": "AT+QCFG=\\\"nwscanmode\\\",2",
+ "gsm": "AT+QCFG=\\\"nwscanmode\\\",1",
+ "auto": "AT+QCFG=\\\"nwscanmode\\\",0"
+ },
+ "connect": "AT+qnetdevctl=1,${profile},1",
+ "disconnect": "AT+qnetdevctl=0,${profile},0"
+ },
"\"zte": {
"initialize": [
"AT+CFUN=1"
diff --git a/package/network/utils/comgt/files/ncm.sh
b/package/network/utils/comgt/files/ncm.sh
index a2c913ea1d..2f36697487 100644
--- a/package/network/utils/comgt/files/ncm.sh
+++ b/package/network/utils/comgt/files/ncm.sh
@@ -31,6 +31,8 @@ proto_ncm_setup() {
local device ifname apn auth username password pincode delay mode
pdptype profile $PROTO_DEFAULT_OPTIONS
json_get_vars device ifname apn auth username password pincode delay
mode pdptype profile $PROTO_DEFAULT_OPTIONS
+ local context_type
+
[ "$metric" = "" ] && metric="0"
[ -n "$profile" ] || profile=1
@@ -38,6 +40,10 @@ proto_ncm_setup() {
pdptype=$(echo "$pdptype" | awk '{print toupper($0)}')
[ "$pdptype" = "IP" -o "$pdptype" = "IPV6" -o "$pdptype" = "IPV4V6" ]
|| pdptype="IP"
+ [ "$pdptype" = "IPV4V6" ] && context_type=3
+ [ -z "$context_type" -a "$pdptype" = "IPV6" ] && context_type=2
+ [ -n "$context_type" ] || context_type=1
+
[ -n "$ctl_device" ] && device=$ctl_device
[ -n "$device" ] || {
--
2.38.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[BACKPORT 22.03 v2 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD-25Q128ESIG3
* Wi-Fi:
* MT7613BEN: 5GHz
* MT7603EN: 2.4GHz
* Ethernet: 2x 1GbE
* USB: None - only used internally
* LTE Modem: Quectel EC200T-EU
* UART: 115200 baud
* LEDs:
* 7 blue at the front
* 1 Power
* 2 LAN / WAN
* 1 Status
* 3 RSSI (annotated 4G)
* 1 green at the bottom (4G LED)
* Buttons: 1 reset button
Installation:
* press and hold the reset button while powering on the device
* keep it pressed for ten seconds
* connect to 192.168.10.1 via webbrowser (chromium/chrome works, at
least Firefox 106.0.3 does not)
* upload the sysupgrade image, confirm the checksum, wait 2 minutes
until the device reboots
Revert to stock firmware:
* same as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
Acked-by: Arınç ÜNAL
(cherry picked from commit dce66899bf243d78689afcc693340b891bbf4c2d)
---
.../dts/mt7621_wavlink_ws-wn572hp3-4g.dts | 184 ++
target/linux/ramips/image/mt7621.mk | 17 ++
.../mt7621/base-files/etc/board.d/02_network | 1 +
3 files changed, 202 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
diff --git a/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
new file mode 100644
index 00..60d0708a80
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "wavlink,ws-wn572hp3-4g", "mediatek,mt7621-soc";
+ model = "Wavlink WS-WN572HP3 4G";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ label-mac-device =
+ led-boot = _status_blue;
+ led-failsafe = _status_blue;
+ led-running = _status_blue;
+ led-upgrade = _status_blue;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "Reset Button";
+ gpios = < 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssihigh {
+ label = "blue:rssihigh";
+ gpios = < 4 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "blue:rssimedium";
+ gpios = < 17 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow {
+ label = "blue:rssilow";
+ gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_blue: status_blue {
+ label = "blue:status";
+ gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
+
+ // gpio 15 would be Quectels PWRKEY if used
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "config";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,fit";
+ label = "firmware";
+ reg = <0x5 0xf3>;
+ };
+
+ partition@f0 {
+ label = "vendor";
+ reg = <0xf8 0x8>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay&q
Re: [PATCH] realtek: update GPIO bindings for DGS-1210-10P
On 12/5/22 00:02, Jan-Niklas Burfeind wrote:
On 12/4/22 20:45, Sander Vanheule wrote:
Hi Jan-Niklas,
On Fri, 2022-12-02 at 14:55 +0100, Jan-Niklas Burfeind wrote:
add three missing LEDs
- PoE-Max
- Link/Act
- PoE
Do the latter two LEDs indicate which LED mode is currently selected
(on stock
FW)? Users can do with these LEDs what they like, of course, but it
would be
good to know what the 'default' behaviour is in case somebody ever
wanted to add
a default trigger.
I think they, but am not near the device or its manual; will report back
tomorrow.
The manual confirms, the button is for switching the port-LEDs mode
between poe and link/act.
Regarding the changes, I have one comment below.
add two missing buttons
- mode
- reset
The last was dropped in
commit 61a3d0075b15 ("realtek: update GPIO bindings in the dts files
in dts-
5.10")
Signed-off-by: Jan-Niklas Burfeind
---
Hello everyone,
I just tested the missing GPIO assignments for the DGS-12-10-10P
and verified the three LEDs as well as the reset button are working.
The mode button should work, as its adress is 481 compared to resets
484, but I haven't found a way to test it yet.
You could change the "linux,code" property to and verify
that it
(also) triggers a reboot.
It does trigger a reboot as well, the buttons assingments are both correct.
Will do tomorrow afternoon. Just to be sure, that is not intended to
become part of the patch, but only meant as means for me to verify its
functionality. Please correct me if wrong; otherwise just ignore.
Thanks
Jan-Niklas Burfeind
.../dts-5.10/rtl8382_d-link_dgs-1210-10p.dts | 30 ---
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git
a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
index 7ab37aaa9f..16934ede3b 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
+++ b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
@@ -11,12 +11,34 @@
compatible = "gpio-keys-polled";
poll-interval = <20>;
- /* is this pin 30 on the external RTL8231 ()? */
- /*mode {
+ mode {
+ label = "mode";
+ gpios = < 30 GPIO_ACTIVE_LOW>;
+ linux,code = ;
Strictly speaking, this was intended for turning a (reading) light on
or off.
See Linux kernel commit 5a1bbf21325bd4f2641f6141fb8c47f6095578dd.
You're just
adding back what was dropped in commit 61a3d0075b15, but maybe we
should try to
keep the "turn the lights on/off" semantics for .
I tried to match the other variant (dgs-1210-10mp) [3] if we intend to
change that in this PR, we should probably fix that as well.
The author of that would've been Daniel Groth and you commited.
Either way I'm open for suggested changes, if still wanted.
Let me know, if there anything left, I should add or change in this patch.
The Engenius EW2910P and Panasonic M*eG switch series have similar LED
mode
buttons, which the authors mapped to [1, 2].
See target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
and target/linux/realtek/dts-5.10/rtl8380_engenius_ews2910p.dts
As I'm bikeshedding a bit here, does anyone else on the mailing list
have an
opinion on this?
[1] https://github.com/openwrt/openwrt/pull/9896
[2] https://github.com/openwrt/openwrt/pull/4209
Best,
Sander
[3]
https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10mp-f.dts#L34
___
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: [PATCH] realtek: update GPIO bindings for DGS-1210-10P
On 12/4/22 20:45, Sander Vanheule wrote:
Hi Jan-Niklas,
On Fri, 2022-12-02 at 14:55 +0100, Jan-Niklas Burfeind wrote:
add three missing LEDs
- PoE-Max
- Link/Act
- PoE
Do the latter two LEDs indicate which LED mode is currently selected (on stock
FW)? Users can do with these LEDs what they like, of course, but it would be
good to know what the 'default' behaviour is in case somebody ever wanted to add
a default trigger.
I think they, but am not near the device or its manual; will report back
tomorrow.
Regarding the changes, I have one comment below.
add two missing buttons
- mode
- reset
The last was dropped in
commit 61a3d0075b15 ("realtek: update GPIO bindings in the dts files in dts-
5.10")
Signed-off-by: Jan-Niklas Burfeind
---
Hello everyone,
I just tested the missing GPIO assignments for the DGS-12-10-10P
and verified the three LEDs as well as the reset button are working.
The mode button should work, as its adress is 481 compared to resets
484, but I haven't found a way to test it yet.
You could change the "linux,code" property to and verify that it
(also) triggers a reboot.
Will do tomorrow afternoon. Just to be sure, that is not intended to
become part of the patch, but only meant as means for me to verify its
functionality. Please correct me if wrong; otherwise just ignore.
Thanks
Jan-Niklas Burfeind
.../dts-5.10/rtl8382_d-link_dgs-1210-10p.dts | 30 ---
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
index 7ab37aaa9f..16934ede3b 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
+++ b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
@@ -11,12 +11,34 @@
compatible = "gpio-keys-polled";
poll-interval = <20>;
- /* is this pin 30 on the external RTL8231 ()? */
- /*mode {
+ mode {
+ label = "mode";
+ gpios = < 30 GPIO_ACTIVE_LOW>;
+ linux,code = ;
Strictly speaking, this was intended for turning a (reading) light on or off.
See Linux kernel commit 5a1bbf21325bd4f2641f6141fb8c47f6095578dd. You're just
adding back what was dropped in commit 61a3d0075b15, but maybe we should try to
keep the "turn the lights on/off" semantics for .
I tried to match the other variant (dgs-1210-10mp) [3] if we intend to
change that in this PR, we should probably fix that as well.
The author of that would've been Daniel Groth and you commited.
Either way I'm open for suggested changes, if still wanted.
The Engenius EW2910P and Panasonic M*eG switch series have similar LED mode
buttons, which the authors mapped to [1, 2].
See target/linux/realtek/dts-5.10/rtl83xx_panasonic_mxxeg-pn28xx0k.dtsi
and target/linux/realtek/dts-5.10/rtl8380_engenius_ews2910p.dts
As I'm bikeshedding a bit here, does anyone else on the mailing list have an
opinion on this?
[1] https://github.com/openwrt/openwrt/pull/9896
[2] https://github.com/openwrt/openwrt/pull/4209
Best,
Sander
[3]
https://github.com/openwrt/openwrt/blob/master/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10mp-f.dts#L34
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek: update GPIO bindings for DGS-1210-10P
add three missing LEDs
- PoE-Max
- Link/Act
- PoE
add two missing buttons
- mode
- reset
The last was dropped in
commit 61a3d0075b15 ("realtek: update GPIO bindings in the dts files in
dts-5.10")
Signed-off-by: Jan-Niklas Burfeind
---
Hello everyone,
I just tested the missing GPIO assignments for the DGS-12-10-10P
and verified the three LEDs as well as the reset button are working.
The mode button should work, as its adress is 481 compared to resets
484, but I haven't found a way to test it yet.
Thanks
Jan-Niklas Burfeind
.../dts-5.10/rtl8382_d-link_dgs-1210-10p.dts | 30 ---
1 file changed, 26 insertions(+), 4 deletions(-)
diff --git a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
index 7ab37aaa9f..16934ede3b 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
+++ b/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
@@ -11,12 +11,34 @@
compatible = "gpio-keys-polled";
poll-interval = <20>;
- /* is this pin 30 on the external RTL8231 ()? */
- /*mode {
+ mode {
+ label = "mode";
+ gpios = < 30 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ reset {
label = "reset";
- gpios = < 94 GPIO_ACTIVE_LOW>;
+ gpios = < 33 GPIO_ACTIVE_LOW>;
linux,code = ;
- };*/
+ };
+ };
+
+ leds {
+ link_act {
+ label = "green:link_act";
+ gpios = < 28 GPIO_ACTIVE_LOW>;
+ };
+
+ poe {
+ label = "green:poe";
+ gpios = < 29 GPIO_ACTIVE_LOW>;
+ };
+
+ poe_max {
+ label = "yellow:poe_max";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
};
gpio1: rtl8231-gpio {
--
2.38.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 12/1/22 09:25, Arınç ÜNAL wrote: On 30.11.2022 23:35, Jan-Niklas Burfeind wrote: Wavlink WS-WN572HP3 4G is an 802.11ac dual-band outdoor router with LTE support. Specifications; * Soc: MT7621DAT * RAM: 128MiB * Flash: NOR 16MiB GD-25Q128ESIG3 * Wi-Fi: * MT7613BEN: 5GHz * MT7603EN: 2.4GHz * Ethernet: 2x 1GbE * USB: None - only used internally * LTE Modem: Quectel EC200T-EU * UART: 115200 baud * LEDs: * 7 blue at the front * 1 Power * 2 LAN / WAN * 1 Status * 3 RSSI (annotated 4G) * 1 green at the bottom (4G LED) * Buttons: 1 reset button Installation: * press and hold the reset button while powering on the device * keep it pressed for ten seconds * connect to 192.168.10.1 via webbrowser (chromium/chrome works, at least Firefox 106.0.3 does not) * upload the sysupgrade image, confirm the checksum, wait 2 minutes until the device reboots Revert to stock firmware: * same as installation but use the recovery image for WL-WN572HP3 Signed-off-by: Jan-Niklas Burfeind Acked-by: Arınç ÜNAL Keep this if you send a new version. Arınç I will, thank you; was not sure about whether I should, as I introduced new changes everytime I updated it. Jan-Niklas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 1/2] comgt-ncm: add support for quectel modem EC200T-EU
context_type is an integer mapping of pdptype:
1: IPV4
2: IPV6
3: IPV4V6
Signed-off-by: Jan-Niklas Burfeind
---
package/network/utils/comgt/files/ncm.json | 16
package/network/utils/comgt/files/ncm.sh | 6 ++
2 files changed, 22 insertions(+)
diff --git a/package/network/utils/comgt/files/ncm.json
b/package/network/utils/comgt/files/ncm.json
index b6ad717529..7d9a38fe36 100644
--- a/package/network/utils/comgt/files/ncm.json
+++ b/package/network/utils/comgt/files/ncm.json
@@ -75,6 +75,22 @@
"finalize": "AT+CGDATA=\\\"M-MBIM\\\",${profile},1",
"disconnect": "AT+CGACT=0,${profile}"
},
+ "quectel": {
+ "initialize": [
+ "AT+CFUN=1"
+ ],
+ "configure": [
+
"at+qicsgp=${profile},${context_type},\\\"${apn}\\\",\\\"${username}\\\",\\\"${password}\\\",0"
+ ],
+ "modes": {
+ "lte": "AT+QCFG=\\\"nwscanmode\\\",3",
+ "umts": "AT+QCFG=\\\"nwscanmode\\\",2",
+ "gsm": "AT+QCFG=\\\"nwscanmode\\\",1",
+ "auto": "AT+QCFG=\\\"nwscanmode\\\",0"
+ },
+ "connect": "AT+qnetdevctl=1,${profile},1",
+ "disconnect": "AT+qnetdevctl=0,${profile},0"
+ },
"\"zte": {
"initialize": [
"AT+CFUN=1"
diff --git a/package/network/utils/comgt/files/ncm.sh
b/package/network/utils/comgt/files/ncm.sh
index a2c913ea1d..2f36697487 100644
--- a/package/network/utils/comgt/files/ncm.sh
+++ b/package/network/utils/comgt/files/ncm.sh
@@ -31,6 +31,8 @@ proto_ncm_setup() {
local device ifname apn auth username password pincode delay mode
pdptype profile $PROTO_DEFAULT_OPTIONS
json_get_vars device ifname apn auth username password pincode delay
mode pdptype profile $PROTO_DEFAULT_OPTIONS
+ local context_type
+
[ "$metric" = "" ] && metric="0"
[ -n "$profile" ] || profile=1
@@ -38,6 +40,10 @@ proto_ncm_setup() {
pdptype=$(echo "$pdptype" | awk '{print toupper($0)}')
[ "$pdptype" = "IP" -o "$pdptype" = "IPV6" -o "$pdptype" = "IPV4V6" ]
|| pdptype="IP"
+ [ "$pdptype" = "IPV4V6" ] && context_type=3
+ [ -z "$context_type" -a "$pdptype" = "IPV6" ] && context_type=2
+ [ -n "$context_type" ] || context_type=1
+
[ -n "$ctl_device" ] && device=$ctl_device
[ -n "$device" ] || {
--
2.38.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD-25Q128ESIG3
* Wi-Fi:
* MT7613BEN: 5GHz
* MT7603EN: 2.4GHz
* Ethernet: 2x 1GbE
* USB: None - only used internally
* LTE Modem: Quectel EC200T-EU
* UART: 115200 baud
* LEDs:
* 7 blue at the front
* 1 Power
* 2 LAN / WAN
* 1 Status
* 3 RSSI (annotated 4G)
* 1 green at the bottom (4G LED)
* Buttons: 1 reset button
Installation:
* press and hold the reset button while powering on the device
* keep it pressed for ten seconds
* connect to 192.168.10.1 via webbrowser (chromium/chrome works, at
least Firefox 106.0.3 does not)
* upload the sysupgrade image, confirm the checksum, wait 2 minutes
until the device reboots
Revert to stock firmware:
* same as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
---
Huge thanks to Znevna, he suggested using gpio adresses modulo banksize.
No clue where the system get's the info that bank three is the
"LED-gpio-bank" but it works.
Other than that I added the missing label-mac-alias to the 5GHz wifi
device.
Thanks again, I think now I'm okay with this patch.
Have a nice evening
Jan-Niklas
.../dts/mt7621_wavlink_ws-wn572hp3-4g.dts | 184 ++
target/linux/ramips/image/mt7621.mk | 17 ++
.../mt7621/base-files/etc/board.d/02_network | 1 +
3 files changed, 202 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
diff --git a/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
new file mode 100644
index 00..60d0708a80
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
@@ -0,0 +1,184 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "wavlink,ws-wn572hp3-4g", "mediatek,mt7621-soc";
+ model = "Wavlink WS-WN572HP3 4G";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ label-mac-device =
+ led-boot = _status_blue;
+ led-failsafe = _status_blue;
+ led-running = _status_blue;
+ led-upgrade = _status_blue;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "Reset Button";
+ gpios = < 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssihigh {
+ label = "blue:rssihigh";
+ gpios = < 4 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "blue:rssimedium";
+ gpios = < 17 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow {
+ label = "blue:rssilow";
+ gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_blue: status_blue {
+ label = "blue:status";
+ gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
+
+ // gpio 15 would be Quectels PWRKEY if used
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "config";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,fit";
+ label = "firmware";
+ reg = <0x5 0xf3>;
+ };
+
+ partiti
Re: [PATCH v3 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 11/30/22 19:54, Jan-Niklas Burfeind wrote: On 11/30/22 18:27, Arınç ÜNAL wrote: On 30.11.2022 19:44, Jan-Niklas Burfeind wrote: Wavlink WS-WN572HP3 4G is an 802.11ac dual-band outdoor router with LTE support. Specifications; * Soc: MT7621DAT * RAM: 128MiB * Flash: NOR 16MiB GD-25Q128ESIG3 * Wi-Fi: * MT7613BEN: 5GHz * MT7603EN: 2.4GHz * Ethernet: 2x 1GbE * USB: None - only used internally * LTE Modem: Quectel EC200T-EU * UART: 115200 baud * LEDs: * 7 blue at the front * 1 Power * 2 LAN / WAN * 1 Status * 3 RSSI (annotated 4G) * 1 green at the bottom (4G LED) * Buttons: 1 reset button Installation: * press and hold the reset button while powering on the device * keep it pressed for ten seconds * connect to 192.168.10.1 via webbrowser (chromium/chrome works, at least Firefox 106.0.3 does not) * upload the sysupgrade image, confirm the checksum, wait 2 minutes until the device reboots Revert to stock firmware: * same as installation but use the recovery image for WL-WN572HP3 Signed-off-by: Jan-Niklas Burfeind I assume everything works fine now? Acked-by: Arınç ÜNAL Arınç The LAN-port works fine, thanks for that. S-2 made me aware of my weird LED situtation though. Im certain the gpios match the LEDs correctly, but the LEDsare always on, regardless of trigger being "None", "heartbeat" or else. I can set them manually (using the offset 416) like this: `echo "1" > /sys/class/gpio/gpio496/value` in order to turn blue:rssilow (GPIO 80) >off<. I'm not sure what I'm doing wrong there; might be missing assignments in board.d/01_leds or may active low was wrong. I'm not sure and have to try, sorry for the holdup. Thanks for the supoort though Jan-Niklas Maybe using the rssi LEDs at all is just wrong though, as they are marked "4G" and showed LTE rssi in the stock firmware. In that case I'd just be wondering why "status" and the three "rssi" LEDs would be on on the trigger "none". ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 11/30/22 18:27, Arınç ÜNAL wrote: On 30.11.2022 19:44, Jan-Niklas Burfeind wrote: Wavlink WS-WN572HP3 4G is an 802.11ac dual-band outdoor router with LTE support. Specifications; * Soc: MT7621DAT * RAM: 128MiB * Flash: NOR 16MiB GD-25Q128ESIG3 * Wi-Fi: * MT7613BEN: 5GHz * MT7603EN: 2.4GHz * Ethernet: 2x 1GbE * USB: None - only used internally * LTE Modem: Quectel EC200T-EU * UART: 115200 baud * LEDs: * 7 blue at the front * 1 Power * 2 LAN / WAN * 1 Status * 3 RSSI (annotated 4G) * 1 green at the bottom (4G LED) * Buttons: 1 reset button Installation: * press and hold the reset button while powering on the device * keep it pressed for ten seconds * connect to 192.168.10.1 via webbrowser (chromium/chrome works, at least Firefox 106.0.3 does not) * upload the sysupgrade image, confirm the checksum, wait 2 minutes until the device reboots Revert to stock firmware: * same as installation but use the recovery image for WL-WN572HP3 Signed-off-by: Jan-Niklas Burfeind I assume everything works fine now? Acked-by: Arınç ÜNAL Arınç The LAN-port works fine, thanks for that. S-2 made me aware of my weird LED situtation though. Im certain the gpios match the LEDs correctly, but the LEDsare always on, regardless of trigger being "None", "heartbeat" or else. I can set them manually (using the offset 416) like this: `echo "1" > /sys/class/gpio/gpio496/value` in order to turn blue:rssilow (GPIO 80) >off<. I'm not sure what I'm doing wrong there; might be missing assignments in board.d/01_leds or may active low was wrong. I'm not sure and have to try, sorry for the holdup. Thanks for the supoort though Jan-Niklas ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
s-2 made me aware of an LED rssi issue; this is not ready to merge yet.
On 11/30/22 17:44, Jan-Niklas Burfeind wrote:
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD-25Q128ESIG3
* Wi-Fi:
* MT7613BEN: 5GHz
* MT7603EN: 2.4GHz
* Ethernet: 2x 1GbE
* USB: None - only used internally
* LTE Modem: Quectel EC200T-EU
* UART: 115200 baud
* LEDs:
* 7 blue at the front
* 1 Power
* 2 LAN / WAN
* 1 Status
* 3 RSSI (annotated 4G)
* 1 green at the bottom (4G LED)
* Buttons: 1 reset button
Installation:
* press and hold the reset button while powering on the device
* keep it pressed for ten seconds
* connect to 192.168.10.1 via webbrowser (chromium/chrome works, at
least Firefox 106.0.3 does not)
* upload the sysupgrade image, confirm the checksum, wait 2 minutes
until the device reboots
Revert to stock firmware:
* same as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
---
.../dts/mt7621_wavlink_ws-wn572hp3-4g.dts | 183 ++
target/linux/ramips/image/mt7621.mk | 17 ++
.../mt7621/base-files/etc/board.d/02_network | 1 +
3 files changed, 201 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
diff --git a/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
new file mode 100644
index 00..a9b6b7a0df
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "wavlink,ws-wn572hp3-4g", "mediatek,mt7621-soc";
+ model = "Wavlink WS-WN572HP3 4G";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ led-boot = _status_blue;
+ led-failsafe = _status_blue;
+ led-running = _status_blue;
+ led-upgrade = _status_blue;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "Reset Button";
+ gpios = < 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssihigh {
+ label = "blue:rssihigh";
+ gpios = < 68 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "blue:rssimedium";
+ gpios = < 81 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow {
+ label = "blue:rssilow";
+ gpios = < 80 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_blue: status_blue {
+ label = "blue:status";
+ gpios = < 67 GPIO_ACTIVE_LOW>;
+ };
+
+ // gpio 79 would be Quectels PWRKEY if used
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "config";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,fit";
+ label = "firmware";
+ reg = <0x5 0xf3>;
+ };
+
+ partition@f0 {
+ label = "vendor";
+ reg = <0xf8 0x8>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ sta
[PATCH v3 1/2] comgt-ncm: add support for quectel modem EC200T-EU
context_type is an integer mapping of pdptype:
1: IPV4
2: IPV6
3: IPV4V6
Signed-off-by: Jan-Niklas Burfeind
---
package/network/utils/comgt/files/ncm.json | 16
package/network/utils/comgt/files/ncm.sh | 6 ++
2 files changed, 22 insertions(+)
diff --git a/package/network/utils/comgt/files/ncm.json
b/package/network/utils/comgt/files/ncm.json
index b6ad717529..7d9a38fe36 100644
--- a/package/network/utils/comgt/files/ncm.json
+++ b/package/network/utils/comgt/files/ncm.json
@@ -75,6 +75,22 @@
"finalize": "AT+CGDATA=\\\"M-MBIM\\\",${profile},1",
"disconnect": "AT+CGACT=0,${profile}"
},
+ "quectel": {
+ "initialize": [
+ "AT+CFUN=1"
+ ],
+ "configure": [
+
"at+qicsgp=${profile},${context_type},\\\"${apn}\\\",\\\"${username}\\\",\\\"${password}\\\",0"
+ ],
+ "modes": {
+ "lte": "AT+QCFG=\\\"nwscanmode\\\",3",
+ "umts": "AT+QCFG=\\\"nwscanmode\\\",2",
+ "gsm": "AT+QCFG=\\\"nwscanmode\\\",1",
+ "auto": "AT+QCFG=\\\"nwscanmode\\\",0"
+ },
+ "connect": "AT+qnetdevctl=1,${profile},1",
+ "disconnect": "AT+qnetdevctl=0,${profile},0"
+ },
"\"zte": {
"initialize": [
"AT+CFUN=1"
diff --git a/package/network/utils/comgt/files/ncm.sh
b/package/network/utils/comgt/files/ncm.sh
index a2c913ea1d..2f36697487 100644
--- a/package/network/utils/comgt/files/ncm.sh
+++ b/package/network/utils/comgt/files/ncm.sh
@@ -31,6 +31,8 @@ proto_ncm_setup() {
local device ifname apn auth username password pincode delay mode
pdptype profile $PROTO_DEFAULT_OPTIONS
json_get_vars device ifname apn auth username password pincode delay
mode pdptype profile $PROTO_DEFAULT_OPTIONS
+ local context_type
+
[ "$metric" = "" ] && metric="0"
[ -n "$profile" ] || profile=1
@@ -38,6 +40,10 @@ proto_ncm_setup() {
pdptype=$(echo "$pdptype" | awk '{print toupper($0)}')
[ "$pdptype" = "IP" -o "$pdptype" = "IPV6" -o "$pdptype" = "IPV4V6" ]
|| pdptype="IP"
+ [ "$pdptype" = "IPV4V6" ] && context_type=3
+ [ -z "$context_type" -a "$pdptype" = "IPV6" ] && context_type=2
+ [ -n "$context_type" ] || context_type=1
+
[ -n "$ctl_device" ] && device=$ctl_device
[ -n "$device" ] || {
--
2.38.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD-25Q128ESIG3
* Wi-Fi:
* MT7613BEN: 5GHz
* MT7603EN: 2.4GHz
* Ethernet: 2x 1GbE
* USB: None - only used internally
* LTE Modem: Quectel EC200T-EU
* UART: 115200 baud
* LEDs:
* 7 blue at the front
* 1 Power
* 2 LAN / WAN
* 1 Status
* 3 RSSI (annotated 4G)
* 1 green at the bottom (4G LED)
* Buttons: 1 reset button
Installation:
* press and hold the reset button while powering on the device
* keep it pressed for ten seconds
* connect to 192.168.10.1 via webbrowser (chromium/chrome works, at
least Firefox 106.0.3 does not)
* upload the sysupgrade image, confirm the checksum, wait 2 minutes
until the device reboots
Revert to stock firmware:
* same as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
---
.../dts/mt7621_wavlink_ws-wn572hp3-4g.dts | 183 ++
target/linux/ramips/image/mt7621.mk | 17 ++
.../mt7621/base-files/etc/board.d/02_network | 1 +
3 files changed, 201 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
diff --git a/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
new file mode 100644
index 00..a9b6b7a0df
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "wavlink,ws-wn572hp3-4g", "mediatek,mt7621-soc";
+ model = "Wavlink WS-WN572HP3 4G";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ led-boot = _status_blue;
+ led-failsafe = _status_blue;
+ led-running = _status_blue;
+ led-upgrade = _status_blue;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "Reset Button";
+ gpios = < 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssihigh {
+ label = "blue:rssihigh";
+ gpios = < 68 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "blue:rssimedium";
+ gpios = < 81 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow {
+ label = "blue:rssilow";
+ gpios = < 80 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_blue: status_blue {
+ label = "blue:status";
+ gpios = < 67 GPIO_ACTIVE_LOW>;
+ };
+
+ // gpio 79 would be Quectels PWRKEY if used
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "config";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,fit";
+ label = "firmware";
+ reg = <0x5 0xf3>;
+ };
+
+ partition@f0 {
+ label = "vendor";
+ reg = <0xf8 0x8>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ wifi0: mt76@0,0 {
+ compatible = "mediatek,mt76";
+ reg = <0
Re: [PATCH v2 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
On 11/30/22 10:41, Arınç ÜNAL wrote: On 30.11.2022 12:33, Jan-Niklas Burfeind wrote: Wavlink WS-WN572HP3 4G is an 802.11ac dual-band outdoor router with LTE support. Specifications; * Soc: MT7621DAT * RAM: 128MiB * Flash: NOR 16MiB GD-25Q128ESIG3 * Wi-Fi: * MT7613BEN: 5GHz * MT7603EN: 2.4GHz * Ethernet: 2x 1GbE * USB: None - only used internally * LTE Modem: Quectel EC200T-EU * UART: 115200 baud * LEDs: * 7 blue at the front * 1 Power * 2 LAN / WAN * 1 Status * 3 RSSI (annotated 4G) * 1 green at the bottom (4G LED) * Buttons: 1 reset button Installation: * press and hold the reset button while powering on the device * keep it pressed for ten seconds * connect to 192.168.10.1 via webbrowser (chromium/chrome works, at least Firefox 106.0.3 does not) * upload the sysupgrade image, confirm the checksum, wait 2 minutes until the device reboots Revert to stock firmware: * same as installation but use the recovery image for WL-WN572HP3 Signed-off-by: Jan-Niklas Burfeind Acked-by: Arınç ÜNAL Arınç Something must've gone wrong. Connecting the lan port does not trigger a log message anymore. WAN still does: 982.295568] mtk_soc_eth 1e10.ethernet wan: Link is Up - 1Gbps/Full - flow control rx/tx Arınç: Could you have a look at the diff, whether I deleted the node in the way you intended? Not sure what I'm missing now; worked before. Thanks, Jan-Niklas Burfeind ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD-25Q128ESIG3
* Wi-Fi:
* MT7613BEN: 5GHz
* MT7603EN: 2.4GHz
* Ethernet: 2x 1GbE
* USB: None - only used internally
* LTE Modem: Quectel EC200T-EU
* UART: 115200 baud
* LEDs:
* 7 blue at the front
* 1 Power
* 2 LAN / WAN
* 1 Status
* 3 RSSI (annotated 4G)
* 1 green at the bottom (4G LED)
* Buttons: 1 reset button
Installation:
* press and hold the reset button while powering on the device
* keep it pressed for ten seconds
* connect to 192.168.10.1 via webbrowser (chromium/chrome works, at
least Firefox 106.0.3 does not)
* upload the sysupgrade image, confirm the checksum, wait 2 minutes
until the device reboots
Revert to stock firmware:
* same as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
---
.../dts/mt7621_wavlink_ws-wn572hp3-4g.dts | 183 ++
target/linux/ramips/image/mt7621.mk | 17 ++
.../mt7621/base-files/etc/board.d/02_network | 1 +
3 files changed, 201 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
diff --git a/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
new file mode 100644
index 00..a9b6b7a0df
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
@@ -0,0 +1,183 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "wavlink,ws-wn572hp3-4g", "mediatek,mt7621-soc";
+ model = "Wavlink WS-WN572HP3 4G";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ led-boot = _status_blue;
+ led-failsafe = _status_blue;
+ led-running = _status_blue;
+ led-upgrade = _status_blue;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "Reset Button";
+ gpios = < 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssihigh {
+ label = "blue:rssihigh";
+ gpios = < 68 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "blue:rssimedium";
+ gpios = < 81 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow {
+ label = "blue:rssilow";
+ gpios = < 80 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_blue: status_blue {
+ label = "blue:status";
+ gpios = < 67 GPIO_ACTIVE_LOW>;
+ };
+
+ // gpio 79 would be Quectels PWRKEY if used
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "config";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,fit";
+ label = "firmware";
+ reg = <0x5 0xf3>;
+ };
+
+ partition@f0 {
+ label = "vendor";
+ reg = <0xf8 0x8>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ wifi0: mt76@0,0 {
+ compatible = "mediatek,mt76";
+ reg = <0
[PATCH v2 1/2] comgt-ncm: add support for quectel modem EC200T-EU
context_type is an integer mapping of pdptype:
1: IPV4
2: IPV6
3: IPV4V6
Signed-off-by: Jan-Niklas Burfeind
---
package/network/utils/comgt/files/ncm.json | 16
package/network/utils/comgt/files/ncm.sh | 6 ++
2 files changed, 22 insertions(+)
diff --git a/package/network/utils/comgt/files/ncm.json
b/package/network/utils/comgt/files/ncm.json
index b6ad717529..7d9a38fe36 100644
--- a/package/network/utils/comgt/files/ncm.json
+++ b/package/network/utils/comgt/files/ncm.json
@@ -75,6 +75,22 @@
"finalize": "AT+CGDATA=\\\"M-MBIM\\\",${profile},1",
"disconnect": "AT+CGACT=0,${profile}"
},
+ "quectel": {
+ "initialize": [
+ "AT+CFUN=1"
+ ],
+ "configure": [
+
"at+qicsgp=${profile},${context_type},\\\"${apn}\\\",\\\"${username}\\\",\\\"${password}\\\",0"
+ ],
+ "modes": {
+ "lte": "AT+QCFG=\\\"nwscanmode\\\",3",
+ "umts": "AT+QCFG=\\\"nwscanmode\\\",2",
+ "gsm": "AT+QCFG=\\\"nwscanmode\\\",1",
+ "auto": "AT+QCFG=\\\"nwscanmode\\\",0"
+ },
+ "connect": "AT+qnetdevctl=1,${profile},1",
+ "disconnect": "AT+qnetdevctl=0,${profile},0"
+ },
"\"zte": {
"initialize": [
"AT+CFUN=1"
diff --git a/package/network/utils/comgt/files/ncm.sh
b/package/network/utils/comgt/files/ncm.sh
index a2c913ea1d..2f36697487 100644
--- a/package/network/utils/comgt/files/ncm.sh
+++ b/package/network/utils/comgt/files/ncm.sh
@@ -31,6 +31,8 @@ proto_ncm_setup() {
local device ifname apn auth username password pincode delay mode
pdptype profile $PROTO_DEFAULT_OPTIONS
json_get_vars device ifname apn auth username password pincode delay
mode pdptype profile $PROTO_DEFAULT_OPTIONS
+ local context_type
+
[ "$metric" = "" ] && metric="0"
[ -n "$profile" ] || profile=1
@@ -38,6 +40,10 @@ proto_ncm_setup() {
pdptype=$(echo "$pdptype" | awk '{print toupper($0)}')
[ "$pdptype" = "IP" -o "$pdptype" = "IPV6" -o "$pdptype" = "IPV4V6" ]
|| pdptype="IP"
+ [ "$pdptype" = "IPV4V6" ] && context_type=3
+ [ -z "$context_type" -a "$pdptype" = "IPV6" ] && context_type=2
+ [ -n "$context_type" ] || context_type=1
+
[ -n "$ctl_device" ] && device=$ctl_device
[ -n "$device" ] || {
--
2.38.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] ramips: add support for Wavlink WS-WN572HP3 4G
Wavlink WS-WN572HP3 4G is an 802.11ac
dual-band outdoor router with LTE support.
Specifications;
* Soc: MT7621DAT
* RAM: 128MiB
* Flash: NOR 16MiB GD-25Q128ESIG3
* Wi-Fi:
* MT7613BEN: 5GHz
* MT7603EN: 2.4GHz
* Ethernet: 2x 1GbE
* USB: None - only used internally
* LTE Modem: Quectel EC200T-EU
* UART: 115200 baud
* LEDs:
* 7 blue at the front
* 1 Power
* 2 LAN / WAN
* 1 Status
* 3 RSSI (annotated 4G)
* 1 green at the bottom (4G LED)
* Buttons: 1 reset button
Installation:
* press and hold the reset button while powering on the device
* keep it pressed for ten seconds
* connect to 192.168.10.1 via webbrowser (chromium/chrome works, at
least Firefox 106.0.3 does not)
* upload the sysupgrade image, confirm the checksum, wait 2 minutes
until the device reboots
Revert to stock firmware:
* same as installation but use the recovery image for WL-WN572HP3
Signed-off-by: Jan-Niklas Burfeind
---
.../dts/mt7621_wavlink_ws-wn572hp3-4g.dts | 186 ++
target/linux/ramips/image/mt7621.mk | 17 ++
2 files changed, 203 insertions(+)
create mode 100644 target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
diff --git a/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
new file mode 100644
index 00..89f7bb218d
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_wavlink_ws-wn572hp3-4g.dts
@@ -0,0 +1,186 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "wavlink,ws-wn572hp3-4g", "mediatek,mt7621-soc";
+ model = "Wavlink WS-WN572HP3 4G";
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ aliases {
+ led-boot = _status_blue;
+ led-failsafe = _status_blue;
+ led-running = _status_blue;
+ led-upgrade = _status_blue;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "Reset Button";
+ gpios = < 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssihigh {
+ label = "blue:rssihigh";
+ gpios = < 68 GPIO_ACTIVE_LOW>;
+ };
+
+ rssimedium {
+ label = "blue:rssimedium";
+ gpios = < 81 GPIO_ACTIVE_LOW>;
+ };
+
+ rssilow {
+ label = "blue:rssilow";
+ gpios = < 80 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_blue: status_blue {
+ label = "blue:status";
+ gpios = < 67 GPIO_ACTIVE_LOW>;
+ };
+
+ // gpio 79 would be Quectels PWRKEY if used
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "config";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = "factory";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition@5 {
+ compatible = "denx,fit";
+ label = "firmware";
+ reg = <0x5 0xf3>;
+ };
+
+ partition@f0 {
+ label = "vendor";
+ reg = <0xf8 0x8>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ wifi0: mt76@0,0 {
+ compatible = "mediatek,mt76";
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eepro
[PATCH 1/2] comgt-ncm: add support for quectel modem EC200T-EU
context_type is an integer mapping of pdptype:
1: IPV4
2: IPV6
3: IPV4V6
Signed-off-by: Jan-Niklas Burfeind
---
package/network/utils/comgt/files/ncm.json | 16
package/network/utils/comgt/files/ncm.sh | 6 ++
2 files changed, 22 insertions(+)
diff --git a/package/network/utils/comgt/files/ncm.json
b/package/network/utils/comgt/files/ncm.json
index b6ad717529..7d9a38fe36 100644
--- a/package/network/utils/comgt/files/ncm.json
+++ b/package/network/utils/comgt/files/ncm.json
@@ -75,6 +75,22 @@
"finalize": "AT+CGDATA=\\\"M-MBIM\\\",${profile},1",
"disconnect": "AT+CGACT=0,${profile}"
},
+ "quectel": {
+ "initialize": [
+ "AT+CFUN=1"
+ ],
+ "configure": [
+
"at+qicsgp=${profile},${context_type},\\\"${apn}\\\",\\\"${username}\\\",\\\"${password}\\\",0"
+ ],
+ "modes": {
+ "lte": "AT+QCFG=\\\"nwscanmode\\\",3",
+ "umts": "AT+QCFG=\\\"nwscanmode\\\",2",
+ "gsm": "AT+QCFG=\\\"nwscanmode\\\",1",
+ "auto": "AT+QCFG=\\\"nwscanmode\\\",0"
+ },
+ "connect": "AT+qnetdevctl=1,${profile},1",
+ "disconnect": "AT+qnetdevctl=0,${profile},0"
+ },
"\"zte": {
"initialize": [
"AT+CFUN=1"
diff --git a/package/network/utils/comgt/files/ncm.sh
b/package/network/utils/comgt/files/ncm.sh
index a2c913ea1d..2f36697487 100644
--- a/package/network/utils/comgt/files/ncm.sh
+++ b/package/network/utils/comgt/files/ncm.sh
@@ -31,6 +31,8 @@ proto_ncm_setup() {
local device ifname apn auth username password pincode delay mode
pdptype profile $PROTO_DEFAULT_OPTIONS
json_get_vars device ifname apn auth username password pincode delay
mode pdptype profile $PROTO_DEFAULT_OPTIONS
+ local context_type
+
[ "$metric" = "" ] && metric="0"
[ -n "$profile" ] || profile=1
@@ -38,6 +40,10 @@ proto_ncm_setup() {
pdptype=$(echo "$pdptype" | awk '{print toupper($0)}')
[ "$pdptype" = "IP" -o "$pdptype" = "IPV6" -o "$pdptype" = "IPV4V6" ]
|| pdptype="IP"
+ [ "$pdptype" = "IPV4V6" ] && context_type=3
+ [ -z "$context_type" -a "$pdptype" = "IPV6" ] && context_type=2
+ [ -n "$context_type" ] || context_type=1
+
[ -n "$ctl_device" ] && device=$ctl_device
[ -n "$device" ] || {
--
2.38.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek: fix dell typo
should be add/delete or abbreviated add/del
Signed-off-by: Jan-Niklas Burfeind
---
.../realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c
b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c
index 2a60f61c95..e86ff9ccdf 100644
--- a/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c
+++ b/target/linux/realtek/files-5.10/drivers/net/dsa/rtl83xx/common.c
@@ -1401,7 +1401,7 @@ static int rtl83xx_fib_event(struct notifier_block *this,
unsigned long event, v
case FIB_EVENT_ENTRY_REPLACE:
case FIB_EVENT_ENTRY_APPEND:
case FIB_EVENT_ENTRY_DEL:
- pr_debug("%s: FIB_ENTRY ADD/DELL, event %ld\n", __func__,
event);
+ pr_debug("%s: FIB_ENTRY ADD/DEL, event %ld\n", __func__, event);
if (info->family == AF_INET) {
struct fib_entry_notifier_info *fen_info = ptr;
@@ -1420,7 +1420,7 @@ static int rtl83xx_fib_event(struct notifier_block *this,
unsigned long event, v
} else if (info->family == AF_INET6) {
struct fib6_entry_notifier_info *fen6_info = ptr;
- pr_warn("%s: FIB_RULE ADD/DELL for IPv6 not
supported\n", __func__);
+ pr_warn("%s: FIB_RULE ADD/DEL for IPv6 not
supported\n", __func__);
kfree(fib_work);
return NOTIFY_DONE;
}
@@ -1428,7 +1428,7 @@ static int rtl83xx_fib_event(struct notifier_block *this,
unsigned long event, v
case FIB_EVENT_RULE_ADD:
case FIB_EVENT_RULE_DEL:
- pr_debug("%s: FIB_RULE ADD/DELL, event: %ld\n", __func__,
event);
+ pr_debug("%s: FIB_RULE ADD/DEL, event: %ld\n", __func__, event);
memcpy(_work->fr_info, ptr, sizeof(fib_work->fr_info));
fib_rule_get(fib_work->fr_info.rule);
break;
--
2.38.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] ath79: rename references of UniFi to UniFi AP
extract the compatible and model to make room for other variants
follow-up of
commit dc23df8a8ca7 ("ath79: change Ubiquiti UniFi AP model name to include
"AP"")
Signed-off-by: Jan-Niklas Burfeind
---
target/linux/ath79/dts/ar7241_ubnt_unifi-ap.dts | 8
.../{ar7241_ubnt_unifi.dts => ar7241_ubnt_unifi-ap.dtsi} | 3 ---
target/linux/ath79/image/generic-ubnt.mk | 6 +++---
3 files changed, 11 insertions(+), 6 deletions(-)
create mode 100644 target/linux/ath79/dts/ar7241_ubnt_unifi-ap.dts
rename target/linux/ath79/dts/{ar7241_ubnt_unifi.dts =>
ar7241_ubnt_unifi-ap.dtsi} (95%)
diff --git a/target/linux/ath79/dts/ar7241_ubnt_unifi-ap.dts
b/target/linux/ath79/dts/ar7241_ubnt_unifi-ap.dts
new file mode 100644
index 00..e9f57c0bbe
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_ubnt_unifi-ap.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar7241_ubnt_unifi-ap.dtsi"
+
+/ {
+ compatible = "ubnt,unifi", "qca,ar7241";
+ model = "Ubiquiti UniFi AP";
+};
diff --git a/target/linux/ath79/dts/ar7241_ubnt_unifi.dts
b/target/linux/ath79/dts/ar7241_ubnt_unifi-ap.dtsi
similarity index 95%
rename from target/linux/ath79/dts/ar7241_ubnt_unifi.dts
rename to target/linux/ath79/dts/ar7241_ubnt_unifi-ap.dtsi
index 3c50e89d01..c70a1c02db 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_unifi.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_unifi-ap.dtsi
@@ -3,9 +3,6 @@
#include "ar7241_ubnt_unifi.dtsi"
/ {
- compatible = "ubnt,unifi", "qca,ar7241";
- model = "Ubiquiti UniFi AP";
-
aliases {
led-boot = _dome_green;
led-failsafe = _dome_green;
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 69f7a94863..e6a6de48f0 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -210,12 +210,12 @@ define Device/ubnt_routerstation-pro
endef
TARGET_DEVICES += ubnt_routerstation-pro
-define Device/ubnt_unifi
+define Device/ubnt_unifi-ap
$(Device/ubnt-bz)
DEVICE_MODEL := UniFi AP
- SUPPORTED_DEVICES += unifi
+ SUPPORTED_DEVICES += unifi ubnt,unifi
endef
-TARGET_DEVICES += ubnt_unifi
+TARGET_DEVICES += ubnt_unifi-ap
define Device/ubnt_unifiac
DEVICE_VENDOR := Ubiquiti
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] ath79: add variant UniFi AP LR
The hardware difference is the antenna which has a higher gain compared
to the original UniFi AP.
The variant was supported before in ar71xx.
Signed-off-by: Jan-Niklas Burfeind
---
target/linux/ath79/dts/ar7241_ubnt_unifi-ap-lr.dts | 8
target/linux/ath79/image/generic-ubnt.mk | 8
2 files changed, 16 insertions(+)
create mode 100644 target/linux/ath79/dts/ar7241_ubnt_unifi-ap-lr.dts
diff --git a/target/linux/ath79/dts/ar7241_ubnt_unifi-ap-lr.dts
b/target/linux/ath79/dts/ar7241_ubnt_unifi-ap-lr.dts
new file mode 100644
index 00..ab2b455228
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_ubnt_unifi-ap-lr.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar7241_ubnt_unifi-ap.dtsi"
+
+/ {
+ compatible = "ubnt,unifi", "qca,ar7241";
+ model = "Ubiquiti UniFi AP LR";
+};
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index e6a6de48f0..fe158e584b 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -217,6 +217,14 @@ define Device/ubnt_unifi-ap
endef
TARGET_DEVICES += ubnt_unifi-ap
+define Device/ubnt_unifi-ap-lr
+ $(Device/ubnt-bz)
+ DEVICE_MODEL := UniFi AP
+ DEVICE_VARIANT := LR
+ SUPPORTED_DEVICES += unifi ubnt,unifi ubnt,unifi-ap
+endef
+TARGET_DEVICES += ubnt_unifi-ap-lr
+
define Device/ubnt_unifiac
DEVICE_VENDOR := Ubiquiti
SOC := qca9563
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] ath79: add support for Ubiquiti NanoBeam M5
Ubiquiti NanoBeam M5 devices are CPE equipment for customer locations
with one Ethernet port and a 5 GHz 300Mbps wireless interface.
Specificatons:
- Atheros AR9342
- 535 MHz CPU
- 64 MB RAM
- 8 MB Flash
- 1x 10/100 Mbps Ethernet with passive PoE input (24 V)
- 6 LEDs of which four are rssi
- 1 reset button
- UART (4-pin) header on PCB
Notes:
The device was supported by OpenWrt in ar71xx.
Flash instructions (web/ssh/tftp):
Loading the image via ssh vias a stock firmware prior "AirOS 5.6".
Downgrading stock is possible.
* Flashing is possible via AirOS software update page:
The "factory" ROM image is recognized as non-native and then installed
correctly.
AirOS warns to better be familiar with the recovery procedure.
* Flashing can be done via ssh, which is becoming difficult due to legacy
keyexchange methods.
This is an exempary ssh-config:
KexAlgorithms +diffie-hellman-group1-sha1
HostKeyAlgorithms ssh-rsa
PubkeyAcceptedKeyTypes ssh-rsa
User ubnt
The password is ubnt.
Connecting via IPv6 link local worked best for me.
1. scp the factory image to /tmp
2. fwupdate.real -m /tmp/firmware_image_file.bin -d
* Alternatively tftp is possible:
1. Configure PC with static IP 192.168.1.2/24.
2. Enter the rescue mode. Power off the device, push the reset button on
the device (or the PoE) and keep it pressed.
Power on the device, while still pushing the reset button.
3. When all the leds blink at the same time, release the reset button.
4. Upload the firmware image file via TFTP:
tftp 192.168.1.20
tftp> bin
tftp> trace
Packet tracing on.
tftp> put firmware_image.bin
Signed-off-by: Jan-Niklas Burfeind
---
Sorry for messing up the versioning earlier,
this is v3 not v2.
.../ath79/dts/ar9342_ubnt_nanobeam-m5.dts | 26 +++
target/linux/ath79/image/generic-ubnt.mk | 8 ++
2 files changed, 34 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
b/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
new file mode 100644
index 00..86a5e3a751
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,nanobeam-m5-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti NanoBeam M5 (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <0x1>;
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ phy-mode = "mii";
+ reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ status = "okay";
+
+ phy-handle = <>;
+};
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 0b613df62b..9de83d42c2 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -255,6 +255,14 @@ define Device/ubnt_nanobeam-ac-xc
endef
TARGET_DEVICES += ubnt_nanobeam-ac-xc
+define Device/ubnt_nanobeam-m5
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := NanoBeam M5
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_nanobeam-m5
+
define Device/ubnt_nanobridge-m
$(Device/ubnt-xm)
SOC := ar7241
--
2.36.0
___
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 NanoBeam M5
The dmesg output you asked for is attached.
Thanks
Jan-Niklas
On 4/21/22 08:34, Jan-Niklas Burfeind wrote:
Ubiquiti NanoBeam M5 devices are CPE equipment for customer locations
with one Ethernet port and a 5 GHz 300Mbps wireless interface.
Specificatons:
- Atheros AR9342
- 535 MHz CPU
- 64 MB RAM
- 8 MB Flash
- 1x 10/100 Mbps Ethernet with passive PoE input (24 V)
- 6 LEDs of which four are rssi
- 1 reset button
- UART (4-pin) header on PCB
Notes:
The device was supported by OpenWrt in ar71xx.
Flash instructions (web/ssh/tftp):
Loading the image via ssh vias a stock firmware prior "AirOS 5.6".
Downgrading stock is possible.
* Flashing is possible via AirOS software update page:
The "factory" ROM image is recognized as non-native and then installed
correctly.
AirOS warns to better be familiar with the recovery procedure.
* Flashing can be done via ssh, which is becoming difficult due to legacy
keyexchange methods.
This is an exempary ssh-config:
KexAlgorithms +diffie-hellman-group1-sha1
HostKeyAlgorithms ssh-rsa
PubkeyAcceptedKeyTypes ssh-rsa
User ubnt
The password is ubnt.
Connecting via IPv6 link local worked best for me.
1. scp the factory image to /tmp
2. fwupdate.real -m /tmp/firmware_image_file.bin -d
* Alternatively tftp is possible:
1. Configure PC with static IP 192.168.1.2/24.
2. Enter the rescue mode. Power off the device, push the reset button on
the device (or the PoE) and keep it pressed.
Power on the device, while still pushing the reset button.
3. When all the leds blink at the same time, release the reset button.
4. Upload the firmware image file via TFTP:
tftp 192.168.1.20
tftp> bin
tftp> trace
Packet tracing on.
tftp> put firmware_image.bin
Signed-off-by: Jan-Niklas Burfeind
---
.../ath79/dts/ar9342_ubnt_nanobeam-m5.dts | 26 +++
target/linux/ath79/image/generic-ubnt.mk | 8 ++
2 files changed, 34 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
b/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
new file mode 100644
index 00..86a5e3a751
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,nanobeam-m5-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti NanoBeam M5 (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <0x1>;
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ phy-mode = "mii";
+ reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ status = "okay";
+
+ phy-handle = <>;
+};
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 0b613df62b..9de83d42c2 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -255,6 +255,14 @@ define Device/ubnt_nanobeam-ac-xc
endef
TARGET_DEVICES += ubnt_nanobeam-ac-xc
+define Device/ubnt_nanobeam-m5
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := NanoBeam M5
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_nanobeam-m5
+
define Device/ubnt_nanobridge-m
$(Device/ubnt-xm)
SOC := ar7241[0.00] Linux version 5.10.111 (aiyion@chromia)
(mips-openwrt-linux-musl-gcc (OpenWrt GCC 11.2.0 r19508+1-0d2d52df69) 11.2.0,
GNU ld (GNU Binutils) 2.37) #0 Wed Apr 20 16:26:56 2022
[0.00] printk: bootconsole [early0] enabled
[0.00] CPU0 revision is: 0001974c (MIPS 74Kc)
[0.00] MIPS: machine is Ubiquiti NanoBeam M5 (XW)
[0.00] SoC: Atheros AR9342 rev 2
[0.00] Initrd not found or empty - disabling initrd
[0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes.
[0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32
bytes
[0.00] Zone ranges:
[0.00] Normal [mem 0x-0x03ff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00] node 0: [mem 0x-0x03ff]
[0.00] Initmem setup node 0 [mem 0x-0x03ff]
[0.00] On node 0 totalpages: 16384
[0.00] Normal zone: 144 pages used for memmap
[0.00] Normal zone: 0 pages reserved
[0.00] Normal zone: 16384 pages, LIFO batch:3
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0
[0.00] Built 1 zonelists, mobility grouping on. Total pages: 16240
[0.00] Kernel command line: console=ttyS0,115200
rootfstype=squashfs,jffs2
[0.00] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes,
linear)
[0.00
[PATCH v2] ath79: add support for Ubiquiti NanoBeam M5
Ubiquiti NanoBeam M5 devices are CPE equipment for customer locations
with one Ethernet port and a 5 GHz 300Mbps wireless interface.
Specificatons:
- Atheros AR9342
- 535 MHz CPU
- 64 MB RAM
- 8 MB Flash
- 1x 10/100 Mbps Ethernet with passive PoE input (24 V)
- 6 LEDs of which four are rssi
- 1 reset button
- UART (4-pin) header on PCB
Notes:
The device was supported by OpenWrt in ar71xx.
Flash instructions (web/ssh/tftp):
Loading the image via ssh vias a stock firmware prior "AirOS 5.6".
Downgrading stock is possible.
* Flashing is possible via AirOS software update page:
The "factory" ROM image is recognized as non-native and then installed
correctly.
AirOS warns to better be familiar with the recovery procedure.
* Flashing can be done via ssh, which is becoming difficult due to legacy
keyexchange methods.
This is an exempary ssh-config:
KexAlgorithms +diffie-hellman-group1-sha1
HostKeyAlgorithms ssh-rsa
PubkeyAcceptedKeyTypes ssh-rsa
User ubnt
The password is ubnt.
Connecting via IPv6 link local worked best for me.
1. scp the factory image to /tmp
2. fwupdate.real -m /tmp/firmware_image_file.bin -d
* Alternatively tftp is possible:
1. Configure PC with static IP 192.168.1.2/24.
2. Enter the rescue mode. Power off the device, push the reset button on
the device (or the PoE) and keep it pressed.
Power on the device, while still pushing the reset button.
3. When all the leds blink at the same time, release the reset button.
4. Upload the firmware image file via TFTP:
tftp 192.168.1.20
tftp> bin
tftp> trace
Packet tracing on.
tftp> put firmware_image.bin
Signed-off-by: Jan-Niklas Burfeind
---
.../ath79/dts/ar9342_ubnt_nanobeam-m5.dts | 26 +++
target/linux/ath79/image/generic-ubnt.mk | 8 ++
2 files changed, 34 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
b/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
new file mode 100644
index 00..86a5e3a751
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_nanobeam-m5.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,nanobeam-m5-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti NanoBeam M5 (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <0x1>;
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ phy-mode = "mii";
+ reset-gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+ {
+ status = "okay";
+
+ phy-handle = <>;
+};
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 0b613df62b..9de83d42c2 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -255,6 +255,14 @@ define Device/ubnt_nanobeam-ac-xc
endef
TARGET_DEVICES += ubnt_nanobeam-ac-xc
+define Device/ubnt_nanobeam-m5
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := NanoBeam M5
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_nanobeam-m5
+
define Device/ubnt_nanobridge-m
$(Device/ubnt-xm)
SOC := ar7241
--
2.35.3
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3 2/2] command-nas: fix json output
Hello Henrik,
I think changing the print_system_info function would require us to
change its signature, wouldn't it?
The function is called with similar parameters from 2g,3g and 4g
pendants. As the calculation and target values differ we'd need to add a
uint for geneneration.
If that info is already extractable from another parameter let me know.
Else I'd implement a modified print function this weekend, that meets
your reccomendation.
Any suggestions on the other two commits?
Jan-Niklas
On 3/16/22 22:00, Henrik Ginstmark wrote:
Hi
You can break down LTE global-cell-id to enodeb_id and cell_id like this:
"intrafrequency_lte_info": {
"tracking_area_code": 14000,
"global_cell_id": 10498829,
=
"enodeb_id": 41011,
"cell_id": 13,
blobmsg_add_u32(,
"enodeb_id",res.data.intrafrequency_lte_info_v2.global_cell_id/256);
blobmsg_add_u32(,
"cell_id",res.data.intrafrequency_lte_info_v2.global_cell_id%256);
Same in nas_get_system_info and for UMTS global_cell_id you can break
down to rnc_id and
cell_id.
blobmsg_add_u32(, "rnc_id",res.data.wcdma_system_info_v2.cid/65536);
blobmsg_add_u32(, "cell_id",res.data.wcdma_system_info_v2.cid%65536);
Henrik
Den mån 14 mars 2022 kl 17:00 skrev Jan-Niklas Burfeind :
Hey everyone,
I attached the current output of my patched uqmi.
Please let me know if you think the arrays should be named differently
or if you spot an error.
Thanks and have a nice day
Aiyion
On 3/8/22 16:01, Jan-Niklas Burfeind wrote:
Output the cells from --get-cell-location-info in an array "cells",
"geran" entries as an array called alike,
and wrap output for different "frequencies" as such.
Reported-by: Cezary Jackiewicz
Suggested-by: Oskari Lemmelä
Signed-off-by: Jan-Niklas Burfeind
---
Hey Oskari and Cezary,
Please have a thorough look at this, as I do not have the matching
equipment at hand to test all cases.
Let me know if you rather would see `frequencies` become `channels`
and if the `geran`-array does make sense.
I just compiled this series without errors and will have a look at the
LTE-related json-outputs.
Thanks for your time
Jan-Niklas
commands-nas.c | 46 +-
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 275c53f..b99767f 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -708,7 +708,7 @@ static void
cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_nas_get_cell_location_info_response res;
- void *c, *t, *cell, *freq;
+ void *c, *t, *cell, *cells, *freq, *frequencies, *geran;
int i, j;
qmi_parse_nas_get_cell_location_info_response(msg, );
@@ -724,6 +724,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.umts_info_v2.primary_scrambling_code);
blobmsg_add_u32(, "rscp", res.data.umts_info_v2.rscp);
blobmsg_add_u32(, "ecio", res.data.umts_info_v2.ecio);
+ cells = blobmsg_open_array(, "cells");
for (j = 0; j < res.data.umts_info_v2.cell_n; j++) {
cell = blobmsg_open_table(, NULL);
blobmsg_add_u32(, "channel",
@@ -734,6 +735,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "ecio",
res.data.umts_info_v2.cell[j].ecio);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
+ geran = blobmsg_open_array(, "geran");
for (j = 0; j < res.data.umts_info_v2.neighboring_geran_n; j++) {
cell = blobmsg_open_table(, "neighboring_geran");
blobmsg_add_u32(, "channel",
@@ -746,6 +749,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.umts_info_v2.neighboring_geran[j].rssi);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, geran);
blobmsg_close_table(, c);
}
if (res.set.intrafrequency_lte_info_v2) {
@@ -769,6 +773,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "s_intra_search_threshold",
res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n; i++)
{
cell = b
Re: [PATCH v3 2/2] command-nas: fix json output
Hey everyone,
I attached the current output of my patched uqmi.
Please let me know if you think the arrays should be named differently
or if you spot an error.
Thanks and have a nice day
Aiyion
On 3/8/22 16:01, Jan-Niklas Burfeind wrote:
Output the cells from --get-cell-location-info in an array "cells",
"geran" entries as an array called alike,
and wrap output for different "frequencies" as such.
Reported-by: Cezary Jackiewicz
Suggested-by: Oskari Lemmelä
Signed-off-by: Jan-Niklas Burfeind
---
Hey Oskari and Cezary,
Please have a thorough look at this, as I do not have the matching
equipment at hand to test all cases.
Let me know if you rather would see `frequencies` become `channels`
and if the `geran`-array does make sense.
I just compiled this series without errors and will have a look at the
LTE-related json-outputs.
Thanks for your time
Jan-Niklas
commands-nas.c | 46 +-
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 275c53f..b99767f 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -708,7 +708,7 @@ static void
cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_nas_get_cell_location_info_response res;
- void *c, *t, *cell, *freq;
+ void *c, *t, *cell, *cells, *freq, *frequencies, *geran;
int i, j;
qmi_parse_nas_get_cell_location_info_response(msg, );
@@ -724,6 +724,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.umts_info_v2.primary_scrambling_code);
blobmsg_add_u32(, "rscp", res.data.umts_info_v2.rscp);
blobmsg_add_u32(, "ecio", res.data.umts_info_v2.ecio);
+ cells = blobmsg_open_array(, "cells");
for (j = 0; j < res.data.umts_info_v2.cell_n; j++) {
cell = blobmsg_open_table(, NULL);
blobmsg_add_u32(, "channel",
@@ -734,6 +735,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "ecio",
res.data.umts_info_v2.cell[j].ecio);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
+ geran = blobmsg_open_array(, "geran");
for (j = 0; j < res.data.umts_info_v2.neighboring_geran_n; j++)
{
cell = blobmsg_open_table(, "neighboring_geran");
blobmsg_add_u32(, "channel",
@@ -746,6 +749,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.umts_info_v2.neighboring_geran[j].rssi);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, geran);
blobmsg_close_table(, c);
}
if (res.set.intrafrequency_lte_info_v2) {
@@ -769,6 +773,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "s_intra_search_threshold",
res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
@@ -780,11 +785,14 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, c);
}
if (res.set.interfrequency_lte_info) {
- if (res.data.interfrequency_lte_info.frequency_n > 0)
+ if (res.data.interfrequency_lte_info.frequency_n > 0) {
c = blobmsg_open_table(,
"interfrequency_lte_info");
+ frequencies = blobmsg_open_array(,
"frequencies");
+ }
for (i = 0; i < res.data.interfrequency_lte_info.frequency_n;
i++) {
freq = blobmsg_open_table(, NULL);
blobmsg_add_u32(, "channel",
@@ -795,6 +803,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.freque
[PATCH v3 2/2] command-nas: fix json output
Output the cells from --get-cell-location-info in an array "cells",
"geran" entries as an array called alike,
and wrap output for different "frequencies" as such.
Reported-by: Cezary Jackiewicz
Suggested-by: Oskari Lemmelä
Signed-off-by: Jan-Niklas Burfeind
---
Hey Oskari and Cezary,
Please have a thorough look at this, as I do not have the matching
equipment at hand to test all cases.
Let me know if you rather would see `frequencies` become `channels`
and if the `geran`-array does make sense.
I just compiled this series without errors and will have a look at the
LTE-related json-outputs.
Thanks for your time
Jan-Niklas
commands-nas.c | 46 +-
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 275c53f..b99767f 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -708,7 +708,7 @@ static void
cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_nas_get_cell_location_info_response res;
- void *c, *t, *cell, *freq;
+ void *c, *t, *cell, *cells, *freq, *frequencies, *geran;
int i, j;
qmi_parse_nas_get_cell_location_info_response(msg, );
@@ -724,6 +724,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.umts_info_v2.primary_scrambling_code);
blobmsg_add_u32(, "rscp", res.data.umts_info_v2.rscp);
blobmsg_add_u32(, "ecio", res.data.umts_info_v2.ecio);
+ cells = blobmsg_open_array(, "cells");
for (j = 0; j < res.data.umts_info_v2.cell_n; j++) {
cell = blobmsg_open_table(, NULL);
blobmsg_add_u32(, "channel",
@@ -734,6 +735,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "ecio",
res.data.umts_info_v2.cell[j].ecio);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
+ geran = blobmsg_open_array(, "geran");
for (j = 0; j < res.data.umts_info_v2.neighboring_geran_n; j++)
{
cell = blobmsg_open_table(, "neighboring_geran");
blobmsg_add_u32(, "channel",
@@ -746,6 +749,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.umts_info_v2.neighboring_geran[j].rssi);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, geran);
blobmsg_close_table(, c);
}
if (res.set.intrafrequency_lte_info_v2) {
@@ -769,6 +773,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "s_intra_search_threshold",
res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
@@ -780,11 +785,14 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, c);
}
if (res.set.interfrequency_lte_info) {
- if (res.data.interfrequency_lte_info.frequency_n > 0)
+ if (res.data.interfrequency_lte_info.frequency_n > 0) {
c = blobmsg_open_table(,
"interfrequency_lte_info");
+ frequencies = blobmsg_open_array(,
"frequencies");
+ }
for (i = 0; i < res.data.interfrequency_lte_info.frequency_n;
i++) {
freq = blobmsg_open_table(, NULL);
blobmsg_add_u32(, "channel",
@@ -795,6 +803,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_high_threshold,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_low_threshold);
}
+ cells = blobmsg_open_array(
[PATCH v3 1/2] command-nas: fix cmd_nas_get_cell_location_info_cb
Correct order of rsrp and rsrq parameters for print_lte_info.
Signed-off-by: Jan-Niklas Burfeind
---
commands-nas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/commands-nas.c b/commands-nas.c
index 01ca3b8..275c53f 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -688,7 +688,7 @@ cmd_nas_get_tx_rx_info_prepare(struct qmi_dev *qmi, struct
qmi_request *req, str
}
static void
-print_lte_info(int32_t cell_id, int16_t rsrp, int16_t rsrq, int16_t rssi)
+print_lte_info(int32_t cell_id, int16_t rsrq, int16_t rsrp, int16_t rssi)
{
blobmsg_add_u32(, "physical_cell_id", cell_id);
blobmsg_add_double(, "rsrq", ((double)rsrq)/10);
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/2] command-nas: fix json output
Hey Oskari,
I'm almost done with the second commit;
And was wondering about the two loops in `umts_info_v2`.
I'd wrap the first as `cells` like for the others.
Any suggestions on the arrayname for the second, `geran`?
I'll be done in a few minutes and will update the patch series accordingly.
Jan-Niklas
On 3/7/22 18:59, Oskari Lemmelä wrote:
Hi Jan-Niklas,
On 7.3.2022 14.14, Jan-Niklas Burfeind wrote:
Output the cells from --get-cell-location-info in an array "cells".
Signed-off-by: Jan-Niklas Burfeind
---
Hey Oskari,
I think you original author would be you?
Have you got any suggestions how to name the cells array, or whether there's a
cleaner way to fix the json output thats more how you intended it to be in the
first place?
I did not validate then json after adding this feature. I should have
done it :)
I think the array is the best. At least I don't know a better solution.
Another similar problem is with multiple channels. One example in
interfrequency_lte_info.
That, too, should be fixed. In the qmi-service-nas.json file, they are
called frequency and cell arrays.
Maybe the plurals of the words frequencies or channels and cells are
good names for them.
Thanks,
Oskari
Thanks
Aiyion
commands-nas.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/commands-nas.c b/commands-nas.c
index ff7a6c3..4b86304 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -708,7 +708,7 @@ static void
cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_nas_get_cell_location_info_response res;
- void *c, *t, *cell, *freq;
+ void *c, *t, *cell, *cells, *freq;
int i, j;
qmi_parse_nas_get_cell_location_info_response(msg, );
@@ -769,6 +769,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "s_intra_search_threshold",
res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
@@ -780,6 +781,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, c);
}
if (res.set.interfrequency_lte_info) {
@@ -795,6 +797,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_high_threshold,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_low_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (j = 0; j <
res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
@@ -806,6 +809,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell[j].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, freq);
}
if (res.data.interfrequency_lte_info.frequency_n > 0)
___
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: [PATCH v2 1/2] command-nas: fix cmd_nas_get_cell_location_info_cb
Hey Oskari,
I thought so too, but was not eager to change the functions signature
without your consent, as I was not sure if the function was used
somewhere else, or came from an upstream source I did not find.
I'll update the patch in a moment and send it when I updated the second
commit regarding json as well.
Thanks
Jan-Niklas
On 3/7/22 18:10, Oskari Lemmelä wrote:
Hi Jan-Niklas,
On 7.3.2022 14.14, Jan-Niklas Burfeind wrote:
Correct order of rsrp and rsrq parameters for print_lte_info.
Good catch. I didn’t check those similar variable names carefully enough.
I think my typo is in the print_lte_info parameters. This could also be
corrected
by swapping the order of the rsrp and rsrq variables in the function
definition.
Then the print order is also the same as the order of the function
parameters.
Thanks,
Oskari
Signed-off-by: Jan-Niklas Burfeind
---
commands-nas.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 01ca3b8..ff7a6c3 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -772,8 +772,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
-
res.data.intrafrequency_lte_info_v2.cell[i].rsrq,
res.data.intrafrequency_lte_info_v2.cell[i].rsrp,
+
res.data.intrafrequency_lte_info_v2.cell[i].rsrq,
res.data.intrafrequency_lte_info_v2.cell[i].rssi);
if (res.data.intrafrequency_lte_info_v2.ue_in_idle)
blobmsg_add_u32(,
"cell_selection_rx_level",
@@ -798,8 +798,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
for (j = 0; j <
res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
-
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrq,
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrp,
+
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrq,
res.data.interfrequency_lte_info.frequency[i].cell[j].rssi);
if (res.data.interfrequency_lte_info.ue_in_idle)
blobmsg_add_u32(,
"cell_selection_rx_level",
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2 2/2] command-nas: fix json output
Good afternoon Cezary and Oskari,
this commit is now tested as well and does output a json like this:
{
"intrafrequency_lte_info": {
"tracking_area_code": 14000,
"global_cell_id": 10498829,
"channel": 3350,
"band": 7,
"frequency": 2600,
"duplex": "FDD",
"serving_cell_id": 460,
"cells": [
{
"physical_cell_id": 460,
"rsrq": -9.90,
"rsrp": -99.80,
"rssi": -71.60
},
{
"physical_cell_id": 17,
"rsrq": -14.10,
"rsrp": -104.70,
"rssi": -81.60
},
{
"physical_cell_id": 445,
"rsrq": -14.40,
"rsrp": -104.80,
"rssi": -81.50
},
{
"physical_cell_id": 43,
"rsrq": -19.10,
"rsrp": -109.90,
"rssi": -81.700000
}
]
}
}
Let me know if this does solve the problem, if one of you found time to
test it or if you have other broken json outputs for this subcommand.
Thanks so far
Jan-Niklas
On 3/7/22 13:25, Jan-Niklas Burfeind wrote:
Disclaimer: This particular commit compiled, but has not been tested yet.
On 3/7/22 13:14, Jan-Niklas Burfeind wrote:
Output the cells from --get-cell-location-info in an array "cells".
Signed-off-by: Jan-Niklas Burfeind
---
Hey Oskari,
I think you original author would be you?
Have you got any suggestions how to name the cells array, or whether
there's a cleaner way to fix the json output thats more how you
intended it to be in the first place?
Thanks
Aiyion
commands-nas.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/commands-nas.c b/commands-nas.c
index ff7a6c3..4b86304 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -708,7 +708,7 @@ static void
cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct
qmi_request *req, struct qmi_msg *msg)
{
struct qmi_nas_get_cell_location_info_response res;
- void *c, *t, *cell, *freq;
+ void *c, *t, *cell, *cells, *freq;
int i, j;
qmi_parse_nas_get_cell_location_info_response(msg, );
@@ -769,6 +769,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev
*qmi, struct qmi_request *req,
blobmsg_add_u32(, "s_intra_search_threshold",
res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
@@ -780,6 +781,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev
*qmi, struct qmi_request *req,
res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, c);
}
if (res.set.interfrequency_lte_info) {
@@ -795,6 +797,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev
*qmi, struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_high_threshold,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_low_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (j = 0; j <
res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
@@ -806,6 +809,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev
*qmi, struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell[j].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, freq);
Re: [PATCH v2 2/2] command-nas: fix json output
Disclaimer: This particular commit compiled, but has not been tested yet.
On 3/7/22 13:14, Jan-Niklas Burfeind wrote:
Output the cells from --get-cell-location-info in an array "cells".
Signed-off-by: Jan-Niklas Burfeind
---
Hey Oskari,
I think you original author would be you?
Have you got any suggestions how to name the cells array, or whether there's a
cleaner way to fix the json output thats more how you intended it to be in the
first place?
Thanks
Aiyion
commands-nas.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/commands-nas.c b/commands-nas.c
index ff7a6c3..4b86304 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -708,7 +708,7 @@ static void
cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_nas_get_cell_location_info_response res;
- void *c, *t, *cell, *freq;
+ void *c, *t, *cell, *cells, *freq;
int i, j;
qmi_parse_nas_get_cell_location_info_response(msg, );
@@ -769,6 +769,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "s_intra_search_threshold",
res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
@@ -780,6 +781,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, c);
}
if (res.set.interfrequency_lte_info) {
@@ -795,6 +797,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_high_threshold,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_low_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (j = 0; j <
res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
@@ -806,6 +809,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell[j].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, freq);
}
if (res.data.interfrequency_lte_info.frequency_n > 0)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/2] command-nas: fix json output
Output the cells from --get-cell-location-info in an array "cells".
Signed-off-by: Jan-Niklas Burfeind
---
Hey Oskari,
I think you original author would be you?
Have you got any suggestions how to name the cells array, or whether there's a
cleaner way to fix the json output thats more how you intended it to be in the
first place?
Thanks
Aiyion
commands-nas.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/commands-nas.c b/commands-nas.c
index ff7a6c3..4b86304 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -708,7 +708,7 @@ static void
cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi, struct qmi_request
*req, struct qmi_msg *msg)
{
struct qmi_nas_get_cell_location_info_response res;
- void *c, *t, *cell, *freq;
+ void *c, *t, *cell, *cells, *freq;
int i, j;
qmi_parse_nas_get_cell_location_info_response(msg, );
@@ -769,6 +769,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
blobmsg_add_u32(, "s_intra_search_threshold",
res.data.intrafrequency_lte_info_v2.s_intra_search_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
@@ -780,6 +781,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.intrafrequency_lte_info_v2.cell[i].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, c);
}
if (res.set.interfrequency_lte_info) {
@@ -795,6 +797,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_high_threshold,
res.data.interfrequency_lte_info.frequency[i].cell_selection_rx_level_low_threshold);
}
+ cells = blobmsg_open_array(, "cells");
for (j = 0; j <
res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
@@ -806,6 +809,7 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
res.data.interfrequency_lte_info.frequency[i].cell[j].cell_selection_rx_level);
blobmsg_close_table(, cell);
}
+ blobmsg_close_array(, cells);
blobmsg_close_table(, freq);
}
if (res.data.interfrequency_lte_info.frequency_n > 0)
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/2] command-nas: fix cmd_nas_get_cell_location_info_cb
Correct order of rsrp and rsrq parameters for print_lte_info.
Signed-off-by: Jan-Niklas Burfeind
---
commands-nas.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 01ca3b8..ff7a6c3 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -772,8 +772,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
-
res.data.intrafrequency_lte_info_v2.cell[i].rsrq,
res.data.intrafrequency_lte_info_v2.cell[i].rsrp,
+
res.data.intrafrequency_lte_info_v2.cell[i].rsrq,
res.data.intrafrequency_lte_info_v2.cell[i].rssi);
if (res.data.intrafrequency_lte_info_v2.ue_in_idle)
blobmsg_add_u32(,
"cell_selection_rx_level",
@@ -798,8 +798,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
for (j = 0; j <
res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
-
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrq,
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrp,
+
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrq,
res.data.interfrequency_lte_info.frequency[i].cell[j].rssi);
if (res.data.interfrequency_lte_info.ue_in_idle)
blobmsg_add_u32(,
"cell_selection_rx_level",
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] command-nas: fix cmd_nas_get_cell_location_info_cb
Hello Cezary,
I think for that particular problem it wuld suffice to wrap the three
cell-objects in an array called cells.
I drafted a commit for this, but am currently sitting in a train and can
only test it in a few hours.
Looking at the surrounding code there appear to be more for-loops, that
might produce similar problems.
Without breaking existing codes, it might be worthwile to ask the
original author about his intention on this.
Until later
Aiyion
On 3/6/22 18:37, Cezary Jackiewicz wrote:
Dnia 2022-03-06, o godz. 18:25:57
Jan-Niklas Burfeind napisał(a):
Correct order of rsrp and rsrq parameters for print_lte_info.
Signed-off-by: Jan-Niklas Burfeind
Hi,
BTW, syntax is invalid. Output is not valid json format.
Could you also proper format output?
Ex: missing keys after serving_cell_id:
# uqmi -d /dev/cdc-wdm0 --get-cell-location-info
{
"intrafrequency_lte_info": {
"tracking_area_code": 11041,
"global_cell_id": 2742796,
"channel": 3526,
"band": 8,
"frequency": 900,
"duplex": "FDD",
"serving_cell_id": 49,
{
"physical_cell_id": 49,
"rsrq": -70.80,
"rsrp": -10.40,
"rssi": -47.20
},
{
"physical_cell_id": 10,
"rsrq": -78.50,
"rsrp": -17.90,
"rssi": -50.90
},
{
"physical_cell_id": 50,
"rsrq": -78.40,
"rsrp": -18.50,
"rssi": -50.90
}
}
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] command-nas: fix cmd_nas_get_cell_location_info_cb
Correct order of rsrp and rsrq parameters for print_lte_info.
Signed-off-by: Jan-Niklas Burfeind
---
This was introduced in
d647f8d89f68 uqmi: add more diagnostics commands
Currently --get-cell-location-info prints the rsrq and rsrp values
swapped.
I ignored the checkpatch.pl warning for line lengths, as the long line is
already in the codebase and only got swapped in their order.
commands-nas.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/commands-nas.c b/commands-nas.c
index 01ca3b8..ff7a6c3 100644
--- a/commands-nas.c
+++ b/commands-nas.c
@@ -772,8 +772,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
for (i = 0; i < res.data.intrafrequency_lte_info_v2.cell_n;
i++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.intrafrequency_lte_info_v2.cell[i].physical_cell_id,
-
res.data.intrafrequency_lte_info_v2.cell[i].rsrq,
res.data.intrafrequency_lte_info_v2.cell[i].rsrp,
+
res.data.intrafrequency_lte_info_v2.cell[i].rsrq,
res.data.intrafrequency_lte_info_v2.cell[i].rssi);
if (res.data.intrafrequency_lte_info_v2.ue_in_idle)
blobmsg_add_u32(,
"cell_selection_rx_level",
@@ -798,8 +798,8 @@ cmd_nas_get_cell_location_info_cb(struct qmi_dev *qmi,
struct qmi_request *req,
for (j = 0; j <
res.data.interfrequency_lte_info.frequency[i].cell_n; j++) {
cell = blobmsg_open_table(, NULL);
print_lte_info(res.data.interfrequency_lte_info.frequency[i].cell[j].physical_cell_id,
-
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrq,
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrp,
+
res.data.interfrequency_lte_info.frequency[i].cell[j].rsrq,
res.data.interfrequency_lte_info.frequency[i].cell[j].rssi);
if (res.data.interfrequency_lte_info.ue_in_idle)
blobmsg_add_u32(,
"cell_selection_rx_level",
--
2.35.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] wireguard-tools: allow generating private_key
Tested-by: Jan-Niklas Burfeind This has been running on at least 80 devices in the past months in our ff-community. Let me know if and what you need more Aiyion On 9/15/21 03:09, Leonardo Mörlein wrote: When the uci configuration is created automatically during a very early stage, where no entropy daemon is set up, generating the key directly is not an option. Therefore we allow to set the private_key to "generate" and generate the private key directly before the interface is taken up. Signed-off-by: Leonardo Mörlein --- v2: Changes since v1: - The (recently introduced) uci flag "-t" is used to avoid interference with potentially existing uncommited user changes. This addresses Jo-Philipp Wich's concerns about v1 of the patch. - The functionality has been moved to a function, so it can be included from other files. References: - v1 of the patch: https://patchwork.ozlabs.org/project/openwrt/patch/20210108012435.175345-1...@irrelefant.net/ - uci "-t": https://git.openwrt.org/?p=project/uci.git;a=commit;h=4b3db1179747b6a6779029407984bacef851325c [...] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] wireguard-tools: allow generating private_key
Hello ynezz, [1] says you are reviewing this? It might be outdated? It's been three and a half months now; any chance one could help you with this? Thanks so far Aiyion On 1/24/22 11:43, Aiyion.Prime wrote: Hey ynezz, I tried to bump this in #openwrt-devel yesterday; as your last message there is from december, I thought I do it here instead. We've been using the patch for a few months now. Is there something I can help to progress this faster? Thanks for the effort Aiyion On 9/15/21 03:09, Leonardo Mörlein wrote: [...] ___ 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
[PATCH] scripts: eva_ramboot.py: remove unused import
concludes:
commit e7bc8984d9ca ("scripts: make eva_ramboot.py offset configurable")
Signed-off-by: Jan-Niklas Burfeind
---
scripts/flashing/eva_ramboot.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/scripts/flashing/eva_ramboot.py b/scripts/flashing/eva_ramboot.py
index b182f09d21..365fceecf6 100755
--- a/scripts/flashing/eva_ramboot.py
+++ b/scripts/flashing/eva_ramboot.py
@@ -3,7 +3,6 @@
import argparse
from ftplib import FTP
-from sys import argv
from os import stat
parser = argparse.ArgumentParser(description='Tool to boot AVM EVA ramdisk
images.')
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v4] ath79: add support for onion omega
The Onion Omega is a hardware development platform with built-in WiFi.
https://onioniot.github.io/wiki/
Specifications:
- QCA9331 @ 400 MHz (MIPS 24Kc Big-Endian Processor)
- 64MB of DDR2 RAM running at 400 MHz
- 16MB of on-board flash storage
- Support for USB 2.0
- Support for Ethernet at 100 Mbps
- 802.11b/g/n WiFi at 150 Mbps
- 18 digital GPIOs
- A single Serial UART
- Support for SPI
- Support for I2S
Flash instructions:
The device is running OpenWrt upon release using the ar71xx target.
Both a sysupgrade
and uploading the factory image using u-boots web-UI do work fine.
Depending on the ssh client, it might be necessary to enable outdated
KeyExchange methods e.g. in the clients ssh-config:
Host 192.168.1.1
KexAlgorithms +diffie-hellman-group1-sha1
The stock credentials are: root onioneer
For u-boots web-UI manually configure `192.168.1.2/24` on your computer,
connect to `192.168.1.1`.
MAC addresses as verified by OEM firmware:
2G phy0 label
LAN eth0 label - 1
LAN is only available in combination with an optional expansion dock.
Based on vendor acked commit:
commit 5cd49bb067ca ("ar71xx: add support for Onion Omega")
Partly reverts:
commit fc553c7e4c8e ("ath79: drop unused/incomplete dts")
Signed-off-by: Jan-Niklas Burfeind
---
I adressed Adrians comments on v3 and built and deployed the image.
Everything seems to work as well as before.
Thanks!
Aiyion
target/linux/ath79/dts/ar9331_onion_omega.dts | 137 ++
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic.mk | 13 ++
3 files changed, 151 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9331_onion_omega.dts
diff --git a/target/linux/ath79/dts/ar9331_onion_omega.dts
b/target/linux/ath79/dts/ar9331_onion_omega.dts
new file mode 100644
index 00..09e4234194
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_onion_omega.dts
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9331.dtsi"
+
+#include
+#include
+
+/ {
+ model = "Onion Omega";
+ compatible = "onion,omega", "qca,ar9331";
+
+ aliases {
+ serial0 =
+ label-mac-device =
+ led-boot = _system;
+ led-failsafe = _system;
+ led-running = _system;
+ led-upgrade = _system;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_system: system {
+ label = "amber:system";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 11 GPIO_ACTIVE_HIGH>;
+ debounce-interval = <60>;
+ };
+ };
+
+ reg_usb_vbus: reg_usb_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+ {
+ clock-frequency = <2500>;
+};
+
+ {
+ status = "okay";
+
+ vbus-supply = <_usb_vbus>;
+ dr_mode = "host";
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ compatible = "syscon", "simple-mfd";
+};
+
+ {
+ status = "okay";
+
+ nvmem-cells = <_uboot_1fc00>;
+ nvmem-cell-names = "mac-address";
+ mac-address-increment = <(-1)>;
+
+ gmac-config {
+ device = <>;
+ switch-phy-addr-swap = <4>;
+ switch-phy-swap = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <2500>;
+ reg = <0>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x02>;
+ read-only;
+ };
+
+ partition@2 {
+ compatible = "tplink,firmware";
+ label = "firmware";
+ reg = <
Re: [PATCH v4] ath79: add support for onion omega
On 8/22/21 2:18 PM, Adrian Schmutzler wrote: > It's common practice at the moment to put a separate block for defining the > MAC addresses at the end of the file. > Please do so, just look at any other DTS file in recent master. I was under the impression that the separate block was part of a scripts output and not intended in the first place. Is there any documentation on this matter, that I can read up on? Thanks Aiyion ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for onion omega
On 8/14/21 7:08 PM, Lech Perczak wrote:
> [...]
>>>
>>> The six bytes at 001fd00 spell OMEGA.
>> Is this the only data in 0x1-0x2? What's in 0x1-0x11000?
>>
> + read-only;
> + compatible = "nvmem-cells";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + macaddr_uboot_1fc00: macaddr@1fc00 {
> + reg = <0x1fc00 0x6>;
> + };
> + };
> +
> + partition@2 {
> + compatible = "tplink,firmware";
> + label = "firmware";
> + reg = <0x02 0xfd>;
> + };
> +
> + art: partition@ff {
> + label = "art";
> + reg = <0xff 0x01>;
> + read-only;
> + };
>
> The whole ordeal looks very much like typical pre-safeloader TP-link
> flash layout, so I expect no writable U-boot environment there, at least
> for stock U-boot.
> Of course, it would be best to check if it's possible to write it using
> serial console, on actual device.
>
I just tried to copy part of the string "OMEGA" from its current position.
> md 0x9F01FD00
9F01FD00: 4F4D4547[...]
cp 0x9F01FD00 0x9F01FE00 3
> md 0x9F01FE00
9F01FE00: [...]
Reading the partition works fine; writing not so much; at least not
within uboot.
[...]
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for onion omega
On 8/14/21 5:43 PM, Tomasz Maciej Nowak wrote: > [..] >> uboot knows it is 64KiB, printenv yields uboot_size=0x1 > > That should be reflected in partitions list and the space between > 0x1-0x2 partition name should reflect what's inside. If the > vendor firmware had a name for this space, use that. That's the thing. The stock firmware calls it u-boot, start to finish. root@Omega-10B1:/# cat /proc/mtd dev:size erasesize name mtd0: 0002 0001 "u-boot" ... > [...] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for onion omega
Hey there; answer is inline too.
Thanks for picking this up!
On 8/14/21 3:54 PM, Tomasz Maciej Nowak wrote:
> Hi,
> one comment inline.
>
> W dniu 14.08.2021 o 14:33, Jan-Niklas Burfeind pisze:
>> [...]
>> +partitions {
>> +compatible = "fixed-partitions";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +
>> +uboot: partition@0 {
>> +label = "u-boot";
>> +reg = <0x00 0x02>;
>
> Is this really the size of the U-Boot? According to the sources of
> U-Boot [1] the max size of bootloader is 64KiB. If the sources don't
> lie, what's between 0x1-0x2? Is that some hardcoded data or
> U-Boot environment? If it's the environment, You can't use static
> address of the MAC in nvmem-cells, because it can move around if
someone modified the environment. For that You'll need to extract it in
> userspace.
>
> 1.
https://github.com/OnionIoT/uboot/blob/684829a3a89eabca4b573530e89d60faed277dee/Makefile#L31
>
uboot knows it is 64KiB, printenv yields uboot_size=0x1
It further knows, firmware starts not before 128Kib:
firmware_addr=0x9F02
these are the last lines of mtd0:
000f8d0
*
001fc00 40a3 6bc1 10b2
001fc10
*
001fd00 4f4d 4547 41ff
001fd10
*
002
The six bytes at 001fc00 are the macaddress.
The six bytes at 001fd00 spell OMEGA.
>> +read-only;
>> +compatible = "nvmem-cells";
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +
>> +macaddr_uboot_1fc00: macaddr@1fc00 {
>> +reg = <0x1fc00 0x6>;
>> +};
>> +};
>> +
>> +partition@2 {
>> +compatible = "tplink,firmware";
>> +label = "firmware";
>> +reg = <0x02 0xfd>;
>> +};
>> +
>> +art: partition@ff {
>> +label = "art";
>> +reg = <0xff 0x01>;
>> +read-only;
>> +};
>> +};
>> +};
>> +};
>> +
>> + {
>> +status = "okay";
>> +
>> +mtd-cal-data = < 0x1000>;
>> +nvmem-cells = <_uboot_1fc00>;
>> +nvmem-cell-names = "mac-address";
>> +};
>
> [ snip ]
>
> Regards
>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] ath79: add support for onion omega
The Onion Omega is a hardware development platform with built-in WiFi.
https://onioniot.github.io/wiki/
Specifications:
- QCA9331 @ 400 MHz (MIPS 24Kc Big-Endian Processor)
- 64MB of DDR2 RAM running at 400 MHz
- 16MB of on-board flash storage
- Support for USB 2.0
- Support for Ethernet at 100 Mbps
- 802.11b/g/n WiFi at 150 Mbps
- 18 digital GPIOs
- A single Serial UART
- Support for SPI
- Support for I2S
Flash instructions:
The device is running OpenWrt upon release using the ar71xx target.
Both a sysupgrade
and uploading the factory image using u-boots web-UI do work fine.
Depending on the ssh client, it might be necessary to enable outdated
KeyExchange methods e.g. in the clients ssh-config:
Host 192.168.1.1
KexAlgorithms +diffie-hellman-group1-sha1
The stock credentials are: root onioneer
For u-boots web-UI manually configure `192.168.1.2/24` on your computer,
connect to `192.168.1.1`.
MAC addresses as verified by OEM firmware:
2G phy0 label
LAN eth0 label - 1
LAN is only available in combination with an optional expansion dock.
Based on vendor acked commit:
commit 5cd49bb067ca ("ar71xx: add support for Onion Omega")
Partly reverts:
commit fc553c7e4c8e ("ath79: drop unused/incomplete dts")
Signed-off-by: Jan-Niklas Burfeind
---
kmod-usb-chipidea2 is now included as well as tested; usb devices are
now recognized.
I added the usb vbus section, like the pisen wmm003n has it and verified
the gpio looking at the ar71xx commit.
target/linux/ath79/dts/ar9331_onion_omega.dts | 137 ++
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic.mk | 13 ++
3 files changed, 151 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9331_onion_omega.dts
diff --git a/target/linux/ath79/dts/ar9331_onion_omega.dts
b/target/linux/ath79/dts/ar9331_onion_omega.dts
new file mode 100644
index 00..43a0b2f392
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_onion_omega.dts
@@ -0,0 +1,137 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include
+#include
+
+#include "ar9331.dtsi"
+
+/ {
+ model = "Onion Omega";
+ compatible = "onion,omega", "qca,ar9331";
+
+ aliases {
+ serial0 =
+ led-boot = _system;
+ led-failsafe = _system;
+ led-running = _system;
+ led-upgrade = _system;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_system: system {
+ label = "amber:system";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ poll-interval = <100>;
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 11 GPIO_ACTIVE_HIGH>;
+ debounce-interval = <60>;
+ };
+ };
+
+ reg_usb_vbus: reg_usb_vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_vbus";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ gpio = < 8 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+};
+
+ {
+ clock-frequency = <2500>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ vbus-supply = <_usb_vbus>;
+ dr_mode = "host";
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ compatible = "syscon", "simple-mfd";
+};
+
+ {
+ status = "okay";
+
+ nvmem-cells = <_uboot_1fc00>;
+ nvmem-cell-names = "mac-address";
+ mac-address-increment = <(-1)>;
+
+ gmac-config {
+ device = <>;
+ switch-phy-addr-swap = <4>;
+ switch-phy-swap = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <2500>;
+ reg = <0>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x02>;
+ read-only;
+ compatible = "nvmem-cells";
+
[PATCH v2] ath79: add support for onion omega
The Onion Omega is a hardware development platform with built-in WiFi.
https://onioniot.github.io/wiki/
Specifications:
- QCA9331 @ 400 MHz (MIPS 24Kc Big-Endian Processor)
- 64MB of DDR2 RAM running at 400 MHz
- 16MB of on-board flash storage
- Support for USB 2.0
- Support for Ethernet at 100 Mbps
- 802.11b/g/n WiFi at 150 Mbps
- 18 digital GPIOs
- A single Serial UART
- Support for SPI
- Support for I2S
Flash instructions:
The device is running OpenWrt upon release using the ar71xx target.
Both a sysupgrade
and uploading the factory image using u-boots web-UI do work fine.
Depending on the ssh client, it might be necessary to enable outdated
KeyExchange methods e.g. in the clients ssh-config:
Host 192.168.1.1
KexAlgorithms +diffie-hellman-group1-sha1
The stock credentials are: root onioneer
For u-boots web-UI manually configure `192.168.1.2/24` on your computer,
connect to `192.168.1.1`.
MAC addresses as verified by OEM firmware:
2G phy0 label
LAN eth0 label - 1
LAN is only available in combination with an optional expansion dock.
Based on vendor acked commit:
commit 5cd49bb067ca ("ar71xx: add support for Onion Omega")
Partly reverts:
commit fc553c7e4c8e ("ath79: drop unused/incomplete dts")
Signed-off-by: Jan-Niklas Burfeind
---
Hello David,
thanks for the review.
I think I got both you as well as Sebastians suggestion patched.
This revision contains them both, compiled without errors this morning
and is currently running on an omega next to me;
dmesg is inconspicuous.
Thanks
Jan-Niklas/Aiyion
target/linux/ath79/dts/ar9331_onion_omega.dts | 127 ++
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic.mk | 13 ++
3 files changed, 141 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9331_onion_omega.dts
diff --git a/target/linux/ath79/dts/ar9331_onion_omega.dts
b/target/linux/ath79/dts/ar9331_onion_omega.dts
new file mode 100644
index 00..b08c62221f
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_onion_omega.dts
@@ -0,0 +1,127 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include
+#include
+
+#include "ar9331.dtsi"
+
+/ {
+ model = "Onion Omega";
+ compatible = "onion,omega", "qca,ar9331";
+
+ aliases {
+ serial0 =
+ led-boot = _system;
+ led-failsafe = _system;
+ led-running = _system;
+ led-upgrade = _system;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_system: system {
+ label = "amber:system";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ poll-interval = <100>;
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 11 GPIO_ACTIVE_HIGH>;
+ debounce-interval = <60>;
+ };
+ };
+};
+
+ {
+ clock-frequency = <2500>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ dr_mode = "host";
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ compatible = "syscon", "simple-mfd";
+};
+
+ {
+ status = "okay";
+
+ nvmem-cells = <_uboot_1fc00>;
+ nvmem-cell-names = "mac-address";
+ mac-address-increment = <(-1)>;
+
+ gmac-config {
+ device = <>;
+ switch-phy-addr-swap = <4>;
+ switch-phy-swap = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <2500>;
+ reg = <0>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x02>;
+ read-only;
+ compatible = "nvmem-cells";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ macaddr_uboot_1fc00: macaddr@1fc00 {
+ reg = <0x1fc00 0x6>;
+ };
+ };
+
+ partition@2 {
+
[PATCH] ath79: add support for onion omega
The Onion Omega is a hardware development platform with built-in WiFi.
https://onioniot.github.io/wiki/
Specifications:
- QCA9331 @ 400 MHz (MIPS 24Kc Big-Endian Processor)
- 64MB of DDR2 RAM running at 400 MHz
- 16MB of on-board flash storage
- Support for USB 2.0
- Support for Ethernet at 100 Mbps
- 802.11b/g/n WiFi at 150 Mbps
- 18 digital GPIOs
- A single Serial UART
- Support for SPI
- Support for I2S
Flash instructions:
The device is running OpenWrt upon release using the ar71xx target.
Both a sysupgrade
and uploading the factory image using u-boots web-UI do work fine.
Depending on the ssh client, it might be necessary to enable outdated
KeyExchange methods e.g. in the clients ssh-config:
Host 192.168.1.1
KexAlgorithms +diffie-hellman-group1-sha1
The stock credentials are: root onioneer
For u-boots web-UI manually configure `192.168.1.2/24` on your computer,
connect to `192.168.1.1`.
MAC addresses as verified by OEM firmware:
2G phy0 label
LAN eth0 label - 1
LAN is only available in combination with an optional expansion dock.
Based on vendor acked commit:
commit 5cd49bb067ca ("ar71xx: add support for Onion Omega")
Partly reverts:
commit fc553c7e4c8e ("ath79: drop unused/incomplete dts")
Signed-off-by: Jan-Niklas Burfeind
---
target/linux/ath79/dts/ar9331_onion_omega.dts | 138 ++
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic.mk | 14 ++
3 files changed, 153 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9331_onion_omega.dts
diff --git a/target/linux/ath79/dts/ar9331_onion_omega.dts
b/target/linux/ath79/dts/ar9331_onion_omega.dts
new file mode 100644
index 00..3b72a293b4
--- /dev/null
+++ b/target/linux/ath79/dts/ar9331_onion_omega.dts
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar9331.dtsi"
+
+/ {
+ model = "Onion Omega";
+ compatible = "onion,omega", "qca,ar9331";
+
+ aliases {
+ serial0 =
+ led-boot = _system;
+ led-failsafe = _system;
+ led-running = _system;
+ led-upgrade = _system;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_system: system {
+ label = "onion:amber:system";
+ gpios = < 27 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ button0 {
+ label = "reset";
+ linux,code = ;
+ gpios = < 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
+};
+
+ {
+ clock-frequency = <2500>;
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ dr_mode = "host";
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ compatible = "syscon", "simple-mfd";
+};
+
+ {
+ status = "okay";
+
+ nvmem-cells = <_uboot_1fc00>;
+ nvmem-cell-names = "mac-address";
+ mac-address-increment = <(-1)>;
+
+ gmac-config {
+ device = <>;
+ switch-phy-addr-swap = <4>;
+ switch-phy-swap = <4>;
+ };
+};
+
+
+ {
+ status = "okay";
+
+ num-chipselects = <1>;
+
+ /* Winbond 25Q128FVSG SPI flash */
+ flash@0 {
+ compatible = "winbond,w25q128", "jedec,spi-nor";
+ spi-max-frequency = <2500>;
+ reg = <0>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x02>;
+ read-only;
+ };
+
+ partition@2 {
+ compatible = "tplink,firmware";
+ label = "firmware";
+ reg = <0x02 0xfd>;
+ };
+
+ art: partition@ff {
+ label = "art";
+ reg = <0xff 0x01>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
