With Google discontinuing support for OnHub Wi-Fi routers after Dec 19 2022, is there any further on progress running OpenWRT?
Because OnHub Wi-Fi routers are only managed using Google Home app, they will effectively be bricked in Dec 2022 because there will be no way to change settings after Google discontinues support in Google Home smartphone app.
Since OnHub uses Qualcomm IPQ8064 SoC and QCA9880 + QCA9882 WLAN chips that are same as chips used in OpenWRT supported routers like Linksys EA8500 or TP-Link Archer C2600, seems like it's feasible to get OpenWRT running on OnHub routers and save them from landfills and reduce e-waste.
I'm not familiar with bootloader differences between coreboot vs u-boot, but hope the experts who do have this knowledge don't give up and can continue to work on this.
The big question would be how difficult google made it. The SOC is supported and working well, but google tends to deploy quite a 'different' software ecosystem to their branded devices (good in the sense of better system specs, bad in the sense that quite fundamental things behave differently and need new solutions) - and there might be an unknown danger, the SOC supports secure boot, if google enabled that (like e.g. the Norton Core) it would be game over.
I've had these onhub devices on my to-buy list for quite a while, but they're almost non-existent on the European market (and even worse if you're looking for cheap second hand devices), which makes it a bit difficult to get.
Well, if you're looking to buy a device in the US, the rac2v1k would be the better choice anyways (starting at 20 USD used, the more modern ipq8065+qca9984 chipset - and already supported).
What else needs to be done right now to add support for this device? What needs to be done after gaining serial access?
I found 1.27mm pitch 2x5 (10-pin) IDC ribbon cable that looks like it would fit on circuit board debug connector to get a serial connection. Trying to see how I could help if I had the special cable & a 1.8v USB TTL adapter before I spend the money to buy this equipment.
The same as before, as for any other device (you might just be able to rely on some firmware image tools now being present, rather than having to find/ write them yourself), basic device porting. This involves documenting the hardware and how the OEM firmware works (booting --> DTS, network setup, GPIO assignment, on-flash firmware structure, flashing procedures - and the big question, is secure boot enabled, how to disable it), then that documentation has to be transferred into a usable firmware image (development).
Neither of these are easy or simple, but they can be done (either by an experienced developer or a newcomer with a steep-steep learning curve).
With google intentionally bricking them soon, they might hit the secondary markets at attractive prices - but these devices are rather rare in Europe and I don't know that many developers/ advanced users interested in ipq806x in the US (by the time google bricks them for good, interest might have faded even further in favour of ipq807x and friends).
Seems like there's no major technical roadblocks that can't be overcome with some development work.
Google WiFi (gale) (released 2016) is based on ipq4019 platform and is supported in OpenWRT (toh).
Google OnHub (storm) (released 2015) is based on ipq8064 platform. Routers using this platform are already supported in OpenWRT, but not Google OnHub in particular.
Both use the same bootloader (coreboot + depthcharge).
I don't have any OpenWRT development experience, got this info from reviewing the OpenWRT commit that added support for Google Wifi device.
I have 3 OnHub devices that are perfectly working fine in my home wireless network, and my goal is to convert them to running OpenWRT and reduce e-waste. I just bought a 4th TP-Link OnHub for $5 on craigslist. I plan to disassemble it and attempt to get serial access to dump the bootlog (waiting on 1.27mm pitch connector & cable to be delivered).
Maybe this will also help others in my same situation.
Be sure to measure the serial console voltage, it might be 1.8 volts (like the TP-Link Archer c2600, most other vendors added the level shifter to bring the voltages up to the more common 3.3 volts, the archer c2600 did not).
I literally just joined so I apologize if I'm not posting in the right place, but I too have an OnHub (Asus Version)
Due to the incoming brickening of my hardware I'm de-googlify-ing my life, but I love this hardware and since I paid full price for it I intend to either get OpenWRT on it or blow it up trying since I already have an OpenWRT machine to hold me over.
Is this hardware similar enough to work in tandem with the TP-Link version in effort to get OpenWRT up and running or should I start this project separately. I'm not very well versed in coding but have been flashing tasmota devices and building a PFsense machine to de-googlify my network.
Is anyone able to point me in the right direction? OnHub is on my desk waiting to be taken apart if we need more info on the internals.
Asus and TP-Link OnHub shares the same base board (storm) & chipset (IPQ8064). The case is different, and the location of the developer mode button and serial headers are different.
I haven't been able to spend any more time on this project in the last 2 weeks. I confirmed the 1.27mm pitch 2x5 (10-pin) IDC ribbon cable fits the serial header on the TP-Link OnHub, but I haven't yet modified the cable to connect to my 1.8v FTDI serial adapter to gain serial console access.
I would treat them as separate devices in the sense of image recipes and top level dts, as this also makes it easier for the user to comfirm the right image for their device. Behind the scenes, it does make sense to share as much as possible in a common dtsi include (leaving pretty much only the device name in the top level device dts), but only the development efforts themselves will show you how far you may go - what's the same, what's different.
Given that the Google Wifi (gale) , which I think is the spiritual successor to these, supports Chrome's Closed Case Debugging (CCD), perhaps these earlier OnHubs also support it?
Creating one of the SuzyQ / SuzyQable mentioned in their docs might be a good alternative to gain access to a serial console, rather than finding the right size tiny serial headers? It seems that unfortunately there aren't any prebuilt SuzyQs for sale anymore due to chip shortages.
Although, looking at it more, it seems that CCD might require USB C, and these older OnHubs have USB A.
Unfortunately, I couldn't boot very far after making a trivial port of those, and I didn't get time to pursue further.
These definitely don't support Closed Case Debugging, so that SuzyQ won't help you. I don't know if they have any other exposed UART pins, but I believe the predecessor to CCD was the "Yoshi Flex" connector. But I believe that's only for early/pre-production devices and probably isn't available on most available hardware.
I just got the case of my OnHub open, and confirmed what I suspected. The set of 10 pins (5x2) spaced really close together seems to match the shape of an SWD connector, so it's not a standard serial output. I was able to connect to it with these two products from Adafruit:
Unfortunately, I wasn't able to find a 1.8v SWD usb device that was in stock (really wanted the J-Link EDU). I had tried to just use plain TTL, with this DSD Tech USB to TTL converter from Amazon, that can adjusted to several different voltages, including 1.8v. It wasn't until trying to figure out which wires should go where that I realized that the 3 pin TTL serial protocol (TX, RX, GND) doesn't work with the SWD protocol, since SWD wants to send and transmit over the same wire.
It seems like it might be possible to use OpenOCD, combined with some different wiring, to allow my usb FTDI adapter to act like an SWD device. Or perhaps an old Raspberry Pi 2 I have around the house. But I also wonder how helpful seeing these logs will really be.
I was able to get the startup logs from the OnHub when it loads ChromeOS, by hitting the http://192.168.84.1/api/v1/diagnostic-report api mentioned here.
Once it boots into OpenWRT though, that API won't be available, so I'll be flying pretty blind.
Since I wasn't able to get the debug serial output working, I think the next step is to try and make a branch with the DTS files and get an image that will hopefully boot up enough that I can ssh in and examine the log messages, like @bnorris mentioned.
