ath79-generic: (re)add Rocket M2/M5 (XM)

[AiyionPrime]

Gone due to commit 45c84a117bf8 ("ar71xx: drop target")

"nrb" intends to test this device "after sleeping".

• [x] Must be flashable from vendor firmware
  • ~~Web interface~~
  • [x] TFTP
  • ~~Other: ~~
• [x] Must support upgrade mechanism
  • [x] Must have working sysupgrade
    • [x] Must keep/forget configuration (sysupgrade [-n], firstboot)
  • [x] Gluon profile name matches autoupdater image name (lua -e 'print(require("platform_info").get_image_name())')
• [x] Reset/WPS/... button must return device into config mode
• [x] Primary MAC address should match address on device label (or packaging) (https://gluon.readthedocs.io/en/latest/dev/hardware.html#notes)
  • When re-adding a device that was supported by an earlier version of Gluon, a factory reset must be performed before checking the primary MAC address, as the setting from the old version is not reset otherwise.
• Wired network
  • [x] should support all network ports on the device
  • [x] must have correct port assignment (WAN/LAN)
    • On devices supplied via PoE, there is usually no explicit WAN/LAN labeling on the hardware. The PoE input should be the WAN port in this case.
• Wireless network (if applicable)
  • [x] Association with AP must be possible on all radios
  • [x] Association with 802.11s mesh must work on all radios
  • [x] AP+mesh mode must work in parallel on all radios
• LED mapping
  • Power/system LED
    • [x] Lit while the device is on
    • [ ] Should display config mode blink sequence (https://gluon.readthedocs.io/en/latest/features/configmode.html)
  • Radio LEDs
    • [x] Should map to their respective radio
    • [x] Should show activity rssi
  • Switch port LEDs
    • [x] Should map to their respective port (or switch, if only one led present)
    • [x] Should show link state and activity
• Outdoor devices only:
  • [x] Added board name to is_outdoor_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua

[AiyionPrime]

aiyion: they're pretty much the same hardware, adding the M5 as well seems fine

orginally posted 2022-07-09 00:26:33 by @neoraider in hackint#gluon

[nrbffs]

Works well for me:

• [x] Must be flashable from vendor firmware
  • installed stock v5.6.15-sign.31612 (XM)
  • flashing via Webinterface doesn't work: "This firmware is not trusted by airOS. To maintain security, it will not be loaded. Please load trusted firmware."
  • [x] flashed same firmware via TFTP: press Reset while plugging in PoE, tftp to 192.168.1.20 -> works
• [x] Must support upgrade mechanism
  • [x] Must have working sysupgrade: sysupgrade ar71xx->ath79 works
    • [x] Must keep/forget configuration (sysupgrade [-n], firstboot) -> sysupgrade -n forgets config
  • [x] Gluon profile name matches autoupdater image name:

root@nrb-test-rocket-m2:~# lua -e 'print(require("platform_info").get_image_name())'
ubiquiti-rocket-m-xm

• [x] Reset/WPS/... button must return device into config mode
• [x] Primary MAC address should match address on device label (or packaging) (https://gluon.readthedocs.io/en/latest/dev/hardware.html#notes)
  • When re-adding a device that was supported by an earlier version of Gluon, a factory reset must be performed before checking the primary MAC address, as the setting from the old version is not reset otherwise.

root@nrb-test-rocket-m2:~# cat /lib/gluon/core/sysconfig/primary_mac
68:72:51:2e:35:25

• [x] Wired network
  • [x] should support all network ports on the device
  • [x] must have correct port assignment (WAN/LAN)
    • On devices supplied via PoE, there is usually no explicit WAN/LAN labeling on the hardware. The PoE input should be the WAN port in this case.
• [x] Wireless network (if applicable)
  • [x] Association with AP must be possible on all radios
  • [x] Association with 802.11s mesh must work on all radios
  • [x] AP+mesh mode must work in parallel on all radios
• [ ] LED mapping
  • [x] Power/system LED
    • [x] Lit while the device is on
    • [ ] Should display config mode blink sequence (https://gluon.readthedocs.io/en/latest/features/configmode.html)
      • n/a, device doesn't have SYS LED
  • [ ] Radio LEDs -> only signal strength indicator, seems to show mesh signal strength
    • [ ] Should map to their respective radio
    • [ ] Should show activity n/a
  • [x] Switch port LEDs
    • [x] Should map to their respective port (or switch, if only one led present)
    • [x] Should show link state and activity

[AiyionPrime]

Thanks to nrb for testing! The config-LED issue seems like something we could fix later, if at all. ~~Not sure, which of the LEDs should blink in configmode.~~

Looks like link4 (gpio7) is intended to show such stuff: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar724x_ubnt_xm_outdoor.dtsi

Not sure whether these mappings are fit for the rocket though.

[rotanid]

@nrbffs have you compared the LED appearance with a ar71xx build? if it's the same, it's fine, if not, we should look for a fix.

[nrbffs]

@nrbffs have you compared the LED appearance with a ar71xx build? if it's the same, it's fine, if not, we should look for a fix.

I can check that but it will probably take me a while, I am quite busy in the coming week.

[AiyionPrime]

Maybe we can get the PR #2583 of @T-X done by then, so that the commit @rotanid referenced is then already in master.

[AiyionPrime]

@nrbffs as this PR is now rebased and includes 26b5764c748c5d44cb7e6d368a55ef8a58b8a751 (after merging #2583 ), the config mode should use the fourth LED of the rssi-indicator to blink, as referenced in OpenWrts ar724x_ubnt_xm_outdoor.dtsi.

[rotanid]

@nrbffs any update possible?

[nrbffs]

Sorry no. Maybe next weekend.

On August 6, 2022 6:00:43 PM GMT+02:00, Andreas Ziegler @.> wrote: @. any update possible?

[AiyionPrime]

@nrbffs At this point I really just want to inform you: It's been another three weeks, the release is imminent, there's a weekend ongoing.

If you don't get to it that's fine, your device just won't be supported by the release. A follow-up version is probably released sometime in early or mid fall.

[nrbffs]

Sorry, a blinking LED in config mode is just not much of a priority for me currently.

[rotanid]

@nrbffs maybe you could borrow the device to someone for the testing, if you don't have the time yourself?

[nrbffs]

On Tue, 2022-10-11 at 11:38 -0700, Andreas Ziegler wrote:

@nrbffs maybe you could borrow the device to someone for the testing, if you don't have the time yourself?

Sure, just reach out.

[AiyionPrime]

@nrbffs Testing, whether the devices LED link4 blinks in configmode would still be highly appreciated. For you it's "just a blinking LED" but for a dozen others it's whether their device can be reliably updated or not.

[niehauss]

@nrbffs Testing, whether the devices LED link4 blinks in configmode would still be highly appreciated.

It blinks in config mode

[niehauss]

Thanks to nrb for testing! The config-LED issue seems like something we could fix later, if at all. ~Not sure, which of the LEDs should blink in configmode.~

Looks like link4 (gpio7) is intended to show such stuff: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar724x_ubnt_xm_outdoor.dtsi

Not sure whether these mappings are fit for the rocket though.

Yes, they fit for the Rocket XM

[niehauss]

@nrbffs any update possible?

Checklist successful completed :-)

[Djfe]

murxmaster also completed the checklist by now for future reference: https://forum.freifunk.net/t/ubiquiti-rocket-m2-m5-xm-besitzer-gesucht/23762

[herbetom]

The device was moved in October from ath79-generic to ath79-tiny: 4b5bd1509195bc8f19999ebe481b59356b5c3512

Therfore the action after the merge failed: https://github.com/freifunk-gluon/gluon/actions/runs/5434055688/jobs/9882198280

[rotanid]

The device was moved in October from ath79-generic to ath79-tiny: 4b5bd1509195bc8f19999ebe481b59356b5c3512

Therfore the action after the merge failed: https://github.com/freifunk-gluon/gluon/actions/runs/5434055688/jobs/9882198280

however, it was moved to tiny erroneously. the device has 64m memory and therefore should not have been moved along with the 32mb devices. @Djfe is preparing a commit to revert this change. after that, maybe @AiyionPrime can prepare a new testing image and new PR and maybe @niehauss has the time and motivation to test again

PR is here: https://github.com/openwrt/openwrt/pull/13047

[AiyionPrime]

Thanks for looking into this, highly appreciated :)

[niehauss]

for the Rocket XM

I might find a Rocket M2 for gluon testing if you think they differ too much from Rocket M2. Feel free to contact me ...

[Djfe]

What do you mean? 😅 There is the Rocket M2/M5 (XM) and rocket M2/M5 (XW) Both differ in their motherboards. This thread was meant to revive support for the rocket XMs (M2/M5). Do you have access to an XW, or what are you trying to say? Murxmaster in the forum helped us test the XM variant :)

[niehauss]

This thread was meant to revive support for the rocket XMs (M2/M5).

I don't know if M5 (XM) and M2 (XM) behave exactly the same way. If they do not behave the same way I might be able to find a M2 (XM).

If you dont't need a Rocket M2 (XM) for further testing: that's great!

[Djfe]

now I know what you are talking about. I'm 99% certain they behave the same way in this regard. they were served by the same image in ar71xx as well and stuff like led's, ethernet etc. are hooked up the same way. But if you want to, you may feel free to test run the m5 xm as well but we probably don't need the whole checklist again. If anyone disagrees, you may voice your complaint now ^^

The only actual difference I know of, would be a rocket xm with a usb port but I don't even know whether these were sold in the EU. airOS apparently never supported this usb port and openwrt doesn't support usb with the default image of the rocket xm either.

[rotanid]

backport for 23.05 was done: https://github.com/openwrt/openwrt/commit/ac34f6469ecf07cdeb32f65788192262fd8e0100