Adding new target ipq807x-generic and new device Xiaomi AX3600

[ChristianMiddendorf]

• Must be flashable from vendor firmware
  • Web interface
  • TFTP
  • Other: <supgrade from OpenWRT but do not save configuration over reflash... "sysupgrade -n filenamefromsysupgrade.bin">
• Must support upgrade mechanism
  • Must have working sysupgrade
    • Must keep/forget configuration (sysupgrade [-n], firstboot)
  • Gluon profile name matches autoupdater image name
    (lua -e 'print(require("platform_info").get_image_name())')
• Reset/WPS/... button must return device into config mode
• Primary MAC address should match address on device label (or packaging)
  (https://gluon.readthedocs.io/en/latest/dev/hardware.html#hardware-support-in-packages)
  • 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
  • should support all network ports on the device
  • must have correct port assignment (WAN/LAN)
    • if there are multiple ports but no WAN port:
      • the PoE input should be WAN, all other ports LAN
      • otherwise the first port should be declared as WAN, all other ports LAN
• Wireless network (if applicable)
  • Association with AP must be possible on all radios
  • Association with 802.11s mesh must work on all radios
  • AP+mesh mode must work in parallel on all radios
• LED mapping
  • Power/system LED
    • Lit while the device is on
    • Should display config mode blink sequence
      (https://gluon.readthedocs.io/en/latest/features/configmode.html)
  • Radio LEDs
    • Should map to their respective radio
    • Should show activity
  • Switch port LEDs
    • Should map to their respective port (or switch, if only one led present)
    • Should show link state and activity
• Outdoor devices only:
  • Added board name to is_outdoor_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua
• Cellular devices only:
  • Added board name to is_cellular_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua
  • Added board name with modem setup function setup_ncm_qmi to package/gluon-core/luasrc/lib/gluon/upgrade/250-cellular
• Docs:
  • Added Device to docs/user/supported_devices.rst

[ChristianMiddendorf]

gluon-ffin-v2023.2.2+116-fastd-xiaomi_ax3600-sysupgrade.zip
Example for the Freifunk Ingolstadt Community

[herbetom]

Hi,

could you please edit your PR description so that the checklist renders properly?

Should just be a one to one copy and if you want to check something just change [ ] to [x].
Of course it's fine to add comments where appropiate but proper formating allows for much better readability.

Also you'll have to add the target to .github/filters.yml:

https://github.com/freifunk-gluon/gluon/actions/runs/11308434515/job/31451274282

If you click on the "Show diff" CI Step you can see what and where you'll have to add it to make the CI pass.

[ChristianMiddendorf]

.github/filters.yml

Thanks a lot for your kind support!

A short explanation why some points are not marked as checked:

• The device has three WLAN radios but with gluon you can just use two. One for 2,4GHz, one for 5GHz.
• Radio LEDs: You can just see activity of the access point with one LED, the other one is to show that it is working. But you do not see if it is traffic from a special radio or LAN port
• As there are no LEDs for the LAN ports they are not assigned and do not show activities that are mapped to a special port.

To get around the question if it would be better to use xiaomi_ax3600 oder xiaomi-ax3600 both labels are now supported.

[maurerle]

So this is also relying on #1661 as well.
Seems like you have a similar workaround as the #3057 where one radio driver was removed, so that gluon only sees two and functions in some way.

This would only get broken support, and it probably would be better to first work out functional support for devices with three radios in gluon.. :/

[ChristianMiddendorf]

So this is also relying on #1661 as well. Seems like you have a similar workaround as the #3057 where one radio driver was removed, so that gluon only sees two and functions in some way.

This would only get broken support, and it probably would be better to first work out functional support for devices with three radios in gluon.. :/

Hello,
this solution will also close #3032.
The difference is that you have now official OpenWRT support for AX3600 and just have to disable the third radio. Before you had to activate the drivers for the two working radios yourself that would bring trouble if the OpenWRT solution gets updated. This one that bases on the official solution has a better chance to survive in the future.

Generally it would be great if all radios (n) would get support. But I believe there is no reason to wait and the device is now available in the market with a lot of CPU power, WLAN6 and a good antenna array.

If we have support for the ipq807 target it should be easy to support Xiaomi AX9000 as well. As far as I know one of the most powerful OpenWRT devices that serves 1000+ clients if needed. Just the secure boot thing and different layouts for CN and International version are unpleasant.

[ChristianMiddendorf]

Hallo Tom, ich hatte gerade noch mal nachgesehen bezüglich der Syntax. Wäre es nicht besser wenn wir die Schreibweisenfrage ausgliedern über den aliases Teil? Beispiel im „read the docs“: device('aruba-ap-303', 'aruba_ap-303', { factory = false, aliases = {'aruba-instant-on-ap11'}, })

>>also

device('xiaomi_ax3600', 'xiaomi-ax3600', { aliases = {'xiaomi_ax3600'}, }) Leider geht die Benennung ob Bindestrich oder Unterstrich quer durcheinander, sodass ich vermute, dass egal welche Schreibweise wir festlegen würden es auch mal die falsche je nach Anwendungsfall ist und das Sysupgrade nur noch per force erreicht werden könnte... was unschön wäre. Meine Variante hatte zumindest den Vorteil das kommend von OpenWRT es keine Rückfragen erzeugt. Beste Grüße Christian Von: Tom Herbers ***@***.***> Gesendet: Sonntag, 13. Oktober 2024 00:27 An: freifunk-gluon/gluon ***@***.***> Cc: Christian Middendorf ***@***.***>; Author ***@***.***> Betreff: Re: [freifunk-gluon/gluon] Adding new target ipq807x-generic and new device Xiaomi AX3600 (PR #3354) @herbetom requested changes on this pull request. Hi, could you please edit your PR description so that the checklist renders properly? Should just be a one to one copy <https://github.com/freifunk-gluon/gluon/wiki/Device-Integration-checklist> and if you want to check something just change [ ] to [x]. Of course it's fine to add comments where appropiate but proper formating allows for much better readability. Also you'll have to add the target to .github/filters.yml: https://github.com/freifunk-gluon/gluon/actions/runs/11308434515/job/31451274282 If you click on the "Show diff" CI Step you can see what and where you'll have to add it to make the CI pass.

_____ In targets/ipq807x-generic <#3354 (comment)> :

@@ -0,0 +1,11 @@

+-- Xiaomi + +device('xiaomi_ax3600', 'xiaomi_ax3600', { ⬇️ Suggested change

…

-device('xiaomi_ax3600', 'xiaomi_ax3600', { +device('xiaomi_ax3600', 'xiaomi-ax3600', { probably — Reply to this email directly, view it on GitHub <#3354 (review)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/A7UN54APZ6H5AJKRS7QMM73Z3GOZRAVCNFSM6AAAAABP2WQ7MOVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDGNRUGYZTOOJTGY> . You are receiving this because you authored the thread. <https://github.com/notifications/beacon/A7UN54DNBKUESJMBA34TLJLZ3GOZRA5CNFSM6AAAAABP2WQ7MOWGG33NNVSW45C7OR4XAZNRKB2WY3CSMVYXKZLTORJGK5TJMV32UY3PNVWWK3TUL5UWJTUM6GBPA.gif> Message ID: ***@***.*** ***@***.***> >

[maurerle]

@ChristianMiddendorf zum Verständnis was diese beiden Strings im Device bedeuten:

• der vordere muss immer mit dem Namen übereinstimmen, den der Autoupdater erwartet. Der Name für den Autoupdater ist vom Model String im Device Tree abgeleitet.
  https://github.com/openwrt/openwrt/blob/e98987048ad73012cb29993c39c2de8682d64f9b/target/linux/qualcommax/image/ipq807x.mk#L364-L365 bzw entspricht exakt lua -e 'print(require("platform_info").get_image_name())' auf deinem Gerät
• der hintere muss immer dem Namen des Devices in Openwrt übereinstimmen (hier https://github.com/openwrt/openwrt/blob/e98987048ad73012cb29993c39c2de8682d64f9b/target/linux/qualcommax/image/ipq807x.mk#L361)
• bei manchen Geräten gibt es bei der selben Firmware zusätzliche Model Names die in der Regel in den manifest_aliases eingetragen werden. Das macht man aber nur wenn es auch tatsächlich ein Gerät gibt, welches diesen String in lua -e 'print(require("platform_info").get_image_name())' auch reported.

Das ist im Grunde auch hier beschrieben:
https://gluon.readthedocs.io/en/latest/dev/hardware.html#device-definitions
ist jedoch etwas ausbaufähig.

Du müsstest es meines Erachtens nach also genau andersrum handhaben in deiner Config @herbetom

[Djfe]

The big problem that Blocktrron might still have with the target is that no one has added support for Gluon to handle the new regulatory domain (iw reg dm).
Actually, it was always the case that this is regulated by Linux. But now (ath11k, ath12) the wifi chip determines which frequencies are allowed and which signal strength via information in its firmware.
Gluon must be able to select the country correctly with iw and be restricted in such a way that it does not select a frequency/signal strength combination (e.g. in outdoor mode) that the wifi chip outright rejects.
This would then lead to an error and non-functioning wifi.

[blocktrron]

@Djfe we could postpone a decision by adding this platform as broken. I don't own such a platform and would like to make myself a better picture about the situation / implications (every information i have is from mailinglists and thus could be incomplete / incorrect).

[Djfe]

I'd would like/support such a decision.

[ChristianMiddendorf]

@Djfe we could postpone a decision by adding this platform as broken. I don't own such a platform and would like to make myself a better picture about the situation / implications (every information i have is from mailinglists and thus could be incomplete / incorrect).

Good morning,
What do you think about me sending you the device?
If experiments go wrong, you can simply reinstall the stock firmware via TFTP and start from scratch :)
Best regards,
Christian

[AiyionPrime]

@Djfe sorry, I did not realize the duplicate PR, thanks for the heads up.

[...]

I have not checked latest OpenWrt changes, but know that @cawi2001 would be available to test something, if there's something missing here and if he were provided with an image for the device.
The "IOT" triple radio is not worth waiting for (at least for this device) due to the ridiculous small possible throughput.

Deactivating it is very much fine, I'd say.

What @blocktrron said.

Originally posted by @AiyionPrime in #3032 (comment)

[AiyionPrime]

@ChristianMiddendorf is there anything you would like @cawi2001 to test?
I think his offer still stands.