ath79-generic: Re-add OpenMesh devices #2325

ecsv · 2021-10-10T17:02:16Z

Support for the OpenMesh devices was dropped in the commit 9fdc57c ("treewide: drop ar71xx platform specific code"). These devices will now be introduced for the ath79-generic architecture.

Source of device support

Upstream in OpenWrt 21.02

MR600 (v1, v2)
MR900 (v1, v2)
MR1750 (v1, v2)
OM2P (v2, v4)
OM2P-HS (v1, v2, v3, v4)
OM2P-LC
OM5P

Upstream in OpenWrt master

A40
A60
OM2P (v1)
OM5P-AC (v1, v2)
OM5P-AN

Pending fix for OpenWrt 21.02

OM5P-AC (v2) [21.02] ath79: Add support for OpenMesh OM5P-AC v2 openwrt/openwrt#4966

Image name changes

The switch to OpenWrt 21.02 also changed some device names slightly. manifest_aliases were added for these (but the one for OM2P-v2 was disabled and an explanation was added to targets/ath79-generic

openmesh-mr600 => openmesh-mr600-v1
openmesh-mr600v2 => openmesh-mr600-v2
openmesh-mr900 => openmesh-mr900-v1
openmesh-mr900v2 => openmesh-mr900-v2
openmesh-mr1750 => openmesh-mr1750-v1
openmesh-mr1750v2 => openmesh-mr1750-v2
openmesh-om2p => openmesh-om2p-v1
openmesh-om2pv2 => openmesh-om2p-v2
openmesh-om2pv4 => openmesh-om2p-v4
openmesh-om2p-hs => openmesh-om2p-hs-v1
openmesh-om2p-hsv2 => openmesh-om2p-hs-v2
openmesh-om2p-hsv3 => openmesh-om2p-hs-v3
openmesh-om2p-hsv4 => openmesh-om2p-hs-v4
openmesh-om5p-ac => openmesh-om5p-ac-v1
openmesh-om5p-acv2 => openmesh-om5p-ac-v2

neocturne · 2021-10-11T17:46:58Z

What's the migration situation for previously supported devices? Is a sysupgrade from Gluon 2021.1.x working without problems?

ecsv · 2021-10-12T07:41:36Z

What's the migration situation for previously supported devices? Is a sysupgrade from Gluon 2021.1.x working without problems?

The "working without problems" part is always hard to say - I would even say that it is impossible to make a 100% accurate statement. So I will limit my my statements to things I am aware of:

the previously mentioned name changes prevent that some devices can find images in the manifest

Retrieving manifest from http://firmware.freifunk-vogtland.net/firmware/test/sysupgrade//experimental.manifest ...
autoupdater: warning: no matching firmware found (model openmesh-om5p-acv2)
autoupdater: error: no usable mirror found

I am not aware of any significant problems after the sysupgrade for most devices
the OM2Pv2 has the physical assignment of the WAN interface swapped (to match the symbol on the housing) which requires a swap of the ethernet cable to the correct WAN port (or following has to be done after the system was upgrade:
```
echo eth1 > /lib/gluon/core/sysconfig/setup_ifname
echo eth0 > /lib/gluon/core/sysconfig/wan_ifname
gluon-reconfigure
uci del_list network.client.ifname=eth0
uci commit network
reboot
```
)

neocturne · 2021-10-16T12:06:37Z

So far our stance on devices needing migration is that we do not merge support for them, not even as BROKEN, as long as we do not have automated migration implemented, to avoid unnecessary churn for devices that run with experimental software and get autoupdates.

Another device I'd love to get in again, but that will have to wait for the same reason, is the CPE510v1. Finally implementing a fine-grained replacement for the BROKEN flag might be another option (but we'll have to deal with the migration anyways before the next Gluon release...)

ecsv · 2021-10-16T12:12:09Z

So far our stance on devices needing migration is that we do not merge support for them, not even as BROKEN, as long as we do not have automated migration implemented, to avoid unnecessary churn for devices that run with experimental software and get autoupdates.

But you understand that you don't get autoupdates on the OM2Pv2 because of the first point?

