ramips-mt7621: add dlink-dap-1620-b1

[GoliathLabs]

• Must be flashable from vendor firmware
  • Web interface -- should theoretically work, didn't work for me; used u-boot web recovery instead
  • TFTP
  • Other: Bootloader web recovery
• 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.
  • Doesnt have MAC printed on label or packaging
• 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
    --> marked as broken
• 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
    • [n/a] Should map to their respective radio
    • Should show activity --> Same as with the DAP-X1860
  • Switch port LEDs
    • [n/a] Should map to their respective port (or switch, if only one led present)
    • [n/a] Should show link state and activity
• Outdoor devices only:
  • [n/a] Added board name to is_outdoor_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua
• Cellular devices only:
  • [n/a] Added board name to is_cellular_device function in package/gluon-core/luasrc/usr/lib/lua/gluon/platform.lua
  • [n/a] 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

[GoliathLabs]

Hello,
the firmware can be flashed according to the checklist. Nevertheless, I have a specific problem. I have to do wifi down and wifi up after booting. Otherwise I cannot connect to the network (e.g. access denied). The WLAN configuration is also suboptimal. The SSID is visible, but only 2.4 GHz, as 5 GHz is apparently deactivated and not configured.

I would be very grateful for any tips on how to approach this problem. 🚀

config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '6'
        option band '2g'
        option htmode 'VHT20'
        option country 'DE'
        option legacy_rates '0'

config wifi-iface 'mesh_radio0'
        option ifname 'mesh0'
        option network 'mesh_radio0'
        option device 'radio0'
        option mesh_fwding '0'
        option mesh_id 'ffmuc-augsburg-mesh'
        option mcast_rate '12000'
        option mode 'mesh'
        option disabled '0'
        option macaddr '16:84:d1:83:7b:09'

config wifi-iface 'client_radio0'
        option ifname 'client0'
        option network 'client'
        option disabled '0'
        option device 'radio0'
        option mode 'ap'
        option macaddr '16:84:d1:83:7b:08'
        option ssid 'muenchen.freifunk.net/augsburg'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0+1'
        option channel '36'
        option band '5g'
        option htmode 'VHT80'
        option disabled '1'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'

[Djfe]

Hello GoliathLabs,

in principal this platform should be supported.
We have one other device from the same type. The TP-Link RE650 v1 is also mt7621 + mt7615 dbdc.
But maybe something broke due to OpenWrt 23.

What does iw list output?
Does 5GHz work on OpenWrt?
Please upload Gluon's logread output from boot to pastebin :)
Maybe a second output after wifi reload.

[GoliathLabs]

I've flashed OpenWrt 23.05.2 to test it out. Interestingly, it only shows one interface which is the 5 GHz one (association with the SSID works as expected). Logread of OpenWrt down below.

EDIT to my last comment. To associate with the wifi on gluon, I had to issue the following command prior to wifi up the wifi again: echo 1 > /sys/kernel/debug/ieee80211/phy0/mt76/dbdc. The logread of that is also down below.

root@OpenWrt:~# cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '36'
        option band '5g'
        option htmode 'VHT80'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt'
        option encryption 'none'

logread_gluon.txt
logred_gluon_dbdc.txt
logred_openwrt.txt
iwlist.txt

[Djfe]

Maybe we should try to figure out whether this broke due to a commit since openwrt/openwrt@e4c7703
Because I expect that it worked fine back then
Atleast since the day this fix was pushed to master:
openwrt/openwrt#12361 (comment)
This bug is likely a regression

but maybe it's wise to test OpenWrt master first before we start bisecting :)

[GoliathLabs]

Maybe we should try to figure out whether this broke due to a commit since openwrt/openwrt@e4c7703 Because I expect that it worked fine back then Atleast since the day this fix was pushed to master: openwrt/openwrt#12361 (comment) This bug is likely a regression

but maybe it's wise to test OpenWrt master first before we start bisecting :)

Do you have a chance to test the TP-Link RE650 v1 again to see whether it's just the DAP-1620-B1 or a general OpenWrt thing?

[blocktrron]

What's the status here? Has the open issue been adressed?

[GoliathLabs]

Issue persists to this day, even with newer builds

[blocktrron]

Please check the EEPROM for it's validity, the information if said chip has a DBDC frontend is encoded in there. Add the dump of the EEPROM partition to this ticket, so we can have a look at it.

[GoliathLabs]

Hi,
thank you for looking into this. I've dumped the factory partition as per

root@ffmuc-60634c423d24:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00010000 00010000 "factory"
mtd3: 00fb0000 00010000 "firmware"
mtd4: 002ac07a 00010000 "kernel"
mtd5: 00d03f86 00010000 "rootfs"
mtd6: 00750000 00010000 "rootfs_data"

eeprom_dump.zip

[blocktrron]

Thanks. Indeed MT_EE_WIFI_CONF at offset 0x3e is all zeros while bit 4 and 5 shall be set for DBDC operation.

This has to be worked around in the mt76 driver by overriding this field or fixed in another way. Initially i suspected the caldata offset being wrong but it is correctly defined.

[GoliathLabs]

Thanks. Indeed MT_EE_WIFI_CONF at offset 0x3e is all zeros while bit 4 and 5 shall be set for DBDC operation.

This has to be worked around in the mt76 driver by overriding this field or fixed in another way. Initially i suspected the caldata offset being wrong but it is correctly defined.

Thank you for looking into this!

[blocktrron]

QUestion would be how to proceed with this then. Do you plan on providing upstream patches to work around the invalid EEPROM? If not, I'd close this PR, as fixing this upstream would be a hard dependency.

Otherwise we could go down the route and mark the device as broken.

[GoliathLabs]

I don't think I have the expertise to provide upstream patches. We could merge this PR as broken then. If someone wants to pick this up, I'd be happy to help as much as I can.

[blocktrron]

Fine with me, please rebase this and add broken then.

[GoliathLabs]

Fine with me, please rebase this and add broken then.

Done.