Avoid shipping ath10k board file in Mikrotik initram images
Most will only ever need to use these initram images once—to initially
load OpenWrt, but fix these images for more consistent Wi-Fi performance
between the initram and installed squashfs images.
OpenWrt BUILDBOT config ignores -cut packages in the initram images build.
This results in BUILDBOT initram images including the linux-firmware
qca4019 board-2.bin, and (initram image booted) Mikrotik devices loading
a generic BDF, rather than the intended BDF data loaded
from NOR as an api 1 board_file.
buildbot snapshot booted as initram image:
cat /etc/openwrt_version
r19679-810eac8c7f
dmesg | grep ath10k | grep -E board\|BDF
[ 9.794556] ath10k_ahb a000000.wifi: Loading BDF type 0
[ 9.807192] ath10k_ahb a000000.wifi: board_file api 2 bmi_id 0:16
crc32 11892f9b
[ 12.457105] ath10k_ahb a800000.wifi: Loading BDF type 0
[ 12.464945] ath10k_ahb a800000.wifi: board_file api 2 bmi_id 0:17
crc32 11892f9b
CC: Robert Marko <robimarko@gmail.com>
Fixes: 5eee67a72f ("ipq40xx: mikrotik: dont include ath10k-board-qca4019 by default")
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
Reviewed-by: Robert Marko <robimarko@gmail.com>
This reverts commit 35d2bbc29b as we
believe we found that it is indeed an openssl issue, where openssl is
trying to use getrandom(2), but fails because this particular builder
has an ancient kernel without that syscall. We didn't get to the bottom
of why openssl doesn't fall back to something like /dev/random.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
the buildbots are having troubles with the image.
They seem to get "Killed" at the last step of the KERNEL rule:
|/cros-vbutil -k zImage.itb.vboot -c "root=PARTUUID=%U/PARTNROFF=1" -o zImage.itb.vboot.new
|make[4]: *** [Makefile:18: zImage.itb.vboot] Killed
Since the Google Wifi (Gale) is currently the only target in
this sub-target. So this means that subtarget has to be disabled
from the time being to not be picked up by the builders.
For people wanting to checkout out OpenWrt on the Google Wifi:
please compile it locally.
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Google WiFi (codename: Gale) is an IPQ4019-based AP, with 2 Ethernet
ports, 2x2 2.4+5GHz WiFi, 512 MB RAM, 4 GB eMMC, and a USB type C port.
In its stock configuration, it runs a Chromium OS-based system, but you
wouldn't know it, since you can only manage it via a "cloud" +
mobile-app system.
The "v2" label is coded into the bootloader, which prefers the
"google,gale-v2" compatible string. I believe "v1" must have been
pre-release hardware.
Note: this is *not* the Google Nest WiFi, released in 2019.
I include "factory.bin" support, where we generate a GPT-based disk
image with 2 partitions -- a kernel partition (using the custom "Chrome
OS kernel" GUID type) and a root filesystem partition. See below for
flashing instructions.
Sysupgrade is supported via recent emmc_do_upgrade() helper.
This is a subtarget because it enables different features
(FEATURES=boot-part rootfs-part) whose configurations don't make sense
in the "generic" target, and because it builds in a few USB drivers,
which are necessary for installation (installation is performed by
booting from USB storage, and so these drivers cannot be built as
modules, since we need to load modules from USB storage).
Flashing instructions
=====================
Documented here:
https://openwrt.org/inbox/toh/google/google_wifi
Note this requires booting from USB storage.
Features
========
I've tested:
* Ethernet, both WAN and LAN ports
* eMMC
* USB-C (hub, power-delivery, peripherals)
* LED0 (R/G/B)
* WiFi (limited testing)
* SPI flash
* Serial console: once in developer mode, console can be accessed via
the USB-C port with SuzyQable, or other similar "Closed Case
Debugging" tools:
https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/ccd.md#suzyq-suzyqable
* Sysupgrade
Not tested:
* TPM
Known not working:
* Reboot: this requires some additional TrustZone / SCM
configuration to disable Qualcomm's SDI. I have a proposal upstream,
and based on IRC chats, this might be acceptable with additional DT
logic:
[RFC PATCH] firmware: qcom_scm: disable SDI at boot
https://lore.kernel.org/linux-arm-msm/20200721080054.2803881-1-computersforpeace@gmail.com/
* SMP: enabling secondary CPUs doesn't currently work using the stock
bootloader, as the qcom_scm driver assumes newer features than this
TrustZone firmware has. I posted notes here:
[RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
https://lore.kernel.org/linux-arm-msm/20200913201608.GA3162100@bDebian/
* There's a single external button, and a few useful internal GPIO
switches. I haven't hooked them up.
The first two are fixed with subsequent commits.
Additional notes
================
Much of the DTS is pulled from the Chrome OS kernel 3.18 branch, which
the manufacturer image uses.
Note: the manufacturer bootloader knows how to patch in calibration data
via the wifi{0,1} aliases in the DTB, so while these properties aren't
present in the DTS, they are available at runtime:
# ls -l
/sys/firmware/devicetree/base/soc/wifi@a*/qcom,ath10k-pre-calibration-data
-r--r--r-- 1 root root 12064 Jul 15 19:11 /sys/firmware/devicetree/base/soc/wifi@a000000/qcom,ath10k-pre-calibration-data
-r--r--r-- 1 root root 12064 Jul 15 19:11 /sys/firmware/devicetree/base/soc/wifi@a800000/qcom,ath10k-pre-calibration-data
Ethernet MAC addresses are similarly patched in via the ethernet{0,1} aliases.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
(updated 901 - x1pro moved in the process)
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
