mirror of
https://github.com/openwrt/openwrt.git
synced 2024-12-27 17:18:59 +00:00
6d2ed484fa
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> |
||
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> |