neocturne · 2021-10-16T12:20:11Z

So far our stance on devices needing migration is that we do not merge support for them, not even as BROKEN, as long as we do not have automated migration implemented, to avoid unnecessary churn for devices that run with experimental software and get autoupdates.

But you understand that you don't get autoupdates on the OM2Pv2 because of the first point?

I guess it might be okay to merge it under these circumstances then, with a comment in the target definition that a manifest alias should be added once the migration is working. I'm unsure whether this should be marked as BROKEN for now or not.

It is unfortunate that there are devices that are not in OpenWrt master yet, but I'm not sure if I have time to help on that at the moment. In the worst case, merging these into Gluon now might require another migration when OpenWrt takes these patches after further changes...

ecsv · 2021-10-16T12:26:37Z

I guess it might be okay to merge it under these circumstances then, with a comment in the target definition that a manifest alias should be added once the migration is working. I'm unsure whether this should be marked as BROKEN for now or not.

If I read it correctly then I should add aliases for the rest (where no migration problems are known and the device name changed slightly).

neocturne · 2021-10-16T12:33:28Z

If I read it correctly then I should add aliases for the rest (where no migration problems are known and the device name changed slightly).

Yes, as long as the update can work without passing -F to sysupgrade.

ecsv · 2022-01-17T06:59:54Z

The support of these devices is now in OpenWrt master

ecsv · 2022-01-18T20:50:25Z

Is this PR blocked because of some other ticket or because the changes were not in OpenWrt master (until end of last week)?

neocturne · 2022-01-18T21:11:26Z

