Onhub TP-LINK TGR1900 future support?

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.

1 Like

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.

To bad I didn't know they were killing the support, would have bought one, while in US.

But I guess they'll be even cheaper after Dec '22.

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).

1 Like

Indeed, but this would be for the challenge of taking it apart, and trying to get it to work ,)

I'd probably keep on buying Archer C2600s, if I needed more wireless coverage :slight_smile:

FWIW, the bootloader disk format tools are merged now:


Now it's a matter of getting the rest (device tree; maybe a few other driver quirks) in order I suppose.


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.

1 Like

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).


I have one too, would love to install openWRT on this great hardware.

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).

Technical OpenWRT question:
Is qcom-ipq4019-wifi.dts based on src/board/gale/board.c? If so, then could the corresponding src/board/storm/board.c file be used to create dts for OnHub?

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.

Disassembly and developer mode instructions are here: Asus OnHub - Exploitee.rs

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.

1 Like

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.

1 Like

Thank you!

I don't have a 1.8v adapter but just ordered one from Amazon.

Once I gain serial access it's just a matter of building the right firmware I'm assuming?

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.

I've got a pile of hardware, but no time to spend on them.

You'd want to derive the DTS from one of these (Chrome OS kernel 3.14):
[[ EDIT: or possibly
qcom-ipq8064-arkham.dts, since some of you are talking about the ASUS model ]]

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.

1 Like