Onhub TP-LINK TGR1900 future support?

rmelick · June 14, 2022, 11:37pm

Today I worked on getting an OpenWRT image built that I could flash to a USB drive.

First, I captured a "diagnostic report", using the api/v1/diagnostic-report api mentioned in olssonm/google-wifi-api. That gives me access to the following files (not sure which are helpful)

./proc
./proc/net
./proc/net/arp
./proc/slabinfo
./etc
./etc/lsb-release
./var
./var/log
./var/log/boot.log
./var/log/messages
./var/log/messages.log
./var/log/update_engine
./var/log/update_engine/update_engine.19700101-000008
./var/log/net.log
./var/log/webservd
./var/log/webservd/2017-04-28.log
./sys
./sys/firmware
./sys/firmware/log
./tmp
./tmp/debug-log

My work so far is in my fork (https://github.com/rmelick/openwrt/pull/1/files).

This is my first time working with firmware, device trees, etc., so I could use any help from someone with more OpenWRT experience to help guide the configuration. Most of it was copy pasted from either the commit from @bnorris to add support for Google Wifi, and the device tree is from the chromiumOS whirlwind-sp5 dts file.

I flashed the built image to a USB, but had the same issue as @bnorris - the router would go dark after booting from the USB, and since I don't have serial access I couldn't see anything.

I have a few questions, if anyone can help I think I could make more forward progress:

Is it recommended to start with a very simple device tree, or to start with the one I copy pasted? What are the critical elements to get boot from USB and SSH access working?
Is there a way in the device tree to enable regular TTL serial using the pins that would normally be used for SWD? That would allow me to use my existing adapter.
Is there anything I need to do while configuring the openWRT build so that it enables ssh access over the ethernet port after boot?
Is there a way to configure the OpenWRT to write logs to the usb when it tries booting (and then a way to read those logs back off?)
What further information can I collect or share that would be helpful to OpenWRT experts?
What errors can I look for during the OpenWRT build that will help me catch any issues with my device tree.

For example, I saw these warnings when building with make V=s

arch/arm/boot/dts/qcom-ipq8064-onhub.dts:324.6-16: Warning (reg_format): /soc/gsbi@16500000/spi@16580000/spidev@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:447.11-460.6: Warning (pci_bridge): /soc/pci@1b500000/pcie@0: missing ranges for PCI bridge (or not a bridge)
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:453.16-459.7: Warning (pci_bridge): /soc/pci@1b500000/pcie@0/ath10k@0,0: node name is not "pci" or "pcie"
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:453.16-459.7: Warning (pci_bridge): /soc/pci@1b500000/pcie@0/ath10k@0,0: missing ranges for PCI bridge (or not a bridge)
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:453.16-459.7: Warning (pci_bridge): /soc/pci@1b500000/pcie@0/ath10k@0,0: incorrect #address-cells for PCI bridge
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:453.16-459.7: Warning (pci_bridge): /soc/pci@1b500000/pcie@0/ath10k@0,0: incorrect #size-cells for PCI bridge
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:470.11-483.6: Warning (pci_bridge): /soc/pci@1b700000/pcie@0: missing ranges for PCI bridge (or not a bridge)
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:476.16-482.7: Warning (pci_bridge): /soc/pci@1b700000/pcie@0/ath10k@0,0: node name is not "pci" or "pcie"
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:476.16-482.7: Warning (pci_bridge): /soc/pci@1b700000/pcie@0/ath10k@0,0: missing ranges for PCI bridge (or not a bridge)
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:476.16-482.7: Warning (pci_bridge): /soc/pci@1b700000/pcie@0/ath10k@0,0: incorrect #address-cells for PCI bridge
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:476.16-482.7: Warning (pci_bridge): /soc/pci@1b700000/pcie@0/ath10k@0,0: incorrect #size-cells for PCI bridge
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:493.11-504.6: Warning (pci_bridge): /soc/pci@1b900000/pcie@0: missing ranges for PCI bridge (or not a bridge)
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:499.16-503.7: Warning (pci_bridge): /soc/pci@1b900000/pcie@0/ath10k@0,0: node name is not "pci" or "pcie"
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:499.16-503.7: Warning (pci_bridge): /soc/pci@1b900000/pcie@0/ath10k@0,0: missing ranges for PCI bridge (or not a bridge)
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:499.16-503.7: Warning (pci_bridge): /soc/pci@1b900000/pcie@0/ath10k@0,0: incorrect #address-cells for PCI bridge
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:499.16-503.7: Warning (pci_bridge): /soc/pci@1b900000/pcie@0/ath10k@0,0: incorrect #size-cells for PCI bridge
arch/arm/boot/dts/qcom-ipq8064-onhub.dtb: Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
arch/arm/boot/dts/qcom-ipq8064-onhub.dtb: Warning (pci_device_bus_num): Failed prerequisite 'pci_bridge'
arch/arm/boot/dts/qcom-ipq8064-onhub.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:313.23-327.6: Warning (spi_bus_bridge): /soc/gsbi@16500000/spi@16580000: incorrect #address-cells for SPI bus
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:313.23-327.6: Warning (spi_bus_bridge): /soc/gsbi@16500000/spi@16580000: incorrect #size-cells for SPI bus
arch/arm/boot/dts/qcom-ipq8064-onhub.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
arch/arm/boot/dts/qcom-ipq8064-onhub.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge'
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:322.14-326.7: Warning (avoid_default_addr_size): /soc/gsbi@16500000/spi@16580000/spidev@0: Relying on default #address-cells value
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:322.14-326.7: Warning (avoid_default_addr_size): /soc/gsbi@16500000/spi@16580000/spidev@0: Relying on default #size-cells value
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:300.5-301.22: Warning (dmas_property): /soc/gsbi@1a200000/spi@1a280000:dmas: cell 2 is not a phandle reference
arch/arm/boot/dts/qcom-ipq8064.dtsi:899.17-910.6: Warning (dmas_property): /soc/gsbi@1a200000/spi@1a280000: Missing property '#dma-cells' in node /soc/clock-controller@2098000 or bad phandle (referred from dmas[2])
  also defined at arch/arm/boot/dts/qcom-ipq8064-v1.0.dtsi:30.23-46.6
  also defined at arch/arm/boot/dts/qcom-ipq8064-onhub.dts:294.23-308.6
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:319.5-320.24: Warning (dmas_property): /soc/gsbi@16500000/spi@16580000:dmas: cell 2 is not a phandle reference
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:313.23-327.6: Warning (dmas_property): /soc/gsbi@16500000/spi@16580000: Missing property '#dma-cells' in node /soc/rpm@108000/regulators/s2b or bad phandle (referred from dmas[2])
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:457.6-41: Warning (gpios_property): /soc/pci@1b500000/pcie@0/ath10k@0,0:qcom,ath10k-sa-gpio: cell 0 is not a phandle reference
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:453.16-459.7: Warning (gpios_property): /soc/pci@1b500000/pcie@0/ath10k@0,0: Missing property '#gpio-cells' in node /soc/qfprom@700000/speedbin@0c0 or bad phandle (referred from qcom,ath10k-sa-gpio[0])
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:480.6-41: Warning (gpios_property): /soc/pci@1b700000/pcie@0/ath10k@0,0:qcom,ath10k-sa-gpio: cell 0 is not a phandle reference
arch/arm/boot/dts/qcom-ipq8064-onhub.dts:476.16-482.7: Warning (gpios_property): /soc/pci@1b700000/pcie@0/ath10k@0,0: Missing property '#gpio-cells' in node /soc/qfprom@700000/speedbin@0c0 or bad phandle (referred from qcom,ath10k-sa-gpio[0])

rmelick · June 16, 2022, 6:17pm

Trouble booting to exploit flash
@gsf could you try to boot your TP-Link following the exploitee instructions. I'm having trouble getting it to successfully boot into the flash drive (the step called "Insert USB to boot into intermediary shell enabled kernel"). It makes a single beep after I press the hidden dev mode switch, and then the usb blinks for a bit, but it doesn't seem to fully boot, and isn't reachable on the ip addresses mentioned.

If I check the onhub logs after I restart it (by calling curl http://192.168.84.1/api/v1/diagnostic-report), and then look for the section about "starting deptcharge", I see that it tries to boot from the exploit USB, but seems to think it's invalid and can't find a kernel:

VbBootDeveloper() - user pressed Ctrl+U; try USB
VbExDisplayInit:30 invoked
VbExDisplayBacklight:36 invoked
VbDisplayScreenFromGBB(): invalid/too new bitmap header
VbTryLoadKernel() start, get_info_flags=0x1
VbTryLoadKernel() found 1 disks
VbTryLoadKernel() trying disk 0
GptNextKernelEntry no more kernels
VbTryLoadKernel() LoadKernel() = 65551
VbSetRecoveryRequest(91)
VbBootDeveloper() - no kernel found on USB

I'd love to know if you hit the same problem, or if you're able to boot successfully to the exploit flash drive.

Still stuck on serial access
I spent some more time with the OnHub today, but kept running up against dead ends. After chatting with a hardware friend of mine (and remembering this openwrt email thread), I realized that the JP2 part of the motherboard (a blank looking spot on the right side, near the ethernet ports) is probably a better bet to find a serial console than the SWD header at JP6.

I believe this JP2 is designed to have a socket soldered to it, and then connected to a google proprietary Servo v2 by using their (also proprietary) "Yoshi" flex cable.

I downloaded the schematic of the Yoshi cable, and looked at the pin out.

By testing which pins had continuity to each other (and chatting with the hardware friend), I think I know the orientation on the board. If you look at the picture from iFixit, I think it matches the orientation from the schematic if you rotate the schematic 90 degrees clockwise. The top right pin is a Ground, and the bottom right is DUT_SPI2_CLK_BUF.

J2pins

There were four pins of special interest on the pinout

UART2_SERVO_DUT_TX 
UART2_DUT_SERVO_TX
UART1_SERVO_DUT_TX
UART1_DUT_SERVO_TX

I'm guessing that DUT_SERVO_TX means it's a line for transmit that starts at the DeviceUnderTest (DUT) and goes to the SERVO.

I didn't have the right socket (or confidence in soldering something so small) to hook up all the pins, but I did try just holding some wires manually to them, while having a serial monitor open. I used my USB -> Serial adapter (with FTDI FT232RL chip), connected the GND pin on the adapter to that top right GND pin on the OnHub, and then tried connecting the RXD pin of the adapter to each of the four UART TX pins on the OnHub. I used a baud rate of 115200, because in the /var/log/messages extracted from a call to /api/v1/diagnostic-report after a successful boot with Google firmware, I had seen

1970-01-01T00:00:06.442371+00:00 INFO kernel: [    0.636828] msm_serial: detected port #0
1970-01-01T00:00:06.442377+00:00 INFO kernel: [    0.636996] uartclk = 1843200
1970-01-01T00:00:06.442383+00:00 INFO kernel: [    0.637044] 16340000.serial: ttyMSM0 at MMIO 0x16340000 (irq = 184, base_baud = 115200) is a MSM
1970-01-01T00:00:06.442390+00:00 INFO kernel: [    0.638194] msm_serial: driver initialized

Unfortunately, all I saw come through from every pin was either garbage, or no data. I think the garbage was sometimes from accidentally touching one of the VREF pins right next to the TX pin. I tried a few different baud rates as well on one of the pins, and everything still looked like garbage. I was using the Arduino IDE serial monitor.

I had tried to read these pins both while the onhub was running google firmware, and while it was trying to boot to the USB I had flashed with OpenWRT from my fork.

Does anyone have any advice where to go next?

Should I go back to my fork and try to simplify my device tree, to give it a better chance of booting?
Are there other pins on that J2 header I should try?
Is there something that SWD could help me do to look at the logs?
Should I look into trying to hack the OnHubs auto update feature (I did see it trying to make a Omaha request in one of the boot logs).

Ukraine · June 18, 2022, 11:58am

@rmelick Hi, Just Don't Stop, I believe in you.
Few people are trying to do something, although there have been requests for a long time.

Belvar · August 8, 2022, 1:43pm

Hello everyone, after updating the firmware, the google onhub router (TP link TGR 1900) refused to work. Resetting to factory settings did not help, trying to restore via onhub recovery tool too.(dev mode dont help) The router is not visible in wifi and lan. When turn it on, it lights up blue and then blinks red. I assume that the flash on the Micron N25Q064A memory chip is broken. Please help , if possible, send me this firmware or dump from this chip from a working device.

CTJohnson · August 9, 2022, 7:31am

I have one of the TP link routers; if you can point me to instructions I can take a crack at getting you the info from my stock board.

Ukraine · August 20, 2022, 7:47pm

Hi guys, as far as I understand the work stands still?
Perhaps there is news? I have two of these routers, I don't want to throw them away.

An-GG · August 22, 2022, 5:56pm

Your experience with the exploitee.rs root procedure exactly matches my attempts. I first tried resetting the router firmware to the standard 9334.41.3 (using Onhub Recovery Tool), and attempting a root before setting up (this is required now even for rooting GALE devices), but I also tried resetting to 7077.122.4 which would've been the firmware available in late 2015.

Unsuccessful both times obviously, but I believe the 7077.122.4 firmware fails to fully complete installation, although it does appear to recognize the boot disk and the led flashes for a while (device is not in dev mode and light pattern is blinking red after recovery). Regardless, following the exploitee instructions results in a single beep immediately upon pressing the dev mode switch with the new firmware, and a similar but delayed beep upon pressing the switch using the old firmware.

I suspect that the exploitee instructions no longer work for any Onhub with updated firmware, but your post is probably one of the first documented cases I've seen online detailing the issue precisely. I was unsure if it was just an issue with my unit previously.

I think your idea of attempting get serial access using the Yoshi Flex socket is probably the right approach. I can give a shot at soldering to the header pads later tonight, but I'm unsure if we should even really be expecting any parsable debug output at all, as the actual debug cable seems to have quite a bit of active circuitry. Haven't looked into it much, but do you think there might be an enable pin or something on one of the pads? Not very familiar with the Servo debug standard.

rmelick · August 26, 2022, 7:07am

@An-GG I'm glad to hear that someone else has the same issues with the exploitee instructions. For accessing the UART serials, I've designed a breakout board for the Panasonic connectors used by the Yoshi cable. I've ordered a couple of the connectors, and am just waiting for the board to come back from manufacture to be able to put it all together. It's by far the smallest thing I've ever soldered, so hopefully I don't ruin the router. The board should be here in the next week or two, so I'll have more to report then.

In terms of actually enabling the serial port so that something prints to it, I'm not sure.
I don't remember exactly where, but somewhere in the ChromeOS documentation, I saw that .the release builds have all serial output disabled. So, I'm not sure there will be much to see while it is booting the stock firmware.

My hope, is that if I can get it to try and boot OpenWRT from a flash drive, either the CoreBoot bootloader (unlikely) or the actual OpenWRT linux kernel will print some kind of message. To do that, I think I should change my device tree in my OpenWRT branch and make it super minimal (just the serial port maybe?) to avoid chances for things to go wrong.

zgrimz · October 2, 2022, 7:01pm

Very interested in OpenWRT on the TP OnHub. I'd even throw in for a bounty to get before EOL this December.

bnorris · October 6, 2022, 7:42pm

I don't remember exactly where, but somewhere in the ChromeOS documentation, I saw that .the release builds have all serial output disabled.

Couldn't find great documentation, but here:
https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/463b4798a7f11e5b9f3ef2e8b95228554844efaa/sys-boot/chromeos-bootimage/chromeos-bootimage-9999.ebuild#479

So, likely no firmware logs.

So, I'm not sure there will be much to see while it is booting the stock firmware.

They'll at least spawn a getty in dev mode, so you should be able to log in:
https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/chromiumos-overlay/chromeos-base/tty/files/tty-base.conf;l=22;drc=132e2285dfaf834a4149baafcab979057a25e4a2

bnorris · November 1, 2022, 3:21am

I managed to get something working. It's in somewhat of WIP state, but it has most of the basic functions (Ethernet, WiFi to some extent, eMMC, USB, LEDs) working.

No warranties, very little documentation, yadda yadda. There's quite a few TODOs noted in the commits, and hopefully I'll get some time to clean it up enough to submit in the not-too-distant future. I'll probably be force-pushing/rebasing, so it also won't have any stable commit hashes to point at.

But if you know how to build and boot from USB, it might work for initial testing.

Nadonate · November 17, 2022, 5:07pm

I'm new to openwrt (tomato user ), but i would like to help out (where i can) with this project.

I picked up 2 of these units, i can build from your repo, but I'm not sure how to boot from USB. Where should i start? Can you instruct, or point me at the pertinent documentation?

Thanks!

bnorris · November 18, 2022, 5:13am

Hi! Others have posted links to some instructions on exploitee already. I haven't verified those exactly as-is, but it might be worth giving a shot. Obviously you'd dd the openwrt image instead of the one they link, but otherwise I think they should work for this.

Also, it's not what you're asking, but I could probably use some help on the documentation. In the past, I think people have recommended (required?) a device page of some kind, to document installation, etc. See: Add a device to the Table of Hardware. It wasn't trivial writing up the Google WiFi ToH entry last time.

One other word on status: I still couldn't figure out how to get multi-CPU support working (the second CPU hangs when it's brought up), so one of the two cores is kept offline for now. That's still probably good enough to merge some kind of support into openwrt.git, but I'd really like to get that fixed.

zuzu · December 2, 2022, 5:17pm

Ah, just got email from Google informing me my Google Onhub (Asus) will not be supported come Jan 11, 2023.

The router works really well, zero hiccup. What a waste just to throw it away. Any hope for OpenWRT on it? Thanks much!

slh · December 2, 2022, 7:48pm

It still needs someone to start working on it, that doesn't happen by itself - so if you're the one, speak up now or forever hold your breath

The SOC itself is well supported, google's special sauce doesn't make it any easier though, as it renders crucial parts of the boot process rather non-standard (but we have prior art in the ipq40xx target, for the first generation google wifi mesh clients, so it should be possible - but it really needs someone with the hardware making this happen).

zuzu · December 3, 2022, 3:11am

Thanks but nope, def not the one. I have 2, 1 is brand new. Bought years ago.

Gotta throw them away then unless someone wants them.

Leo-PL · December 4, 2022, 1:33pm

In which country do you live? Maybe there is someone willing to take them on near you.

An-GG · December 5, 2022, 6:39pm

Sounds awesome! Could you throw together a video of your exact boot procedure from power off state so I can follow along? Not asking for a tutorial with build instructions or anything - just boot steps. I remember having some trouble interpreting the exploitee procedure instructions precisely, it was a bit confusing.

Haven't had time to check out your fork, but could you define the end state of your whirlwind device a bit more? Do you have a working remote shell on the device? Or do you mean after booting from your fork, Ethernet, eMMc (actually, for this did you get write working as well?), USB, and LEDs 'work' in some non-inspectable manner? Or something else?

bnorris · December 5, 2022, 9:43pm

I'm unlikely to make my own video, but I'll probably try to write some modified boot/install instructions at some point, because Exploitee has a different goal than running OpenWrt. But as it happens, they already made a video which should be good enough with some creative adjustment:

Regarding my work: I have a working shell and everything; it's fully functioning, albeit a bit slow due to 1 missing CPU. (And yes, I can read and write the eMMC.)

LEDs are a touchy subject, since I found there are a few variations of this hardware. Out of the 3 test TP-Link devices I have, only one is the "sp3" variant which I tested (and LEDs work; although I didn't configure them to go "on" by default); the others are "sp5", and the LEDs need some tweaks. I'll have to figure out a way to provide alternate DTBs on the same image, or else we'll need different subtargets for "sp3" and "sp5."

BTW, @zuzu: I also have an ASUS model, and I got it working too. Technically, it works with the same "whirlwind" (i.e., TP-Link) branch I already posted, but it also needs some different tweaks to get the LEDs working. I have something in my local branch working, and I'll post it eventually.

goixiz · December 5, 2022, 11:50pm

Thank you for trying to get openWRT onto these TGR1900s
I just replaced my home mesh with another TPlink mesh XE5300