ipq40xx: only include ath10k-board-qca4019 for the generic subtarget 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 <robimarko@gmail.com>
ipq40xx: dynamically build board-2.bin for Mikrotik 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 <chunkeey@gmail.com>
ipq40xx: RT-AC58U: Try ARTIFACTS for install.trx 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 <chunkeey@gmail.com>
base-files: leds: do reverse lookup in get_dt_led() 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 <chunkeey@gmail.com>
ath79: add Cisco Meraki MR18 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: <https://openwrt.org/toh/meraki/mr18> 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 <chunkeey@gmail.com>
ath79: add Cisco Meraki Z1 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: <https://openwrt.org/toh/meraki/z1> 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 <chunkeey@gmail.com>
ath79: ar934x: still advertise subpage on soft ecc 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 <chunkeey@gmail.com>
apm821xx: disable Netgear WNDR4700 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 <chunkeey@gmail.com>
ipq40xx: add support for Linksys WHW01 v1 This patch adds support for Linksys WHW01 v1 ("Velop") [FCC ID Q87-03331]. Specification ------------- SOC: Qualcomm IPQ4018 WiFi 1: Qualcomm QCA4019 IEEE 802.11b/g/n WiFi 2: Qualcomm QCA4019 IEEE 802.11a/n/ac Bluetooth: Qualcomm CSR8811 (A12U) Ethernet: Qualcomm QCA8072 (2-port) SPI Flash 1: Mactronix MX25L1605D (2MB) SPI Flash 2: Winbond W25M02GV (256MB) DRAM: Nanya NT5CC128M16IP-DI (256MB) LED Controller: NXP PCA963x (I2C) Buttons: Single reset button (GPIO). Notes ----- There does not appear to be a way to trigger TFTP recovery without entering U-Boot. The device must be opened to access the serial console in order to first flash OpenWrt onto a device from factory. The device has automatic recovery backed by a second set of partitions on the larger of the two SPI flash ICs. Both the primary and secondary must be flashed to prevent accidental rollback to "factory" after 3 failed boot attempts. Serial console -------------- A serial console is available on the following pins of the populated J2 connector on the device mainboard (115200 8n1). (<-- Top of PCB / Device) J2 [o o o o o o] | | | | | `-- GND | `---- TX `--------- RX Installation instructions ------------------------- 1. Setup TFTP server with server IP set to 192.168.1.236. 2. Copy compiled `...squashfs-factory.bin` to `nodes-jr.img` in tftp root. 3. Connect to console using pinout detailed in the serial console section. 4. Power on device and press enter when prompted to drop into U-Boot. 5. Flash first partition device via `run flashimg`. 6. Once complete, reset device and allow to power up completely. 7. Once comfortable with device upgrade reboot and drop back into U-Boot. 8. Flash the second partition (recovery) via `run flashimg2`. Revert to "factory" ------------------- 1. Download latest firmware update from vendor support site. 2. Copy extracted `.img` file to `nodes-jr.img` in tftp root. 3. Connect to console using pinout detailed in the serial console section. 4. Power on device and press enter when prompted to drop into U-Boot. 5. Flash first partition device via `run flashimg`. 6. Once complete, reset device and allow to power up completely. 7. Once comfortable with device upgrade reboot and drop back into U-Boot. 8. Flash the second partition (recovery) via `run flashimg2`. Signed-off-by: Peter Adkins <peter@sunkenlab.com> (calibration from nvmem, updated to 5.10+5.15) Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
ipq40xx: mikrotik: dont include ath10k-board-qca4019 by default 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 dont include the ath10k-board-qca4019 package on the MikroTik subtarget. Signed-off-by: Robert Marko <robimarko@gmail.com>
ipq-wifi: remove packaged BDF-s for MikroTik devices Since we now provide the BDF-s for MikroTik IPQ40xx devices on the fly, there is noneed to include package and ship them like we do now. This also resolves the performance issues that happen as MikroTik changes the boards and ships them under the same revision but they actually ship with and require a different BDF. Signed-off-by: Robert Marko <robimarko@gmail.com>
ipq40xx: mikrotik: provide BDF-s on demand Since we now can pass the API 1 BDF-s aka board.bin to the ath10k driver per radio lets use that to provide the BDF-s for MikroTik devices. This also resolves the performance issues that happen as MikroTik changes the boards and ships them under the same revision but they actually ship with and require a different BDF. Signed-off-by: Robert Marko <robimarko@gmail.com>
mac80211: ath10k: backport bus and device specific API 1 BDF selection Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the BDF-s to be extracted from the device storage instead of shipping packaged API 2 BDF-s. This is required as MikroTik has started shipping boards that require BDF-s to be updated, as otherwise their WLAN performance really suffers. This is however impossible as the devices that require this are release under the same revision and its not possible to differentiate them from devices using the older BDF-s. In OpenWrt we are extracting the calibration data during runtime and we are able to extract the BDF-s in the same manner, however we cannot package the BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on the fly. This is an issue as the ath10k driver explicitly looks only for the board.bin file and not for something like board-bus-device.bin like it does for pre-cal data. Due to this we have no way of providing correct BDF-s on the fly, so lets extend the ath10k driver to first look for BDF-s in the board-bus-device.bin format, for example: board-ahb-a800000.wifi.bin If that fails, look for the default board file name as defined previously. So, backport the upstream ath10k patch. Signed-off-by: Robert Marko <robimarko@gmail.com>
ath10k-ct: update to 2022-05-13 Update ath10k-ct to the latest version which includes the backported ath10k commit for requesting API 1 BDF-s with a unique name like caldata. Signed-off-by: Robert Marko <robimarko@gmail.com>
tools/elfutils: only build required components Building all of the components results in strip being installed in staging_dir/host/bin. This strip binary will take precedence over binutils strip that is installed in the toolchain directory. This will not work on host systems that do not have libdw installed, as we do not set HOST_LDFLAGS to override rpath to staging_dir/host/lib. However, rather than overriding rpath, we should just avoid using elfutils strip entirely. Override the SUBDIRS variable in the Makefile to only build and install the libraries we require for dwarves and frr. Fixes the following build failure in toolchain/gdb: strip: error while loading shared libraries: libdw.so.1: cannot open shared object file: No such file or directory Fixes: ad79b9271949 ("elfutils: move host build to tools") Reported-by: Dominick Grift <dominick.grift@defensec.nl> Reported-by: Lucian Cristian <lucian.cristian@gmail.com> Signed-off-by: Stijn Tintel <stijn@linux-ipv6.be>