Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
Hi, > Le 21 janv. 2023 à 02:23, Christian Marangi a écrit : > > Yes CI test will catch that and will just fail. Now I think I have to > ask someone to reboot buildbot again for the new subtarget... Or it will be > picked automatically? It needs a restart. Cheers, Thibaut ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
On Sat, Jan 21, 2023 at 02:23:08AM +0100, Christian Marangi wrote: > On Fri, Jan 20, 2023 at 05:17:43PM -0800, Brian Norris wrote: > > On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi > > wrote: > > > added the changed to my staging repo and testing them here > > > https://github.com/openwrt/openwrt/pull/11843. > > > > > > Merged the fstools requirement. If CI tests doesn't have problems, i > > > will merge this in master. > > > > I see you've merged them to master. Thanks for looking and for > > merging! I'll keep an eye out myself, but feel free to let me know if > > anything goes wrong. > > > > One preemptive heads up: I know my ASoC/sound patch already got merged > > to Linux v5.15.89, so that patch should drop out whenever openwrt > > pulls it in. Presumably whoever does that upgrade will notice the > > conflict/redundancy eventually. > > > > Yes CI test will catch that and will just fail. Good enough. > Now I think I have to > ask someone to reboot buildbot again for the new subtarget... Or it will be > picked automatically? I'm certainly not the expert, but last I dealt with this I hear it needed a restart: https://github.com/openwrt/openwrt/pull/9276#issuecomment-1085448201 Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
On Fri, Jan 20, 2023 at 05:17:43PM -0800, Brian Norris wrote: > On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi > wrote: > > added the changed to my staging repo and testing them here > > https://github.com/openwrt/openwrt/pull/11843. > > > > Merged the fstools requirement. If CI tests doesn't have problems, i > > will merge this in master. > > I see you've merged them to master. Thanks for looking and for > merging! I'll keep an eye out myself, but feel free to let me know if > anything goes wrong. > > One preemptive heads up: I know my ASoC/sound patch already got merged > to Linux v5.15.89, so that patch should drop out whenever openwrt > pulls it in. Presumably whoever does that upgrade will notice the > conflict/redundancy eventually. > Yes CI test will catch that and will just fail. Now I think I have to ask someone to reboot buildbot again for the new subtarget... Or it will be picked automatically? -- Ansuel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
On Fri, Jan 20, 2023 at 6:11 AM Christian Marangi wrote: > added the changed to my staging repo and testing them here > https://github.com/openwrt/openwrt/pull/11843. > > Merged the fstools requirement. If CI tests doesn't have problems, i > will merge this in master. I see you've merged them to master. Thanks for looking and for merging! I'll keep an eye out myself, but feel free to let me know if anything goes wrong. One preemptive heads up: I know my ASoC/sound patch already got merged to Linux v5.15.89, so that patch should drop out whenever openwrt pulls it in. Presumably whoever does that upgrade will notice the conflict/redundancy eventually. Thanks, Brian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 7/7] ipq806x: Initial TP-Link and ASUS OnHub support
On Thu, Jan 12, 2023 at 09:32:22PM -0800, Brian Norris wrote: > 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 Hi, added the changed to my staging repo and testing them here https://github.com/openwrt/openwrt/pull/11843. Merged the fstools requirement. If CI tests doesn't have problems, i will merge this in master. > --- > * There might be better ways to handle the multi-color LED support, >but for now, each color is a separate LED > * A variety of people have been interested in this work, and a few have >tested versions of it already: > https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899 > * This is dependent on an fstools change, to ensure it can find our >'rootfs_data' properly: > [PATCH fstools v2] partname: Ignore root=PARTUUID... > > https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/ > > Changes in v4: > * move LED configuration to device tree > > Changes in v3: > * use 'ucode' for base64, to reduce dependency complexity and avoid >bringing in coreutils > * simplify installation instructions > * add back in second CPU / drop maxcpus=1 (I had apparently already >fixed this, but kept the maxcpus=1) > > Changes in v2: > * Drop custom ath10k base64 property > * Provide base64 caldata parsing via >/etc/hotplug.d/firmware/11-ath10k-caldata instead > * add coreutils-base64 dependency > * add 3rd (rootfs_data) partition, to better handle sysupgrade and >utilize the whole disk > > target/linux/ipq806x/Makefile | 4 +- > .../ipq806x/base-files/etc/board.d/02_network | 6 + > .../etc/hotplug.d/firmware/11-ath10k-caldata | 35 ++ > .../base-files/lib/upgrade/platform.sh| 19 + > .../base-files/usr/bin/base64decode.uc
[PATCH v4 7/7] 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 --- * There might be better ways to handle the multi-color LED support, but for now, each color is a separate LED * A variety of people have been interested in this work, and a few have tested versions of it already: https://forum.openwrt.org/t/onhub-tp-link-tgr1900-future-support/17899 * This is dependent on an fstools change, to ensure it can find our 'rootfs_data' properly: [PATCH fstools v2] partname: Ignore root=PARTUUID... https://patchwork.ozlabs.org/project/openwrt/patch/20230107020424.1703752-1-computersforpe...@gmail.com/ Changes in v4: * move LED configuration to device tree Changes in v3: * use 'ucode' for base64, to reduce dependency complexity and avoid bringing in coreutils * simplify installation instructions * add back in second CPU / drop maxcpus=1 (I had apparently already fixed this, but kept the maxcpus=1) Changes in v2: * Drop custom ath10k base64 property * Provide base64 caldata parsing via /etc/hotplug.d/firmware/11-ath10k-caldata instead * add coreutils-base64 dependency * add 3rd (rootfs_data) partition, to better handle sysupgrade and utilize the whole disk target/linux/ipq806x/Makefile | 4 +- .../ipq806x/base-files/etc/board.d/02_network | 6 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 35 ++ .../base-files/lib/upgrade/platform.sh| 19 + .../base-files/usr/bin/base64decode.uc| 23 + target/linux/ipq806x/chromium/config-default | 13 + target/linux/ipq806x/chromium/target.mk | 2 + .../arm/boot/dts/qcom-ipq8064-asus-onhub.dts | 96 .../arch/arm/boot/dts/qcom-ipq8064-onhub.dtsi | 463 ++ .../boot/dts/qcom-ipq8064-tplink-onhub.dts| 213 target/linux/ipq806x/generic/target.mk| 1 + target/linux/ipq806x/image/chromium.mk| 58 +++ 12 files changed, 931 insertions(+), 2 deletions(-) create mode 100755
