OpenWrt dropped the nand string from filenames in the ipq40xx target [1].

Therefore it's no longer neccesary to work arround it in Gluon.

[1] https://github.com/openwrt/openwrt/commit/d9f7c751c9772772473d226b1088e8dec31f3090

These boards do not support DSA in OpenWrt and thus lack working
ethernet. Disable them for now.

Co-authored-by: Tom Herbers <mail@tomherbers.de>

device fails to build

Signed-off-by: David Bauer <mail@david-bauer.net>

This reverts commit 97efc8ab. (#2580)

Since the commit was openend the device was moved from ath79-generic to ath79-tiny ([4b5bd15](https://github.com/openwrt/openwrt/commit/4b5bd1509195bc8f19999ebe481b59356b5c3512)).

Therefore the commit breaks builds of the ath79-generic target (`unable to enable device 'ubnt_rocket-m'`).

It might be possible to add support for the ath79-tiny target, and with it the Rocket M2/M5 (XM), in the future.

Signed-off-by: Christoph Krapp <achterin@gmail.com>

The only device using the ATH10K_PACKAGES_IPQ40XX variable in
ipq40xx-mikrotik (the MikroTik hAP ac2) has little RAM and is
using ath10k-ct-smallbuffers by default at the moment. This is
just a suggestion to rename the variable in-case the wifi driver
ever has to be replaced by ath10k.

Analogue to 4a00b8ae

Signed-off-by: Felix Baumann <felix.bau@gmx.de>

This partially reverts commit 22c47df2.

Devices in ath79-generic like the TP-Link EAP225-Outdoor v1 are really
unstable with the non -ct Wave2 firmware and regulary crash with 100% memory
consumption when only a handful devices are connected via 5 GHz.

closes freifunk-gluon/gluon#2827

The WRE6066, has in contrast to other ip40xx devices, has only 128MB system RAM.
This results in OOM situations and instability, to circumvent this we need
to use ath10k-smallbuffers.

Signed-off-by: skorpy <skorpy@frankfurt.ccc.de>

Signed-off-by: David Bauer <mail@david-bauer.net>

The device was introduced in #2332 and merged in 102a4b93.

It appears that the autoupdater name wasn't correct and devices therefore don't receive updates.

root@64295-ggw3-20b399bb366f-132:~# lua -e 'print(require("platform_info").get_image_name())'
enterasys-ws-ap3705i

The GL-MT1300 is a high-performance new generation pocket-sized router
that offers a powerful hardware and first-class cybersecurity protocol
with unique and modern design.

Specifications:
- SoC: MT7621A, Dual-Core @880MHz
- RAM: 256 MB DDR3
- Flash: 32 MB
- Ethernet: 3 x 10/100/1000: 2 x LAN + 1 x WAN
- Wireless: 1 x MT7615D Dual-Band 2.4GHz(400Mbps) + 5GHz(867Mbps)
- USB: 1 x USB 3.0 port
- Slot: 1 x MicroSD card slot
- Button: 1 x Reset button
- Switch: 1 x Mode switch
- LED: 1 x Blue LED + 1 x White LED

MAC addresses based on vendor firmware:
WAN : factory 0x4000
LAN : Mac from factory 0x4000 + 1
2.4GHz : factory 0x4
5GHz : Mac form factory 0x4 + 1

Flashing instructions:
1.Connect to one of LAN ports.
2.Set the static IP on the PC to 192.168.1.2.
3.Press the Reset button and power the device (do not release the button).
  After waiting for the blue led to flash 5 times, the white led will
  come on and release the button.
4.Browse the 192.168.1.1 web page and update firmware according to web
  tips.
5.The blue led will flash when the firmware is being upgraded.
6.The blue led stops blinking to indicate that the firmware upgrade is
  complete and U-Boot automatically starts the firmware.

Now that OpenWrt implements a proper fix for the stalled boots on 74kc
boards, the previous workaround can be removed.

Signed-off-by: David Bauer <mail@david-bauer.net>

This is a temporary measure that fixes #2692.

This reverts commit 15ef8858.

add comments about lacking radios
Co-authored-by: Jan-Niklas Burfeind <git@aiyionpri.me>
Co-authored-by: Matthias Schiffer <mschiffer@universe-factory.net>

The activated setup mode is indicated by the WLAN LED.

Co-authored-by: David Bauer <mail@david-bauer.net>

It looks like boot hangs on an AC-Mesh for unknown reasons. The last
message seen on the console is:

    [    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)

But interestingly, it seems like enabling AIO somehow works around this
problem. Changing any off the following options seem to have the same
effect at the moment for Linux 5.10.160+5.10.161

    # CONFIG_KERNEL_AIO is not set
    # CONFIG_KERNEL_CGROUPS is not set
    # CONFIG_KERNEL_FANOTIFY is not set
    # CONFIG_KERNEL_FHANDLE is not set
    # CONFIG_KERNEL_IO_URING is not set
    # CONFIG_KERNEL_IPV6_MROUTE is not set
    # CONFIG_KERNEL_IPV6_SEG6_LWTUNNEL is not set
    # CONFIG_KERNEL_IP_MROUTE is not set
    CONFIG_KERNEL_PROC_STRIPPED=y

Just enable CONFIG_AIO until the actual problem was fixed.

Link: https://github.com/freifunk-gluon/gluon/issues/2784

Direct migration from 19.07 is currently not possible.

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

update lan, wan separation for o2 6431