Those should work fine
2 Likes
I believe my AX6 has zero link indicator LEDs, only the "system" and "internet" leds on top of the device.
Oh, so they saved a cent or two on RJ45-s with LED-s.
Thanks, everybody for the Buy Me a Coffe support, it will be spent on more gear (Added some and ordered a J-Link EDU) as JTAG can be really useful, especially since one can manually enable DDR and PLL clocks and boot U-boot.
Also, my brain finally used some of its cells and made a conclusion that something is not enabling the networking clocks if booting directly.
The reason why it works when using initramfs is that if one interrupts U-boot then it will enable the clocks so that you can use networking.
3 Likes
wow we are at the jtag phase? things looks to be pretty bad... also does jtag works on this? No lock or protection? Or a special tool is needed (notice some on the qsdk)
Well, I wouldn't say it's a must-have now but it for sure makes your life easier and I am also working on stuff like RB5009 where it would be really handy.
It should work just fine, you cant really protect or lock JTAG in any way other than requiring the bootstrap so that pins are not GPIO-s but JTAG pins.
QSDK/Qualcomm only supports Trace32 from Lauterbach and provides scripts for them, so they have scripts that you just load and they will enable DDR and PLL clocks and then just load the U-boot binary into the DRAM and boot that so that you can recover and stuff like that.
But you are free to use J-Link Ozone or I actually like OpenOCD since you can do scripts there as well and replicate whatever, a really good thing is that it provides you with the whole register space, you can use GDB to set breakpoints etc.
You can even abuse the Boundary Scan to toggle pins without the kernel even having a say in it, so I would say its pretty good tool to have.
Only downside to J-Link EDU is that its non commercial only (I mean they have no way of actually enforcing that)
Hmm, and mdio would still detecting the phy's even clocks aren't enabled?
And why does this issue only occurs with kernel 5.15, though networking is working fine with kernel 5.10 on the AX9000.
Yes, cause it's a separate clock and everything.
It's most likely because of something missing in the clock driver as I got rid of the let's copy everything from QCA and hope it works approach.
Hm, copy/pasted the CLK driver from 5.10 and it still doesn't work, lets say that I am a bit stuck.
The thing is that I can see a big difference when initramfs is run and from flash.
UNIPHY clocks aren't being enabled at all, NSS port clocks, etc.
Hm, so I disabled 802.3az through SSDK shell and it triggered the clocks to be enabled.
Like WTF?
nothing to contribute here... but that thing is run on voodoo magic for sure 
Looks like it so far, the worst part is that I tried that again and that time it didn't do it.
I have wasted most of the day chasing WTF are the clocks not being enabled when flashed, it just doesn't make sense at all that if the bootloader doesn't set them it doesn't work.
Even weirder is that SSDK will register them just fine with the parents properly if running from initramfs but as soon as you flash it registers only like a quarter of the required clocks.
I honestly don't know how to approach this further
let's dump the bootloader and reverse it? 
No need, QCA has the source publicly available and you can see what GCC registers it touches.
But that all is supposed to work without the bootloader, the bootloader only does it if you interrupt it so that networking will work inside of the bootloader
If the is behaviour is confined to the AX9000, does it make sense to proceed with the other targets (as Iām sure there will be other gotchas to overcome) and return to the AX9000 afterwards (or worst case even post upstream merge).
Sometimes fresh eyes (and not to mention a few wins) go a long way in helping in situations like this.
1 Like
Other targets are already there, nothing is blocking them.
The thing is that if one board is affected most likely its gonna be all of them since the SSDK uses same logic.
Second set of eyes would be really awesome.
3 Likes
I should really stop with ipq806x and return helping you with ipq807x....
7 Likes
great when will it start
That would be great Ansuel!
Just a thought, but in that case maybe worth reminding people in that thread what's your buy-me-a-pizza URL? 
5 Likes
This is with 5.15:
I see that you moved some repos. Do I need to make a new build from the new ipq807x-5.15 branch?
1 Like
I did some cleanups, so you can give it a go but it shouldnt change memory or networking
2 Likes
Recompiled it, works fine so far.
1 Like