openwrt/target/linux/ipq40xx/chromium/target.mk

BOARDNAME:=Google Chromium
FEATURES += emmc boot-part rootfs-part
ipq40xx: Add subtarget for Google WiFi (Gale) 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> 2020-05-25 21:50:20 +00:00			`BOARDNAME:=Google Chromium`
Revert "ipq40xx: stop chromium sub-target builds on the buildbots" This reverts commit 35d2bbc29ba7f802706bf65585aeb8808fcac622 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> 2022-04-01 05:38:43 +00:00			`FEATURES += emmc boot-part rootfs-part`