It is blocked by the addition of migration code from OpenWrt 19.07 (#2372). I intend to finish that PR soon.

We will also have to work around the naming changes, so autoupdates for again for all devices as far as possible, but I don't consider that a blocker for this PR (but for the next Gluon release).

AiyionPrime · 2022-03-21T08:16:36Z

@ecsv this is no longer blocked by #2372

Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 3T3R 2.4 GHz Wi-Fi (11n) * 3T3R 5 GHz Wi-Fi (11ac) * multi-color LED (controlled via red/green/blue GPIOs) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x ethernet - eth0 + Label: Ethernet 1 + AR8035 ethernet PHY (RGMII) + 10/100/1000 Mbps Ethernet + 802.3af POE + used as WAN interface - eth1 + Label: Ethernet 2 + AR8031 ethernet PHY (SGMII) + 10/100/1000 Mbps Ethernet + used as LAN interface * 1x USB * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin

Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2T2R 2.4 GHz Wi-Fi (11n) * 2T2R 5 GHz Wi-Fi (11ac) * multi-color LED (controlled via red/green/blue GPIOs) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x ethernet - eth0 + Label: Ethernet 1 + AR8035 ethernet PHY (RGMII) + 10/100/1000 Mbps Ethernet + 802.3af POE + used as WAN interface - eth1 + Label: Ethernet 2 + AR8035 ethernet PHY (SGMII) + 10/100/1000 Mbps Ethernet + used as LAN interface * 1x USB * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin

Device specifications: ====================== * Qualcomm/Atheros AR9344 rev 2 * 560/450/225 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2T2R 2.4 GHz Wi-Fi * 2T2R 5 GHz Wi-Fi * 4x GPIO-LEDs (2x wifi, 1x wps, 1x power) * 1x GPIO-button (reset) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 1x ethernet - AR8035 ethernet PHY (RGMII) - 10/100/1000 Mbps Ethernet - 802.3af POE - used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-mr600" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros AR9344 rev 2 * 560/450/225 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2T2R 2.4 GHz Wi-Fi * 2T2R 5 GHz Wi-Fi * 8x GPIO-LEDs (6x wifi, 1x wps, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 1x ethernet - AR8035 ethernet PHY (RGMII) - 10/100/1000 Mbps Ethernet - 802.3af POE - used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-mr600v2" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 3T3R 2.4 GHz Wi-Fi * 3T3R 5 GHz Wi-Fi * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 1x ethernet - AR8035 ethernet PHY (RGMII) - 10/100/1000 Mbps Ethernet - 802.3af POE - used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-mr900" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 3T3R 2.4 GHz Wi-Fi * 3T3R 5 GHz Wi-Fi * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 1x ethernet - AR8035 ethernet PHY (RGMII) - 10/100/1000 Mbps Ethernet - 802.3af POE - used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-mr900v2" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 3T3R 2.4 GHz Wi-Fi (11n) * 3T3R 5 GHz Wi-Fi (11ac) * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 1x ethernet - AR8035 ethernet PHY (RGMII) - 10/100/1000 Mbps Ethernet - 802.3af POE - used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-mr1750" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 3T3R 2.4 GHz Wi-Fi (11n) * 3T3R 5 GHz Wi-Fi (11ac) * 6x GPIO-LEDs (2x wifi, 2x status, 1x lan, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 1x ethernet - AR8035 ethernet PHY (RGMII) - 10/100/1000 Mbps Ethernet - 802.3af POE - used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-mr1750v2" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros AR7240 rev 2 * 350/350/175 MHz (CPU/DDR/AHB) * 32 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2x 10/100 Mbps Ethernet * 1T1R 2.4 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x fast ethernet - eth0 + 18-24V passive POE (mode B) + used as WAN interface - eth1 + builtin switch port 4 + used as LAN interface * 12-24V 1A DC * external antenna The device itself requires the mtdparts from the uboot arguments to properly boot the flashed image and to support dual-boot (primary + recovery image). Unfortunately, the name of the mtd device in mtdparts is still using the legacy name "ar7240-nor0" which must be supplied using the Linux-specfic DT parameter linux,mtd-name to overwrite the generic name "spi0.0". Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-om2p" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros QCA9533 v2 * 650/600/217 MHz (CPU/DDR/AHB) * 64 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2x 10/100 Mbps Ethernet * 1T1R 2.4 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x fast ethernet - eth0 + Label: Ethernet 1 + 24V passive POE (mode B) - eth1 + Label: Ethernet 2 + 802.3af POE + builtin switch port 1 * 12-24V 1A DC * external antenna Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-om2pv4" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros AR9341 rev 1 * 535/400/200 MHz (CPU/DDR/AHB) * 64 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2x 10/100 Mbps Ethernet * 2T2R 2.4 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x fast ethernet - eth0 + 802.3af POE + builtin switch port 1 + used as LAN interface - eth1 + 18-24V passive POE (mode B) + used as WAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-om2phs" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros AR9341 rev 1 * 535/400/200 MHz (CPU/DDR/AHB) * 64 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2x 10/100 Mbps Ethernet * 2T2R 2.4 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x fast ethernet - eth0 + 802.3af POE + builtin switch port 1 + used as LAN interface - eth1 + 18-24V passive POE (mode B) + used as WAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-om2phsv2" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros AR9341 rev 1 * 535/400/200 MHz (CPU/DDR/AHB) * 64 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2x 10/100 Mbps Ethernet * 2T2R 2.4 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x fast ethernet - eth0 + 802.3af POE + builtin switch port 1 + used as LAN interface - eth1 + 18-24V passive POE (mode B) + used as WAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-om2phsv3" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros QCA9533 v2 * 650/600/217 MHz (CPU/DDR/AHB) * 64 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2x 10/100 Mbps Ethernet * 2T2R 2.4 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x fast ethernet - eth0 + 24V passive POE (mode B) + used as WAN interface - eth1 + 802.3af POE + builtin switch port 1 + used as LAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-om2phsv4" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros AR9330 rev 1 * 400/400/200 MHz (CPU/DDR/AHB) * 64 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2x 10/100 Mbps Ethernet * 1T1R 2.4 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x fast ethernet - eth0 + builtin switch port 1 + used as LAN interface - eth1 + 18-24V passive POE (mode B) + used as WAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin

Device specifications: ====================== * Qualcomm/Atheros AR9344 rev 2 * 560/450/225 MHz (CPU/DDR/AHB) * 64 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2x 10/100 Mbps Ethernet * 2T2R 5 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * 2x fast ethernet - eth0 + builtin switch port 1 + used as LAN interface - eth1 + 18-24V passive POE (mode B) + used as WAN interface * 12-24V 1A DC * internal antennas WAN/LAN LEDs appear to be wrong in ar71xx and have been swapped here. Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin

Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/240 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2T2R 2.4 GHz Wi-Fi (11n) * 2T2R 5 GHz Wi-Fi (11ac) * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * TI tmp423 (package kmod-hwmon-tmp421) for temperature monitoring * 2x ethernet - eth0 + AR8035 ethernet PHY (RGMII) + 10/100/1000 Mbps Ethernet + 802.3af POE + used as LAN interface - eth1 + AR8035 ethernet PHY (SGMII) + 10/100/1000 Mbps Ethernet + 18-24V passive POE (mode B) + used as WAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-om5p-ac" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros QCA9558 ver 1 rev 0 * 720/600/200 MHz (CPU/DDR/AHB) * 128 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 2T2R 2.4 GHz Wi-Fi (11n) * 2T2R 5 GHz Wi-Fi (11ac) * 4x GPIO-LEDs (3x wifi, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default)) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * TI tmp423 (package kmod-hwmon-tmp421) for temperature monitoring * 2x ethernet - eth0 + AR8035 ethernet PHY (RGMII) + 10/100/1000 Mbps Ethernet + 802.3af POE + used as LAN interface - eth1 + AR8031 ethernet PHY (RGMII) + 10/100/1000 Mbps Ethernet + 18-24V passive POE (mode B) + used as WAN interface * 12-24V 1A DC * internal antennas This device support is based on the partially working stub from commit 53c474abbdfe ("ath79: add new OF only target for QCA MIPS silicon"). Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin Gluon image name change ======================= The device had the image name "openmesh-om5p-acv2" in older versions of Gluon. This had to be changed with the new name in the device trees of the ath79 device tree.

Device specifications: ====================== * Qualcomm/Atheros AR9344 rev 2 * 560/450/225 MHz (CPU/DDR/AHB) * 64 MB of RAM * 16 MB of SPI NOR flash - 2x 7 MB available; but one of the 7 MB regions is the recovery image * 1T1R 2.4 GHz Wi-Fi * 2T2R 5 GHz Wi-Fi * 6x GPIO-LEDs (3x wifi, 2x ethernet, 1x power) * 1x GPIO-button (reset) * external h/w watchdog (enabled by default) * TTL pins are on board (arrow points to VCC, then follows: GND, TX, RX) * TI tmp423 (package kmod-hwmon-tmp421) for temperature monitoring * 2x ethernet - eth0 + AR8035 ethernet PHY + 10/100/1000 Mbps Ethernet + 802.3af POE + used as LAN interface - eth1 + 10/100 Mbps Ethernet + builtin switch port 1 + 18-24V passive POE (mode B) + used as WAN interface * 12-24V 1A DC * internal antennas Flashing instructions: ====================== Various methods can be used to install the actual image on the flash. Two easy ones are: ap51-flash ---------- The tool ap51-flash (https://github.com/ap51-flash/ap51-flash) should be used to transfer the image to the u-boot when the device boots up. initramfs from TFTP ------------------- The serial console must be used to access the u-boot shell during bootup. It can then be used to first boot up the initramfs image from a TFTP server (here with the IP 192.168.1.21): setenv serverip 192.168.1.21 setenv ipaddr 192.168.1.1 tftpboot 0c00000 <filename-of-initramfs-kernel>.bin && bootm $fileaddr The actual sysupgrade image can then be transferred (on the LAN port) to the device via scp <filename-of-squashfs-sysupgrade>.bin root@192.168.1.1:/tmp/ On the device, the sysupgrade must then be started using sysupgrade -n /tmp/<filename-of-squashfs-sysupgrade>.bin

ecsv · 2022-03-21T08:38:55Z

@AiyionPrime thanks, but I cannot remove the blocked status. The rebased changes were now pushed (which basically only drops the OM5P-AC v2 fix which was already applied upstream for 21.02.2)

neocturne · 2022-03-21T18:23:14Z

Only the interface naming issue has been solved by #2372. sysupgrade will still reject images with changed device names. We have an idea how to solve that as well, but is hasn't been implemented yet.

ecsv · 2022-03-21T19:18:14Z

Only the interface naming issue has been solved by #2372. sysupgrade will still reject images with changed device names. We have an idea how to solve that as well, but is hasn't been implemented yet.

You mean openwrt's sysupgrade code? Because the old names are still in the supported_devices list and at least when I've created the PR, didn't require a -F. The reason for the exception with OM2Pv2 is explained in #2325 (comment)

neocturne · 2022-03-21T19:41:36Z

Only the interface naming issue has been solved by #2372. sysupgrade will still reject images with changed device names. We have an idea how to solve that as well, but is hasn't been implemented yet.

You mean openwrt's sysupgrade code? Because the old names are still in the supported_devices list and at least when I've created the PR, didn't require a -F. The reason for the exception with OM2Pv2 is explained in #2325 (comment)

Ah, I wasn't aware that the old names are in supported_devices for most of the models, in that case upgrades should work fine. Do I understand correctly that this is not the case for the OM2Pv2, so sysupgrade will reject the image?

ecsv · 2022-03-21T19:44:00Z

Do I understand correctly that this is not the case for the OM2Pv2, so sysupgrade will reject the image?

~~yes, on purpose.~~

EDIT: This statement was wrong as @NeoRaider pointed out. The sysupgrade still works but gluon's autoupdater is rejecting the image because manifest_aliases is not set for this device.

neocturne · 2022-03-23T23:01:33Z

Do I understand correctly that this is not the case for the OM2Pv2, so sysupgrade will reject the image?

yes, on purpose.

I had a look at the code, and in Device/openmesh_om2p-v2 it says:

SUPPORTED_DEVICES += om2pv2

Am I misunderstanding something, or would sysupgrade actually accept the new image without -F?

ecsv · 2022-03-24T07:45:25Z

Am I misunderstanding something, or would sysupgrade actually accept the new image without -F?

I have updated my statement about it

neocturne · 2022-03-24T07:56:47Z

Am I misunderstanding something, or would sysupgrade actually accept the new image without -F?

I have updated my statement about it

In that case we can just add the manifest alias now and drop the comment, as Gluon is able to fix up the network configuration now.

ecsv · 2022-03-24T07:58:39Z

Not sure how gluon is able to unplug an ethernet cable and attach it to the other physical port.

neocturne · 2022-03-24T08:01:19Z

Not sure how gluon is able to unplug an ethernet cable and attach it to the other physical port.

Sorry, it seems I misunderstood the whole issue. What is going on with this device? How many ports does if have? How are these ports labelled physically? Was the WAN/LAN assignment incorrect in the previous version, or is it just an arbitrary decision that happens to be reversed in the new version?

ecsv · 2022-03-24T08:12:14Z

Sorry, it seems I misunderstood the whole issue. What is going on with this device? How many ports does if have? How are these ports labelled physically? Was the WAN/LAN assignment incorrect in the previous version, or is it just an arbitrary decision that happens to be reversed in the new version?

It has two ethernet ports. The PCB (which I had for most of the time) didn't had any labels and thus I've just used what Marek Lindner prepared for OpenWrt (and which I've later submitted to OpenWrt). But when I've got one with housing (when I've gathered the devices from various sources), I've noticed that the port used for WAN under OpenWrt 19.07 was not the one labelled as WAN. The OpenWrt 21.02 port is now using the port labelled as WAN actually as WAN port under OpenWrt.

open-mesh.com (bought by Datto) was using whatever port was attached to a network with DHCP as WAN port. As result, Marek was never interested in making sure that physical WAN port had anything to do with the net_device which is used as WAN port. And after a long time of no one noticing or reporting this problem, I've only noticed it with the OpenWrt 21.02 port, fixed it and in this process created the situation which we have now.

github-actions bot added 3. topic: docs Topic: Documentation 3. topic: hardware Topic: Hardware Support labels Oct 10, 2021

ecsv marked this pull request as ready for review October 10, 2021 20:39

ecsv force-pushed the ath79-openmesh branch from da06259 to b0bebb6 Compare October 16, 2021 12:55

neocturne added the 2. status: blocked Marked as blocked because it's waiting on something label Jan 1, 2022

ecsv force-pushed the ath79-openmesh branch 4 times, most recently from 92d5088 to dfeda4e Compare January 18, 2022 20:46

ecsv force-pushed the ath79-openmesh branch from dfeda4e to 5df5e2f Compare March 1, 2022 10:42

ecsv added 9 commits March 21, 2022 09:37

ecsv added 10 commits March 21, 2022 09:37

ecsv force-pushed the ath79-openmesh branch from 5df5e2f to 979cc0a Compare March 21, 2022 08:37

AiyionPrime mentioned this pull request Mar 21, 2022

ar71xx - ath79 migration progress #2413

Open

neocturne added 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. and removed 2. status: blocked Marked as blocked because it's waiting on something labels Mar 21, 2022

neocturne self-assigned this Mar 21, 2022

neocturne added 2. status: waiting-on-author Waiting on some action from the author and removed 2. status: waiting-on-review Awaiting review from the assignee but also interested parties. labels Mar 23, 2022

neocturne merged commit 086aa7a into freifunk-gluon:master Mar 24, 2022

ecsv deleted the ath79-openmesh branch March 24, 2022 08:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

ath79-generic: Re-add OpenMesh devices #2325

ath79-generic: Re-add OpenMesh devices #2325

ecsv commented Oct 10, 2021 •

edited

Loading

neocturne commented Oct 11, 2021

ecsv commented Oct 12, 2021

neocturne commented Oct 16, 2021

ecsv commented Oct 16, 2021

neocturne commented Oct 16, 2021

ecsv commented Oct 16, 2021

neocturne commented Oct 16, 2021 •

edited

Loading

ecsv commented Jan 17, 2022

ecsv commented Jan 18, 2022

neocturne commented Jan 18, 2022

AiyionPrime commented Mar 21, 2022

ecsv commented Mar 21, 2022

neocturne commented Mar 21, 2022

ecsv commented Mar 21, 2022

neocturne commented Mar 21, 2022

ecsv commented Mar 21, 2022 •

edited

Loading

neocturne commented Mar 23, 2022

ecsv commented Mar 24, 2022

neocturne commented Mar 24, 2022

ecsv commented Mar 24, 2022

neocturne commented Mar 24, 2022

ecsv commented Mar 24, 2022

ath79-generic: Re-add OpenMesh devices #2325

ath79-generic: Re-add OpenMesh devices #2325

Conversation

ecsv commented Oct 10, 2021 • edited Loading

Source of device support

Upstream in OpenWrt 21.02

Upstream in OpenWrt master

Pending fix for OpenWrt 21.02

Image name changes

neocturne commented Oct 11, 2021

ecsv commented Oct 12, 2021

neocturne commented Oct 16, 2021

ecsv commented Oct 16, 2021

neocturne commented Oct 16, 2021

ecsv commented Oct 16, 2021

neocturne commented Oct 16, 2021 • edited Loading

ecsv commented Jan 17, 2022

ecsv commented Jan 18, 2022

neocturne commented Jan 18, 2022

AiyionPrime commented Mar 21, 2022

ecsv commented Mar 21, 2022

neocturne commented Mar 21, 2022

ecsv commented Mar 21, 2022

neocturne commented Mar 21, 2022

ecsv commented Mar 21, 2022 • edited Loading

neocturne commented Mar 23, 2022

ecsv commented Mar 24, 2022

neocturne commented Mar 24, 2022

ecsv commented Mar 24, 2022

neocturne commented Mar 24, 2022

ecsv commented Mar 24, 2022

ecsv commented Oct 10, 2021 •

edited

Loading

neocturne commented Oct 16, 2021 •

edited

Loading

ecsv commented Mar 21, 2022 •

edited

Loading