ath79-nand: (re)add hiveap-121

[AiyionPrime]

ath79-nand: (re)add hiveap-121

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

ath79-nand: add vendor to GL.iNet devices

@kpanic23 intends to test this device starting monday.

• Must be flashable from vendor firmware
  • Web interface
  • TFTP
  • Other: install via serial, and load via tftp following the commit message openwrt/openwrt@62db255
  • Other other: In case the bootloader does not allow regular flashing, it does allow flashing these ancient initramfs files: https://github.com/riptidewave93/LEDE-HiveAP-121 (in Releases)
• 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#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
  • should support all network ports on the device
  • 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)
  • 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 none
    • Should map to their respective radio
    • Should show activity
  • Switch port LEDs has none
    • 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

[AiyionPrime]

The patch appears to work well. Checklist follows, when @kpanic23 gets to it.

@blocktrron The patch I'd like to hand in at OpenWrt would use symlinks instead of copies, so would not increase the sysupgrade-imagesize this drastically.
It will contain some logic to handle symlinks in the updater, so it will not help in this migration.

I'd recommend to keep this patch as long as the migrations from ar71xx.

[Djfe]

How is this coming along? Do you need an active tester?
There are 5 of these installed and used in Freifunk Aachen. I could try getting into contact with one of the owners to avoid this from being dropped.

[AiyionPrime]

There are few options for this device; one is to re-add it without adding a migration.
Owners of the device will need to manually update their router.
@kpanic23 received an image for testing this approach last week.
He'll get to it.

The other approach would have been a proper migration, involving upstream patches of tar based sysupgrades, backporting them and then a two image based update; one to have the migration and one two recognize it.
This would have been a little to much effort for the few devices deployed.

A compromise would have included keeping a downstream patch. And at least one update would have been double the size of a regular update.
@blocktrron didn't like that approach to much.
So unless someone is willing to refactor and upstream the sysupgrade-tar-patch, this will stay without migration. Sorry :/

[Djfe]

how does the manual user interaction look like? do they have to return to factory and then flash?

edit:
is the two image approach used for other ath79 devices as well? what do we need two updates for? (is there maybe a post on an issue that explains this further? I get what you just explained to me but this is the first I read about needing two updates to complete the dsa migration and I wonder why. Are there sysupgrade paths that were never modified upstream to support dsa migration and tar is one of those rarer paths?)

[AiyionPrime]

how does the manual user interaction look like? do they have to return to factory and then flash?

sysupgrade -nF <image>

edit: is the two image approach used for other ath79 devices as well?

Upstream there might be more, anything that used sysupgrade-tar and changed its board_name.

what do we need two updates for?

While you need the update to contain a reference to the old board_name, you also need the update process in the router to be able to handle such references correctly.
Neither is done yet, so if you currently implemented such references by e.g. symlinks, the currently running images won't be able to unpack the update properly.
So you'll need an update of the stable branch which contains code that handles such references/symlinks properly.

(is there maybe a post on an issue that explains this further?

I don't think so.
You can look at past commits of this PR to see the compromise I described above.
82fd035

Maybe some past protocol of a developer meetup contains an explanation; I explained it and our options at some point, when blocktrron dismissed the approach with the bloated image and the staying patch in the old-stable branch.

I get what you just explained to me but this is the first I read about needing two updates to complete the dsa migration and I wonder why.

It's not the DSA migration, that requires a second update, but the implicit modification of sysupgrade-tar, which is necessary due to changes in the board_name of the device, which happened while cleaning up devices in the migration.

Are there sysupgrade paths that were never modified upstream to support dsa migration and tar is one of those rarer paths?)

Not many anymore, I'd say. And this is not necessary for the DSA-migration, but just happened during it.

[blocktrron]

CLosing as discussed at last meeting. This can be re-opened once someone is interested to pursue this further.

[AiyionPrime]

@kpanic23 Just finished testing the proposed changes. Results are above, this is ready for review.

[AiyionPrime]

I just ran make lint-editorconfig locally, no issues.
GitHubs networking ftw.

[github-actions]

Successfully created backport PR for v2022.1.x:

• [Backport v2022.1.x] ath79-nand: (re)add hiveap-121 #2884

[Djfe]

update-path from v2021 is not working. see #3181