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