[PATCH 2/2] qoriq: pad rootfs with zeros so that sysupgrade -n resets the overlayfs
Presently, sysupgrade -n does *not* reset the overlayfs, retaining unwanted filesystem contents. Adding PADDING=1 in front of gen_image_generic.sh in image/Makefile ensures that the overlayfs is recreated on firstboot. Signed-off-by: Russell Senior --- target/linux/qoriq/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/qoriq/image/Makefile b/target/linux/qoriq/image/Makefile index ec46e4d543..69fea238b5 100644 --- a/target/linux/qoriq/image/Makefile +++ b/target/linux/qoriq/image/Makefile @@ -13,7 +13,7 @@ define Build/sdcard-img $(foreach dtb,$(DEVICE_DTS),$(CP) $(KDIR)/image-$(dtb).dtb $@.boot), \ $(CP) $(KDIR)/image-/*.dtb $@.boot) -$(SCRIPT_DIR)/gen_image_generic.sh \ +PADDING=1 $(SCRIPT_DIR)/gen_image_generic.sh \ $@ \ $(CONFIG_TARGET_KERNEL_PARTSIZE) $@.boot \ $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(IMAGE_ROOTFS) \ -- 2.43.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] qoriq: add missing compat_version to allow sysupgrade to save old config
Currently, sysupgrade without the -n option complains: # sysupgrade -v tmp/openwrt-qoriq-generic-watchguard_firebox-m300-squashfs-sysupgrade.img.gz upgrade: The device is supported, but the config is incompatible to the new image (1.0->1.1). Please upgrade without keeping config (sysupgrade -n). upgrade: Kernel switched to FIT uImage. Update U-Boot environment. upgrade: Reading partition table from bootdisk... upgrade: Extract boot sector from the image upgrade: Reading partition table from image... Image check failed. So, add the missing 05_compat-version to /etc/board.d/ Signed-off-by: Russell Senior --- .../base-files/etc/board.d/05_compat-version | 18 ++ 1 file changed, 18 insertions(+) create mode 100644 target/linux/qoriq/base-files/etc/board.d/05_compat-version diff --git a/target/linux/qoriq/base-files/etc/board.d/05_compat-version b/target/linux/qoriq/base-files/etc/board.d/05_compat-version new file mode 100644 index 00..62ad804389 --- /dev/null +++ b/target/linux/qoriq/base-files/etc/board.d/05_compat-version @@ -0,0 +1,18 @@ +# +# Copyright (C) 2020 OpenWrt.org +# + +. /lib/functions.sh +. /lib/functions/uci-defaults.sh + +board_config_update + +case "$(board_name)" in + watchguard,firebox-m300) + ucidef_set_compat_version "1.1" + ;; +esac + +board_config_flush + +exit 0 -- 2.43.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Implementing bluetooth speakers on OpenWrt?
Should have mentioned, I'm using a USB bluetooth dongle as well in the OpenWrt router, currently a tp-link UB500(UN). On Mon, Sep 4, 2023 at 1:15 PM Russell Senior wrote: > > Hi, > > Has anyone implemented bluetooth speakers on OpenWrt? I am fiddling > with playing Spotify/Pandora from a phone (android or iOS) to an > OpenWrt device with a USB audio device plugged in and the > out-of-the-box configuration doesn't seem to work. > > Any pointers are welcome. Thanks! > > -- > Russell Senior > russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Implementing bluetooth speakers on OpenWrt?
Hi, Has anyone implemented bluetooth speakers on OpenWrt? I am fiddling with playing Spotify/Pandora from a phone (android or iOS) to an OpenWrt device with a USB audio device plugged in and the out-of-the-box configuration doesn't seem to work. Any pointers are welcome. Thanks! -- Russell Senior russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Error in Common Ubiquiti Procedures for XM AirMax devices?
On Sun, Nov 7, 2021 at 5:07 PM Joe Ayers wrote: > > Openwrt Github commit notes, Forum posts, and Documentation, refer to: > > "The mtd partitions layout for XM-type devices changed from AirOS v5.5 > to AirOS v5.6. Before installing OpenWrt, downgrade first to AirOS > 5.5." > > reference: https://openwrt.org/toh/ubiquiti/common > > While the documentation is a path to succeed loading openwrt firmware, > this commit fixed the soft-brick issue (soft-brick meaning tftp > recovery with serial cable is possible): > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc I went looking and found that this commit is in all releases starting with 17.01.x, but not in v15.05.1 > > It is a key message, that openwrt firmware after this commit, will no > longer soft-brick the device, not communicated. > > The key misunderstanding is around the root cause due to Ubiquiti > tightening up uboot to further check partition sizes. The root cause > was identified as a bad openwrt size definition that older versions of > uboot accepted, without end user awareness. > > The reason I raise this issue is due to users in the > https//www.arednmesh.org community struggling to downgrade to AirOX > v5.5, and we spend time working with them only to do tftp > "hold-reset-button" firmware loads to succeed as quickest path. > > Note, however, there are still issues where newer Uboot versions > expect images to have particular naming conventions, which are also > addressed in later fixes: > > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 This one is in releases starting with v19.07.x, but not in v18.06.x and earlier. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] iproute2: update to 5.15
from https://git.kernel.org/pub/scm/network/iproute2/iproute2.git
changes since 5.14.0:
ad3a118f rdma: Fix SRQ resource tracking information json
7a235a10 man: devlink-port: fix pfnum for devlink port add
229eaba5 uapi: pickup fix for xfrm ABI breakage
a500c5ac lib/bpf: fix map-in-map creation without prepopulation
7c032cac man: devlink-port: remove extra .br
04ee8e6f man: devlink-port: fix style
14802d84 man: devlink-port: fix the devlink port add synopsis
897772a7 cmd: use spaces instead of tabs for usage indentation
e7a98a96 mptcp: unbreak JSON endpoint list
2f5825cb lib: bpf_legacy: fix bpffs mount when /sys/fs/bpf exists
d756c08a tc/f_flower: fix port range parsing
92e32f77 uapi: updates from 5.15-rc1
e7e0e2ce iptuntap: fix multi-queue flag display
deef844b man: ip-link: remove double of
a3272b93 configure: restore backward compatibility
ceba5930 tree-wide: fix some typos found by Lintian
7a705242 ip: remove leftovers from IPX and DECnet
8ab1834e uapi: update headers from 5.15 merge
6d0d35ba ip/bond: add lacp active support
926ad641 Update kernel headers
c730bd0b ip/tunnel: always print all known attributes
df8912ed ipioam6: use print_nl instead of print_null
7e7270bb tc/skbmod: Introduce SKBMOD_F_ECN option
86c596ed IOAM man8
2d83c710 New IOAM6 encap type for routes
f0b3808a Add, show, link, remove IOAM namespaces and schemas
acbdef93 Import ioam6 uapi headers
2d6fa30b Update kernel headers
508ad89c ipneigh: add support to print brief output of neigh cache in tabular
format
* update patch 170-ip_tiny.patch to accomodate ioam.
Signed-off-by: Russell Senior
---
package/network/utils/iproute2/Makefile | 4 ++--
package/network/utils/iproute2/patches/170-ip_tiny.patch | 5 +++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/package/network/utils/iproute2/Makefile
b/package/network/utils/iproute2/Makefile
index ca3cb4753a..928f44e797 100644
--- a/package/network/utils/iproute2/Makefile
+++ b/package/network/utils/iproute2/Makefile
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=iproute2
-PKG_VERSION:=5.14.0
+PKG_VERSION:=5.15.0
PKG_RELEASE:=$(AUTORELEASE)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_URL:=@KERNEL/linux/utils/net/iproute2
-PKG_HASH:=210fa785a52f3763c4287fd5ae63e246f6311bfaa48c424baab6d383bb7591d4
+PKG_HASH:=38e3e4a5f9a7f5575c015027a10df097c149111eeb739993128e5b2b35b291ff
PKG_BUILD_PARALLEL:=1
PKG_BUILD_DEPENDS:=iptables
PKG_LICENSE:=GPL-2.0
diff --git a/package/network/utils/iproute2/patches/170-ip_tiny.patch
b/package/network/utils/iproute2/patches/170-ip_tiny.patch
index 2c1ec1dcb3..cd687e7601 100644
--- a/package/network/utils/iproute2/patches/170-ip_tiny.patch
+++ b/package/network/utils/iproute2/patches/170-ip_tiny.patch
@@ -30,7 +30,7 @@
"Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }\n"
" ip [ -force ] -batch filename\n"
+#ifndef IPROUTE2_TINY
- "where OBJECT := { address | addrlabel | fou | help | ila |
l2tp | link |\n"
+ "where OBJECT := { address | addrlabel | fou | help | ila |
ioam | l2tp | link |\n"
" macsec | maddress | monitor | mptcp |
mroute | mrule |\n"
" neighbor | neighbour | netconf | netns |
nexthop | ntable |\n"
" ntbl | route | rule | sr | tap | tcpmetrics
|\n"
@@ -43,7 +43,7 @@
" OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] |
-r[esolve] |\n"
"-h[uman-readable] | -iec | -j[son] |
-p[retty] |\n"
"-f[amily] { inet | inet6 | mpls | bridge |
link } |\n"
-@@ -91,36 +97,50 @@ static const struct cmd {
+@@ -91,37 +97,51 @@ static const struct cmd {
int (*func)(int argc, char **argv);
} cmds[] = {
{ "address",do_ipaddr },
@@ -90,6 +90,7 @@
+#ifndef IPROUTE2_TINY
{ "nexthop",do_ipnh },
{ "mptcp", do_mptcp },
+ { "ioam", do_ioam6 },
+#endif
{ "help", do_help },
{ 0 }
--
2.33.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Release goals for 22.XX
>>>>> "Sergey" == Sergey Ryazanov writes: Sergey> I am in the process of migrating ath25 to the 5.10 Sergey> kernel. Initial build was trivial. But I need to restore the Sergey> Marvel swconfig driver that was lost during the initial 5.10 Sergey> kernel introduction, and carefully run-time test it. I bricked Sergey> (or possibly broke) my test FON2200 during the last migration to Sergey> the 5.4. Would you like to volunteer and test the new version as Sergey> soon as it will be ready? I have some ath25 devices (some even still providing service as dumb APs), I can test too. First gen ubiquiti nanostations and accton mr3201a's. PS: frankly, i don't understand the rush to de-support older devices. -- Russell Senior russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/2] ath79: add support for Ubiquiti PowerBeam M2 (XW)
This patch adds support for the Ubiquiti PowerBeam M2 (XW), e.g. PBE-M2-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put openwrt-ath79-generic-ubnt_powerbeam-m2-xw-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM2HP
v2: corrects some lingering cut/paste references to the M5
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts | 34 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 44 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts
new file mode 100644
index 00..046715b00a
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m2-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M2 (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 5707bbac4e..8715a57213 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -406,6 +406,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m2-xw|\
ubnt,powerbeam-m5-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 780068790c..fba6d56674 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -86,6 +86,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+ ubnt,powerbeam-m2-xw|\
ubnt,powerbeam-m5-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-5ac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 547af632f6..3888e1652b 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
+define Device/ubnt_powerbeam-m2-xw
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := PowerBeam M2
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m2-xw
+
define Device/ubnt_powerbeam-m5-xw
$(Device/ubnt-xw)
DEVICE_MODEL := PowerBeam M5
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/2] ath79: rename Ubiquiti powerbeam-m to powerbeam-m5
The commit 12eb5b2384a6 added support for Ubiquiti PowerBeam M (XW), tested
on the PBE-M5-400. But, it turns out the PBE-M2-400 has a different ethernet
configuration, so make the support specific to the m5 version in anticipation
of adding specific support for the m2 in a separate commit.
Signed-off-by: Russell Senior
---
...t_powerbeam-m-xw.dts => ar9342_ubnt_powerbeam-m5-xw.dts} | 2 +-
target/linux/ath79/generic/base-files/etc/board.d/01_leds | 2 +-
.../linux/ath79/generic/base-files/etc/board.d/02_network | 2 +-
target/linux/ath79/image/generic-ubnt.mk| 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
rename target/linux/ath79/dts/{ar9342_ubnt_powerbeam-m-xw.dts =>
ar9342_ubnt_powerbeam-m5-xw.dts} (88%)
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m5-xw.dts
similarity index 88%
rename from target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
rename to target/linux/ath79/dts/ar9342_ubnt_powerbeam-m5-xw.dts
index 6db058f887..09494ad538 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m5-xw.dts
@@ -3,7 +3,7 @@
#include "ar9342_ubnt_xw.dtsi"
/ {
- compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
+ compatible = "ubnt,powerbeam-m5-xw", "ubnt,xw", "qca,ar9342";
model = "Ubiquiti PowerBeam M (XW)";
};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 7a07b0ce6d..5707bbac4e 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -406,7 +406,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
-ubnt,powerbeam-m-xw|\
+ubnt,powerbeam-m5-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4fe7fbc027..780068790c 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -86,7 +86,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
- ubnt,powerbeam-m-xw|\
+ ubnt,powerbeam-m5-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-5ac-lite|\
ubnt,rocket-m|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 01e8533fd6..547af632f6 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,13 +328,13 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
-define Device/ubnt_powerbeam-m-xw
+define Device/ubnt_powerbeam-m5-xw
$(Device/ubnt-xw)
- DEVICE_MODEL := PowerBeam M
+ DEVICE_MODEL := PowerBeam M5
DEVICE_PACKAGES += rssileds
SUPPORTED_DEVICES += loco-m-xw
endef
-TARGET_DEVICES += ubnt_powerbeam-m-xw
+TARGET_DEVICES += ubnt_powerbeam-m5-xw
define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 0/2] ath79: split support for Ubiquiti PowerBeam M5 and M2
A previous commit added support for Ubiquiti PowerBeam M, but it turns out that the M5 (PBE-M5-400) tested worked fine, but the M2 (PBE-M2-400) requires a different ethernet configuration. This series renames powerbeam-m to powerbeam-m5, and adds support specifically for powerbeam-m2. Only tested on PBE-M2-400. The series is composed of the following commits: [PATCH 1/2] ath79: rename Ubiquiti powerbeam-m to powerbeam-m5 [PATCH 2/2] ath79: add support for Ubiquiti PowerBeam M2 (XW) v2: fixes some left over m5 references in patch 2/2 Signed-off-by: Russell Senior ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] ath79: add support for Ubiquiti PowerBeam M2 (XW)
This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_powerbeam-m2-xw-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM5HP
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts | 34 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 44 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts
new file mode 100644
index 00..046715b00a
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m2-xw.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m2-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M2 (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 5707bbac4e..8715a57213 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -406,6 +406,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m2-xw|\
ubnt,powerbeam-m5-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 780068790c..fba6d56674 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -86,6 +86,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+ ubnt,powerbeam-m2-xw|\
ubnt,powerbeam-m5-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-5ac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 547af632f6..3888e1652b 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
+define Device/ubnt_powerbeam-m2-xw
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := PowerBeam M2
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m2-xw
+
define Device/ubnt_powerbeam-m5-xw
$(Device/ubnt-xw)
DEVICE_MODEL := PowerBeam M5
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] ath79: rename Ubiquiti powerbeam-m to powerbeam-m5
The commit 12eb5b2384a6 added support for Ubiquiti PowerBeam M (XW), tested
on the PBE-M5-400. But, it turns out the PBE-M2-400 has a different ethernet
configuration, so make the support specific to the m5 version in anticipation
of adding specific support for the m2 in a separate commit.
Signed-off-by: Russell Senior
---
...t_powerbeam-m-xw.dts => ar9342_ubnt_powerbeam-m5-xw.dts} | 2 +-
target/linux/ath79/generic/base-files/etc/board.d/01_leds | 2 +-
.../linux/ath79/generic/base-files/etc/board.d/02_network | 2 +-
target/linux/ath79/image/generic-ubnt.mk| 6 +++---
4 files changed, 6 insertions(+), 6 deletions(-)
rename target/linux/ath79/dts/{ar9342_ubnt_powerbeam-m-xw.dts =>
ar9342_ubnt_powerbeam-m5-xw.dts} (88%)
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m5-xw.dts
similarity index 88%
rename from target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
rename to target/linux/ath79/dts/ar9342_ubnt_powerbeam-m5-xw.dts
index 6db058f887..09494ad538 100644
--- a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m5-xw.dts
@@ -3,7 +3,7 @@
#include "ar9342_ubnt_xw.dtsi"
/ {
- compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
+ compatible = "ubnt,powerbeam-m5-xw", "ubnt,xw", "qca,ar9342";
model = "Ubiquiti PowerBeam M (XW)";
};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 7a07b0ce6d..5707bbac4e 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -406,7 +406,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
-ubnt,powerbeam-m-xw|\
+ubnt,powerbeam-m5-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4fe7fbc027..780068790c 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -86,7 +86,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
- ubnt,powerbeam-m-xw|\
+ ubnt,powerbeam-m5-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-5ac-lite|\
ubnt,rocket-m|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 01e8533fd6..547af632f6 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,13 +328,13 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
-define Device/ubnt_powerbeam-m-xw
+define Device/ubnt_powerbeam-m5-xw
$(Device/ubnt-xw)
- DEVICE_MODEL := PowerBeam M
+ DEVICE_MODEL := PowerBeam M5
DEVICE_PACKAGES += rssileds
SUPPORTED_DEVICES += loco-m-xw
endef
-TARGET_DEVICES += ubnt_powerbeam-m-xw
+TARGET_DEVICES += ubnt_powerbeam-m5-xw
define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/2] ath79: split support for Ubiquiti PowerBeam M5 and M2
A previous commit added support for Ubiquiti PowerBeam M, but it turns out that the M5 (PBE-M5-400) tested worked fine, but the M2 (PBE-M2-400) requires a different ethernet configuration. This series renames powerbeam-m to powerbeam-m5, and adds support specifically for powerbeam-m2. Only tested on PBE-M2-400. The series is composed of the following commits: [PATCH 1/2] ath79: rename Ubiquiti powerbeam-m to powerbeam-m5 [PATCH 2/2] ath79: add support for Ubiquiti PowerBeam M2 (XW) Signed-off-by: Russell Senior ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
Merged in:
commit 12eb5b2384a63427c0062856331fda60a1ebb309
reboot-17087-g12eb5b2384
Thanks Adrian!
--
Russell Senior
russ...@personaltelco.net
On Fri, Jul 2, 2021 at 9:43 PM Russell Senior wrote:
>
> It has been about a month now since v4. Is it time to apply this? I am
> using it in production. It doesn't touch anything else, so I am not
> seeing a downside in merging.
>
> --
> Russell Senior
> russ...@personaltelco.net
>
> On Sun, Jun 13, 2021 at 8:33 PM Russell Senior
> wrote:
> >
> > Is it time to apply this?
> >
> > --
> > Russell Senior
> > russ...@personaltelco.net
> >
> > On Fri, Jun 4, 2021 at 5:29 PM Russell Senior
> > wrote:
> > >
> > > This patch adds support for the Ubiquiti PowerBeam M (XW), e.g.
> > > PBE-M5-400,
> > > a 802.11n wireless with a feed+dish form factor. This device was
> > > previously
> > > supported by the ar71xx loco-m-xw firmware.
> > >
> > > Specifications:
> > > - Atheros AR9342 SoC
> > > - 64 MB RAM
> > > - 8 MB SPI flash
> > > - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> > > - Power and LAN green LEDs
> > > - 4x RSSI LEDs (red, orange, green, green)
> > > - UART (115200 8N1)
> > >
> > > Flashing via stock GUI:
> > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
> > >https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
> > > - Upload the factory image via AirOS web GUI.
> > >
> > > Flashing via TFTP:
> > > - Use a pointy tool (e.g., unbent paperclip) to keep the
> > >reset button pressed.
> > > - Power on the device (keep reset button pressed).
> > > - Keep pressing until LEDs flash alternatively LED1+LED3 =>
> > >LED2+LED4 => LED1+LED3, etc.
> > > - Release reset button.
> > > - The device starts a TFTP server at 192.168.1.20.
> > > - Set a static IP on the computer (e.g., 192.168.1.21/24).
> > > - Upload via tftp the factory image:
> > > $ tftp 192.168.1.20
> > > tftp> bin
> > > tftp> trace
> > > tftp> put
> > > openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
> > >
> > > WARNING: so far, no non-destructive method has been discovered for
> > > opening the enclosure to reach the serial console. Internal photos
> > > are available here: https://fcc.io/SWX-NBM5HP
> > >
> > > since v1:
> > > * renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
> > > since v2:
> > > * removed redundant mtd-mac-address from dts
> > > since v3:
> > > * based on testimony of Joe Ayers :
> > > * the bricking problem was resolved by 076d58d3440f (2016-02)
> > > * the tftp flashing problem was resolved by 6009b3fd586a (2018-11)
> > >so, removed the associated warnings.
> > >
> > > Signed-off-by: Russell Senior
> > > ---
> > > .../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 34 +++
> > > .../generic/base-files/etc/board.d/01_leds| 1 +
> > > .../generic/base-files/etc/board.d/02_network | 1 +
> > > target/linux/ath79/image/generic-ubnt.mk | 8 +
> > > 4 files changed, 44 insertions(+)
> > > create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > >
> > > diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > > b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > > new file mode 100644
> > > index 00..6db058f887
> > > --- /dev/null
> > > +++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > > @@ -0,0 +1,34 @@
> > > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > > +
> > > +#include "ar9342_ubnt_xw.dtsi"
> > > +
> > > +/ {
> > > + compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
> > > + model = "Ubiquiti PowerBeam M (XW)";
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +
> > > + phy-mask = <4>;
> > > +
> > > + phy4: ethernet-phy@4 {
> > > + reg = <4>;
> > > + };
> > > +};
> > > +
> > > + {
> > > + status = "okay";
> > > +
> > > + /* default for ar934x, except for 1000M and 10M */
> > > +
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
It has been about a month now since v4. Is it time to apply this? I am
using it in production. It doesn't touch anything else, so I am not
seeing a downside in merging.
--
Russell Senior
russ...@personaltelco.net
On Sun, Jun 13, 2021 at 8:33 PM Russell Senior
wrote:
>
> Is it time to apply this?
>
> --
> Russell Senior
> russ...@personaltelco.net
>
> On Fri, Jun 4, 2021 at 5:29 PM Russell Senior
> wrote:
> >
> > This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
> > a 802.11n wireless with a feed+dish form factor. This device was previously
> > supported by the ar71xx loco-m-xw firmware.
> >
> > Specifications:
> > - Atheros AR9342 SoC
> > - 64 MB RAM
> > - 8 MB SPI flash
> > - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> > - Power and LAN green LEDs
> > - 4x RSSI LEDs (red, orange, green, green)
> > - UART (115200 8N1)
> >
> > Flashing via stock GUI:
> > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
> >https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
> > - Upload the factory image via AirOS web GUI.
> >
> > Flashing via TFTP:
> > - Use a pointy tool (e.g., unbent paperclip) to keep the
> >reset button pressed.
> > - Power on the device (keep reset button pressed).
> > - Keep pressing until LEDs flash alternatively LED1+LED3 =>
> >LED2+LED4 => LED1+LED3, etc.
> > - Release reset button.
> > - The device starts a TFTP server at 192.168.1.20.
> > - Set a static IP on the computer (e.g., 192.168.1.21/24).
> > - Upload via tftp the factory image:
> > $ tftp 192.168.1.20
> > tftp> bin
> > tftp> trace
> > tftp> put
> > openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
> >
> > WARNING: so far, no non-destructive method has been discovered for
> > opening the enclosure to reach the serial console. Internal photos
> > are available here: https://fcc.io/SWX-NBM5HP
> >
> > since v1:
> > * renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
> > since v2:
> > * removed redundant mtd-mac-address from dts
> > since v3:
> > * based on testimony of Joe Ayers :
> > * the bricking problem was resolved by 076d58d3440f (2016-02)
> > * the tftp flashing problem was resolved by 6009b3fd586a (2018-11)
> >so, removed the associated warnings.
> >
> > Signed-off-by: Russell Senior
> > ---
> > .../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 34 +++
> > .../generic/base-files/etc/board.d/01_leds| 1 +
> > .../generic/base-files/etc/board.d/02_network | 1 +
> > target/linux/ath79/image/generic-ubnt.mk | 8 +
> > 4 files changed, 44 insertions(+)
> > create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> >
> > diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > new file mode 100644
> > index 00..6db058f887
> > --- /dev/null
> > +++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> > @@ -0,0 +1,34 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +
> > +#include "ar9342_ubnt_xw.dtsi"
> > +
> > +/ {
> > + compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
> > + model = "Ubiquiti PowerBeam M (XW)";
> > +};
> > +
> > + {
> > + status = "okay";
> > +
> > + phy-mask = <4>;
> > +
> > + phy4: ethernet-phy@4 {
> > + reg = <4>;
> > + };
> > +};
> > +
> > + {
> > + status = "okay";
> > +
> > + /* default for ar934x, except for 1000M and 10M */
> > + pll-data = <0x0200 0x0101 0x1313>;
> > +
> > + phy-mode = "rgmii-id";
> > + phy-handle = <>;
> > +
> > + gmac-config {
> > + device = <>;
> > + rxd-delay = <3>;
> > + rxdv-delay = <3>;
> > + };
> > +};
> > diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> > b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> > index 1990353394..35ce90aeb4 100644
> > --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> > +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> > @@ -383,6 +383,7 @@ ubnt,nanostation
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
Random observations follow: I received another PBE-M5-400 feedhorn today. It arrived with XW.v6.1.4 installed. Using its GUI, I tried directly flashing a recent master branch OpenWrt with my support commit on top and it complained with a "firmware image check failed". Using the v6.1.4 GUI, I downgraded to XW.v5.6.15-sign.31612.170908.1440.bin. That was accepted and the device rebooted into v5.6.15. Using the v5.6.15 GUI, I tried to flash my same OpenWrt image and got: "This firmware is not trusted by airOS. To maintain security, it will not be loaded. Please load trusted firmware." >From those observations, I infer that reverting to 5.5.x is still needed to use the GUI to flash. Reverting to 5.5.x still requires some ssh'ing and scp'ing, but it does not require TFTP, and might still be a desirable path for people allergic to TFTP for whatever reason. I also tried directly TFTP flashing from v6.1.4 to my openwrt factory image and confirmed that worked. When I tried TFTP flashing from v6.1.4 to v5.5.10-u2, I got the message: "Error code 2: Firmware check failed". When I tried TFTP flashing from v6.1.4 to v5.6.15 (unsigned), that succeeded, (the uboot partition /dev/mtdblock0 had the same md5sum hash as on v6.1.4), but from v5.6.15 (unsigned) I could scp v5.5.10-u2 to /tmp/fwupdate.bin and use the built in fwupdate.real to update: XW.v5.6.15# fwupdate.real -m fwupdate.bin Current ver: 329231 New version: 328970 No need to fix. Writing 'u-boot ' to /dev/mtd0(u-boot ) ... [%100] Writing 'kernel ' to /dev/mtd2(kernel ) ... [%100] Writing 'rootfs ' to /dev/mtd3(rootfs ) ... [%100] Done Then you can ssh into v5.5.10-u2 (with a relaxation of modern ssh key exchange algorithms): $ ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 ubnt@192.168.1.20 and confirm the md5sum of the u-boot has changed: XW.v5.5.10-u2# dd if=/dev/mtdblock0 | md5sum 512+0 records in 512+0 records out 753d74c53339edfd8f8289e772f5abeb - and you won't have any pesky "Firmware checks" anymore, if you need that. I also did some experiments with the current firmware v6.3.2. It has a yet again different u-boot md5sum, and for as-yet-unknown reasons I started to have trouble connecting with it at 192.168.1.20. I have some packet captures that suggest it's trying to phone home, requesting DHCP and so forth. On an isolated network, I was able to TFTP directly from v6.3.2 to my OpenWrt firmware. I'll continue experimenting, but I don't see any of this as a reason to hold up merging the support-adding commit. On Mon, Jun 14, 2021 at 1:05 PM Russell Senior wrote: > > On Mon, Jun 14, 2021 at 6:54 AM Joe Ayers wrote: > > > > > > I'm having a bit of heartburn with continuing with these instructions: > > > > > > > > > Flashing via stock GUI: > > > > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first > > > > > (see > > > > >https://openwrt.org/toh/ubiquiti/powerbeam installation > > > > > instructions) > > > > > > > > This issue was resolved with: > > > > > > > > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc > > > > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 > > > > > > Those commits resolve the problem for TFTP, but if people want to use > > > the GUI, they still need to downgrade, right? Both instructions are > > > included in the commit message. Note that the TFTP instructions don't > > > mention downgrading. > > > > I remember flashing via the stock GUI in AirOS v5.6.? had worked. As > > I recall, firmware signatures were not required until a future AirOS > > version . If so, downgrading shouldn't need to occur all the way > > back to v5.5.10-u2. The AirOS release note history should tell us > > when firmware signing was introduced. I'm sorry, I don't have time > > available to substantiate right now, to make sure my memory is > > correct. > > > > Would anyone ever follow the GUI flash with all the steps, when 1 tftp > > flash works?I suspect there is no impact regardless, might just > > move forward, not worth the time. > > No one seems to have tried all the starting condition possibilities, I > certainly haven't. If we were being crushingly complete in testing, we > would try every one of them. If we knew how likely each starting > condition is, we could even weight our instructions accordingly. Given > that serial access is not easy right now, because of not being able > (at least I'm not able) to non-destructively open the feedhorn > enclosure to get access to the serial console pins, I'd rather not > risk trying an Ai
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
On Mon, Jun 14, 2021 at 6:54 AM Joe Ayers wrote: > > > > I'm having a bit of heartburn with continuing with these instructions: > > > > > > > Flashing via stock GUI: > > > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see > > > >https://openwrt.org/toh/ubiquiti/powerbeam installation instructions) > > > > > > This issue was resolved with: > > > > > > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc > > > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 > > > > Those commits resolve the problem for TFTP, but if people want to use > > the GUI, they still need to downgrade, right? Both instructions are > > included in the commit message. Note that the TFTP instructions don't > > mention downgrading. > > I remember flashing via the stock GUI in AirOS v5.6.? had worked. As > I recall, firmware signatures were not required until a future AirOS > version . If so, downgrading shouldn't need to occur all the way > back to v5.5.10-u2. The AirOS release note history should tell us > when firmware signing was introduced. I'm sorry, I don't have time > available to substantiate right now, to make sure my memory is > correct. > > Would anyone ever follow the GUI flash with all the steps, when 1 tftp > flash works?I suspect there is no impact regardless, might just > move forward, not worth the time. No one seems to have tried all the starting condition possibilities, I certainly haven't. If we were being crushingly complete in testing, we would try every one of them. If we knew how likely each starting condition is, we could even weight our instructions accordingly. Given that serial access is not easy right now, because of not being able (at least I'm not able) to non-destructively open the feedhorn enclosure to get access to the serial console pins, I'd rather not risk trying an AirOS that might make it impossible to recover. Given that this is *JUST A COMMIT MESSAGE* and not a mutable, improvable, instruction (which should live on the wiki anyway), it seems to me reasonable to accept being a little conservative in the instructions here, even if some of the steps turn out to not be strictly necessary. -- Russell Senior russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
On Sun, Jun 13, 2021 at 9:52 PM Joe Ayers wrote: > > I'm having a bit of heartburn with continuing with these instructions: > > > Flashing via stock GUI: > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see > >https://openwrt.org/toh/ubiquiti/powerbeam installation instructions) > > This issue was resolved with: > > https://github.com/openwrt/openwrt/commit/076d58d3440f382c536ea8874f58b0df23c263bc > https://github.com/openwrt/openwrt/commit/6009b3fd586a1fd91400074080afb9545c6cf7e2 Those commits resolve the problem for TFTP, but if people want to use the GUI, they still need to downgrade, right? Both instructions are included in the commit message. Note that the TFTP instructions don't mention downgrading. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
Is it time to apply this?
--
Russell Senior
russ...@personaltelco.net
On Fri, Jun 4, 2021 at 5:29 PM Russell Senior wrote:
>
> This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
> a 802.11n wireless with a feed+dish form factor. This device was previously
> supported by the ar71xx loco-m-xw firmware.
>
> Specifications:
> - Atheros AR9342 SoC
> - 64 MB RAM
> - 8 MB SPI flash
> - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> - Power and LAN green LEDs
> - 4x RSSI LEDs (red, orange, green, green)
> - UART (115200 8N1)
>
> Flashing via stock GUI:
> - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
>https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
> - Upload the factory image via AirOS web GUI.
>
> Flashing via TFTP:
> - Use a pointy tool (e.g., unbent paperclip) to keep the
>reset button pressed.
> - Power on the device (keep reset button pressed).
> - Keep pressing until LEDs flash alternatively LED1+LED3 =>
>LED2+LED4 => LED1+LED3, etc.
> - Release reset button.
> - The device starts a TFTP server at 192.168.1.20.
> - Set a static IP on the computer (e.g., 192.168.1.21/24).
> - Upload via tftp the factory image:
> $ tftp 192.168.1.20
> tftp> bin
> tftp> trace
> tftp> put
> openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
>
> WARNING: so far, no non-destructive method has been discovered for
> opening the enclosure to reach the serial console. Internal photos
> are available here: https://fcc.io/SWX-NBM5HP
>
> since v1:
> * renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
> since v2:
> * removed redundant mtd-mac-address from dts
> since v3:
> * based on testimony of Joe Ayers :
> * the bricking problem was resolved by 076d58d3440f (2016-02)
> * the tftp flashing problem was resolved by 6009b3fd586a (2018-11)
>so, removed the associated warnings.
>
> Signed-off-by: Russell Senior
> ---
> .../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 34 +++
> .../generic/base-files/etc/board.d/01_leds| 1 +
> .../generic/base-files/etc/board.d/02_network | 1 +
> target/linux/ath79/image/generic-ubnt.mk | 8 +
> 4 files changed, 44 insertions(+)
> create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> new file mode 100644
> index 00..6db058f887
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include "ar9342_ubnt_xw.dtsi"
> +
> +/ {
> + compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
> + model = "Ubiquiti PowerBeam M (XW)";
> +};
> +
> + {
> + status = "okay";
> +
> + phy-mask = <4>;
> +
> + phy4: ethernet-phy@4 {
> + reg = <4>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + /* default for ar934x, except for 1000M and 10M */
> + pll-data = <0x0200 0x0101 0x1313>;
> +
> + phy-mode = "rgmii-id";
> + phy-handle = <>;
> +
> + gmac-config {
> + device = <>;
> + rxd-delay = <3>;
> + rxdv-delay = <3>;
> + };
> +};
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> index 1990353394..35ce90aeb4 100644
> --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> @@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\
> ubnt,nanostation-m|\
> ubnt,nanostation-m-xw|\
> ubnt,picostation-m|\
> +ubnt,powerbeam-m-xw|\
> ubnt,powerbridge-m|\
> ubnt,rocket-m)
> ucidef_set_rssimon "wlan0" "20" "1"
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> index 4133b9d7d3..6e31cdac69 100644
> --- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
> @@ -85,6 +85,7 @@ ath79_setup_interfaces()
> ubnt,picostation-m|\
> ubnt,powerbeam-5ac-500|\
> ubnt,powerbeam-5ac-gen2|\
> + ubnt,powerbeam-m-xw|\
> ubnt,powerbridge-m|\
> ubnt,rocke
[PATCH v4] ath79: add support for Ubiquiti PowerBeam M (XW)
This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first (see
https://openwrt.org/toh/ubiquiti/powerbeam installation instructions)
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM5HP
since v1:
* renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
since v2:
* removed redundant mtd-mac-address from dts
since v3:
* based on testimony of Joe Ayers :
* the bricking problem was resolved by 076d58d3440f (2016-02)
* the tftp flashing problem was resolved by 6009b3fd586a (2018-11)
so, removed the associated warnings.
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 34 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 44 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
new file mode 100644
index 00..6db058f887
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 1990353394..35ce90aeb4 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4133b9d7d3..6e31cdac69 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -85,6 +85,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+ ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m|\
ubnt,unifiac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 733d803d7a..5948e059e8 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
+define Device/ubnt_powerbeam-m-xw
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := PowerBeam M
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m-xw
+
define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
SOC := ar7241
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] ath79: add support for Ubiquiti PowerBeam M (XW)
This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM5HP
since v1:
* renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
since v2:
* removed redundant mtd-mac-address from dts
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 34 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 44 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
new file mode 100644
index 00..6db058f887
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
@@ -0,0 +1,34 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 1990353394..35ce90aeb4 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4133b9d7d3..6e31cdac69 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -85,6 +85,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+ ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m|\
ubnt,unifiac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 733d803d7a..5948e059e8 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
+define Device/ubnt_powerbeam-m-xw
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := PowerBeam M
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m-xw
+
define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
SOC := ar7241
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
I am going to send a v3 patch with the redundant mtd-mac-address
removed in a few minutes, hopefully in-reply-to this thread if I can
manage to do it right.
On Thu, May 27, 2021 at 3:01 PM Adrian Schmutzler
wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Vincent Wiemann
> > Sent: Sonntag, 23. Mai 2021 14:20
> > To: Russell Senior ; openwrt-
> > de...@lists.openwrt.org
> > Subject: Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
> >
> > Just as a side-note:
> > There are 5 different versions of the PowerBeam with different device IDs...
> >
> > Source:
> > https://github.com/freifunk-gluon/gluon/issues/94#issuecomment-
> > 510831878
> > -- PowerBeam M5
> > -- ERP 26 dBm according to datasheet
> > 'e3e5' = { -- PBE-M5-300
> > pa_gain = 4
> > ant_gain = 22
> > },
> > 'e4e5' = { -- PBE-M5-400
> > pa_gain = 4
> > ant_gain = 25
> > },
> > 'e6e5' = { -- PBE-M5-400 ISO!!
> > pa_gain = 4
> > ant_gain = 25
> > },
> > 'e885' = { -- PBE-M5-620
> > pa_gain = 4
> > ant_gain = 29
> > },
> >
> > -- Powerbeam M2 400?
> > -- ERP 28 dBm according to datasheet
> > 'e6c2' = { -- PBE-M2-400
> > pa_gain = 6
> > ant_gain = 18 dBi
> > },
> >
> > While I think there shouldn't be different DTS files for them, there is a
> > script
> > missing that respects the antenna and external PA gain of these devices.
>
> So far, we have not cared about this at device-support level (at all) as far
> as I remember.
> I'm not sure whether we apply antenna gain for ath79 Ubiquiti _at all_ by
> default. (From what I remember we don't).
>
> So, I tend to not care about this for this particular PR.
>
> Best
>
> Adrian
>
> >
> > Best,
> >
> > Vincent
> >
> >
> >
> > On 5/23/21 1:59 PM, Russell Senior wrote:
> > > This patch adds support for the Ubiquiti PowerBeam M (XW), e.g.
> > > PBE-M5-400, a 802.11n wireless with a feed+dish form factor. This
> > > device was previously supported by the ar71xx loco-m-xw firmware.
> > >
> > > Specifications:
> > > - Atheros AR9342 SoC
> > > - 64 MB RAM
> > > - 8 MB SPI flash
> > > - 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
> > > - Power and LAN green LEDs
> > > - 4x RSSI LEDs (red, orange, green, green)
> > > - UART (115200 8N1)
> > >
> > > Flashing via stock GUI:
> > > - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
> > > device! Read the wiki for more info.
> > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> > > - Upload the factory image via AirOS web GUI.
> > >
> > > Flashing via TFTP:
> > > - WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
> > > device! Read the wiki for more info.
> > > - Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
> > > - Use a pointy tool (e.g., unbent paperclip) to keep the
> > > reset button pressed.
> > > - Power on the device (keep reset button pressed).
> > > - Keep pressing until LEDs flash alternatively LED1+LED3 =>
> > > LED2+LED4 => LED1+LED3, etc.
> > > - Release reset button.
> > > - The device starts a TFTP server at 192.168.1.20.
> > > - Set a static IP on the computer (e.g., 192.168.1.21/24).
> > > - Upload via tftp the factory image:
> > > $ tftp 192.168.1.20
> > > tftp> bin
> > > tftp> trace
> > > tftp> put
> > > openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-
> > factory.bin
> > >
> > > WARNING: so far, no non-destructive method has been discovered for
> > > opening the enclosure to reach the serial console. Internal photos are
> > > available here: https://fcc.io/SWX-NBM5HP
> > >
> > > Changes since v1:
> > > * renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
> > >
> > > Signed-off-by: Russell S
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Tue, May 25, 2021 at 2:33 AM Russell Senior
wrote:
>
> On Tue, May 25, 2021 at 1:40 AM Rafał Miłecki wrote:
> >
> > On 23.05.2021 13:59, Russell Senior wrote:
> > > + {
> > > + status = "okay";
> > > +
> > > + /* default for ar934x, except for 1000M and 10M */
> > > + pll-data = <0x0200 0x0101 0x1313>;
> > > +
> > > + mtd-mac-address = < 0x0>;
> >
> > I'd love to have new DTS use upstream "nvmem-cells" property for that basic
> > case.
> >
> > Example:
> > arm64: dts: broadcom: bcm4908: add Ethernet MAC addr
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f01f5cdb548352418b34ce77db02a560fe2913b
>
> Not sure this qualifies as a new DTS, it is derived almost entirely
> from other ubiquiti ar9342 hardware's DTS. I think such a conversion
> would make more sense to do wholesale, later on. I'm not particularly
> prepared to take that on at the moment.
Looking closer, I realize that the mtd-mac-address line isn't even
needed, since it will inherit it from the included
ar9342_ubnt_xw.dtsi.
I took a swing at replacing mtd-mac-address with nvmem-cells as in
your example, but I got an incomprehensible cascade of errors from
unrelated ath79 devices dts, like this:
"Missing #address-cells in interrupt provider"
which made no sense to me and I gave up.
>
> $ git grep mtd-mac-address | wc -l
> 1119
>
> $ git grep -l mtd-mac-address | wc -l
> 568
>
> >
> >
> > > +
> > > + phy-mode = "rgmii-id";
> > > + phy-handle = <>;
> > > +
> > > + gmac-config {
> > > + device = <>;
> > > + rxd-delay = <3>;
> > > + rxdv-delay = <3>;
> > > + };
> > > +};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Tue, May 25, 2021 at 3:57 AM Russell Senior wrote: > > On Tue, May 25, 2021 at 3:33 AM Vincent Wiemann > wrote: > > > > On 5/25/21 2:23 AM, Russell Senior wrote: > > > On Mon, May 24, 2021 at 2:51 AM Vincent Wiemann > > > wrote: > > >> > > >> Hi Russel, > > >> > > >> On 5/24/21 1:06 AM, Russell Senior wrote: > > >>> On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, > > >>> not "e6 c2". > > >> > > >> That's very interesting... I think the PowerBeam 400 was sold under the > > >> NanoBeam series at the beginning. So there might be an entry missing. > > >> Is your PowerBeam old? > > > > > > It was purchased circa 2015. It is clearly marked PowerBeam M2 on the > > > sticker, along with "M/N: PBE-M2-400", although the FCCID suggests > > > some overlap with NanoBeam (SWX-NBM2HP). > > > > > > > Thank you for that information. We've also purchased a PowerBeam in 2015 > > where on the sticker it says PowerBeam, but the box stated NanoBeam... (sorry for the empty reply ... gmail--) I went and checked my box, it says PowerBeam M2. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Tue, May 25, 2021 at 3:33 AM Vincent Wiemann wrote: > > On 5/25/21 2:23 AM, Russell Senior wrote: > > On Mon, May 24, 2021 at 2:51 AM Vincent Wiemann > > wrote: > >> > >> Hi Russel, > >> > >> On 5/24/21 1:06 AM, Russell Senior wrote: > >>> On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, not > >>> "e6 c2". > >> > >> That's very interesting... I think the PowerBeam 400 was sold under the > >> NanoBeam series at the beginning. So there might be an entry missing. > >> Is your PowerBeam old? > > > > It was purchased circa 2015. It is clearly marked PowerBeam M2 on the > > sticker, along with "M/N: PBE-M2-400", although the FCCID suggests > > some overlap with NanoBeam (SWX-NBM2HP). > > > > Thank you for that information. We've also purchased a PowerBeam in 2015 > where on the sticker it says PowerBeam, but the box stated NanoBeam... ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Tue, May 25, 2021 at 1:40 AM Rafał Miłecki wrote:
>
> On 23.05.2021 13:59, Russell Senior wrote:
> > + {
> > + status = "okay";
> > +
> > + /* default for ar934x, except for 1000M and 10M */
> > + pll-data = <0x0200 0x0101 0x1313>;
> > +
> > + mtd-mac-address = < 0x0>;
>
> I'd love to have new DTS use upstream "nvmem-cells" property for that basic
> case.
>
> Example:
> arm64: dts: broadcom: bcm4908: add Ethernet MAC addr
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f01f5cdb548352418b34ce77db02a560fe2913b
Not sure this qualifies as a new DTS, it is derived almost entirely
from other ubiquiti ar9342 hardware's DTS. I think such a conversion
would make more sense to do wholesale, later on. I'm not particularly
prepared to take that on at the moment.
$ git grep mtd-mac-address | wc -l
1119
$ git grep -l mtd-mac-address | wc -l
568
>
>
> > +
> > + phy-mode = "rgmii-id";
> > + phy-handle = <>;
> > +
> > + gmac-config {
> > + device = <>;
> > + rxd-delay = <3>;
> > + rxdv-delay = <3>;
> > + };
> > +};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
On Mon, May 24, 2021 at 2:51 AM Vincent Wiemann wrote: > > Hi Russel, > > On 5/24/21 1:06 AM, Russell Senior wrote: > > On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, not > > "e6 c2". > > That's very interesting... I think the PowerBeam 400 was sold under the > NanoBeam series at the beginning. So there might be an entry missing. > Is your PowerBeam old? It was purchased circa 2015. It is clearly marked PowerBeam M2 on the sticker, along with "M/N: PBE-M2-400", although the FCCID suggests some overlap with NanoBeam (SWX-NBM2HP). -- Russell Senior russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
>>>>> "Vincent" == Vincent Wiemann writes:
Vincent> Just as a side-note: There are 5 different versions of the
Vincent> PowerBeam with different device IDs...
Vincent> Source:
Vincent>
https://github.com/freifunk-gluon/gluon/issues/94#issuecomment-510831878
Vincent> -- PowerBeam M5 -- ERP 26 dBm according to datasheet 'e3e5' = {
Vincent> -- PBE-M5-300 pa_gain = 4 ant_gain = 22 }, 'e4e5' = { --
Vincent> PBE-M5-400 pa_gain = 4 ant_gain = 25 }, 'e6e5' = { --
Vincent> PBE-M5-400 ISO!! pa_gain = 4 ant_gain = 25 }, 'e885' = { --
Vincent> PBE-M5-620 pa_gain = 4 ant_gain = 29 },
FWIW, I see the "e4 e5" bytes in the ART partition at offset 0x000c and 0xa01e.
Vincent>-- Powerbeam M2 400? -- ERP 28 dBm according to
Vincent> datasheet 'e6c2' = { -- PBE-M2-400 pa_gain = 6 ant_gain = 18
Vincent> dBi },
On the PowerBeam M2 (PBE-M2-400) I see "e2 c2" in the same locations, not "e6
c2".
Vincent> While I think there shouldn't be different DTS files for them,
Vincent> there is a script missing that respects the antenna and
Vincent> external PA gain of these devices.
-ENOPATCH
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] ath79: add support for Ubiquiti PowerBeam M (XW)
This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_powerbeam-m-xw-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM5HP
Changes since v1:
* renamed from ubnt,powerbeam-m to ubnt,powerbeam-m-xw
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts | 36 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 46 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
new file mode 100644
index 00..edcb06acef
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m-xw.dts
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m-xw", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ mtd-mac-address = < 0x0>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 1990353394..35ce90aeb4 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4133b9d7d3..6e31cdac69 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -85,6 +85,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+ ubnt,powerbeam-m-xw|\
ubnt,powerbridge-m|\
ubnt,rocket-m|\
ubnt,unifiac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 733d803d7a..5948e059e8 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
+define Device/ubnt_powerbeam-m-xw
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := PowerBeam M
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m-xw
+
define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
SOC := ar7241
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: add support for Ubiquiti PowerBeam M (XW)
This patch adds support for the Ubiquiti PowerBeam M (XW), e.g. PBE-M5-400,
a 802.11n wireless with a feed+dish form factor. This device was previously
supported by the ar71xx loco-m-xw firmware.
Specifications:
- Atheros AR9342 SoC
- 64 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet port, 24 Vdc PoE-in
- Power and LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1)
Flashing via stock GUI:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Upload the factory image via AirOS web GUI.
Flashing via TFTP:
- WARNING: flashing OpenWrt from AirOS v5.6 or newer will brick your
device! Read the wiki for more info.
- Downgrade to AirOS v5.5.x (latest available is 5.5.10-u2) first.
- Use a pointy tool (e.g., unbent paperclip) to keep the
reset button pressed.
- Power on the device (keep reset button pressed).
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button.
- The device starts a TFTP server at 192.168.1.20.
- Set a static IP on the computer (e.g., 192.168.1.21/24).
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put openwrt-ath79-generic-x-ubnt_powerbeam-m-squashfs-factory.bin
WARNING: so far, no non-destructive method has been discovered for
opening the enclosure to reach the serial console. Internal photos
are available here: https://fcc.io/SWX-NBM5HP
Signed-off-by: Russell Senior
---
.../ath79/dts/ar9342_ubnt_powerbeam-m.dts | 36 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
target/linux/ath79/image/generic-ubnt.mk | 8 +
4 files changed, 46 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
new file mode 100644
index 00..1a2ce428f2
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_powerbeam-m.dts
@@ -0,0 +1,36 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar9342_ubnt_xw.dtsi"
+
+/ {
+ compatible = "ubnt,powerbeam-m", "ubnt,xw", "qca,ar9342";
+ model = "Ubiquiti PowerBeam M (XW)";
+};
+
+ {
+ status = "okay";
+
+ phy-mask = <4>;
+
+ phy4: ethernet-phy@4 {
+ reg = <4>;
+ };
+};
+
+ {
+ status = "okay";
+
+ /* default for ar934x, except for 1000M and 10M */
+ pll-data = <0x0200 0x0101 0x1313>;
+
+ mtd-mac-address = < 0x0>;
+
+ phy-mode = "rgmii-id";
+ phy-handle = <>;
+
+ gmac-config {
+ device = <>;
+ rxd-delay = <3>;
+ rxdv-delay = <3>;
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 1990353394..3bf120b92b 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -383,6 +383,7 @@ ubnt,nanostation-loco-m-xw|\
ubnt,nanostation-m|\
ubnt,nanostation-m-xw|\
ubnt,picostation-m|\
+ubnt,powerbeam-m|\
ubnt,powerbridge-m|\
ubnt,rocket-m)
ucidef_set_rssimon "wlan0" "20" "1"
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 4133b9d7d3..2b4ab946e1 100644
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -85,6 +85,7 @@ ath79_setup_interfaces()
ubnt,picostation-m|\
ubnt,powerbeam-5ac-500|\
ubnt,powerbeam-5ac-gen2|\
+ ubnt,powerbeam-m|\
ubnt,powerbridge-m|\
ubnt,rocket-m|\
ubnt,unifiac-lite|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 733d803d7a..5f403984be 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -328,6 +328,14 @@ define Device/ubnt_powerbeam-5ac-gen2
endef
TARGET_DEVICES += ubnt_powerbeam-5ac-gen2
+define Device/ubnt_powerbeam-m
+ $(Device/ubnt-xw)
+ DEVICE_MODEL := PowerBeam M
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += loco-m-xw
+endef
+TARGET_DEVICES += ubnt_powerbeam-m
+
define Device/ubnt_powerbridge-m
$(Device/ubnt-xm)
SOC := ar7241
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek: Fix VLAN issues introduced by multicast patches
I did a buld with the patch applied to commit e1adb1fa39dd5ef97280ad1b2bb9e8ff4c43674f and it fixes the bug I reported on my Netgear GS198Tv3. -- Rissell Senior russ...@personaltelco.net On Sat, May 8, 2021 at 11:16 AM Bjørn Mork wrote: > > John Crispin writes: > > > @bmork, kindly confirm :-) > > Works for me on 8380, ignoring whitespace issues. Tested on Netgear > GS108Tv3 with a very basic VLAN config. Cannot say anything about 839x > or 93xx. > > > Bjørn > > ___ > 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: realtek: Setup all VLANs with default configurations
This is the configuration that was previously working. Note also, it works for about 400 (plus or minus 70) seconds and then stops. config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config device 'switch' option name 'switch' option type 'bridge' option macaddr '9c:c9:eb:aa:bb:cc' config bridge-vlan 'wan_vlan' option device 'switch' option vlan '1' option ports 'lan1' config interface 'wan' option ifname 'switch.1' option proto 'dhcp' config device 'wan_switch_1_dev' option name 'switch.1' option macaddr '9c:c9:eb:aa:bb:cc' config interface 'wan6' option ifname 'switch.1' option proto 'dhcpv6' option reqprefix '60' config bridge-vlan 'pub_vlan' option device 'switch' option vlan '2' option ports 'lan2 lan3 lan4 lan5 lan6 lan7 lan8' config interface 'pub' option proto 'static' option ipaddr '10.0.0.161' option ifname 'switch.2' option netmask '255.255.255.224' config device 'lan_switch_2_dev' option macaddr '9e:c9:eb:d8:d8:d0' option name 'switch.2' On Fri, May 7, 2021 at 10:41 PM Birger Koblitz wrote: > > Dear Russel, > > depending on how a particular device was configured previously by > u-boot, this commit might have enabled proper vlan-filtering for the > first time on your device. The default vlan-configuration has port 1 > configured as management port with vlan-id 100. So your DHCP server > would need to answer with this vlan-id. Could you check that > - before the commit, the device was actually filtering vlans > - after the commit you have a correct vlan configuration on the device > talking to the switch on port 1 and that this corresponds to the vlan > configuration of that port > > Cheers, >Birger > > On 08/05/2021 01:55, Russell Senior wrote: > > The recent commit 4342d27ec90cd0988fd3e62ccefbe66f2e691372 to OpenWrt > > seems to have broken the network on my Netgear GS108T v3. After about > > 300-500 seconds of uptime, the interface (in my case, switch.1 > > configured as WAN) stops receiving traffic. Nothing in dmesg or syslog > > at the time of failure. From tcpdump -i switch.1 I can see the device > > ARP'ing for the gateway address (which it received by DHCP) but not > > seeing anything come back. Rolling back to the commit immediately > > before and I don't see the problem and can ping the gateway > > indefinitely. > > > > Thanks! > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: realtek: Setup all VLANs with default configurations
The recent commit 4342d27ec90cd0988fd3e62ccefbe66f2e691372 to OpenWrt seems to have broken the network on my Netgear GS108T v3. After about 300-500 seconds of uptime, the interface (in my case, switch.1 configured as WAN) stops receiving traffic. Nothing in dmesg or syslog at the time of failure. From tcpdump -i switch.1 I can see the device ARP'ing for the gateway address (which it received by DHCP) but not seeing anything come back. Rolling back to the commit immediately before and I don't see the problem and can ping the gateway indefinitely. Thanks! -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: add missing CONFIG symbol for testing kernel 5.10
CONFIG_MFD_RB4XX_CPLD is missing from the testing kernel config, add it disabled Signed-off-by: Russell Senior --- target/linux/ath79/config-5.10 | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ath79/config-5.10 b/target/linux/ath79/config-5.10 index 9aa320dcda..d4abddb445 100644 --- a/target/linux/ath79/config-5.10 +++ b/target/linux/ath79/config-5.10 @@ -96,6 +96,7 @@ CONFIG_MDIO_BUS=y CONFIG_MDIO_DEVICE=y CONFIG_MDIO_GPIO=y CONFIG_MEMFD_CREATE=y +# CONFIG_MFD_RB4XX_CPLD is not set CONFIG_MFD_SYSCON=y CONFIG_MIGRATION=y CONFIG_MIPS=y -- 2.31.1 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
commit 2683eeb627 breaks buffalo wzr600dhp
Building master (182eaa4916) with kernel 5.10 and booting, I get: [...] [0.706515] spi-nor spi0.0: mx25l12805d (16384 Kbytes) [0.716193] spi-nor spi0.1: unrecognized JEDEC id bytes: 20 18 c2 20 18 c2 [0.723165] spi-nor: probe of spi0.1 failed with error -2 [0.730576] libphy: Fixed MDIO Bus: probed [0.737716] ag71xx 1900.eth: invalid MAC address, using random address [1.062573] libphy: ag71xx_mdio: probed [1.069024] switch0: Atheros AR8316 rev. 1 switch registered on mdio.0 [1.077657] ag71xx 1900.eth: connected to PHY at fixed-0:00 [uid=, driver=Generic PHY] [1.087283] eth0: Atheros AG71xx at 0xb900, irq 4, mode: rgmii [1.093851] ag71xx 1a00.eth: invalid MAC address, using random address [1.164292] random: fast init done [1.417471] ar8316: Using port 4 as PHY [2.470428] ag71xx 1a00.eth: connected to PHY at mdio.0:04 [uid=004dd041, driver=Atheros AR8216/AR8236/AR8316] [2.481391] eth1: Atheros AG71xx at 0xba00, irq 5, mode: rgmii [2.487813] i2c /dev entries driver [2.492936] NET: Registered protocol family 10 [2.502467] Segment Routing with IPv6 [2.506307] NET: Registered protocol family 17 [2.510841] 8021q: 802.1Q VLAN Support v1.8 [2.518597] /dev/root: Can't open blockdev [2.522754] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6 [2.530242] Please append a correct "root=" boot option; here are the available partitions: [2.538600] 1f00 16384 mtdblock0 [2.538604] (driver?) [2.545140] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [2.553386] Rebooting in 1 seconds.. Reverting 2683eeb627 lets it work again. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] busybox: udhcpc, allow zero length dhcp options
This patch skips zero length DHCP options instead of failing.
v2 changelog:
* fix off-by-one
* add a warning message
* move commit message into patch sent upstream
Signed-off-by: Russell Senior
---
...205-udhcpc_allow_zero_length_options.patch | 49 +++
1 file changed, 49 insertions(+)
create mode 100644
package/utils/busybox/patches/205-udhcpc_allow_zero_length_options.patch
diff --git
a/package/utils/busybox/patches/205-udhcpc_allow_zero_length_options.patch
b/package/utils/busybox/patches/205-udhcpc_allow_zero_length_options.patch
new file mode 100644
index 00..abe8baf54f
--- /dev/null
+++ b/package/utils/busybox/patches/205-udhcpc_allow_zero_length_options.patch
@@ -0,0 +1,49 @@
+From 7eed119b84b0f7efb7ef351940dd895dc2379eb3 Mon Sep 17 00:00:00 2001
+From: Russell Senior
+Date: Mon, 15 Mar 2021 23:27:58 -0700
+Subject: [PATCH v2] udhcpc: ignore zero-length DHCP options
+
+Discovered that the DHCP server on a TrendNet router (unknown model)
+provides a zero-length option 12 (Host Name) in the DHCP ACK message. This
+has the effect of causing udhcpc to drop the rest of the options, including
+option 51 (IP Address Lease Time), 3 (Router), and 6 (Domain Name Server),
+most importantly leaving the OpenWrt device with no default gateway.
+
+The TrendNet behavior violates RFC 2132, which in Section 3.14 declares that
+option 12 has a miniumum length of 1 octet. It is perhaps not a cosmic
coincidence
+that I found this behavior on Pi Day.
+
+This patch allows zero length options without bailing out, by simply skipping
them.
+
+v2 changelog:
+* advance the optionptr by two bytes, not one;
+* add a message to warn about the rfc violation;
+
+Signed-off-by: Russell Senior
+---
+ networking/udhcp/common.c | 9 +++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/networking/udhcp/common.c b/networking/udhcp/common.c
+index 4bc719001..a16fd85d0 100644
+--- a/networking/udhcp/common.c
b/networking/udhcp/common.c
+@@ -277,8 +277,13 @@ uint8_t* FAST_FUNC udhcp_scan_options(struct dhcp_packet
*packet, struct dhcp_sc
+ goto complain; /* complain and return NULL */
+ len = 2 + scan_state->optionptr[OPT_LEN];
+ scan_state->rem -= len;
+- /* So far no valid option with length 0 known. */
+- if (scan_state->rem < 0 || scan_state->optionptr[OPT_LEN] == 0)
++ /* skip any options with zero length */
++ if (scan_state->optionptr[OPT_LEN] == 0) {
++ scan_state->optionptr += 2;
++ bb_simple_error_msg("warning: zero length DHCP option
violates rfc2132, skipping");
++ continue;
++ }
++ if (scan_state->rem < 0)
+ goto complain; /* complain and return NULL */
+
+ if (scan_state->optionptr[OPT_CODE] == DHCP_OPTION_OVERLOAD) {
+--
+2.30.1
+
--
2.30.1
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] busybox: udhcpc, allow zero length dhcp options
Discovered that the DHCP server on a TrendNet router (unknown model)
provides a zero-length option 12 (Host Name) in the DHCP ACK message. This
has the effect of causing udhcpc to drop the rest of the options, including
option 51 (IP Address Lease Time), 3 (Router), and 6 (Domain Name Server),
most importantly leaving the OpenWrt device with no default gateway.
The TrendNet behavior violates RFC 2132, which in Section 3.14 declares that
option 12 has a miniumum length of 1 octet. It is perhaps not a cosmic
coincidence
that I found this behavior on Pi Day.
This patch allows zero length options without bailing out, by simply
skipping them.
[patch also sent upstream]
Signed-off-by: Russell Senior
---
.../205-udhcpc_allow_zero_length_options.patch | 17 +
1 file changed, 17 insertions(+)
create mode 100644
package/utils/busybox/patches/205-udhcpc_allow_zero_length_options.patch
diff --git
a/package/utils/busybox/patches/205-udhcpc_allow_zero_length_options.patch
b/package/utils/busybox/patches/205-udhcpc_allow_zero_length_options.patch
new file mode 100644
index 00..ecb18530e2
--- /dev/null
+++ b/package/utils/busybox/patches/205-udhcpc_allow_zero_length_options.patch
@@ -0,0 +1,17 @@
+--- a/networking/udhcp/common.c
b/networking/udhcp/common.c
+@@ -277,8 +277,12 @@ uint8_t* FAST_FUNC udhcp_scan_options(st
+ goto complain; /* complain and return NULL */
+ len = 2 + scan_state->optionptr[OPT_LEN];
+ scan_state->rem -= len;
+- /* So far no valid option with length 0 known. */
+- if (scan_state->rem < 0 || scan_state->optionptr[OPT_LEN] == 0)
++ /* skip any options with zero length */
++ if (scan_state->optionptr[OPT_LEN] == 0) {
++ scan_state->optionptr += OPT_LEN;
++ continue;
++ }
++ if (scan_state->rem < 0)
+ goto complain; /* complain and return NULL */
+
+ if (scan_state->optionptr[OPT_CODE] == DHCP_OPTION_OVERLOAD) {
--
2.30.1
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Commit e95b1b23f1b6951318d6c6caf3803fb933f71a6c kernel: bump 5.4 to 5.4.97 kills mt7621/dir860l
I rev'd up to 15785-g0fde111702 today (without my revert) and the freeze is gone, the dir860l-b1 boots normally again. I don't know why, but not knowing is made more tolerable by it working. -- Russell Senior russ...@personaltelco.net On Sun, Feb 14, 2021 at 4:51 AM Russell Senior wrote: > > Looks like this linux-stable commit might be the guilty party: > > e57d70c59bb7f6835ee47eb633e44efce4ab51b9 > > Reverting it in openwrt seems to fix the freezes. > > On Sun, Feb 14, 2021 at 4:07 AM Russell Senior > wrote: > > > > I am stepping though the kernel patches (intially 10 at a whack) > > between 5.4.96 and 5.4.97 to see if I can find what broke it. > > > > On Sat, Feb 13, 2021 at 2:51 PM Stijn Segers > > wrote: > > > > > > Hi, > > > > > > Op zaterdag 13 februari 2021 om 18u05 schreef Adrian Schmutzler > > > : > > > >> [1.176208] mt7621-pci 1e14.pcie: Parsing DT failed > > > > > > > > Is this introduced with the commit or has it been there before on > > > > this device? > > > > > > > > > This has been around for quite a while on MT7621. See also this comment > > > on the ramips 5.10 > > > PR of the MT7621 PCI driver author as to why this can be safely ignored: > > > > > > https://github.com/openwrt/openwrt/pull/3693#issuecomment-750436483 > > > > > > I am seeing this message on all three MT7621 devices I have in > > > production with master builds, > > > every single time. I thought it was an issue as well until Sergio > > > pointed out it really isn't. > > > > > > Cheers > > > > > > Stijn > > > > > > > > > > > Best > > > > > > > > Adrian > > > > ___ > > > > 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: Commit e95b1b23f1b6951318d6c6caf3803fb933f71a6c kernel: bump 5.4 to 5.4.97 kills mt7621/dir860l
Looks like this linux-stable commit might be the guilty party: e57d70c59bb7f6835ee47eb633e44efce4ab51b9 Reverting it in openwrt seems to fix the freezes. On Sun, Feb 14, 2021 at 4:07 AM Russell Senior wrote: > > I am stepping though the kernel patches (intially 10 at a whack) > between 5.4.96 and 5.4.97 to see if I can find what broke it. > > On Sat, Feb 13, 2021 at 2:51 PM Stijn Segers wrote: > > > > Hi, > > > > Op zaterdag 13 februari 2021 om 18u05 schreef Adrian Schmutzler > > : > > >> [1.176208] mt7621-pci 1e14.pcie: Parsing DT failed > > > > > > Is this introduced with the commit or has it been there before on > > > this device? > > > > > > This has been around for quite a while on MT7621. See also this comment > > on the ramips 5.10 > > PR of the MT7621 PCI driver author as to why this can be safely ignored: > > > > https://github.com/openwrt/openwrt/pull/3693#issuecomment-750436483 > > > > I am seeing this message on all three MT7621 devices I have in > > production with master builds, > > every single time. I thought it was an issue as well until Sergio > > pointed out it really isn't. > > > > Cheers > > > > Stijn > > > > > > > > Best > > > > > > Adrian > > > ___ > > > 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: Commit e95b1b23f1b6951318d6c6caf3803fb933f71a6c kernel: bump 5.4 to 5.4.97 kills mt7621/dir860l
I am stepping though the kernel patches (intially 10 at a whack) between 5.4.96 and 5.4.97 to see if I can find what broke it. On Sat, Feb 13, 2021 at 2:51 PM Stijn Segers wrote: > > Hi, > > Op zaterdag 13 februari 2021 om 18u05 schreef Adrian Schmutzler > : > >> [1.176208] mt7621-pci 1e14.pcie: Parsing DT failed > > > > Is this introduced with the commit or has it been there before on > > this device? > > > This has been around for quite a while on MT7621. See also this comment > on the ramips 5.10 > PR of the MT7621 PCI driver author as to why this can be safely ignored: > > https://github.com/openwrt/openwrt/pull/3693#issuecomment-750436483 > > I am seeing this message on all three MT7621 devices I have in > production with master builds, > every single time. I thought it was an issue as well until Sergio > pointed out it really isn't. > > Cheers > > Stijn > > > > > Best > > > > Adrian > > ___ > > 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
Commit e95b1b23f1b6951318d6c6caf3803fb933f71a6c kernel: bump 5.4 to 5.4.97 kills mt7621/dir860l
I tried building head a few hours ago and got a boot failure (they vary), bisected it back to this commit. The failure manifests as a lockup about here: [...] [1.141782] mt7530 mdio-bus:1f: MT7530 adapts as multi-chip module [1.157487] mtk_soc_eth 1e10.ethernet eth0: mediatek frame engine at 0xbe10, irq 21 [1.176208] mt7621-pci 1e14.pcie: Parsing DT failed [1.189358] NET: Registered protocol family 10 [1.199620] Segment Routing with IPv6 [1.207054] NET: Registered protocol family 17 [1.216208] 8021q: 802.1Q VLAN Support v1.8 Sometimes I get a stack trace, sometimes not. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v3] ath79: Add support for Ubiquiti Bullet AC
Checking if there is an obstacle to merging this.
--
Russell Senior
russ...@personaltelco.net
On Tue, Dec 22, 2020 at 6:39 PM Russell Senior
wrote:
>
>
> CPU: Atheros AR9342 rev 3 SoC
> RAM: 64 MB DDR2
> Flash: 16 MB NOR SPI
> WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
> WLAN 5.0GHz: QCA988X
> Ports: 1x GbE
>
> Flashing procedure is identical to other ubnt devices.
> https://openwrt.org/toh/ubiquiti/common
>
> Flashing through factory firmware
> 1. Ensure firmware version v8.7.0 is installed.
>Up/downgrade to this exact version.
> 2. Patch fwupdate.real binary using
>`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
> hexdump -R > /tmp/fwupdate.real`
> 3. Make the patched fwupdate.real binary executable using
>`chmod +x /tmp/fwupdate.real`
> 4. Copy the squashfs factory image to /tmp on the device
> 5. Flash OpenWrt using `/tmp/fwupdate.real -m `
> 6. Wait for the device to reboot
> (copied from Ubiquiti NanoBeam AC and modified)
>
> Flashing from serial console
> 1. Connect serial console (115200 baud)
> 2. Connect ethernet to a network with a TFTP server, through a
>passive PoE injector.
> 3. Press a key to obtain a u-boot prompt
> 4. Set your TFTP server's ip address, with:
>setenv serverip
> 5. Set the Bullet AC's ip address, with:
>setenv ipaddr
> 6. Set the boot file, with:
>setenv bootfile
> 7. Fetch the binary with tftp:
>tftpboot
> 8. Boot the initramfs binary:
>bootm
> 9. From the initramfs, fetch the sysupgrade binary, and flash it with
>sysupgrade.
>
> The Bullet AC is identified as a 2WA board by Ubiquiti. As such, the UBNT_TYPE
> must match from the "Flashing through factory firmware" install instructions
> to work.
>
> Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
> on which 5GHz is disabled. It isn't currently known whether phy1 is
> routed to the N connector at all.
>
> Signed-off-by: Russell Senior
> ---
> v2:
> - Make "Flashing through factory firmware" instructions actually work by
> changing UBNT_TYPE to 2WA
> v3:
> - Added a note to the commit message about 2WA boards
> - reordered section in 01_leds to preserve ordering as requested
> ---
> .../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
> .../generic/base-files/etc/board.d/01_leds| 21 +-
> .../generic/base-files/etc/board.d/02_network | 1 +
> .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> target/linux/ath79/image/generic-ubnt.mk | 17 +
> 5 files changed, 68 insertions(+), 10 deletions(-)
> create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
>
> diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> new file mode 100644
> index 00..be0b0792bb
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> @@ -0,0 +1,38 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include "ar9342_ubnt_wa_1port.dtsi"
> +
> +/ {
> + compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
> + model = "Ubiquiti Bullet AC (2WA)";
> +
> + aliases {
> + led-boot = _rssi3;
> + led-failsafe = _rssi3;
> + led-upgrade = _rssi3;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + rssi0 {
> + label = "blue:rssi0";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssi1 {
> + label = "blue:rssi1";
> + gpios = < 16 GPIO_ACTIVE_LOW>;
> + };
> +
> + rssi2 {
> + label = "blue:rssi2";
> + gpios = < 13 GPIO_ACTIVE_LOW>;
> + };
> +
> + led_rssi3: rssi3 {
> + label = "blue:rssi3";
> + gpios = < 14 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> index 443e81..9bbdc39204 100755
> --- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> +++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
> @@ -349,6 +349,17 @@ tplink,tl-wr842n-v2)
> trendnet,tew-823dru)
> ucidef_set_led_netdev "wan" "WAN" "green:planet" "eth0&quo
[PATCH] iproute2: update to 5.10.0
c8faeca5 (ss: mptcp: fix add_addr_accepted stat print, 2020-11-18) 0d78e8ea (tc: pedit: fix memory leak in print_pedit, 2020-12-11) ec1346ac (devlink: fix memory leak in cmd_dev_flash(), 2020-12-11) 309e6027 (man: tc-flower: fix manpage, 2020-12-11) 376367d9 (uapi: merge in change to bpf.h, 2020-12-14) 2e80ae89 (Merge branch 'gcc-10' into main, 2020-12-03) 755b1c58 (tc/mqprio: json-ify output, 2020-12-02) 975c4944 (ip/netns: use flock when setting up /run/netns, 2020-11-27) fb054cb3 (uapi: update devlink.h, 2020-11-29) c95d63e4 (uapi: update devlink.h, 2020-11-29) cae2e929 (f_u32: fix compiler gcc-10 compiler warning, 2020-11-29) c0149839 (misc: fix compiler warning in ifstat and nstat, 2020-11-29) 2319db90 (tc: fix compiler warnings in ip6 pedit, 2020-11-29) 5bdc4e91 (bridge: fix string length warning, 2020-11-29) f8176999 (devlink: fix uninitialized warning, 2020-11-29) 7a49ff9d (bridge: report correct version, 2020-11-15) 8682f588 (tc-mpls: fix manpage example and help message string, 2020-11-02) 7c7a0fe0 (tc-vlan: fix help and error message strings, 2020-11-02) 72f88bd4 (uapi: update kernel headers from 5.10-rc2, 2020-11-08) b90c39be (rdma: fix spelling error in comment, 2020-11-08) c8424b73 (man: fix spelling errors, 2020-11-08) cbf64817 (tc/m_gate: fix spelling errors, 2020-11-08) 14b189f0 (uapi: updates from 5.10-rc1, 2020-11-03) 9fc5bf73 (libnetlink: define __aligned conditionally, 2020-10-26) eb12cc9a (Merge branch 'main' into next, 2020-10-25) f1298d76 (m_mpls: test the 'mac_push' action after 'modify', 2020-10-22) 2b7a7684 (Merge branch 'tipc-encryption' into next, 2020-10-20) 2bf1ba5a (tipc: add option to set rekeying for encryption, 2020-10-16) 5fb36818 (tipc: add option to set master key for encryption, 2020-10-16) b4edd6a8 (Merge branch 'tc-mpls-l2-vpn' into next Guillaume Nault says:, 2020-10-20) 02a261b5 (m_mpls: add mac_push action, 2020-10-19) d61167dd (m_vlan: add pop_eth and push_eth actions, 2020-10-19) 3342688a (devlink: display elapsed time during flash update, 2020-10-14) cb7ce51c (v5.9.0, 2020-10-15) b5a583fb (Merge branch 'main' into next Signed-off-by: David Ahern , 2020-10-11) 78120128 (genl: ctrl: print op -> policy idx mapping, 2020-10-03) 91c54917 (Merge branch 'bridge-igmpv3-mldv2' into next Nikolay Aleksandrov says:, 2020-10-11) 86588450 (bridge: mdb: print protocol when available, 2020-10-08) 2de81d1e (bridge: mdb: print source list when available, 2020-10-08) 1d28c480 (bridge: mdb: print filter mode when available, 2020-10-08) e331677e (bridge: mdb: show igmpv3/mldv2 flags, 2020-10-08) f94e8b07 (bridge: mdb: print fast_leave flag, 2020-10-08) 547b3197 (bridge: mdb: add support for source address, 2020-10-08) f905191a (Update kernel headers, 2020-10-11) 4322b13c (ip xfrm: support setting XFRMA_SET_MARK_MASK attribute in states, 2020-10-02) 8dc1db80 (devlink: Add health reporter test command support, 2020-10-01) 01216471 (devlink: support setting the overwrite mask attribute, 2020-09-30) 34be2d26 (Update kernel headers, 2020-10-07) d2be31d9 (ss: add support for xdp statistics, 2020-09-24) f481515c (Update kernel headers, 2020-09-29) b8663da0 (ip: promote missed packets to the -s row, 2020-09-16) cec67df9 (Merge branch 'devlink-controller-external-info' into next Parav Pandit says:, 2020-09-22) 748cbad3 (devlink: Show controller number of a devlink port, 2020-09-18) 8fadd011 (devlink: Show external port attribute, 2020-09-18) 454429e8 (Update kernel headers, 2020-09-22) ad34d5fa (iproute2: ss: add support to expose various inet sockopts, 2020-08-19) c8eb4b52 (Update kernel headers, 2020-09-08) abee772f (tipc: support 128bit node identity for peer removing, 2020-08-27) 6fd53b2a (iplink: add support for protodown reason, 2020-08-28) af27494d (ip xfrm: support printing XFRMA_SET_MARK_MASK attribute in states, 2020-08-28) 275eed9b (Merge branch 'main' into next, 2020-09-01) cc889b82 (genl: ctrl: support dumping netlink policy, 2020-08-24) d5acae24 (libnetlink: add nl_print_policy() helper, 2020-08-24) 784fa9f6 (libnetlink: add rtattr_for_each_nested() iteration macro, 2020-08-24) OpenWrt patches unchanged. Successfully built for ramips/mt7621 and x86/geode with: CONFIG_PACKAGE_devlink=m CONFIG_PACKAGE_genl=m CONFIG_PACKAGE_ip-bridge=m CONFIG_PACKAGE_ip-full=m CONFIG_PACKAGE_ip-tiny=m CONFIG_PACKAGE_nstat=m CONFIG_PACKAGE_rdma=m CONFIG_PACKAGE_ss=m CONFIG_PACKAGE_tc=m Minimally run-tested ip-tiny on ramips/mt7621 (ubnt-erx). Signed-off-by: Russell Senior --- package/network/utils/iproute2/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/package/network/utils/iproute2/Makefile b/package/network/utils/iproute2/Makefile index 237f84736b..a20916f6ca 100644 --- a/package/network/utils/iproute2/Makefile +++ b/package/network/utils/iproute2/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=iproute2 -PKG_VERSION:=5.9.0 +PKG_VERSION:=5.10.0 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_
[PATCH v3] ath79: Add support for Ubiquiti Bullet AC
CPU: Atheros AR9342 rev 3 SoC
RAM: 64 MB DDR2
Flash: 16 MB NOR SPI
WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
WLAN 5.0GHz: QCA988X
Ports: 1x GbE
Flashing procedure is identical to other ubnt devices.
https://openwrt.org/toh/ubiquiti/common
Flashing through factory firmware
1. Ensure firmware version v8.7.0 is installed.
Up/downgrade to this exact version.
2. Patch fwupdate.real binary using
`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
hexdump -R > /tmp/fwupdate.real`
3. Make the patched fwupdate.real binary executable using
`chmod +x /tmp/fwupdate.real`
4. Copy the squashfs factory image to /tmp on the device
5. Flash OpenWrt using `/tmp/fwupdate.real -m `
6. Wait for the device to reboot
(copied from Ubiquiti NanoBeam AC and modified)
Flashing from serial console
1. Connect serial console (115200 baud)
2. Connect ethernet to a network with a TFTP server, through a
passive PoE injector.
3. Press a key to obtain a u-boot prompt
4. Set your TFTP server's ip address, with:
setenv serverip
5. Set the Bullet AC's ip address, with:
setenv ipaddr
6. Set the boot file, with:
setenv bootfile
7. Fetch the binary with tftp:
tftpboot
8. Boot the initramfs binary:
bootm
9. From the initramfs, fetch the sysupgrade binary, and flash it with
sysupgrade.
The Bullet AC is identified as a 2WA board by Ubiquiti. As such, the UBNT_TYPE
must match from the "Flashing through factory firmware" install instructions
to work.
Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
on which 5GHz is disabled. It isn't currently known whether phy1 is
routed to the N connector at all.
Signed-off-by: Russell Senior
---
v2:
- Make "Flashing through factory firmware" instructions actually work by
changing UBNT_TYPE to 2WA
v3:
- Added a note to the commit message about 2WA boards
- reordered section in 01_leds to preserve ordering as requested
---
.../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
.../generic/base-files/etc/board.d/01_leds| 21 +-
.../generic/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ath79/image/generic-ubnt.mk | 17 +
5 files changed, 68 insertions(+), 10 deletions(-)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
new file mode 100644
index 00..be0b0792bb
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include "ar9342_ubnt_wa_1port.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
+ model = "Ubiquiti Bullet AC (2WA)";
+
+ aliases {
+ led-boot = _rssi3;
+ led-failsafe = _rssi3;
+ led-upgrade = _rssi3;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssi0 {
+ label = "blue:rssi0";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ };
+
+ rssi1 {
+ label = "blue:rssi1";
+ gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+ rssi2 {
+ label = "blue:rssi2";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led_rssi3: rssi3 {
+ label = "blue:rssi3";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 443e81..9bbdc39204 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -349,6 +349,17 @@ tplink,tl-wr842n-v2)
trendnet,tew-823dru)
ucidef_set_led_netdev "wan" "WAN" "green:planet" "eth0"
;;
+ubnt,bullet-ac|\
+ubnt,nanobeam-ac|\
+ubnt,nanobeam-ac-gen2|\
+ubnt,nanostation-ac|\
+ubnt,powerbeam-5ac-gen2)
+ ucidef_set_rssimon "wlan0" "20" "1"
+ ucidef_set_led_rssi "rssilow" "RSSILOW" "blue:rssi0" "wlan0" "1" "100"
+ ucidef_set_led_rssi "rssimediumlow" "RSSIMEDIUMLOW" "blue:rssi1"
"wlan0" "26" "100"
+ ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "blue:rssi2"
"wlan0" "51" "100"
+ ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "blue:rss
Re: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
I would suggest doing the re-ordering to maintain lexical ordering in
a separate commit, to keep the functional changes more clear.
On Wed, Dec 16, 2020 at 12:27 PM Russell Senior
wrote:
>
> responses in-line.
>
> On Wed, Dec 16, 2020 at 8:20 AM Adrian Schmutzler
> wrote:
> >
> > Hi,
> >
> > > -Original Message-
> > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > > On Behalf Of Russell Senior
> > > Sent: Mittwoch, 16. Dezember 2020 12:01
> > > To: openwrt-devel@lists.openwrt.org
> > > Subject: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
> > >
> > >
> > > CPU: Atheros AR9342 rev 3 SoC
> > > RAM: 64 MB DDR2
> > > Flash: 16 MB NOR SPI
> > > WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
> > > WLAN 5.0GHz: QCA988X
> > > Ports: 1x GbE
> > >
> > > Flashing procedure is identical to other ubnt devices.
> > > https://openwrt.org/toh/ubiquiti/common
> > >
> > > Flashing through factory firmware
> > > 1. Ensure firmware version v8.7.0 is installed.
> > >Up/downgrade to this exact version.
> > > 2. Patch fwupdate.real binary using
> > >`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
> > > hexdump -R > /tmp/fwupdate.real`
> > > 3. Make the patched fwupdate.real binary executable using
> > >`chmod +x /tmp/fwupdate.real`
> > > 4. Copy the squashfs factory image to /tmp on the device 5. Flash OpenWrt
> > > using `/tmp/fwupdate.real -m ` 6. Wait for the
> > > device to reboot (copied from Ubiquiti NanoBeam AC and modified)
> > >
> > > Flashing from serial console
> > > 1. Connect serial console (115200 baud)
> > > 2. Connect ethernet to a network with a TFTP server, through a
> > >passive PoE injector.
> > > 3. Press a key to obtain a u-boot prompt 4. Set your TFTP server's ip
> > > address,
> > > with:
> > >setenv serverip 5. Set the Bullet AC's ip
> > > address,
> > > with:
> > >setenv ipaddr
> > > 6. Set the boot file, with:
> > >setenv bootfile
> > > 7. Fetch the binary with tftp:
> > >tftpboot
> > > 8. Boot the initramfs binary:
> > >bootm
> > > 9. From the initramfs, fetch the sysupgrade binary, and flash it with
> > >sysupgrade.
> > >
> > > Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
> > > on which 5GHz is disabled. It isn't currently known whether phy1 is
> > > routed to
> > > the N connector at all.
> > >
> > > Signed-off-by: Russell Senior
> > > ---
> > > v2:
> > > - Make "Flashing through factory firmware" instructions actually work by
> > > changing UBNT_TYPE to 2WA
> > > ---
> > > .../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
> > > .../generic/base-files/etc/board.d/01_leds| 1 +
> > > .../generic/base-files/etc/board.d/02_network | 1 +
> > > .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> > > target/linux/ath79/image/generic-ubnt.mk | 17 +
> > > 5 files changed, 58 insertions(+)
> > > create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > >
> > > diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > > b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > > new file mode 100644
> > > index 00..be0b0792bb
> > > --- /dev/null
> > > +++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > > @@ -0,0 +1,38 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +
> > > +#include "ar9342_ubnt_wa_1port.dtsi"
> > > +
> > > +/ {
> > > + compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
> > > + model = "Ubiquiti Bullet AC (2WA)";
> >
> > would you provide some details about that odd "2WA"?
>
> 2WA is what Ubiquiti calls it. It is needed in UBNT_TYPE in order for
> the patched fwupdate.real to match and accept the factory.bin
>
> There are two other 2WA devices supported by the same Ubiquiti
> firmware. The 2 in 2WA seems to represent the 2.4GHz band (despite the
> Bullet AC being able to use either band).
>
> >
> > > +
> > > + aliases {
> > > + led-boot = _rssi3;
> > > + led-failsafe = _rssi3;
> >
Re: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
responses in-line.
On Wed, Dec 16, 2020 at 8:20 AM Adrian Schmutzler
wrote:
>
> Hi,
>
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Russell Senior
> > Sent: Mittwoch, 16. Dezember 2020 12:01
> > To: openwrt-devel@lists.openwrt.org
> > Subject: [PATCHv2] ath79: Add support for Ubiquiti Bullet AC
> >
> >
> > CPU: Atheros AR9342 rev 3 SoC
> > RAM: 64 MB DDR2
> > Flash: 16 MB NOR SPI
> > WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
> > WLAN 5.0GHz: QCA988X
> > Ports: 1x GbE
> >
> > Flashing procedure is identical to other ubnt devices.
> > https://openwrt.org/toh/ubiquiti/common
> >
> > Flashing through factory firmware
> > 1. Ensure firmware version v8.7.0 is installed.
> >Up/downgrade to this exact version.
> > 2. Patch fwupdate.real binary using
> >`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
> > hexdump -R > /tmp/fwupdate.real`
> > 3. Make the patched fwupdate.real binary executable using
> >`chmod +x /tmp/fwupdate.real`
> > 4. Copy the squashfs factory image to /tmp on the device 5. Flash OpenWrt
> > using `/tmp/fwupdate.real -m ` 6. Wait for the
> > device to reboot (copied from Ubiquiti NanoBeam AC and modified)
> >
> > Flashing from serial console
> > 1. Connect serial console (115200 baud)
> > 2. Connect ethernet to a network with a TFTP server, through a
> >passive PoE injector.
> > 3. Press a key to obtain a u-boot prompt 4. Set your TFTP server's ip
> > address,
> > with:
> >setenv serverip 5. Set the Bullet AC's ip address,
> > with:
> >setenv ipaddr
> > 6. Set the boot file, with:
> >setenv bootfile
> > 7. Fetch the binary with tftp:
> >tftpboot
> > 8. Boot the initramfs binary:
> >bootm
> > 9. From the initramfs, fetch the sysupgrade binary, and flash it with
> >sysupgrade.
> >
> > Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
> > on which 5GHz is disabled. It isn't currently known whether phy1 is routed
> > to
> > the N connector at all.
> >
> > Signed-off-by: Russell Senior
> > ---
> > v2:
> > - Make "Flashing through factory firmware" instructions actually work by
> > changing UBNT_TYPE to 2WA
> > ---
> > .../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
> > .../generic/base-files/etc/board.d/01_leds| 1 +
> > .../generic/base-files/etc/board.d/02_network | 1 +
> > .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
> > target/linux/ath79/image/generic-ubnt.mk | 17 +
> > 5 files changed, 58 insertions(+)
> > create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> >
> > diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > new file mode 100644
> > index 00..be0b0792bb
> > --- /dev/null
> > +++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
> > @@ -0,0 +1,38 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +
> > +#include "ar9342_ubnt_wa_1port.dtsi"
> > +
> > +/ {
> > + compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
> > + model = "Ubiquiti Bullet AC (2WA)";
>
> would you provide some details about that odd "2WA"?
2WA is what Ubiquiti calls it. It is needed in UBNT_TYPE in order for
the patched fwupdate.real to match and accept the factory.bin
There are two other 2WA devices supported by the same Ubiquiti
firmware. The 2 in 2WA seems to represent the 2.4GHz band (despite the
Bullet AC being able to use either band).
>
> > +
> > + aliases {
> > + led-boot = _rssi3;
> > + led-failsafe = _rssi3;
> > + led-upgrade = _rssi3;
> > + };
> > +
> > + leds {
> > + compatible = "gpio-leds";
> > +
> > + rssi0 {
> > + label = "blue:rssi0";
> > + gpios = < 11 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + rssi1 {
> > + label = "blue:rssi1";
> > + gpios = < 16 GPIO_ACTIVE_LOW>;
> > + };
> > +
> > + rssi2 {
> > + label = "blue:rssi2";
> > + gpios = <
[PATCHv2] ath79: Add support for Ubiquiti Bullet AC
CPU: Atheros AR9342 rev 3 SoC
RAM: 64 MB DDR2
Flash: 16 MB NOR SPI
WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
WLAN 5.0GHz: QCA988X
Ports: 1x GbE
Flashing procedure is identical to other ubnt devices.
https://openwrt.org/toh/ubiquiti/common
Flashing through factory firmware
1. Ensure firmware version v8.7.0 is installed.
Up/downgrade to this exact version.
2. Patch fwupdate.real binary using
`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
hexdump -R > /tmp/fwupdate.real`
3. Make the patched fwupdate.real binary executable using
`chmod +x /tmp/fwupdate.real`
4. Copy the squashfs factory image to /tmp on the device
5. Flash OpenWrt using `/tmp/fwupdate.real -m `
6. Wait for the device to reboot
(copied from Ubiquiti NanoBeam AC and modified)
Flashing from serial console
1. Connect serial console (115200 baud)
2. Connect ethernet to a network with a TFTP server, through a
passive PoE injector.
3. Press a key to obtain a u-boot prompt
4. Set your TFTP server's ip address, with:
setenv serverip
5. Set the Bullet AC's ip address, with:
setenv ipaddr
6. Set the boot file, with:
setenv bootfile
7. Fetch the binary with tftp:
tftpboot
8. Boot the initramfs binary:
bootm
9. From the initramfs, fetch the sysupgrade binary, and flash it with
sysupgrade.
Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
on which 5GHz is disabled. It isn't currently known whether phy1 is
routed to the N connector at all.
Signed-off-by: Russell Senior
---
v2:
- Make "Flashing through factory firmware" instructions actually work by
changing UBNT_TYPE to 2WA
---
.../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ath79/image/generic-ubnt.mk | 17 +
5 files changed, 58 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
new file mode 100644
index 00..be0b0792bb
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include "ar9342_ubnt_wa_1port.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
+ model = "Ubiquiti Bullet AC (2WA)";
+
+ aliases {
+ led-boot = _rssi3;
+ led-failsafe = _rssi3;
+ led-upgrade = _rssi3;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssi0 {
+ label = "blue:rssi0";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ };
+
+ rssi1 {
+ label = "blue:rssi1";
+ gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+ rssi2 {
+ label = "blue:rssi2";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led_rssi3: rssi3 {
+ label = "blue:rssi3";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index a0ed21e318..46d4650eac 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -366,6 +366,7 @@ ubnt,rocket-m)
ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "green:link3"
"wlan0" "51" "100"
ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "green:link4" "wlan0" "76"
"100"
;;
+ubnt,bullet-ac|\
ubnt,nanobeam-ac|\
ubnt,nanobeam-ac-gen2|\
ubnt,nanostation-ac|\
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 905848a2ba..9293e5522b 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -58,6 +58,7 @@ ath79_setup_interfaces()
tplink,re450-v2|\
tplink,re450-v3|\
tplink,tl-wr902ac-v1|\
+ ubnt,bullet-ac|\
ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
diff --git
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 0d09cd3140..be62e52480 100644
---
a/target/linux/ath79/generic/base-files/
[PATCH] ath79: Add support for Ubiquiti Bullet AC
CPU: Atheros AR9342 rev 3 SoC
RAM: 64 MB DDR2
Flash: 16 MB NOR SPI
WLAN 2.4GHz: Atheros AR9342 v3 (ath9k)
WLAN 5.0GHz: QCA988X
Ports: 1x GbE
Flashing procedure is identical to other ubnt devices.
https://openwrt.org/toh/ubiquiti/common
Flashing through factory firmware
1. Ensure firmware version v8.7.0 is installed.
Up/downgrade to this exact version.
2. Patch fwupdate.real binary using
`hexdump -Cv /bin/ubntbox | sed 's/14 40 fe 27/00 00 00 00/g' | \
hexdump -R > /tmp/fwupdate.real`
3. Make the patched fwupdate.real binary executable using
`chmod +x /tmp/fwupdate.real`
4. Copy the squashfs factory image to /tmp on the device
5. Flash OpenWrt using `/tmp/fwupdate.real -m `
6. Wait for the device to reboot
(copied from Ubiquiti NanoBeam AC and modified)
Flashing from serial console
1. Connect serial console (115200 baud)
2. Connect ethernet to a network with a TFTP server, through a
passive PoE injector.
3. Press a key to obtain a u-boot prompt
4. Set your TFTP server's ip address, with:
setenv serverip
5. Set the Bullet AC's ip address, with:
setenv ipaddr
6. Set the boot file, with:
setenv bootfile
7. Fetch the binary with tftp:
tftpboot
8. Boot the initramfs binary:
bootm
9. From the initramfs, fetch the sysupgrade binary, and flash it with
sysupgrade.
Phy0 is QCA988X which can tune either band (2.4 or 5GHz). Phy1 is AR9342,
on which 5GHz is disabled. It isn't currently known whether phy1 is
routed to the N connector at all.
Signed-off-by: Russell Senior
---
.../linux/ath79/dts/ar9342_ubnt_bullet-ac.dts | 38 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ath79/image/generic-ubnt.mk | 7
5 files changed, 48 insertions(+)
create mode 100644 target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
diff --git a/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
new file mode 100644
index 00..be0b0792bb
--- /dev/null
+++ b/target/linux/ath79/dts/ar9342_ubnt_bullet-ac.dts
@@ -0,0 +1,38 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include "ar9342_ubnt_wa_1port.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-ac", "ubnt,wa", "qca,ar9342";
+ model = "Ubiquiti Bullet AC (2WA)";
+
+ aliases {
+ led-boot = _rssi3;
+ led-failsafe = _rssi3;
+ led-upgrade = _rssi3;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ rssi0 {
+ label = "blue:rssi0";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ };
+
+ rssi1 {
+ label = "blue:rssi1";
+ gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+ rssi2 {
+ label = "blue:rssi2";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ };
+
+ led_rssi3: rssi3 {
+ label = "blue:rssi3";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index a0ed21e318..46d4650eac 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -366,6 +366,7 @@ ubnt,rocket-m)
ucidef_set_led_rssi "rssimediumhigh" "RSSIMEDIUMHIGH" "green:link3"
"wlan0" "51" "100"
ucidef_set_led_rssi "rssihigh" "RSSIHIGH" "green:link4" "wlan0" "76"
"100"
;;
+ubnt,bullet-ac|\
ubnt,nanobeam-ac|\
ubnt,nanobeam-ac-gen2|\
ubnt,nanostation-ac|\
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 149f7b1141..44430d375a 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -58,6 +58,7 @@ ath79_setup_interfaces()
tplink,re450-v2|\
tplink,re450-v3|\
tplink,tl-wr902ac-v1|\
+ ubnt,bullet-ac|\
ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
diff --git
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 0d09cd3140..be62e52480 100644
---
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-calda
Re: Alix2 doesn't boot
Sorry for the delay. I just tried HEAD and it is working for me too. Does any version work on your hardware? On Sun, Oct 25, 2020 at 11:38 AM nino wrote: > > I tried to compile commit you suggested me but my alix stops to boot at > the same point... neither console prompt or login by serial neither > network reachability. > Any suggestions? > Thank you > Nino > > Il 25/10/20 10:50, Russell Senior ha scritto: > > I built and ran a version successfully from master recently > > (14607-g3fab4ace57) around the end of September. > > > > On Sat, Oct 24, 2020 at 12:13 PM nino wrote: > >> Hi all, > >> > >> I'm trying to install latest openwrt releases to my old pcengines Alix > >> 2d2 board. > >> > >> All latest release from 17.01.0 to 19.07.4 do not give me console at the > >> boot process end > >> > >> and I it's not clear if boot ended or not, no console or login prompt > >> appears. > >> > >> Attached a boot example. > >> > >> I tried a very old release (maybe backfire) and I works. > >> > >> Can you help me, please? > >> > >> Thank you > >> > >> Nino Ciurleo (ninux.org) > >> > >> > >> > >> > >> ___ > >> 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: Alix2 doesn't boot
I built and ran a version successfully from master recently (14607-g3fab4ace57) around the end of September. On Sat, Oct 24, 2020 at 12:13 PM nino wrote: > > Hi all, > > I'm trying to install latest openwrt releases to my old pcengines Alix > 2d2 board. > > All latest release from 17.01.0 to 19.07.4 do not give me console at the > boot process end > > and I it's not clear if boot ended or not, no console or login prompt > appears. > > Attached a boot example. > > I tried a very old release (maybe backfire) and I works. > > Can you help me, please? > > Thank you > > Nino Ciurleo (ninux.org) > > > > > ___ > 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 0/2] ath25: add 5.4 kernel support (not for merge)
>>>>> "Daniel" == Daniel Golle writes: Daniel> On Fri, Sep 04, 2020 at 03:20:49AM +0300, Sergey Ryazanov wrote: >> This series introduces support for 5.4 kernel. I know that this >> target was dropped earlier this week. And I think that this was a >> good decision. So, this series is not for merging, but for reference >> if someone still uses one of these boards and want to create a custom >> build with a modern kernel version. Daniel> I'd say as you have apprently really managed to get it booting Daniel> it is worth reverting the removal and including it. Sure, a bit Daniel> late, but there is hardware out there which would benefit from Daniel> recent OpenWrt (old ubnt gear, fonera, ... some of them 8/32). Daniel> But in terms of resources, ath25 is more advanced than good-old Daniel> bcm47xx and also played an important role in OpenWrt history. Daniel> Maybe I'm just nostalgic... +1 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MR24 wifi broken by recent commit
>>>>> Christian Lamparter writes: > On 2020-09-03 10:44, Russell Senior wrote: >> commit 9153955095f01a7ac5f2659a671f0229cbad3507 Author: Christian >> Lamparter mailto:chunk...@gmail.com>> Date: >> Wed Aug 12 18:26:43 2020 +0200 >> >> apm821xx: MR24: enumerate PCIe in device-tree >> >> This patch adds the pcie-switch and bridge configuration for >> the Meraki MR24. >> >> Signed-off-by: Christian Lamparter > <mailto:chunk...@gmail.com>> >> >> The symptom is client devices can't see the beacons. Wifi ifaces >> appear, can scan and hear other networks, but clients can't see the >> MR24's SSIDs. Reverting the commit above and it works normally again. > Thanks for the report. CONFIG_PCI_DEBUG > "ath9k :44:00.0: runtime IRQ mapping not provided by arch" > since DT overwrites the usual PCI(e) enumeration and MSI(x) is > busted there's no choice but to specify legacy INTABCDs. > Can you please try the attached patch? Your patch fixes it. I am a little curious, if it works without your commit, what is the motivation for the commit? -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
MR24 wifi broken by recent commit
commit 9153955095f01a7ac5f2659a671f0229cbad3507 Author: Christian Lamparter Date: Wed Aug 12 18:26:43 2020 +0200 apm821xx: MR24: enumerate PCIe in device-tree This patch adds the pcie-switch and bridge configuration for the Meraki MR24. Signed-off-by: Christian Lamparter The symptom is client devices can't see the beacons. Wifi ifaces appear, can scan and hear other networks, but clients can't see the MR24's SSIDs. Reverting the commit above and it works normally again. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Missing ar71xx devices in ath79 before 20.xx
>>>>>writes: > Hi, I just did a quick comparison which ar71xx devices are still > missing in ath79. This has also been posted in the forum here: > https://forum.openwrt.org/t/missing-ar71xx-devices-in-ath79-before-20-xx/70687 > [...] > wzr-600dhp I have a bunch of these and they are the same board as "buffalo,wzr-hp-ag300h", which has had ath79 support for a good long while. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: fix 04_led_migration case syntax
Commit f761f4052c4 had bogus case syntax, the uci-defaults script threw
errors as a result and exited non-zero, probably didn't do what was
intended, but tried over and over since the non-zero exit prevents the
script from being deleted.
Signed-off-by: Russell Senior
---
.../mt7621/base-files/etc/uci-defaults/04_led_migration | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
a/target/linux/ramips/mt7621/base-files/etc/uci-defaults/04_led_migration
b/target/linux/ramips/mt7621/base-files/etc/uci-defaults/04_led_migration
index 73140fd7d5..1248dcec0f 100644
--- a/target/linux/ramips/mt7621/base-files/etc/uci-defaults/04_led_migration
+++ b/target/linux/ramips/mt7621/base-files/etc/uci-defaults/04_led_migration
@@ -9,14 +9,16 @@ boardonly="${board##*,}"
case "$board" in
mikrotik,routerboard-750gr3)
migrate_leds "^rb750gr3:=$boardonly:"
+ ;;
mikrotik,routerboard-m11g)
migrate_leds "^rbm11g:=$boardonly:"
+ ;;
mikrotik,routerboard-m33g)
migrate_leds "^rbm33g:=$boardonly:"
+ ;;
netgear,wndr3700-v5)
migrate_leds "^wndr3700v5:=$boardonly:"
;;
-
esac
migrations_apply system
--
2.26.2
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFT PATCH 0/6] ath25: bump to kernel 5.4
On Mon, Apr 13, 2020 at 10:12 AM Adrian Schmutzler < freif...@adrianschmutzler.de> wrote: > This is another episode in just-make-it-compile kernel bumps. > > This has been built-tested for all devices, but not tested on device. > Here is a test of your branch on an Accton MR3201A: +PHY ID is 0022:5521 Ethernet eth0: MAC address 00:12:cf:83:7b:08 IP: 192.168.0.1/255.255.255.0, Gateway: 0.0.0.0 Default server: 0.0.0.0 RedBoot(tm) bootstrap and debug environment [ROMRAM] Non-certified release, version v1.3.4 - built 19:22:52, Oct 15 2007 Copyright (C) 2000, 2001, 2002, 2003, 2004 Red Hat, Inc. Board: ap51 RAM: 0x8000-0x8200, [0x8003eaf0-0x80fe1000] available FLASH: 0xa800 - 0xa87f, 128 blocks of 0x0001 bytes each. == Executing boot script in 3.000 seconds - enter ^C to abort RedBoot> fis load -l vmlinux.bin.l7 Image loaded from 0x80041000-0x804567ec RedBoot> exec Now booting linux kernel: Base address 0x8003 Entry 0x80041000 Cmdline : [0.00] Linux version 5.4.31 (openwrt@hawg) (gcc version 8.4.0 (OpenWrt GCC 8.4.0 r12956-dcc1489cde)) #0 Mon Apr 13 17:33:46 2020 [0.00] printk: bootconsole [early0] enabled [0.00] CPU0 revision is: 00019064 (MIPS 4KEc) [0.00] Initrd not found or empty - disabling initrd [0.00] Primary instruction cache 16kB, VIPT, 4-way, linesize 16 bytes. [0.00] Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 16 bytes [0.00] Zone ranges: [0.00] Normal [mem 0x-0x01ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x01ff] [0.00] Initmem setup node 0 [mem 0x-0x01ff] [0.00] Built 1 zonelists, mobility grouping on. Total pages: 8128 [0.00] Kernel command line: console=ttyS0,9600 rootfstype=squashfs,jffs2 [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear) [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear) [0.00] mem auto-init: stack:off, heap alloc:off, heap free:off [0.00] Memory: 28040K/32768K available (3432K kernel code, 149K rwdata, 460K rodata, 172K init, 184K bss, 4728K reserved, 0K cma-reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS: 128 [0.00] random: get_random_bytes called from 0x804359b4 with crng_init=0 [0.00] clocksource: MIPS: mask: 0x max_cycles: 0x, max_idle_ns: 20774570075 ns [0.50] sched_clock: 32 bits at 92MHz, resolution 10ns, wraps every 23342213114ns [0.093990] Calibrating delay loop... 182.27 BogoMIPS (lpj=364544) [0.199378] pid_max: default: 32768 minimum: 301 [0.255442] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.342220] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear) [0.449307] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 764504178510 ns [0.565224] futex hash table entries: 256 (order: -1, 3072 bytes, linear) [0.649370] NET: Registered protocol family 16 [1.404220] registering PCI controller with io_map_base unset [1.472231] ar2315-pci ar2315-pci: register PCI controller [1.660673] PCI host bridge to bus :00 [1.709012] pci_bus :00: root bus resource [mem 0x8000-0xbfff] [1.791103] pci_bus :00: root bus resource [io 0x] [1.857686] pci_bus :00: root bus resource [??? 0x flags 0x0] [1.938773] pci_bus :00: No busn resource found for root bus, will use [bus 00-ff] [2.033620] pci :00:00.0: [168c:ff18] type 00 class 0x02 [2.105378] pci :00:00.0: reg 0x10: [mem 0x1000-0x1001] [2.180156] pci :00:00.0: reg 0x14: [mem 0x2000-0x23ff] [2.255018] pci :00:00.0: reg 0x18: [mem 0x3000-0x303f] [2.331545] pci :00:01.0: [168c:ff18] type 00 class 0x02 [2.402941] pci :00:01.0: reg 0x10: [mem 0x1000-0x1001] [2.477702] pci :00:01.0: reg 0x14: [mem 0x2000-0x23ff] [2.552565] pci :00:01.0: reg 0x18: [mem 0x3000-0x303f] [2.628850] pci :00:02.0: [168c:ff18] type 00 class 0x02 [2.700169] pci :00:02.0: reg 0x10: [mem 0x1000-0x1001] [2.774932] pci :00:02.0: reg 0x14: [mem 0x2000-0x23ff] [2.849795] pci :00:02.0: reg 0x18: [mem 0x3000-0x303f] [2.926192] pci :00:04.0: [168c:ff18] type 00 class 0x02 [2.997611] pci :00:04.0: reg 0x10: [mem 0x1000-0x1001] [3.072373] pci :00:04.0: reg 0x14: [mem 0x2000-0x23ff] [3.147235] pci :00:04.0: reg 0x18: [mem 0x3000-0x303f] [3.223534] pci :00:05.0: [168c:ff18] type 00 class 0x02 [3.294947] pci :00:05.0: reg 0x10: [mem 0x1000-0x1001] [3.369709] pci
Re: [OpenWrt-Devel] [PATCH] ath79: switch to kernel 5.4
FYI: https://bugs.openwrt.org/index.php?do=details_id=2928 On Fri, Apr 3, 2020 at 3:13 AM David Bauer wrote: > Hello Magnus, > > On 4/3/20 12:07 PM, Magnus Kroken wrote: > > Hi all > > > > On 03.04.2020 11:21, Bjørn Mork wrote: > >> David Bauer writes: > >> > >>> As the reported major bugs are ironed out, switch to the new kernel to > >>> begin testing with a broader audience. > >> > >> > >> Hmm... I wonder if you might want to hold back on that for a while. > >> > >> I have no useful info yet since I don't have console access on this > >> device, but I just lost network access to a UniFi AP AC PRO after trying > >> out current master (fcd14017007d). > > > > I held back and planned to report when I have a log from serial, but I'm > sending this now since this sounds similar to my experience. > > > > I've tested 5.4 on my tl-wdr4300v1, and it got stuck in reboot loop > recently. I plan to get a serial connection on it this weekend to see > exactly what happens, but with the easy TFTP recovery I've bisected it to > the GCC 8.4 update. Doing a dirclean between each test, > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=db70077668e757a27f41d9cb3c84f28ea7d4c22e > is the first bad commit. This is the simple config I've used for testing: > > > > CONFIG_TARGET_ath79=y > > CONFIG_TARGET_ath79_generic=y > > CONFIG_TARGET_ath79_generic_DEVICE_tplink_tl-wdr4300-v1=y > > CONFIG_LINUX_5_4=y > > CONFIG_TESTING_KERNEL=y > > > > Testing is on hold as the device is in service right now, but I'd > appreciate any ideas for further testing. > > Thanks for this report. I'm not in the posession of an AC-Pro but i > have a WDR3600 around, which is mostly identical to the WDR4300. > > I've not tested 5.4 there, but i will see if i can reproduce any > network-related > issue there. > > Best wishes > David > > > > > /Magnus > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] x86/geode: add missing include after rebase
>>>>> Paul Spooren writes: Comments below. > The x86 image generation was refacted via cb007a7bf6 and accidently > not included `geode.mk` when selected as subtarget. > Now the file is included and image compilation for x86/geode works > again. > Thanks to Russell Senior for reporting the > problem and suggesting a patch! The patch is due to Tomasz Maciej Nowak (tmn505). Also, we need the FEATURES modified in target/linux/x86/geode/target.mk, as it is missing needed features, minimally boot-part rootfs-part squashfs ext4 and perhaps others. And, when building for alix, I get prompted for kernel config variables: SCSI_FDOMAIN_ISA, I2C_AMD_MP2, PCENGINES_APU2. I notice that there is a kernel config CONFIG_ALIX disabled in target/linux/x86/config-5.4, seems like it would be useful for an alix build? -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v5 1/1] ath79: add support for ubnt_bullet-m-ar7240 variant
This adds support for the Ubiquiti Bullet M (AR7240).
Specifications:
- AR7240 SoC @ 400 MHz
- 32 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet, 24 Vdc PoE-in
- External antenna
- POWER/LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1) on PCB
Flashing via WebUI:
Upload the factory image via the stock firmware web UI.
Attention: airOS firmware versions >= 5.6 have a new bootloader with
an incompatible partition table!
Please downgrade to <= 5.5 _before_ flashing OpenWrt!
Refer to the device's Wiki page for further information.
Flashing via TFTP:
Same procedure as other Ubiquiti M boards.
- Use a pointy tool (e.g., pen cap, paper clip) and keep the reset
button on the device or on the PoE supply pressed
- Power on the device via PoE (keep reset button pressed)
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button
- The device starts a TFTP server at 192.168.1.20
- Set a static IP on the computer (e.g., 192.168.1.21/24)
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_bullet-m-ar7240-squashfs-factory.bin
The "fixed-link" section of the device tree is needed to avoid errors like this:
Generic PHY mdio.0:1f:04: Master/Slave resolution failed, maybe conflicting
manual settings?
With "fixed-link", the errors go away and eth0 comes up reliably.
Signed-off-by: Russell Senior
---
.../ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts | 22 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 2 ++
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
target/linux/ath79/image/generic-ubnt.mk | 10 +
5 files changed, 36 insertions(+)
create mode 100644 target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
diff --git a/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
new file mode 100644
index 00..58b35f5c8b
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7240.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-m-ar7240", "ubnt,xm", "qca,ar7240";
+ model = "Ubiquiti Bullet M XM (AR7240)";
+};
+
+ {
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+ {
+ compatible = "syscon", "simple-mfd";
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 227ccf0dfe..2df7dca89d 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -250,6 +250,7 @@ tplink,tl-wr842n-v2)
trendnet,tew-823dru)
ucidef_set_led_netdev "wan" "WAN" "trendnet:green:planet" "eth0"
;;
+ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
ubnt,nanostation-loco-m|\
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index dbb722482b..fc1fee4844 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -40,6 +40,7 @@ ath79_setup_interfaces()
tplink,re450-v1|\
tplink,re450-v2|\
tplink,tl-wr902ac-v1|\
+ ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
ubnt,lap-120|\
@@ -446,6 +447,7 @@ ath79_setup_macs()
label_mac=$wan_mac
;;
ubnt,airrouter|\
+ ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,nanostation-loco-m|\
ubnt,nanostation-m|\
diff --git
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 38f158896b..0cf8b43514 100644
---
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -85,6 +85,7 @@ case "$FIRMWARE" in
tplink,tl-wr2543-v1|\
tplink,tl-wr842n-v1|\
ubnt,airrouter|\
+ ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,nanostation-loco-m|\
ubnt,nanostation-m|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 4902023089..ece5886ac6 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -113
[OpenWrt-Devel] [PATCH v5 0/1] ath79: add support for the ar7240 version of the ubiquiti bullet
since v4: * patches 1/4 and 2/4 were already merged, so dropped here * add the second ubnt,bullet-m-ar7240 to the 02_network file, previously missing * modify the board naming as requested in device tree * justify the device tree "fixed-link" section in the commit message * drop the unnecessary XW DEVICE_VARIANT patch Russell Senior (1): ath79: add support for ubnt_bullet-m-ar7240 variant .../ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts | 22 +++ .../generic/base-files/etc/board.d/01_leds| 1 + .../generic/base-files/etc/board.d/02_network | 2 ++ .../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 + target/linux/ath79/image/generic-ubnt.mk | 10 + 5 files changed, 36 insertions(+) create mode 100644 target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts -- 2.25.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 4/4] ath79: add DEVICE_VARIANT for ubnt_bullet-m-xw
Argh. That added line should be DEVICE_VARIANT, not DEVICE_MODEL. I'll hold off sending a v5 until I hear back other feedback. On Tue, Mar 10, 2020 at 6:06 PM Russell Senior wrote: > Signed-off-by: Russell Senior > --- > target/linux/ath79/image/generic-ubnt.mk | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/linux/ath79/image/generic-ubnt.mk > b/target/linux/ath79/image/generic-ubnt.mk > index 5808d8f424..e8c8ebf30b 100644 > --- a/target/linux/ath79/image/generic-ubnt.mk > +++ b/target/linux/ath79/image/generic-ubnt.mk > @@ -136,6 +136,7 @@ TARGET_DEVICES += ubnt_bullet-m-ar7241 > define Device/ubnt_bullet-m-xw >$(Device/ubnt-xw) >DEVICE_MODEL := Bullet-M > + DEVICE_MODEL := XW >DEVICE_PACKAGES += rssileds >SUPPORTED_DEVICES += bullet-m-xw > endef > -- > 2.25.1 > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 3/4] ath79: add support for ubnt_bullet-m-ar7240 variant
This adds support for the Ubiquiti Bullet M (AR7240).
Specifications:
- AR7240 SoC @ 400 MHz
- 32 MB RAM
- 8 MB SPI flash
- 1x 10/100 Mbps Ethernet, 24 Vdc PoE-in
- External antenna
- POWER/LAN green LEDs
- 4x RSSI LEDs (red, orange, green, green)
- UART (115200 8N1) on PCB
Flashing via WebUI:
Upload the factory image via the stock firmware web UI.
Attention: airOS firmware versions >= 5.6 have a new bootloader with
an incompatible partition table!
Please downgrade to <= 5.5 _before_ flashing OpenWrt!
Refer to the device's Wiki page for further information.
Flashing via TFTP:
Same procedure as other Ubiquiti M boards.
- Use a pointy tool (e.g., pen cap, paper clip) and keep the reset
button on the device or on the PoE supply pressed
- Power on the device via PoE (keep reset button pressed)
- Keep pressing until LEDs flash alternatively LED1+LED3 =>
LED2+LED4 => LED1+LED3, etc.
- Release reset button
- The device starts a TFTP server at 192.168.1.20
- Set a static IP on the computer (e.g., 192.168.1.21/24)
- Upload via tftp the factory image:
$ tftp 192.168.1.20
tftp> bin
tftp> trace
tftp> put
openwrt-ath79-generic-x-ubnt_bullet-m-ar7240-squashfs-factory.bin
Signed-off-by: Russell Senior
---
.../ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts | 22 +++
.../generic/base-files/etc/board.d/01_leds| 1 +
.../generic/base-files/etc/board.d/02_network | 1 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 1 +
target/linux/ath79/image/generic-ubnt.mk | 10 +
5 files changed, 35 insertions(+)
create mode 100644 target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
diff --git a/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
new file mode 100644
index 00..99bf971eec
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7240.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-m-ar7240", "ubnt,xm", "qca,ar7240";
+ model = "Ubiquiti Bullet M AR7240";
+};
+
+ {
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+ {
+ compatible = "syscon", "simple-mfd";
+};
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index cf9dfd2b0d..98cdd6b7d4 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -245,6 +245,7 @@ tplink,tl-wr842n-v2)
trendnet,tew-823dru)
ucidef_set_led_netdev "wan" "WAN" "trendnet:green:planet" "eth0"
;;
+ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
ubnt,nanostation-loco-m|\
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index 24ba524c73..f0d96a1273 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -41,6 +41,7 @@ ath79_setup_interfaces()
tplink,re450-v1|\
tplink,re450-v2|\
tplink,tl-wr902ac-v1|\
+ ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
ubnt,lap-120|\
diff --git
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index 225915ef3b..08d0e27acc 100644
---
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -90,6 +90,7 @@ case "$FIRMWARE" in
tplink,tl-wr2543-v1|\
tplink,tl-wr842n-v1|\
ubnt,airrouter|\
+ ubnt,bullet-m-ar7240|\
ubnt,bullet-m-ar7241|\
ubnt,nanostation-loco-m|\
ubnt,nanostation-m|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index 9752319209..5808d8f424 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -113,6 +113,16 @@ define Device/ubnt_airrouter
endef
TARGET_DEVICES += ubnt_airrouter
+define Device/ubnt_bullet-m-ar7240
+ $(Device/ubnt-xm)
+ SOC := ar7240
+ DEVICE_MODEL := Bullet-M
+ DEVICE_VARIANT := XM (AR7240)
+ DEVICE_PACKAGES += rssileds
+ SUPPORTED_DEVICES += bullet-m-ar7240
+endef
+TARGET_DEVICES += ubnt_bullet-m-ar7240
+
define Device/ubnt_bullet-m-ar7241
$(Device/ubnt-xm)
SOC := ar7241
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 2/4] ath79: rename ubnt_bullet-m to ubnt_bullet-m-ar7241
Signed-off-by: Russell Senior
---
...1_ubnt_bullet-m.dts => ar7241_ubnt_bullet-m-ar7241.dts} | 4 ++--
target/linux/ath79/generic/base-files/etc/board.d/01_leds | 2 +-
.../linux/ath79/generic/base-files/etc/board.d/02_network | 2 +-
.../base-files/etc/hotplug.d/firmware/10-ath9k-eeprom | 2 +-
target/linux/ath79/image/generic-ubnt.mk | 7 ---
5 files changed, 9 insertions(+), 8 deletions(-)
rename target/linux/ath79/dts/{ar7241_ubnt_bullet-m.dts =>
ar7241_ubnt_bullet-m-ar7241.dts} (68%)
diff --git a/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
b/target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
similarity index 68%
rename from target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
rename to target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
index a43ed2afdc..bb0f19c9eb 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
@@ -6,8 +6,8 @@
#include "ar724x_ubnt_xm_outdoor.dtsi"
/ {
- compatible = "ubnt,bullet-m", "ubnt,xm", "qca,ar7241";
- model = "Ubiquiti Bullet M";
+ compatible = "ubnt,bullet-m-ar7241", "ubnt,xm", "qca,ar7241";
+ model = "Ubiquiti Bullet M AR7241";
};
{
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
index 390f5f3657..cf9dfd2b0d 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/generic/base-files/etc/board.d/01_leds
@@ -245,7 +245,7 @@ tplink,tl-wr842n-v2)
trendnet,tew-823dru)
ucidef_set_led_netdev "wan" "WAN" "trendnet:green:planet" "eth0"
;;
-ubnt,bullet-m|\
+ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
ubnt,nanostation-loco-m|\
ubnt,nanostation-loco-m-xw|\
diff --git a/target/linux/ath79/generic/base-files/etc/board.d/02_network
b/target/linux/ath79/generic/base-files/etc/board.d/02_network
index ac29c53ced..24ba524c73 100755
--- a/target/linux/ath79/generic/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/generic/base-files/etc/board.d/02_network
@@ -41,7 +41,7 @@ ath79_setup_interfaces()
tplink,re450-v1|\
tplink,re450-v2|\
tplink,tl-wr902ac-v1|\
- ubnt,bullet-m|\
+ ubnt,bullet-m-ar7241|\
ubnt,bullet-m-xw|\
ubnt,lap-120|\
ubnt,litebeam-ac-gen2|\
diff --git
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
index b06a481c94..225915ef3b 100644
---
a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
+++
b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/10-ath9k-eeprom
@@ -90,7 +90,7 @@ case "$FIRMWARE" in
tplink,tl-wr2543-v1|\
tplink,tl-wr842n-v1|\
ubnt,airrouter|\
- ubnt,bullet-m|\
+ ubnt,bullet-m-ar7241|\
ubnt,nanostation-loco-m|\
ubnt,nanostation-m|\
ubnt,picostation-m|\
diff --git a/target/linux/ath79/image/generic-ubnt.mk
b/target/linux/ath79/image/generic-ubnt.mk
index aad177bf4a..9752319209 100644
--- a/target/linux/ath79/image/generic-ubnt.mk
+++ b/target/linux/ath79/image/generic-ubnt.mk
@@ -113,14 +113,15 @@ define Device/ubnt_airrouter
endef
TARGET_DEVICES += ubnt_airrouter
-define Device/ubnt_bullet-m
+define Device/ubnt_bullet-m-ar7241
$(Device/ubnt-xm)
SOC := ar7241
DEVICE_MODEL := Bullet-M
+ DEVICE_VARIANT := XM (AR7241)
DEVICE_PACKAGES += rssileds
- SUPPORTED_DEVICES += bullet-m
+ SUPPORTED_DEVICES += bullet-m-ar7241
endef
-TARGET_DEVICES += ubnt_bullet-m
+TARGET_DEVICES += ubnt_bullet-m-ar7241
define Device/ubnt_bullet-m-xw
$(Device/ubnt-xw)
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 4/4] ath79: add DEVICE_VARIANT for ubnt_bullet-m-xw
Signed-off-by: Russell Senior --- target/linux/ath79/image/generic-ubnt.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ath79/image/generic-ubnt.mk b/target/linux/ath79/image/generic-ubnt.mk index 5808d8f424..e8c8ebf30b 100644 --- a/target/linux/ath79/image/generic-ubnt.mk +++ b/target/linux/ath79/image/generic-ubnt.mk @@ -136,6 +136,7 @@ TARGET_DEVICES += ubnt_bullet-m-ar7241 define Device/ubnt_bullet-m-xw $(Device/ubnt-xw) DEVICE_MODEL := Bullet-M + DEVICE_MODEL := XW DEVICE_PACKAGES += rssileds SUPPORTED_DEVICES += bullet-m-xw endef -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 0/4] ath79: add support for the ar7240 version of the ubiquiti bullet
This series aims to support the AR7240 version of the ubiquiti bullet m.
First it reorganizes the associated dtsi files by making them generic and
usable for
both variants. Second, it renames the existing bullet support to be the
existing
AR7241 variant, along with supporting changes. Third, it adds support for the
AR7240
variant. Lastly, it applies a DEVICE_VARIANT variable to the XW version of the
bullet.
Russell Senior (4):
ath79: generify ubnt_xm dtsi for ar7240 and ar7241
ath79: rename ubnt_bullet-m to ubnt_bullet-m-ar7241
ath79: add support for ubnt_bullet-m-ar7240 variant
ath79: add DEVICE_VARIANT for ubnt_bullet-m-xw
.../ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts | 22
.../linux/ath79/dts/ar7241_ubnt_airrouter.dts | 3 ++-
.../ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts | 15 +++
.../linux/ath79/dts/ar7241_ubnt_bullet-m.dts | 13 --
.../dts/ar7241_ubnt_nanostation-loco-m.dts| 4 ++-
.../ath79/dts/ar7241_ubnt_nanostation-m.dts | 4 ++-
.../ath79/dts/ar7241_ubnt_picostation-m.dts | 4 ++-
.../linux/ath79/dts/ar7241_ubnt_rocket-m.dts | 4 ++-
...r7241_ubnt_xm.dtsi => ar724x_ubnt_xm.dtsi} | 5
...tdoor.dtsi => ar724x_ubnt_xm_outdoor.dtsi} | 2 --
.../generic/base-files/etc/board.d/01_leds| 3 ++-
.../generic/base-files/etc/board.d/02_network | 3 ++-
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 3 ++-
target/linux/ath79/image/generic-ubnt.mk | 25 ---
14 files changed, 78 insertions(+), 32 deletions(-)
create mode 100644 target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
create mode 100644 target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
delete mode 100644 target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
rename target/linux/ath79/dts/{ar7241_ubnt_xm.dtsi => ar724x_ubnt_xm.dtsi}
(92%)
rename target/linux/ath79/dts/{ar7241_ubnt_xm_outdoor.dtsi =>
ar724x_ubnt_xm_outdoor.dtsi} (94%)
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 1/4] ath79: generify ubnt_xm dtsi for ar7240 and ar7241
* Prepare to support the AR7240 variant of ubiquiti bullet m, by
reorganizing the related dtsi files.
* Distribute SOC variable across ubnt-xm devices.
Signed-off-by: Russell Senior
---
target/linux/ath79/dts/ar7241_ubnt_airrouter.dts | 3 ++-
target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts| 4 +++-
target/linux/ath79/dts/ar7241_ubnt_nanostation-loco-m.dts | 4 +++-
target/linux/ath79/dts/ar7241_ubnt_nanostation-m.dts | 4 +++-
target/linux/ath79/dts/ar7241_ubnt_picostation-m.dts | 4 +++-
target/linux/ath79/dts/ar7241_ubnt_rocket-m.dts| 4 +++-
.../ath79/dts/{ar7241_ubnt_xm.dtsi => ar724x_ubnt_xm.dtsi} | 5 -
...41_ubnt_xm_outdoor.dtsi => ar724x_ubnt_xm_outdoor.dtsi} | 2 --
target/linux/ath79/image/generic-ubnt.mk | 7 ++-
9 files changed, 23 insertions(+), 14 deletions(-)
rename target/linux/ath79/dts/{ar7241_ubnt_xm.dtsi => ar724x_ubnt_xm.dtsi}
(92%)
rename target/linux/ath79/dts/{ar7241_ubnt_xm_outdoor.dtsi =>
ar724x_ubnt_xm_outdoor.dtsi} (94%)
diff --git a/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
b/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
index ad2762e20c..dd2421da8e 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
@@ -1,7 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/dts-v1/;
-#include "ar7241_ubnt_xm.dtsi"
+#include "ar7241.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
/ {
compatible = "ubnt,airrouter", "ubnt,xm", "qca,ar7241";
diff --git a/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
b/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
index e16b5fa0be..a43ed2afdc 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/dts-v1/;
-#include "ar7241_ubnt_xm_outdoor.dtsi"
+#include "ar7241.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
/ {
compatible = "ubnt,bullet-m", "ubnt,xm", "qca,ar7241";
diff --git a/target/linux/ath79/dts/ar7241_ubnt_nanostation-loco-m.dts
b/target/linux/ath79/dts/ar7241_ubnt_nanostation-loco-m.dts
index 386b7c7073..60d5a21a22 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_nanostation-loco-m.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_nanostation-loco-m.dts
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/dts-v1/;
-#include "ar7241_ubnt_xm_outdoor.dtsi"
+#include "ar7241.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
/ {
compatible = "ubnt,nanostation-loco-m", "ubnt,xm", "qca,ar7241";
diff --git a/target/linux/ath79/dts/ar7241_ubnt_nanostation-m.dts
b/target/linux/ath79/dts/ar7241_ubnt_nanostation-m.dts
index eebe65e53f..82344bb5ea 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_nanostation-m.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_nanostation-m.dts
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/dts-v1/;
-#include "ar7241_ubnt_xm_outdoor.dtsi"
+#include "ar7241.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
/ {
compatible = "ubnt,nanostation-m", "ubnt,xm", "qca,ar7241";
diff --git a/target/linux/ath79/dts/ar7241_ubnt_picostation-m.dts
b/target/linux/ath79/dts/ar7241_ubnt_picostation-m.dts
index e2376a1b92..d05aca3e67 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_picostation-m.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_picostation-m.dts
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/dts-v1/;
-#include "ar7241_ubnt_xm_outdoor.dtsi"
+#include "ar7241.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
/ {
compatible = "ubnt,picostation-m", "ubnt,xm", "qca,ar7241";
diff --git a/target/linux/ath79/dts/ar7241_ubnt_rocket-m.dts
b/target/linux/ath79/dts/ar7241_ubnt_rocket-m.dts
index 35f5205b41..9e342177e2 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_rocket-m.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_rocket-m.dts
@@ -1,7 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/dts-v1/;
-#include "ar7241_ubnt_xm_outdoor.dtsi"
+#include "ar7241.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
/ {
compatible = "ubnt,rocket-m", "ubnt,xm", "qca,ar7241";
diff --git a/target/linux/ath79/dts/ar7241_ubnt_xm.dtsi
b/target/linux/ath79/dts/ar724x_ubnt_xm.dtsi
similarity index 92%
rename from target/linux/ath79/dts/ar7241_ubnt_xm.dtsi
rename to target/linux/at
Re: [OpenWrt-Devel] [PATCH RFC v3] ath79: add support for the ar7240 version of the ubiquiti bullet
>>>>> "Adrian" == Adrian Schmutzler writes: Adrian> Ah, and please use git format-patch, your v2/v3 didn't even make Adrian> it into patchwork. Fwiw. I did use git format-patch. I have no idea how patchwork functions to extract and link patches. Perhaps you can provide guidance on that? -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC v3] ath79: add support for the ar7240 version of the ubiquiti bullet
Does this look reasonable? Any other comments?
On Sat, Feb 29, 2020 at 5:09 AM Russell Senior
wrote:
>
> The Ubiquiti Bullet M2HP come in two flavors, based on ar7240 and
> ar7241. Both are supported by ar71xx, despite the different SoCs. The
> ath79 target, however, currently supports only the ar7241. The ar7240
> version apparently has a differently wired ethernet interface and the
> ar7241-based image comes up on the ar7240-based versions without a
> working ethernet interface.
>
> This is an attempt to support both flavors of ubnt-bullet-m,
> separately.
>
> Changes since v2:
>
> * generified ar7241_ubnt_xm.dtsi into ar724x_ubnt_xm.dtsi and converted
> the ubnt_xm family of devicetree's to stack #includes rather than chain
> them in order to avoid massive duplication between ar7240 and ar7241.
>
> * fixed a broken reference to ar7241_ubnt_outdoor-xm.dtsi
>
> Changes since v1:
>
> * renamed -v0 and -v1 to -ar7240 and -ar7241, respectively, as
> suggested.
>
> * abstracted ar7241_ubnt_outdoor-xm.dtsi to ar724x_ubnt_outdoor-xm.dtsi,
> so that it could be shared between ar7240 and ar7241. Included the new
> ar724x file in the terminal dts files rather than chain them.
>
> Interested in feedback.
>
> Tested on the AR7240 flavor.
>
> Signed-off-by: Russell Senior
> ---
> .../ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts | 22 +++
> .../linux/ath79/dts/ar7241_ubnt_airrouter.dts | 3 ++-
> .../ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts | 15 +
> .../linux/ath79/dts/ar7241_ubnt_bullet-m.dts | 13 ---
> .../dts/ar7241_ubnt_nanostation-loco-m.dts| 4 +++-
> .../ath79/dts/ar7241_ubnt_nanostation-m.dts | 4 +++-
> .../ath79/dts/ar7241_ubnt_picostation-m.dts | 4 +++-
> .../linux/ath79/dts/ar7241_ubnt_rocket-m.dts | 4 +++-
> ...r7241_ubnt_xm.dtsi => ar724x_ubnt_xm.dtsi} | 5 -
> ...tdoor.dtsi => ar724x_ubnt_xm_outdoor.dtsi} | 2 --
> .../generic/base-files/etc/board.d/01_leds| 3 ++-
> .../generic/base-files/etc/board.d/02_network | 3 ++-
> .../etc/hotplug.d/firmware/10-ath9k-eeprom| 3 ++-
> target/linux/ath79/image/generic-ubnt.mk | 17 ++
> 14 files changed, 70 insertions(+), 32 deletions(-)
> create mode 100644 target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
> create mode 100644 target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
> delete mode 100644 target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
> rename target/linux/ath79/dts/{ar7241_ubnt_xm.dtsi =>
> ar724x_ubnt_xm.dtsi} (92%)
> rename target/linux/ath79/dts/{ar7241_ubnt_xm_outdoor.dtsi =>
> ar724x_ubnt_xm_outdoor.dtsi} (94%)
>
> diff --git a/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
> b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
> new file mode 100644
> index 00..99bf971eec
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "ar7240.dtsi"
> +#include "ar724x_ubnt_xm.dtsi"
> +#include "ar724x_ubnt_xm_outdoor.dtsi"
> +
> +/ {
> + compatible = "ubnt,bullet-m-ar7240", "ubnt,xm", "qca,ar7240";
> + model = "Ubiquiti Bullet M AR7240";
> +};
> +
> + {
> + fixed-link {
> + speed = <100>;
> + full-duplex;
> + };
> +};
> +
> + {
> + compatible = "syscon", "simple-mfd";
> +};
> diff --git a/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
> b/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
> index ad2762e20c..dd2421da8e 100644
> --- a/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
> +++ b/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
> @@ -1,7 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> /dts-v1/;
>
> -#include "ar7241_ubnt_xm.dtsi"
> +#include "ar7241.dtsi"
> +#include "ar724x_ubnt_xm.dtsi"
>
> / {
> compatible = "ubnt,airrouter", "ubnt,xm", "qca,ar7241";
> diff --git a/target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
> b/target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
> new file mode 100644
> index 00..bb0f19c9eb
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "ar7241.dtsi"
> +#include "ar724x_ubnt_xm.dtsi"
> +#include "ar724x_ubnt_xm_outdoor.dtsi"
> +
> +/ {
> + compatible = "ubnt,bullet-m-ar72
Re: [OpenWrt-Devel] [PATCH RFC v3] ath79: add support for the ar7240 version of the ubiquiti bullet
The Ubiquiti Bullet M2HP come in two flavors, based on ar7240 and
ar7241. Both are supported by ar71xx, despite the different SoCs. The
ath79 target, however, currently supports only the ar7241. The ar7240
version apparently has a differently wired ethernet interface and the
ar7241-based image comes up on the ar7240-based versions without a
working ethernet interface.
This is an attempt to support both flavors of ubnt-bullet-m,
separately.
Changes since v2:
* generified ar7241_ubnt_xm.dtsi into ar724x_ubnt_xm.dtsi and converted
the ubnt_xm family of devicetree's to stack #includes rather than chain
them in order to avoid massive duplication between ar7240 and ar7241.
* fixed a broken reference to ar7241_ubnt_outdoor-xm.dtsi
Changes since v1:
* renamed -v0 and -v1 to -ar7240 and -ar7241, respectively, as
suggested.
* abstracted ar7241_ubnt_outdoor-xm.dtsi to ar724x_ubnt_outdoor-xm.dtsi,
so that it could be shared between ar7240 and ar7241. Included the new
ar724x file in the terminal dts files rather than chain them.
Interested in feedback.
Tested on the AR7240 flavor.
Signed-off-by: Russell Senior
---
.../ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts | 22 +++
.../linux/ath79/dts/ar7241_ubnt_airrouter.dts | 3 ++-
.../ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts | 15 +
.../linux/ath79/dts/ar7241_ubnt_bullet-m.dts | 13 ---
.../dts/ar7241_ubnt_nanostation-loco-m.dts| 4 +++-
.../ath79/dts/ar7241_ubnt_nanostation-m.dts | 4 +++-
.../ath79/dts/ar7241_ubnt_picostation-m.dts | 4 +++-
.../linux/ath79/dts/ar7241_ubnt_rocket-m.dts | 4 +++-
...r7241_ubnt_xm.dtsi => ar724x_ubnt_xm.dtsi} | 5 -
...tdoor.dtsi => ar724x_ubnt_xm_outdoor.dtsi} | 2 --
.../generic/base-files/etc/board.d/01_leds| 3 ++-
.../generic/base-files/etc/board.d/02_network | 3 ++-
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 3 ++-
target/linux/ath79/image/generic-ubnt.mk | 17 ++
14 files changed, 70 insertions(+), 32 deletions(-)
create mode 100644 target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
create mode 100644 target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
delete mode 100644 target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
rename target/linux/ath79/dts/{ar7241_ubnt_xm.dtsi => ar724x_ubnt_xm.dtsi}
(92%)
rename target/linux/ath79/dts/{ar7241_ubnt_xm_outdoor.dtsi =>
ar724x_ubnt_xm_outdoor.dtsi} (94%)
diff --git a/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
new file mode 100644
index 00..99bf971eec
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7240.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-m-ar7240", "ubnt,xm", "qca,ar7240";
+ model = "Ubiquiti Bullet M AR7240";
+};
+
+ {
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+ {
+ compatible = "syscon", "simple-mfd";
+};
diff --git a/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
b/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
index ad2762e20c..dd2421da8e 100644
--- a/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
+++ b/target/linux/ath79/dts/ar7241_ubnt_airrouter.dts
@@ -1,7 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
/dts-v1/;
-#include "ar7241_ubnt_xm.dtsi"
+#include "ar7241.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
/ {
compatible = "ubnt,airrouter", "ubnt,xm", "qca,ar7241";
diff --git a/target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
b/target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
new file mode 100644
index 00..bb0f19c9eb
--- /dev/null
+++ b/target/linux/ath79/dts/ar7241_ubnt_bullet-m-ar7241.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7241.dtsi"
+#include "ar724x_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-m-ar7241", "ubnt,xm", "qca,ar7241";
+ model = "Ubiquiti Bullet M AR7241";
+};
+
+ {
+ compatible = "syscon", "simple-mfd";
+};
diff --git a/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
b/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
deleted file mode 100644
index e16b5fa0be..00
--- a/target/linux/ath79/dts/ar7241_ubnt_bullet-m.dts
+++ /dev/null
@@ -1,13 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
-/dts-v1/;
-
-#include "ar7241_ubnt_xm_outdoor.dtsi"
-
-/ {
- compatible = "ubnt,bullet-m", "ubnt,xm", "qca,ar7241";
- model = &q
Re: [OpenWrt-Devel] [PATCH RFC v2] ath79: add support for the ar7240 version of the ubiquiti bullet
This is actually broken in a few minor ways. I'll be following up with a
fixed up v3 shortly.
On Sat, Feb 29, 2020 at 3:36 AM Russell Senior
wrote:
>
> The Ubiquiti Bullet M2HP come in two flavors, based on ar7240 and
> ar7241. Both are supported by ar71xx, despite the different SoCs. The
> ath79 target, however, currently supports only the ar7241. The ar7240
> version apparently has a differently wired ethernet interface and the
> ar7241-based image comes up on the ar7240-based versions without a
> working ethernet interface.
>
> This is an attempt to support both flavors of ubnt-bullet-m,
> separately.
>
> Changes since v1:
>
> * renamed -v0 and -v1 to -ar7240 and -ar7241, respectively, as
> suggested.
>
> * abstracted ar7241_ubnt_outdoor-xm.dtsi to ar724x_ubnt_outdoor-xm.dtsi,
> so that it could be shared between ar7240 and ar7241. Included the new
> ar724x file in the terminal dts files rather than chain them.
>
>
> There is a further opportunity to share a
> target/linux/ath79/dts/ar724x_ubnt_xm.dtsi file, as
> target/linux/ath79/dts/ar7240_ubnt_xm.dtsi and
> target/linux/ath79/dts/ar7241_ubnt_xm.dtsi differ in one line only.
>
> Interested in feedback.
>
> Tested on the AR7240 flavor.
>
> Signed-off-by: Russell Senior
>
>
> ---
> .../ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts | 21
> target/linux/ath79/dts/ar7240_ubnt_xm.dtsi| 99 +++
> ...-m.dts => ar7241_ubnt_bullet-m-ar7241.dts} | 1 +
> ...tdoor.dtsi => ar724x_ubnt_xm_outdoor.dtsi} | 2 -
> .../generic/base-files/etc/board.d/01_leds| 3 +-
> .../generic/base-files/etc/board.d/02_network | 3 +-
> .../etc/hotplug.d/firmware/10-ath9k-eeprom| 3 +-
> target/linux/ath79/image/generic-ubnt.mk | 17 +++-
> 8 files changed, 140 insertions(+), 9 deletions(-)
> create mode 100644 target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
> create mode 100644 target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
> rename target/linux/ath79/dts/{ar7241_ubnt_bullet-m.dts =>
> ar7241_ubnt_bullet-m-ar7241.dts} (88%)
> rename target/linux/ath79/dts/{ar7241_ubnt_xm_outdoor.dtsi =>
> ar724x_ubnt_xm_outdoor.dtsi} (94%)
>
> diff --git a/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
> b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
> new file mode 100644
> index 00..5fb24b36c8
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "ar7240_ubnt_xm.dtsi"
> +#include "ar724x_ubnt_xm_outdoor.dtsi"
> +
> +/ {
> + compatible = "ubnt,bullet-m-ar7240", "ubnt,xm", "qca,ar7240";
> + model = "Ubiquiti Bullet M AR7240";
> +};
> +
> + {
> + fixed-link {
> + speed = <100>;
> + full-duplex;
> + };
> +};
> +
> + {
> + compatible = "syscon", "simple-mfd";
> +};
> diff --git a/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
> b/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
> new file mode 100644
> index 00..7165ce5668
> --- /dev/null
> +++ b/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
> @@ -0,0 +1,99 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +
> +#include
> +#include
> +
> +#include "ar7240.dtsi"
> +
> +/ {
> + compatible = "ubnt,xm", "qca,ar7240";
> + model = "Ubiquiti Networks XM (rev 1.0) board";
> +
> + keys {
> + compatible = "gpio-keys";
> +
> + reset {
> + linux,code = ;
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + debounce-interval = <60>;
> + };
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + num-cs = <1>;
> +
> + flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0>;
> + spi-max-frequency = <2500>;
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@0 {
> + label = "u-boot";
> + reg = <0x00 0x04>;
> + read-only;
> + };
> +
> +
Re: [OpenWrt-Devel] [PATCH RFC v2] ath79: add support for the ar7240 version of the ubiquiti bullet
The Ubiquiti Bullet M2HP come in two flavors, based on ar7240 and
ar7241. Both are supported by ar71xx, despite the different SoCs. The
ath79 target, however, currently supports only the ar7241. The ar7240
version apparently has a differently wired ethernet interface and the
ar7241-based image comes up on the ar7240-based versions without a
working ethernet interface.
This is an attempt to support both flavors of ubnt-bullet-m,
separately.
Changes since v1:
* renamed -v0 and -v1 to -ar7240 and -ar7241, respectively, as
suggested.
* abstracted ar7241_ubnt_outdoor-xm.dtsi to ar724x_ubnt_outdoor-xm.dtsi,
so that it could be shared between ar7240 and ar7241. Included the new
ar724x file in the terminal dts files rather than chain them.
There is a further opportunity to share a
target/linux/ath79/dts/ar724x_ubnt_xm.dtsi file, as
target/linux/ath79/dts/ar7240_ubnt_xm.dtsi and
target/linux/ath79/dts/ar7241_ubnt_xm.dtsi differ in one line only.
Interested in feedback.
Tested on the AR7240 flavor.
Signed-off-by: Russell Senior
---
.../ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts | 21
target/linux/ath79/dts/ar7240_ubnt_xm.dtsi| 99 +++
...-m.dts => ar7241_ubnt_bullet-m-ar7241.dts} | 1 +
...tdoor.dtsi => ar724x_ubnt_xm_outdoor.dtsi} | 2 -
.../generic/base-files/etc/board.d/01_leds| 3 +-
.../generic/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 3 +-
target/linux/ath79/image/generic-ubnt.mk | 17 +++-
8 files changed, 140 insertions(+), 9 deletions(-)
create mode 100644 target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
create mode 100644 target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
rename target/linux/ath79/dts/{ar7241_ubnt_bullet-m.dts =>
ar7241_ubnt_bullet-m-ar7241.dts} (88%)
rename target/linux/ath79/dts/{ar7241_ubnt_xm_outdoor.dtsi =>
ar724x_ubnt_xm_outdoor.dtsi} (94%)
diff --git a/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
new file mode 100644
index 00..5fb24b36c8
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_ubnt_bullet-m-ar7240.dts
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ar7240_ubnt_xm.dtsi"
+#include "ar724x_ubnt_xm_outdoor.dtsi"
+
+/ {
+ compatible = "ubnt,bullet-m-ar7240", "ubnt,xm", "qca,ar7240";
+ model = "Ubiquiti Bullet M AR7240";
+};
+
+ {
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+ {
+ compatible = "syscon", "simple-mfd";
+};
diff --git a/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
b/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
new file mode 100644
index 00..7165ce5668
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include
+#include
+
+#include "ar7240.dtsi"
+
+/ {
+ compatible = "ubnt,xm", "qca,ar7240";
+ model = "Ubiquiti Networks XM (rev 1.0) board";
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ linux,code = ;
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ num-cs = <1>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2500>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x04>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "u-boot-env";
+ reg = <0x04 0x01>;
+ };
+
+ partition@5 {
+ compatible = "denx,uimage";
+ label = "firmware";
+ reg = <0x05 0x75>;
+ };
+
+ partition@7a {
+ label = "board_config";
+ reg = <0x7a 0x01>;
+ read-only;
+ };
+
+ partition@7b {
+ label = "cfg";
+
Re: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet
Sorry for the accidental sidetrack to private mail. Returning the thread to the mailing list. On Thu, Feb 27, 2020 at 5:16 AM Adrian Schmutzler wrote: > Hi, > > What happens if you flash the "wrong" image? Do you see any chance to > have one of the images as "default" without suffix or would this make > things worse? > > > > Currently only the ar7241 is supported in ath79. If you flash an ar7241 > image on an ar7240 device, the wireless works but the ethernet does not. I > have not tried the other way around, but I'd expect the same thing. I > > don't actually have ready access to an ar7241-based ubnt-bullet-m to try an > ar7240 image on to confirm that expectation. > > I have a Picostation M2HP (XM) where I could technically try an ar7240 > bullet-m image. However, I do not think we will learn much from that, as > essentially the difference between ar7240.dtsi and ar7241.dtsi are a few > compatibles and that mdio1 is used instead of mdio0, so I'd expect similar > results to what you described for the opposite case. > My main reason for the question was damage assessment, but with Wifi > disabled by default and Ethernet broken one would still need TFTP for > recovery as this sounds to me. > > I also briefly considered providing a mixed ar7240/ar7241 support as for > ar71xx, but I quickly quit on that as it's hard to achieve and terribly > ugly. > > So, I still do not have a better idea than the different names/variants at > the moment. > Yeah. I am not seeing a particularly better path either, although I dislike the duplication of the dtsi's. > > Best > > Adrian > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet
On Wed, Feb 26, 2020 at 5:19 AM Adrian Schmutzler wrote: > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On > > Behalf Of Russell Senior > > Sent: Mittwoch, 26. Februar 2020 11:20 > > To: openwrt-devel@lists.openwrt.org > > Subject: [OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 > version > > of the ubiquiti bullet > > > > > > The Ubiquiti Bullet M2HP come in two flavors, based on ar7240 and > > ar7241. Both are supported by ar71xx, despite the different SoCs. The > > ath79 target, however, currently supports only the ar7241. The ar7240 > > version apparently has a differently wired ethernet interface and the > > ar7241-based image comes up on the ar7240-based versions without a > > working ethernet interface. > > > > This is an attempt to support both flavors of ubnt-bullet-m, > > separately. Some of the choices I made may be considered dubious and/or > > harmful. > > Interesting. Do you have any indications whether this will also affect the > Loco > M and Picostation XM devices? > I have some Loco's deployed (all of them are AR7241) but no picostations, so I don't know about the latter. > > What's the base for the v0/v1 distinction? Is that visible to the user > somehow? > I fear that meaningful naming will be the biggest problem here... > v0 and v1 mostly come from the need to distinguish between them. You could think of the digit as the least significant digit of the SoC. We could make them -7240 and -7241 instead of -v0 and -v1 to be slightly clearer what the names mean, but that seemed ugly. And, no, as far as I know, the SoC is not indicated on the exterior of the device at all. The user will have to figure out the right version to use somehow. > > Best > > Adrian > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC] ath79: add support for the ar7240 version of the ubiquiti bullet
The Ubiquiti Bullet M2HP come in two flavors, based on ar7240 and
ar7241. Both are supported by ar71xx, despite the different SoCs. The
ath79 target, however, currently supports only the ar7241. The ar7240
version apparently has a differently wired ethernet interface and the
ar7241-based image comes up on the ar7240-based versions without a
working ethernet interface.
This is an attempt to support both flavors of ubnt-bullet-m,
separately. Some of the choices I made may be considered dubious and/or
harmful.
Interested in feedback.
Tested on the AR7240 flavor.
Signed-off-by: Russell Senior
---
target/linux/ath79/dts/ar7240_ubnt_xm.dtsi| 99 +++
.../ath79/dts/ar7240_ubnt_xm_outdoor.dtsi | 35 +++
.../ath79/dts/ar7241_ubnt_bullet-m-v0.dts | 13 +++
...llet-m.dts => ar7241_ubnt_bullet-m-v1.dts} | 4 +-
.../generic/base-files/etc/board.d/01_leds| 3 +-
.../generic/base-files/etc/board.d/02_network | 3 +-
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 3 +-
target/linux/ath79/image/generic-ubnt.mk | 16 ++-
8 files changed, 167 insertions(+), 9 deletions(-)
create mode 100644 target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
create mode 100644 target/linux/ath79/dts/ar7240_ubnt_xm_outdoor.dtsi
create mode 100644 target/linux/ath79/dts/ar7241_ubnt_bullet-m-v0.dts
rename target/linux/ath79/dts/{ar7241_ubnt_bullet-m.dts =>
ar7241_ubnt_bullet-m-v1.dts} (63%)
diff --git a/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
b/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
new file mode 100644
index 00..7165ce5668
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_ubnt_xm.dtsi
@@ -0,0 +1,99 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include
+#include
+
+#include "ar7240.dtsi"
+
+/ {
+ compatible = "ubnt,xm", "qca,ar7240";
+ model = "Ubiquiti Networks XM (rev 1.0) board";
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ linux,code = ;
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+
+ num-cs = <1>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2500>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x04>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "u-boot-env";
+ reg = <0x04 0x01>;
+ };
+
+ partition@5 {
+ compatible = "denx,uimage";
+ label = "firmware";
+ reg = <0x05 0x75>;
+ };
+
+ partition@7a {
+ label = "board_config";
+ reg = <0x7a 0x01>;
+ read-only;
+ };
+
+ partition@7b {
+ label = "cfg";
+ reg = <0x7b 0x04>;
+ read-only;
+ };
+
+ art: partition@7f {
+ label = "art";
+ reg = <0x7f 0x01>;
+ read-only;
+ };
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ wifi: wifi@0,0 {
+ reg = <0x 0 0 0 0>;
+ qca,no-eeprom;
+ };
+};
+
+ {
+ status = "okay";
+
+ mtd-mac-address = < 0x0>;
+};
+
+ {
+ status = "okay";
+
+ mtd-mac-address = < 0x6>;
+};
diff --git a/target/linux/ath79/dts/ar7240_ubnt_xm_outdoor.dtsi
b/target/linux/ath79/dts/ar7240_ubnt_xm_outdoor.dtsi
new file mode 100644
index 00..c9178d8762
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_ubnt_xm_outdoor.dtsi
@@ -0,0 +1,35 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "ar7240_ubnt_xm.dtsi"
+
+/ {
+ aliases {
+ led-boot = _link4;
+ led-failsafe = _link4;
+ label-mac-device =
+ };
+
+ leds {
+
[OpenWrt-Devel] [PATCH] dnsmasq: fix uci-defaults script to exit 0 so it is cleaned up
A file, package/network/services/dnsmasq/files/50-dnsmasq-migrate-resolv-conf-auto.sh, was added in commit 6a2855212096d2c486961a0841b037bae4b75de7, but it does not exit in a way that tells the uci-defaults mechanism that it succeeded, and so it is not cleaned up after running successfully. Add an exit 0 to the end to correct that. Signed-off-by: Russell Senior --- .../dnsmasq/files/50-dnsmasq-migrate-resolv-conf-auto.sh| 2 ++ 1 file changed, 2 insertions(+) diff --git a/package/network/services/dnsmasq/files/50-dnsmasq-migrate-resolv-conf-auto.sh b/package/network/services/dnsmasq/files/50-dnsmasq-migrate-resolv-conf-auto.sh index c78faa112d..480e2df471 100755 --- a/package/network/services/dnsmasq/files/50-dnsmasq-migrate-resolv-conf-auto.sh +++ b/package/network/services/dnsmasq/files/50-dnsmasq-migrate-resolv-conf-auto.sh @@ -4,3 +4,5 @@ uci set dhcp.@dnsmasq[0].resolvfile="/tmp/resolv.conf.d/resolv.conf.auto" uci commit dhcp } + +exit 0 -- 2.25.0 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] brcm47xx: rename target to bcm47xx
>>>>>writes: >> >>>>> "Adrian" == Adrian Schmutzler >> writes: >> Adrian> This change makes the names of Broadcom targets consistent by Adrian> using the common notation based on SoC/CPU ID (which is used Adrian> internally anyway), bcm instead of brcm. This is even Adrian> used for target TITLE in make menuconfig already, only the short Adrian> target name used brcm so far. >> >> This seems like an aesthetic change, but it will have more >> consequential effects in tracing history and searching. I question >> whether the tradeoff is worth it. > Yes, it's purely cosmetical. However, I also don't see any big > drawbacks. The renames will be managed by git automatically, [...] If I 'git mv target/linux/brcm47xx target/linux/bcm47xx', and then do something like 'git log target/linux/bcm47xx', I don't see any of the brcm47xx history. That seems like a loss to me. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] brcm47xx: rename target to bcm47xx
>>>>> "Adrian" == Adrian Schmutzler writes: Adrian> This change makes the names of Broadcom targets consistent by Adrian> using the common notation based on SoC/CPU ID (which is used Adrian> internally anyway), bcm instead of brcm. This is even Adrian> used for target TITLE in make menuconfig already, only the short Adrian> target name used brcm so far. This seems like an aesthetic change, but it will have more consequential effects in tracing history and searching. I question whether the tradeoff is worth it. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mac80211: switch to upstream owl-loader driver
This commit broke wifi on the Buffalo WZR600DHP. See: https://bugs.openwrt.org/index.php?do=details_id=2668 On Fri, Nov 22, 2019 at 12:00 PM Christian Lamparter wrote: > On Monday, 18 November 2019 00:34:01 CET Hauke Mehrtens wrote: > > > +--- a/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c > > > b/drivers/net/wireless/ath/ath9k/ath9k_pci_owl_loader.c > > > +@@ -84,6 +84,10 @@ > > > + val = swahb32(val); > > > + } > > > + > > > ++#ifdef CONFIG_LANTIQ > > > ++ val = swab32(val); > > > ++#endif > > > > Lantiq is big endian, are there other big endian system which do not > > need this byte swap? > > From what I vaguely remember (I know that Mathias explained it to me > once.), > that special hack was necessary due to Lantiq's pci(e?)-host silicon doing > byteswaps just for 32-bit writes. The only other system that uses the > owl-loader > is ath79/ar71xx. This is a big-endian MIPS as well that didn't need the > swap. > > (That said, I don't remember what was the reason for going with > __raw_writel > rather than "iowrite32" though. At least ath9k is using it for the pci > access > just fine everywhere.) > > Anyone fancy checking out lantiq and ath79 devices with a AR92XX without > the > swap above and the __raw_writel replaced by iowrite32? > > > > ++ > > > + __raw_writel(val, mem + reg); > > > + usleep_range(100, 120); > > > + } > > Regards, > Christian > > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mediatek: remove extraneous "+" typo in mt7629 kernel config
As noted by Hauke in IRC. Introduced in commit 50735df7b238ce886c6f718b3e9437a09c8efb28 Cc: John Crispin Cc: Hauke Mehrtens Signed-off-by: Russell Senior --- target/linux/mediatek/mt7629/config-4.19 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/mediatek/mt7629/config-4.19 b/target/linux/mediatek/mt7629/config-4.19 index f32d9d1919..2dab4e393d 100644 --- a/target/linux/mediatek/mt7629/config-4.19 +++ b/target/linux/mediatek/mt7629/config-4.19 @@ -235,7 +235,7 @@ CONFIG_MTD_NAND=y CONFIG_MTD_NAND_CORE=y CONFIG_MTD_NAND_ECC=y CONFIG_MTD_NAND_MTK=y -+CONFIG_MTD_SPI_NAND=y +CONFIG_MTD_SPI_NAND=y CONFIG_MTD_SPI_NOR=y CONFIG_MTD_SPLIT_FIRMWARE=y CONFIG_MTD_SPLIT_FIT_FW=y -- 2.24.0 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: add /usr/share/libubox/jshn.sh to sysupgrade stage2
It should be harmless. +1 On Wed, Nov 13, 2019 at 3:22 PM wrote: > Hi, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Russell Senior > > Sent: Donnerstag, 14. November 2019 00:16 > > To: Daniel Golle > > Cc: openwrt-devel@lists.openwrt.org > > Subject: Re: [OpenWrt-Devel] [PATCH] base-files: add > > /usr/share/libubox/jshn.sh to sysupgrade stage2 > > > > >>>>> "Daniel" == Daniel Golle writes: > > > > Daniel> Hi Russell, > > Daniel> On Tue, Nov 12, 2019 at 03:33:48PM -0800, Russell Senior wrote: > > >> > > >> Discovered recent changes had broken sysupgrade for ar71xx mikrotik > > >> rb-493g, traced the problem to missing /usr/share/libubox/jshn.sh > > >> after switching to tmpfs. > > > > Daniel> I've applied your patch to master. Do we need to apply it for > > Daniel> openwrt-19.07 as well? > > > > I'm not sure, I haven't tested 19.07. > > I think most of the sysupgrade changes have been backported. Despite, we > are fixing ar71xx here, it makes no sense to fix ar71xx in master only ... > And adding a file should not break anything, in worst case the file would > be just useless? > > So, I'd vote for backport. > > Best > > Adrian > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: add /usr/share/libubox/jshn.sh to sysupgrade stage2
>>>>> "Daniel" == Daniel Golle writes: Daniel> Hi Russell, Daniel> On Tue, Nov 12, 2019 at 03:33:48PM -0800, Russell Senior wrote: >> >> Discovered recent changes had broken sysupgrade for ar71xx mikrotik >> rb-493g, traced the problem to missing /usr/share/libubox/jshn.sh >> after switching to tmpfs. Daniel> I've applied your patch to master. Do we need to apply it for Daniel> openwrt-19.07 as well? I'm not sure, I haven't tested 19.07. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: add /usr/share/libubox/jshn.sh to sysupgrade stage2
Discovered recent changes had broken sysupgrade for ar71xx mikrotik
rb-493g, traced the problem to missing /usr/share/libubox/jshn.sh after
switching to tmpfs.
Signed-off-by: Russell Senior
---
package/base-files/files/lib/upgrade/stage2 | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/base-files/files/lib/upgrade/stage2
b/package/base-files/files/lib/upgrade/stage2
index 5d3d46ee80..41a3b2aeb3 100755
--- a/package/base-files/files/lib/upgrade/stage2
+++ b/package/base-files/files/lib/upgrade/stage2
@@ -48,7 +48,7 @@ switch_to_ramfs() {
local file="$(which "$binary" 2>/dev/null)"
[ -n "$file" ] && install_bin "$file"
done
- install_file /etc/resolv.conf /lib/*.sh /lib/functions/*.sh
/lib/upgrade/*.sh /lib/upgrade/do_stage2 $RAMFS_COPY_DATA
+ install_file /etc/resolv.conf /lib/*.sh /lib/functions/*.sh
/lib/upgrade/*.sh /lib/upgrade/do_stage2 /usr/share/libubox/jshn.sh
$RAMFS_COPY_DATA
[ -L "/lib64" ] && ln -s /lib $RAM_ROOT/lib64
--
2.24.0
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] apm821xx: remove unnecessary kernel padding
Chris, Could you test v2 on a Meraki MX60? I only have MR24's. Thanks! -- Russell Senior russ...@personaltelco.net On Sat, Sep 21, 2019 at 1:58 AM Russell Senior wrote: > > The allocation of LEBs to ubi volumes is handled by the sysupgrade script: > > package/base-files/files/lib/upgrade/nand.sh > > and the ubimkvol and or ubirsvol command. Therefore, padding of the > kernel blob is not needed at all, so use cat instead of dd. The > BLOCKSIZE variable was only used in the dd command. In any case, 63k > made no sense for the way BLOCKSIZE was being used. > > 63k (64512) does make sense for DTB_SIZE because of the offsets expected > by u-boot given extant u-boot-env variables. > > Tested on Meraki MR24. > > Signed-off-by: Russell Senior > --- > > v2: got rid of blocking the kernel blob altogether > > target/linux/apm821xx/image/Makefile | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/target/linux/apm821xx/image/Makefile > b/target/linux/apm821xx/image/Makefile > index 8203de39c5..108f63cb7a 100644 > --- a/target/linux/apm821xx/image/Makefile > +++ b/target/linux/apm821xx/image/Makefile > @@ -58,7 +58,7 @@ define Build/MerakiAdd-dtb > $(call Image/BuildDTB,../dts/$(DEVICE_DTS).dts,$@.dtb) > ( \ > dd if=$@.dtb bs=$(DTB_SIZE) conv=sync; \ > - dd if=$@ bs=$(BLOCKSIZE) conv=sync; \ > + cat $@ ; \ > ) > $@.new > @mv $@.new $@ > endef > @@ -127,7 +127,6 @@ define Device/meraki_mr24 >DEVICE_PACKAGES := kmod-spi-gpio -swconfig >BOARD_NAME := mr24 >DEVICE_DTS := meraki-mr24 > - BLOCKSIZE := 63k >IMAGES := sysupgrade.bin >DTB_SIZE := 64512 >IMAGE_SIZE := 8191k > -- > 2.23.0 > > > > -- > Russell Senior, President > russ...@personaltelco.net > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCHv2] apm821xx: remove unnecessary kernel padding
The allocation of LEBs to ubi volumes is handled by the sysupgrade script: package/base-files/files/lib/upgrade/nand.sh and the ubimkvol and or ubirsvol command. Therefore, padding of the kernel blob is not needed at all, so use cat instead of dd. The BLOCKSIZE variable was only used in the dd command. In any case, 63k made no sense for the way BLOCKSIZE was being used. 63k (64512) does make sense for DTB_SIZE because of the offsets expected by u-boot given extant u-boot-env variables. Tested on Meraki MR24. Signed-off-by: Russell Senior --- v2: got rid of blocking the kernel blob altogether target/linux/apm821xx/image/Makefile | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/target/linux/apm821xx/image/Makefile b/target/linux/apm821xx/image/Makefile index 8203de39c5..108f63cb7a 100644 --- a/target/linux/apm821xx/image/Makefile +++ b/target/linux/apm821xx/image/Makefile @@ -58,7 +58,7 @@ define Build/MerakiAdd-dtb $(call Image/BuildDTB,../dts/$(DEVICE_DTS).dts,$@.dtb) ( \ dd if=$@.dtb bs=$(DTB_SIZE) conv=sync; \ - dd if=$@ bs=$(BLOCKSIZE) conv=sync; \ + cat $@ ; \ ) > $@.new @mv $@.new $@ endef @@ -127,7 +127,6 @@ define Device/meraki_mr24 DEVICE_PACKAGES := kmod-spi-gpio -swconfig BOARD_NAME := mr24 DEVICE_DTS := meraki-mr24 - BLOCKSIZE := 63k IMAGES := sysupgrade.bin DTB_SIZE := 64512 IMAGE_SIZE := 8191k -- 2.23.0 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] apm821xx: for Meraki MR24 modify BLOCKSIZE to reduce LEB over-allocation
On Fri, Sep 20, 2019 at 1:35 PM Christian Lamparter wrote: > Hello, > > On Tuesday, September 17, 2019 6:59:28 AM CEST Russell Senior wrote: > > On Meraki MR24, the BLOCKSIZE variable is used to allocate space for the > > kernel blob. The LEB size on MR24 is 15.5k (15872 bytes). In the > > particular instance observed, it was found that reducing blocksize to > > 512 bytes resulted in 3 fewer LEBs being allocated to the kernel ubi > > volume, with no ill effects. > > > > Signed-off-by: Russell Senior > > --- > > target/linux/apm821xx/image/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/target/linux/apm821xx/image/Makefile > b/target/linux/apm821xx/image/Makefile > > index 8203de39c5..1aa4e0dad3 100644 > > --- a/target/linux/apm821xx/image/Makefile > > +++ b/target/linux/apm821xx/image/Makefile > > @@ -127,7 +127,7 @@ define Device/meraki_mr24 > >DEVICE_PACKAGES := kmod-spi-gpio -swconfig > >BOARD_NAME := mr24 > >DEVICE_DTS := meraki-mr24 > > - BLOCKSIZE := 63k > > + BLOCKSIZE := 512 > >IMAGES := sysupgrade.bin > >DTB_SIZE := 64512 > >IMAGE_SIZE := 8191k > > The value looks odd, since UBI volumes are always a multiple of the LEB > size > and the documentation we have > <https://openwrt.org/docs/techref/flash.layout#discovery_how_to_find_out> > states that "The erasesize is the block size of the flash [...]". > so in that regard BLOCKSIZE could be 15872 or 16 KiB (if we would stick to > the real, raw value of the flash). > The only thing BLOCKSIZE is used for (afaict, for MR24) is in bs=$(BLOCKSIZE) while generating the kernel blob (which includes a header and a device tree binary as well). The DTB_SIZE is to align the device tree and kernel at particular addresses. The sysupgrade infrastructure (package/base-files/files/lib/upgrade/nand.sh) on the device deals with ubi volume creation, and it's going to allocate LEBs to volumes to minimally accommodate the file that is provided to occupy that volume. We could just concatenate the kernel with no blocking at all, and it would work fine. The section you are referring to is talking about the mtd layer, not ubi. > > But I don't think a generated image with these parameters would boot > anymore. > Which parameters? I've tested 512 and it boots fine. > As the problem here is hidden in "MerakiAdd-dtb" step that is used > generate the > KERNEL (for sysupgrade) relies on that BLOCKSIZE value being a integer > divisible > of the 63KiB value. Since this magic value (63KiB) is needed to place the > DTB+kernel at the correct offsets for mkmerakifw. > No, the device tree and kernel are placed in the "right spots" (the ones expected by u-boot) because of the DTB_SIZE variable. There is a header, the device tree at offset 1k, and the kernel starts at offset 64k. define Build/MerakiAdd-dtb $(call Image/BuildDTB,../dts/$(DEVICE_DTS).dts,$@.dtb) ( \ dd if=$@.dtb bs=$(DTB_SIZE) conv=sync; \ dd if=$@ bs=$(BLOCKSIZE) conv=sync; \ ) > $@.new @mv $@.new $@ endef That second dd could be "cat $@" and I think it would work (but haven't tested), because the blocking of the kernel is not important. > > so, what to do? Because it's possible to get rid of the whole logic as > well as the > MR24 portion of the mkmerakifw by refactoring the u-boot boot commands to > just load > and boot a multi-file image. The framework is all there since the > initramfs image is > already utilizing "MuImage-initramfs". This would save even more since > this makes it > possible to also shrink down the DTB as well. As the "raw" information in > there is > just around 10k-15k and the rest of this is fluff. (Some of this fluff is > needed by > u-boot though. As it needs some space (probably less than 128 bytes) of > this area to > "add" in values for frequencies and ranges. So it can't be completely > removed like > with newer u-boots). > It seems like the current u-boot-env variables won't support that and it's not clear how to guarantee the u-boot-env is set up before you flash the new image style. It seems much safer to just stick with the current layout for now. > > So, Would you be willing to do this? > > Regards, > Christian > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] apm821xx: for Meraki MR24 modify BLOCKSIZE to reduce LEB over-allocation
On Meraki MR24, the BLOCKSIZE variable is used to allocate space for the kernel blob. The LEB size on MR24 is 15.5k (15872 bytes). In the particular instance observed, it was found that reducing blocksize to 512 bytes resulted in 3 fewer LEBs being allocated to the kernel ubi volume, with no ill effects. Signed-off-by: Russell Senior --- target/linux/apm821xx/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/apm821xx/image/Makefile b/target/linux/apm821xx/image/Makefile index 8203de39c5..1aa4e0dad3 100644 --- a/target/linux/apm821xx/image/Makefile +++ b/target/linux/apm821xx/image/Makefile @@ -127,7 +127,7 @@ define Device/meraki_mr24 DEVICE_PACKAGES := kmod-spi-gpio -swconfig BOARD_NAME := mr24 DEVICE_DTS := meraki-mr24 - BLOCKSIZE := 63k + BLOCKSIZE := 512 IMAGES := sysupgrade.bin DTB_SIZE := 64512 IMAGE_SIZE := 8191k -- 2.23.0 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
>>>>> "Jonas" == Jonas Gorski writes: >> It contains a patch at the end titled: "[PATCH] base-files: pad >> root.squashfs to 64KiB in ubi volumes" This is another approach that >> just deals with the UBI+squashfs issue but works with >> "-nopad". Soo do we all agree there? Jonas> a) 64k is excessive, we only need 4k (actually 1k would be Jonas> enough, since we don't enable CONFIG_SQUASHFS_4K_DEVBLK_SIZE). Jonas> The referenced issue with 64k page size happens when Jonas> loop-mounting a squashfs, since loop defaults to PAGE_SIZE as its Jonas> block size. But we never do that in OpenWrt, and we don't support Jonas> any targets with that huge PAGE_SIZE - biggest is ARC with 8k. Jonas> b) it misses the squashfs's in generic sysupgrade images itself - Jonas> we need to pad their length as well, to avoid breaking devices Jonas> with a sysupgrade image hitting the corner case being flashed Jonas> from an unfixed firmware with the old nand.sh. Jonas> Also IMHO "1c0290c5cc6258c48b8ba46b4f9c85a21de4f875" should be Jonas> reverted, for the previously mentioned issues. Afaict, only devices with LEB sizes of non-integer kilobytes (like the MR24 with its 15.5k LEBs) need any intervention at all. Because squashfs's are read in 1k blocks, there is a 1 in 62 chance of creating a rootfs that is an inopportune size on 15.5k LEBs. I have a PogoPlug v3 with LEBs of 126k, and a MikroTik RouterBOARD 493G with LEBs of 124k. Neither of those is affected. I still kind of like my solution where we explicitly ask for padding for devices that need it. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
>>>>> "Christian" == Christian Lamparter writes: Christian> Ok. Christian> I did push a patch titled: "build: remove harmful -nopad Christian> option from mksquashfs" Christian> <https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=1c0290c5cc6258c48b8ba46b4f9c85a21de4f875> Christian> so, let's see if this triggers more undefined behaviour and Christian> exposes more hidden broken code. Just to re-iterate my earlier worry, if for example: kernel_size + rootfs_with_padding_size crosses an erase block boundary that: kernel_size + rootfs_without_padding_size does not, then we'll be wasting an erase block of flash space on NOR. On a side note, I noticed that there were some checks[1] added to kernels about a year ago (early august 2018) to squashfs code[1], to protect against malformed squash filesystems that might have started triggering the boot loop. This might explain why we haven't seen the problem earlier (it might have been silently ignored). [1] e.g. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=71755ee5350b63fb1f283de8561cdb61b47f4d1d -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
>> Fwiw, I took a little closer look at the squashfs code. I still don't
>> quite understand it, but I sprinkled some printk()'s and got a better
>> idea of what is happening.
>>
>> With a root.squashfs of 6428672 bytes, we get the error in a call:
>
> Actually, the 6428672 bytes was from a later trial. Sorry for the
> confusion. I'm not sure what the real root.squashfs size was
> anymore. Gah. I'll need to redo it.
Here are the corresponding numbers from the retry:
root.squasfs size (from the sysupgrade.bin tarball): 6427978 bytes
squashfs_read_data(sb=(ptrval),index=0,length=6427970,next_index=16777224,output=(null))
b=0; bytes=-322; length=8; cur_index=0
>>
>>
>> squashfs_read_data(sb=(ptrval),index=0,length=6427986,next_index=16777224,output=
>> (null))
>>
>> it enters the loop at fs/squashfs/block.c:122 with b=0; bytes=-338;
>> length=8; cur_index=0
>>
>> for (b = 0; bytes < length; b++, cur_index++) {
>> bh[b] = sb_getblk(sb, cur_index);
>> if (bh[b] == NULL)
>> goto block_release;
>>
>> sb_getblk() must return NULL, because it goes to block_release and falls
>> through to print the error message and exits with an error.
--
Russell Senior, President
russ...@personaltelco.net
_______
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
> Fwiw, I took a little closer look at the squashfs code. I still don't
> quite understand it, but I sprinkled some printk()'s and got a better
> idea of what is happening.
>
> With a root.squashfs of 6428672 bytes, we get the error in a call:
Actually, the 6428672 bytes was from a later trial. Sorry for the
confusion. I'm not sure what the real root.squashfs size was
anymore. Gah. I'll need to redo it.
>
>
> squashfs_read_data(sb=(ptrval),index=0,length=6427986,next_index=16777224,output=
> (null))
>
> it enters the loop at fs/squashfs/block.c:122 with b=0; bytes=-338; length=8;
> cur_index=0
>
> for (b = 0; bytes < length; b++, cur_index++) {
> bh[b] = sb_getblk(sb, cur_index);
> if (bh[b] == NULL)
> goto block_release;
>
> sb_getblk() must return NULL, because it goes to block_release and falls
> through to print the error message and exits with an error.
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
Fwiw, I took a little closer look at the squashfs code. I still don't
quite understand it, but I sprinkled some printk()'s and got a better
idea of what is happening.
With a root.squashfs of 6428672 bytes, we get the error in a call:
squashfs_read_data(sb=(ptrval),index=0,length=6427986,next_index=16777224,output=
(null))
it enters the loop at fs/squashfs/block.c:122 with b=0; bytes=-338; length=8;
cur_index=0
for (b = 0; bytes < length; b++, cur_index++) {
bh[b] = sb_getblk(sb, cur_index);
if (bh[b] == NULL)
goto block_release;
sb_getblk() must return NULL, because it goes to block_release and falls
through to print the error message and exits with an error.
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
r ARCHs with 64KiB pages > > > resulted in "attempt access beyond end of device" errors: > > > <https://sourceforge.net/p/squashfs/mailman/message/28307755/> > > > > AFAICT, the PAGE_SIZE on Meraki MR24 is 4k. In the kernel's > > include/asm-generic/page.h, we have: > The APM821xx SoC supports 4KiB, 16KiB and 64KiB page sizes. > Ie: <https://cateee.net/lkddb/web-lkddb/PPC_64K_PAGES.html> > OpenWrt currently defaults to 4KiB, but the 16KiB and 64KiB > do provide a throughput boost and they are easily enabled > by just editing config-default a bit. The MR24's NAND is only 32MB (okay, that's not tiny), but I'm all for optimizing for size. > > When Jonas and I were discussing this, we noted that sysupgrade changes > > won't be installed the first time you do this, so a lack of padding to > > the root.squashfs can still result in boot looping. > > > > Since Meraki MR24 (afaict) doesn't use the ubinize-image.sh script, it > > won't be protected. > Are you using an alternative flashing approach? > > The wiki: <https://openwrt.org/toh/meraki/mr24> notes that for the initial > install, the MR24 should boot off an tftp-loaded initramfs and then the > user has to use sysupgrade to install the real image. > Yes, existing initramfs + installs will have to be updated before this will > work. But then, this bug has sadly been present from the beginning and on > many other routers as well and nobody fixed it yet. It's definitely a bad > bug though. Reguar sysupgrade.bin is a tarball. I normally use sysupgrade. The initial install from stock meraki firmware is tftp booting an initramfs, and that shouldn't be a problem. The problem I'm referring to is going from an existing openwrt install to a new "fixed" one without tftp booting. If we are depending on the already-on-device sysupgrade nand.sh process, it hasn't been fixed yet. Padding the root.squashfs as delivered in the tarball will avoid the bug no matter the state of nand.sh. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
Some comments inline below ... > On Saturday, August 24, 2019 2:18:55 AM CEST Russell Senior wrote: > > >>>>> "Christian" == Christian Lamparter writes: > > > > > I've posted a similar message to the bugreport: > > > <https://bugs.openwrt.org/index.php?do=details_id=2460> > > > > I should have filed the bug first and linked it in my patch. > I think it's fine. It depends on whenever there will be a > discussion and where it will take place... But yeah, nobody > can tell in advance how this will go. > > On Saturday, August 24, 2019 2:59:31 AM CEST Russell Senior wrote: > > >>>>> "Russell" == Russell Senior writes: > > > > >>>>> "Christian" == Christian Lamparter writes: > > > > Russell> It's mostly inferred from the fact that I saw the error and > > Russell> kernel panic, and glancing at the kernel squashfs code. I am > > Russell> not pretending to understand completely how the squashfs kernel > > Russell> code works, but the position of the error relative to the size > > Russell> of the rootfs in my panic case strongly suggests it was trying > > Russell> to read past the end of the ubi volume. > > > > Oh, and I got important help finding this from Jonas Gorski. I was > > remiss in not mentioning that. > > > Ok, Let's add him to the CC then. As well as some of the > "ramips: Fix and tidy up IMAGE_SIZE #2226" and > "[RFC] Use DTS firmware partition to obsolete IMAGE_SIZE #2310" > > https://github.com/openwrt/openwrt/pull/2226 > https://github.com/openwrt/openwrt/pull/2310 > > crowd. Because this will likely affect them as well... > But they might not know it. In any case: "Welcome everyone! :-D". > > > > What's happening here is that mksquashfs4 is being told > > > through the "-nopad" option to "do not pad filesystem to a > > > multiple of 4K" [0]. > > > > > |define Image/mkfs/squashfs | > > > $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call > > > mkfs_target_dir,$(1)) $@ \ | -nopad -noappend -root-owned \ | > > > -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \ | -processors 1 |endef > > > > > My guess is that this affects more than just the MR24 (I'm > > > looking at you too: pad2jffs and various pad-to $value) > > > . I've tried tracking down the change that added the "-nopad" > > > and found it in a commit from 2005 titled: "add some changes > > > from whiterussian to head" [1] [2]: > > > > I agree that other devices where rootfs is squashfs and lives on a ubi > > volume are probaby also vulnerable to this problem. Regrettably, I haven't > > thought of any other of those devices that I have on hand to test. > > > > > | $(KDIR)/root.squashfs: | @mkdir -p $(KDIR)/root/jffs |- > > > $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend > > > -root-owned -le |+ $(STAGING_DIR)/bin/mksquashfs-lzma > > > $(KDIR)/root $@ -nopad -noappend -root-owned -le > > > > > > > So, this is really old... > > > > > Question is, should we just drop the -nopad? Since as you > > > established, in the described corner-case (see above) > > > squashfs needs this 4k padding and the generated squashfs > > > could be considered broken otherwise? > > > > I'm under the impression that the -nopad makes sense for NOR flash where > > the kernel and rootfs are glued together, padding the isolated rootfs > > would cause alignment problems or wasted space in the combined blobs. > > Yes, that's the nod to padjffs2. That said, > <https://sourceforge.net/p/squashfs/mailman/message/28307755/> makes > it sound like that apart from the BLOCKSIZE, we also need to PAGE_SIZE? > > (I think the APM821XX is a special case, since it can do 64KiB Pages > as well as it's 32MiB SLC NAND that uses 16 KiB erase-blocks. So a > PAGE can span up to 4 pages. > > > > > > (Judging from your > > > message, you went through the kernel code. Can you please > > > share the place where the lack of the padding is breaking the > > > fs?) > > > > It's mostly inferred from the fact that I saw the error and kernel > > panic, and glancing at the kernel squashfs code. I am not pretending to > > understand completely how the squashfs kernel code works, but the > > position of the error relative to the size of the rootfs in my panic > > case strongly suggests it was trying to read past the end of the ubi > > volume. > >
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
>>>>> "Russell" == Russell Senior writes: >>>>> "Christian" == Christian Lamparter writes: Russell> It's mostly inferred from the fact that I saw the error and Russell> kernel panic, and glancing at the kernel squashfs code. I am Russell> not pretending to understand completely how the squashfs kernel Russell> code works, but the position of the error relative to the size Russell> of the rootfs in my panic case strongly suggests it was trying Russell> to read past the end of the ubi volume. Oh, and I got important help finding this from Jonas Gorski. I was remiss in not mentioning that. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
>>>>> "Christian" == Christian Lamparter writes: > I've posted a similar message to the bugreport: > <https://bugs.openwrt.org/index.php?do=details_id=2460> I should have filed the bug first and linked it in my patch. > What's happening here is that mksquashfs4 is being told > through the "-nopad" option to "do not pad filesystem to a > multiple of 4K" [0]. > |define Image/mkfs/squashfs | > $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call > mkfs_target_dir,$(1)) $@ \ | -nopad -noappend -root-owned \ | > -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \ | -processors 1 |endef > My guess is that this affects more than just the MR24 (I'm > looking at you too: pad2jffs and various pad-to $value) > . I've tried tracking down the change that added the "-nopad" > and found it in a commit from 2005 titled: "add some changes > from whiterussian to head" [1] [2]: I agree that other devices where rootfs is squashfs and lives on a ubi volume are probaby also vulnerable to this problem. Regrettably, I haven't thought of any other of those devices that I have on hand to test. > | $(KDIR)/root.squashfs: | @mkdir -p $(KDIR)/root/jffs |- > $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend > -root-owned -le |+ $(STAGING_DIR)/bin/mksquashfs-lzma > $(KDIR)/root $@ -nopad -noappend -root-owned -le > So, this is really old... > Question is, should we just drop the -nopad? Since as you > established, in the described corner-case (see above) > squashfs needs this 4k padding and the generated squashfs > could be considered broken otherwise? I'm under the impression that the -nopad makes sense for NOR flash where the kernel and rootfs are glued together, padding the isolated rootfs would cause alignment problems or wasted space in the combined blobs. > (Judging from your > message, you went through the kernel code. Can you please > share the place where the lack of the padding is breaking the > fs?) It's mostly inferred from the fact that I saw the error and kernel panic, and glancing at the kernel squashfs code. I am not pretending to understand completely how the squashfs kernel code works, but the position of the error relative to the size of the rootfs in my panic case strongly suggests it was trying to read past the end of the ubi volume. The error comes in the kernel's fs/squashfs/block.c in the squashfs_read_data() function. There are a bunch of conditions (at least 5) within the function (see "goto read_failure;") that will lead to that message being printed. -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24
Using pad-squashfs ensures that the root.squashfs is assigned sufficient LEBs on UBI such that all reads of the rootfs succeed, in order to avoid read failures and kernel panics. This fixes one such kernel panic observed on Meraki MR24 where an inopportune-sized unpadded root.squashfs occurred. Note: ext4-sysupgrade firmware binaries will build with this patch, but they are as nonsensical as before the patch. Finding a way to disable ext4 builds for Meraki MR24 is left as a TODO. Signed-off-by: Russell Senior --- target/linux/apm821xx/image/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/apm821xx/image/Makefile b/target/linux/apm821xx/image/Makefile index acfd478755..53192bb448 100644 --- a/target/linux/apm821xx/image/Makefile +++ b/target/linux/apm821xx/image/Makefile @@ -133,7 +133,8 @@ define Device/meraki_mr24 IMAGE_SIZE := 8191k KERNEL := kernel-bin | lzma | uImage lzma | MerakiAdd-dtb | MerakiNAND KERNEL_INITRAMFS := kernel-bin | lzma | dtb | MuImage-initramfs lzma - IMAGE/sysupgrade.bin := sysupgrade-tar | append-metadata + IMAGE/sysupgrade.bin/squashfs := pad-squashfs | sysupgrade-tar | append-metadata + IMAGE/sysupgrade.bin/ext4 := sysupgrade-tar | append-metadata UBINIZE_OPTS := -E 5 SUPPORTED_DEVICES += mr24 endef -- 2.23.0 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH RFC 1/2] build: add squashfs padding infrastructure
Normally, root.squashfs should not be padded for alignment purposes, because particularly on NOR flash it is typically concatenated with other objects, like the kernel and device tree. However, in some cases we do want the root.squashfs to be padded, in particular when it is written into a ubi volume by itself. The kernel wants to read the squashfs in chunks, apparently either 1k or 4k bytes at a time. Because ubi volumes are allocated in logical erase blocks (LEBs) which are typically *not* powers of two (as some of the underlying space is used for metadata), a non-padded squashfs can align on the LEBs in such a way that a block read near the end of the squashfs can bleed into an area that is not part of the ubi volume, resulting in a kernel panic. One such kernel panic was recently observed in a corner case on Meraki MR24. On the MR24, the LEBs are 15.5 kiB in size. If rootfs sizes were uniformily distributed, it would be expected to see such a kernel panic for about 1/4 of the possible rootfs sizes. This commit adds some infrastucture to allow the padding of a root.squashfs to 4k boundaries. Signed-off-by: Russell Senior --- include/image-commands.mk | 5 + 1 file changed, 5 insertions(+) diff --git a/include/image-commands.mk b/include/image-commands.mk index 89c17aec5b..59dcf4e429 100644 --- a/include/image-commands.mk +++ b/include/image-commands.mk @@ -242,6 +242,11 @@ define Build/pad-rootfs $(if $(BLOCKSIZE),$(BLOCKSIZE:%k=%),4 8 16 64 128 256) endef +define Build/pad-squashfs + dd if=$(KDIR)/root.squashfs of=$(KDIR)/root.squashfs.new bs=4k conv=sync + mv $(KDIR)/root.squashfs.new $(KDIR)/root.squashfs +endef + define Build/pad-offset let \ size="$$(stat -c%s $@)" \ -- 2.23.0 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCHv2] tools/scons: update scons to 3.1.1
Signed-off-by: Russell Senior --- tools/scons/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/scons/Makefile b/tools/scons/Makefile index 5ec6554165..a9f2507835 100644 --- a/tools/scons/Makefile +++ b/tools/scons/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=scons -PKG_VERSION:=3.0.5 +PKG_VERSION:=3.1.1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=@SF/scons \ http://fossies.org/linux/misc/ -PKG_HASH:=df676f23dc6d4bfa384fc389d95dcd21ab907e6349d4c848958ba4befb73c73e +PKG_HASH:=4cea417fdd7499a36f407923d03b4b7000b0f9e8fd7b31b316b9ce7eba9143a5 include $(INCLUDE_DIR)/host-build.mk -- 2.22.0 -- Russell Senior, President russ...@personaltelco.net ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] tools/patch: apply upstream patch for cve-2019-13638
GNU patch through 2.7.6 is vulnerable to OS shell command injection that
can be exploited by opening a crafted patch file that contains an ed style
diff payload with shell metacharacters. The ed editor does not need to be
present on the vulnerable system. This is different from CVE-2018-1000156.
https://nvd.nist.gov/vuln/detail/CVE-2019-13638
Signed-off-by: Russell Senior
---
tools/patch/Makefile | 2 +-
tools/patch/patches/060-CVE-2019-13638.patch | 38
2 files changed, 39 insertions(+), 1 deletion(-)
create mode 100644 tools/patch/patches/060-CVE-2019-13638.patch
diff --git a/tools/patch/Makefile b/tools/patch/Makefile
index 3bcf668b04..e0481204f7 100644
--- a/tools/patch/Makefile
+++ b/tools/patch/Makefile
@@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=patch
PKG_VERSION:=2.7.6
-PKG_RELEASE:=5
+PKG_RELEASE:=6
PKG_CPE_ID:=cpe:/a:gnu:patch
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
diff --git a/tools/patch/patches/060-CVE-2019-13638.patch
b/tools/patch/patches/060-CVE-2019-13638.patch
new file mode 100644
index 00..38caff628a
--- /dev/null
+++ b/tools/patch/patches/060-CVE-2019-13638.patch
@@ -0,0 +1,38 @@
+From 3fcd042d26d70856e826a42b5f93dc4854d80bf0 Mon Sep 17 00:00:00 2001
+From: Andreas Gruenbacher
+Date: Fri, 6 Apr 2018 19:36:15 +0200
+Subject: Invoke ed directly instead of using the shell
+
+* src/pch.c (do_ed_script): Invoke ed directly instead of using a shell
+command to avoid quoting vulnerabilities.
+---
+ src/pch.c | 6 ++
+ 1 file changed, 2 insertions(+), 4 deletions(-)
+
+diff --git a/src/pch.c b/src/pch.c
+index 4fd5a05..16e001a 100644
+--- a/src/pch.c
b/src/pch.c
+@@ -2459,9 +2459,6 @@ do_ed_script (char const *inname, char const *outname,
+ *outname_needs_removal = true;
+ copy_file (inname, outname, 0, exclusive, instat.st_mode, true);
+ }
+- sprintf (buf, "%s %s%s", editor_program,
+- verbosity == VERBOSE ? "" : "- ",
+- outname);
+ fflush (stdout);
+
+ pid = fork();
+@@ -2470,7 +2467,8 @@ do_ed_script (char const *inname, char const *outname,
+ else if (pid == 0)
+ {
+ dup2 (tmpfd, 0);
+- execl ("/bin/sh", "sh", "-c", buf, (char *) 0);
++ assert (outname[0] != '!' && outname[0] != '-');
++ execlp (editor_program, editor_program, "-", outname, (char *)
NULL);
+ _exit (2);
+ }
+ else
+--
+cgit v1.0-41-gc330
+
--
2.22.0
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] tools/patch: apply upstream patch for CVE-2019-13636
In GNU patch through 2.7.6, the following of symlinks is mishandled in
certain cases other than input files. This affects inp.c and util.c.
https://nvd.nist.gov/vuln/detail/CVE-2019-13636
Signed-off-by: Russell Senior
---
tools/patch/Makefile | 2 +-
tools/patch/patches/050-CVE-2019-13636.patch | 108 +++
2 files changed, 109 insertions(+), 1 deletion(-)
create mode 100644 tools/patch/patches/050-CVE-2019-13636.patch
diff --git a/tools/patch/Makefile b/tools/patch/Makefile
index cab9fee9f6..3bcf668b04 100644
--- a/tools/patch/Makefile
+++ b/tools/patch/Makefile
@@ -8,7 +8,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=patch
PKG_VERSION:=2.7.6
-PKG_RELEASE:=4
+PKG_RELEASE:=5
PKG_CPE_ID:=cpe:/a:gnu:patch
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
diff --git a/tools/patch/patches/050-CVE-2019-13636.patch
b/tools/patch/patches/050-CVE-2019-13636.patch
new file mode 100644
index 00..e62c3d4175
--- /dev/null
+++ b/tools/patch/patches/050-CVE-2019-13636.patch
@@ -0,0 +1,108 @@
+From dce4683cbbe107a95f1f0d45fabc304acfb5d71a Mon Sep 17 00:00:00 2001
+From: Andreas Gruenbacher
+Date: Mon, 15 Jul 2019 16:21:48 +0200
+Subject: Don't follow symlinks unless --follow-symlinks is given
+
+* src/inp.c (plan_a, plan_b), src/util.c (copy_to_fd, copy_file,
+append_to_file): Unless the --follow-symlinks option is given, open files with
+the O_NOFOLLOW flag to avoid following symlinks. So far, we were only doing
+that consistently for input files.
+* src/util.c (create_backup): When creating empty backup files, (re)create them
+with O_CREAT | O_EXCL to avoid following symlinks in that case as well.
+---
+ src/inp.c | 12 ++--
+ src/util.c | 14 +++---
+ 2 files changed, 21 insertions(+), 5 deletions(-)
+
+diff --git a/src/inp.c b/src/inp.c
+index 32d0919..22d7473 100644
+--- a/src/inp.c
b/src/inp.c
+@@ -238,8 +238,13 @@ plan_a (char const *filename)
+ {
+ if (S_ISREG (instat.st_mode))
+ {
+-int ifd = safe_open (filename, O_RDONLY|binary_transput, 0);
++int flags = O_RDONLY | binary_transput;
+ size_t buffered = 0, n;
++int ifd;
++
++if (! follow_symlinks)
++ flags |= O_NOFOLLOW;
++ifd = safe_open (filename, flags, 0);
+ if (ifd < 0)
+ pfatal ("can't open file %s", quotearg (filename));
+
+@@ -340,6 +345,7 @@ plan_a (char const *filename)
+ static void
+ plan_b (char const *filename)
+ {
++ int flags = O_RDONLY | binary_transput;
+ int ifd;
+ FILE *ifp;
+ int c;
+@@ -353,7 +359,9 @@ plan_b (char const *filename)
+
+ if (instat.st_size == 0)
+ filename = NULL_DEVICE;
+- if ((ifd = safe_open (filename, O_RDONLY | binary_transput, 0)) < 0
++ if (! follow_symlinks)
++flags |= O_NOFOLLOW;
++ if ((ifd = safe_open (filename, flags, 0)) < 0
+ || ! (ifp = fdopen (ifd, binary_transput ? "rb" : "r")))
+ pfatal ("Can't open file %s", quotearg (filename));
+ if (TMPINNAME_needs_removal)
+diff --git a/src/util.c b/src/util.c
+index 1cc08ba..fb38307 100644
+--- a/src/util.c
b/src/util.c
+@@ -388,7 +388,7 @@ create_backup (char const *to, const struct stat *to_st,
bool leave_original)
+
+ try_makedirs_errno = ENOENT;
+ safe_unlink (bakname);
+-while ((fd = safe_open (bakname, O_CREAT | O_WRONLY | O_TRUNC, 0666))
< 0)
++while ((fd = safe_open (bakname, O_CREAT | O_EXCL | O_WRONLY |
O_TRUNC, 0666)) < 0)
+ {
+ if (errno != try_makedirs_errno)
+ pfatal ("Can't create file %s", quotearg (bakname));
+@@ -579,10 +579,13 @@ create_file (char const *file, int open_flags, mode_t
mode,
+ static void
+ copy_to_fd (const char *from, int tofd)
+ {
++ int from_flags = O_RDONLY | O_BINARY;
+ int fromfd;
+ ssize_t i;
+
+- if ((fromfd = safe_open (from, O_RDONLY | O_BINARY, 0)) < 0)
++ if (! follow_symlinks)
++from_flags |= O_NOFOLLOW;
++ if ((fromfd = safe_open (from, from_flags, 0)) < 0)
+ pfatal ("Can't reopen file %s", quotearg (from));
+ while ((i = read (fromfd, buf, bufsize)) != 0)
+ {
+@@ -625,6 +628,8 @@ copy_file (char const *from, char const *to, struct stat
*tost,
+ else
+ {
+ assert (S_ISREG (mode));
++ if (! follow_symlinks)
++ to_flags |= O_NOFOLLOW;
+ tofd = create_file (to, O_WRONLY | O_BINARY | to_flags, mode,
+ to_dir_known_to_exist);
+ copy_to_fd (from, tofd);
+@@ -640,9 +645,12 @@ copy_file (char const *from, char const *to, struct stat
*tost,
+ void
+ append_to_file (char const *from, char const *to)
+ {
++ int to_flags = O_WRONLY | O_APPEND | O_BINARY;
+ int tofd;
+
+- if ((tofd = safe_open (to, O_WRONLY | O_BINARY | O_APPEND, 0)) < 0)
++ if (! follow_symlinks)
++to_flags |= O_NOFOLLOW;
++ if ((tofd = safe_open (to, to_flags, 0)) < 0)
+ pfatal ("Can't reopen file
