IPQ807x SoC Investigation / Status [WIP]

The USB clock warning is harmless, for me its only shown in logs when I tftpboot the image.

tftpboot and the nand boot processes differ slightly it seems, for example

  • tftpboot uses the 1st available FIT config
  • nand boot looks for a specific config name

Can you get into fallback shell ? I had issues with early builds not being able to find the rootfs.

Ok, I thought that it was harmless.
Yeah, I know the differences between normal boot from storage and TFTP loading.
I usually use TFTP loading for testing things untill it works properly because its the fastest way.

FIT is not an issue here, I have already set it to the one that bootloader is searching for.

I actually completely missed that NAND is now not working and throwing:
qcom-nandc 79b0000.nand: failed to request tx channel

Hm, I backported:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/nand/raw/qcom_nandc.c?h=v5.9-rc1&id=cb272395dceef1652247dad08a50ed4153ffbd43
and
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/mtd/nand/raw/qcom_nandc.c?h=v5.9-rc1&id=443440cc4a901af462239d286cd10721aa1c7dfc

And enabled DMA which is disabled by default, now NAND works.
But no luck getting to the shell, it looks like init get stuck somehow.
And yeah, I can get into failsafe shell.

Yeah iv been mostly using TFTP boot for now as well, we had to add some delays to the nand init to get it stable (see : https://github.com/BuzzBumbleBee/openwrt/blob/ax3600/target/linux/ipq807x/patches-5.4/001_qcom_nanc_add_delay.patch)

For me i have had ath11k / eth and nand all working with that USB error showing, im guessing with tftpboot uboot / sbl is leaving the USB clocks in a strange state.

Ok, will give those delays a go but I doubt that thats the cause of OpenWrt init failing.
I also added the WDT node as QCA did not add that for whatever reason, but no luck.

If you don't get anywhere, try either flashing it to nand, or try my branch and start removing patches ?

I know some of the clock ones are unnecessary but thinks like q6 fw load and qmi messaging are needed (and have been back ported from QCOM staging / mailing lists)

Yeah, I will try flashing to NAND as it makes no sense to stall booting.
Yeah, there are remoteproc and QRTR namespace backporting needed for ath11k, but I am far from that.

@Apache14 To update you a bit.
The fault was the lack of correct initab, default one was not dropping shell on specific serial console, but instead relied on cmdline parameter which is not passed by bootloader when using bootm.

@Apache14 @gmzhuo I am moving on the IPQ807x support.
Finally finished ath11k today and am now trying to get PCI-E working for the QCA9887.

If you want to help getting this supported in a upstreamable/mergeable way the code is here:

5 Likes

I'll definitely have a look later this week, work is crazy for the 1st half

1 Like

I tried to do some more work as for whatever reason Xiaomi decided to connect a PCI-E 1.1 compatible radio to the PCI-E 3.0 port.
And that one requires a ton of backporting on the PHY and PCI-E drivers, unfortunatelly after I got it to compile it did not work.

If only we had kernel 5.9 support in OpenWrt, it would get rid of tons of patches.

1 Like

Yeah I found the same for the PCIE stuff, I have up on getting that to work for now as really that's a small bit of broken HW (main parts for me are the switch and ath11k)

I think even in 5.9 we are missing most of the Q6 FW and QMI patches needed for ath11k.

It's been a super busy couple of weeks for me, I'll try get back to helping next week

2 Likes

Yes, stuff is missing in 5.9 as well but the number of patches to the important drivers is much lower.
Plus we dont have to do surgery and further backporting to have the patches apply and compile.

I will start sending nodes for watchdog, smem, prng and SPMI regulators upstream as I have those working fine and in upstreamable state.
Hopefully this weekend.

Also, I have moved the PCI-E WIP stuff to here, simply to not pollute the stuff that works.

4 Likes

any luck ?

No, did not have to work on it.
Until.5.9 support lands its a mess of backporting

1 Like

I received today my new Netgear RAX120 (Nighthawk AX12)
(quad-core, IPQ8074A, 512 MB flash, 1024MB RAM, 802.11ax)

I uploaded its OEM kernel bootlog to
https://openwrt.org/inbox/toh/netgear/netgear_rax120_nighthawk_ax12
in case somebody is interested.

Likely I will attach a serial cable to see more closely what happens with the OEM firmware, as I didn't yet figure out if telnetenable or similar works to get console access.
(Luckily the OEM firmware's debug page enables to save a debug file that contains the kernel bootlog).

4 Likes

test if the standard recovery works

Not sure yet.
Keeping the reset pin pressed at boot makes the power LED to end up blinking slowly, so TFTP recovery likely works like with the earlier models. But I haven't tested actually sending a firmware with TFTP, yet. (I might need to send an older Netgear firmware to prove a difference to the current one)

I would like to attach a serial cable to see how the boot process works, but opening the case seems difficult: Although I have opened seven screws, there are rather tight prongs on the sides, in similar style as is in R7800, but apparently much stronger ones...

EDIT:
Netgear lists RAX120 among the routers with TFTP recovery flash:

Just a brand new router with hard as rock plastic clips (or some screw hidden under some plastic stick)

The real question is if it has secure boot enabled or not...

I would bet that it does not have secure boot.
Secure boot has been available in both IPQ806x and IPQ40xx and nobody used it.
I dont think that Netgear and others like them care enough to increase their cost

2 Likes

Ipq40xx Netgear ex7700 use it and it's a pita... Was trying to support that but I bricked one trying to flash a unlocked uboot