staging/chunkeey, branch master

ipq40xx: only include ath10k-board-qca4019 for the generic subtarget

2022-05-19T14:39:54Z

Since MikroTik subtarget now uses dynamic BDF loading its crucial that it doesnt include the board-2.bin at all which is provided by the ath10k-board-qca4019 package. So to resolve this include the ath10k-board-qca4019 package only for the generic subtarget via its Makefile instead of via the target Makefile. Signed-off-by: Robert Marko

ipq40xx: dynamically build board-2.bin for Mikrotik

2022-05-19T14:39:11Z

Mikrotik devices ship with the boardfile data right on the board itself. This script takes the data from the sysfs firmware "wlan_data" to generate a custom board-2.bin for the ath10k driver to work with. The qcom,ath10k-calibration-variant in each device's device-tree file are being removed as well. Signed-off-by: Christian Lamparter

ipq40xx: RT-AC58U: Try ARTIFACTS for install.trx

2022-05-19T14:39:11Z

Previous attempts of generating an "IMAGES" based approaches to provide a ready-to-go image that can be flashed through the vendor firmware's WEB-UI or via the bootloader Option 1 in order to perform a serial-console-less installation all had the downsides. Either they rendered the INITRAMFS unusable for the bootloader option 2, or broke the IMAGEBUILDER. This hopefully does neither. The IMAGE_SIZE was changed to account for the added 64 Byte U-Boot header. WARNING: Hmm, this could/did break if the initramfs isn't available... (But let's not forget it again that this is dangerous) Signed-off-by: Christian Lamparter

base-files: leds: do reverse lookup in get_dt_led()

2022-05-19T14:39:11Z

In order to match the "label"-less DT properties we have to get creative. In theory the dt-node should have everything (i.e.: color, function and function-enumerator) to make the device-name in /sys/class/leds. But thanks to color being a binary value and not a "string", we would have to maintain a lookup table that keeps in sync with the dt-binding. It's much easier to use the "uevent" property of every led-class device and do reverse lookup with it by comparing the OF_FULLNAME with the alias pathname. (This works with gpio-leds ... let's see where it breaks) Signed-off-by: Christian Lamparter

ath79: add Cisco Meraki MR18

2022-05-19T14:39:11Z

Specifications: SOC: Atheros/Qualcomm QCA9557-AT4A @ 720MHz RAM: 2x Winbond W9751G6KB-25 (128 MiB) FLASH: Hynix H27U1G8F2BTR-BC TSOP48 ONFI NAND (128 MiB) WIFI1: Atheros AR9550 5.0GHz (SoC) WIFI2: Atheros AR9582-AR1A 2.4GHz WIFI2: Atheros AR9582-AR1A 2.4GHz + 5GHz PHYETH: Atheros AR8035-A, 802.3af PoE capable Atheros (1x Gigabit LAN) LED: 1x Power-LED, 1 x RGB Tricolor-LED INPUT: One Reset Button UART: JP1 on PCB (Labeled UART), 3.3v-Level, 115200n8 (VCC, RX, TX, GND - VCC is closest to the boot set jumper under the console pins.) Flashing instructions: Depending on the installed firmware, there fastly different methods to flash a MR18. These have been documented on: Note: upgrades from AR71XX are possible, but require the force sysupgrade option. The LEDs has changed since AR71XX. The white LED is now used during the boot and when upgrading instead of the green tricolor LED. Signed-off-by: Christian Lamparter

ath79: add Cisco Meraki Z1

2022-05-19T14:39:11Z

