Commit Graph

2 Commits

Author SHA1 Message Date
Brian Norris
9ea5487ea5 ipq806x: chromium: Disable kernel's CONFIG_QCOM_SPM
The qcom spm driver is currently broken for IPQ8064 OnHub devices on
kernel 6.1, such that it hangs the system when booting, much to the
consternation of users. This is especially bad as these devices don't
yet have a fully-supported release branch, and are still sometimes
landing on snapshot builds.

OnHub devices have their own kernel config, so it's not that wide of an
impact to disable this.

I haven't fully gotten to the bottom of this, but:

(a) The vendor kernel didn't have any SPM driver at all, and didn't
    utilize cpuidle.
(b) The device tree has never included any (non-disabled) cpuidle
    states, so even when this driver was present on 5.15 (last
    known-working kernel), it didn't actually do anything -- it bailed
    early, before ever doing any SPM initialization.
(c) Refactoring in Linux 5.16 [1] caused the SPM driver to be activated
    unconditionally, including setting us into standby mode
    (PM_SLEEP_MODE_STBY) by default.

Removing the one PM_SLEEP_MODE_STBY line from drivers/soc/qcom/spm.c
seems to fix the problem, but that isn't much different than simply
disabling the driver, so I go with that for now.

I also disable CONFIG_ARM_QCOM_SPM_CPUIDLE, becuase it 'select's
QCOM_SPM.

NB: it's possible there's some other deeper root cause involved in here.
For one, I notice that CPU hotplug (e.g., echo 0 >
/sys/devices/system/cpu/cpu1/online, echo 1 > ...) doesn't work right
either. Perhaps there's some mismatch on upstream Linux qcom-scm
behavior and the old boot firmware used for these systems? It wouldn't
be the first time, as we've had some similar incompatibilities on the
next generation of these devices, Google WiFi [2].

[1] Commit 60f3692b5f0b ("cpuidle: qcom_spm: Detach state machine from
    main SPM handling")
[2] [RFC] qcom_scm: IPQ4019 firmware does not support atomic API?
    https://lore.kernel.org/linux-arm-kernel/20200913201608.GA3162100@bDebian/

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2023-08-27 22:47:02 +02:00
Brian Norris
ef649b0b14
ipq806x: Initial TP-Link and ASUS OnHub support
TP-Link and ASUS OnHub devices are very similar, sharing many of the
same characteristics and much of their Device Tree. They both run a
version of ChromeOS for their factory firmware, and so installation
instructions look very similar to Google Wifi [1].

Things I've tested, and are working:

 * Ethernet
 * WiFi (2.4 and 5 GHz)
 * LEDs
 * USB
 * eMMC
 * Serial console (if you wire it up yourself)
 * 2x CPU
 * Speaker

== Installation instructions summary ==

1. Flash *-factory.bin to a USB drive (e.g., with `dd`)
2. Insert USB drive, to boot OpenWrt from USB
3. Copy the same *-factory.bin over to device, and flash it to eMMC to
   make OpenWrt permanent

== Developer mode, booting from USB (Step 2) ==

To enter Developer Mode and boot OpenWrt from a USB stick:

1. Unplug power
2. Gain access to the "developer switch" through the bottom of the
   device
3. Hold down the "reset switch" (near the USB port / power plug)
4. Plug power back in
5. The LED on the device should turn white, then blink orange, then
   red. Release the reset switch.
6. Insert USB drive with OpenWrt factory.bin
7. Press the hidden developer switch under the device to boot to USB;
   you should see some activity lights (if you have any) on your USB
   drive
8. Depending on your configuration, the router's LED(s) should come on.
   You're now running OpenWrt off a USB stick.

These instructions are derived from:

https://www.exploitee.rs/index.php/Rooting_The_Google_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub
https://www.exploitee.rs/index.php/Asus_OnHub#Enabling_%22Developer_Mode%22_on_the_OnHub

~~Finding the developer switch:~~ for TP-Link, the developer switch is
on the bottom of the device, underneath some of the rubber padding and a
screw. For ASUS, remove the entire base, via 4 screws under the rubber
feet. See the Exploitee instructions for more info and photos.

== Making OpenWrt permanent (on eMMC) (Step 3) ==

Once you're running OpenWrt via USB:

1. Connect Ethernet to the LAN port; router's LAN address should be at
   192.168.1.1
2. Connect another system to the router's LAN, and copy the factory.bin
   image over, via SCP and SSH:

     scp -O openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin root@192.168.1.1:
     ssh root@192.168.1.1 -C "dd if=/dev/zero bs=512 seek=7552991 of=/dev/mmcblk0 count=33 && \
     dd if=/root/openwrt-ipq806x-chromium-tplink_onhub-squashfs-factory.bin of=/dev/mmcblk0"
3. Reboot and remove the USB drive.

== Developer mode beep ==

Note that every time you boot the OnHub in developer mode, the device
will play a loud "beep" after a few seconds. This is described in the
Chromium docs [2], and is intended to make it clear that the device is
not running Google software. It is nontrivial to completely disable this
beep, although it's possible to "acknowledge" developer mode (and skip
the beep) by using a USB keyboard to press CTRL+D every time you boot.

[1] https://openwrt.org/toh/google/wifi
[2] https://chromium.googlesource.com/chromiumos/docs/+/HEAD/developer_mode.md

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
2023-01-21 01:02:25 +01:00