Specifications: SOC: Atheros AR9344 @ 560MHz RAM: 2x Winbond W9751G6KB-25 (128 MiB) FLASH: Hynix H27U1G8F2BTR (128 MiB) WIFI1: Atheros AR9340 5.0GHz (SoC) WIFI2: Atheros AR9280 2.4GHz SWITCH: Atheros AR8236 (5x Gigabit (1x WAN, 4x LAN) LED: 1x Power-LED, 1 x RGB Tricolor-LED INPUT: One Reset Button USB: One USB 2.0 Port UART: JP1 on PCB (Labeled UART), 3.3v-Level, 115200n8 (GND, TX, RX, VCC - GND is next to the UART silk screen) Flashing Instructions: Since this device is brought over from an old AR71xx, there's already a wiki-page with detailed instructions: The gist: 1. Get a root-shell on the device (see wiki). (needs UART access) 2. make a backup (to a PC/safe location) of the existing Meraki firmware. 3. copy over the OpenWrt initramfs kernel for the Z1. This gets written into the kernel NAND partition. (Verify that written image is complete!) After the following reboot and successfull boot of the staging OpenWrt initramfs image: 4. copy over the sysupgrade.bin for the router and use sysupgrade to make the installation permanent. Signed-off-by: Christian Lamparter

ath79: ar934x: still advertise subpage on soft ecc

2022-05-19T14:39:11Z

This sort of reverts Koen Vandeputte's commit 6561ca1fa51 ("ath79: ar934x: fix mounting issues if subpage is not supported") since it does not work on the MR18 as the UBI is coming from Meraki in that way and it used to work with AR71XX before. Signed-off-by: Christian Lamparter

ath79: nand: enable software BCH support

2022-05-19T14:39:11Z

This is necessary to support the Meraki MR18 and likely Z1 as well. Signed-off-by: Christian Lamparter

apm821xx: disable Netgear WNDR4700

2022-05-19T14:39:11Z

This patch disables the Netgear WNDR4700 image, because as it turns out that neither gzipped nor xz'd zImages would work. The reason for the crash is that there are sevaral problems with Netgear's "bootcmd": > if loadn_dniimg 0 0x180000 0x4e0000 && chk_dniimg 0x4e0000; then nand read 0x800000 0x180000 0x20000;bootm 0x500000 - 0x800040;else fw_recovery; fi" This loads the dni-image starting offset 0x180000 from the NAND flash (which is the DTB partition) to 0x4e0000 in the RAM. It then checks whenever the provided image is "valid". If it is then it reads the DTB again to 0x800000 in the RAM and starts the extraction and boot process. (If the image wasn't valid then it starts the automated firmware recovery). The issues here are that first: the kernel image gets "squeezed" between 0x500040 and 0x7fffff... And second, the decompressor only has area 0x0 - 0x500000 for decompression. Hence it would be much easier to "fix" the bootcmd by providing new values (which have been successfully tested with the original Netgear WNDR4700 v1.0.0.56 firmware) for the RAM locations and make full use of the fact that loadn_dniimg loads the DTB as well. This needs to be done only once. Just connect a serial adapter to interface with uboot and overwrite (and save) the new bootcmd. WARNING: The serial port needs a TTL/RS-232 3.3v level converter! Steps: 0. Power-off the WNDR4700 1. Connect the serial interface (you need to open the WNDR4700) 2. Power-up the WNDR4700 3. Monitor the boot-sequence and hit "Enter"-key when it says: "Hit any key to stop autoboot" (Be quick, you have a ~2 second window) 4. in the Prompt enter the following commands (copy & paste) setenv bootcmd "if loadn_dniimg 0 0x180000 0xae0000 && chk_dniimg 0xae0000; then bootm 0xb00000 - 0xae0040;else fw_recovery; fi" saveenv run bootcmd Note: This new bootcmd will also unbrick devices that were bricked by the bigger 4.19/5.4 kernels recently before the buildbot was instructed to skip it. Note2: This method was tested with a WNDR4700. A big kernel with most debug features enabled on v5.4.52 measured 3.10 MiB when compressed with lzma. The uncompressed kernel is 9.83 MiB. This is over the 3 MiB, the device reserves for the kernel... But it booted! For bigger kernels, the device needs repartitioning of the the ubi partition due to the kernel+dtb not fitting into the partition. Note3: For initramfs development. I would advice to load the initramfs images to 0x800000 (or higher). i.e.: tftp 800000 wndr4700.bin Signed-off-by: Christian Lamparter

lldpd: always depend on libbsd

2022-05-19T14:39:11Z

lldpd calls setproctitle() and strtonum(); its configure.ac script has fallbacks for when they're not found, but they should come from libbsd instead. Signed-off-by: Guilherme Janczak