i'ts cheap but only switchOS , too new on market, have You seen this one " Aruba InstantOn 1930 24G 4SFP+" ? i'm curious about this one , in paper look's very good for future upgrade core network
Dude, CSS610 is under 100 EUR and that Aruba is like 4 times that.
Honestly, I just need it for ports and VLAN-s.
Most likely will pull fiber for 10G to the main switch
@Ansuel I am trying to get the voltage scaling working.
Added the DTS nodes as it seems to use the same A53 PLL as IPQ6018 and rest.
Enabled cpufreq-dt in the kernel, but nothing.
cpufreq does not attach to the CPU cores at all as it should.
Can you maybe take a look?
I have pushed it as WIP to my branch.
PS: I know that OPP table is valid for IPQ8071A only, that will be sorted out later.
2 Likes
Will check it this night. Wonder if we need to add something to the blacklist cpufreq platdev? Since we use normal opp v2 we should not use them. Something i would check first is if cpufreq-dt actually registers and doesn't fail in the ENODEV error
1 Like
I dont think that we need to blacklist anything as we are using generic properties.
cpufreq-dt already has a check on probe for cpufreq_register_driver and uses dev_err if its not null.
But I will add some prints to where it registers
Update: It seems that some of the needed resources are missing, adding prints to check which now.
Ok, I narrowed it down to the clock not being ready.
So, there is some difference in the IPQ8074 compared to IPQ6018 after all.
And got it, APSS clock is defined in the APCS mailbox driver.
I simply added the IPQ6018 clock name and it appears to scale, at least it does not crash when going to 1.4 GHz.
Issue with IPQ8074 is that I have no idea of its OPP point voltages as they use CCR to determine within certain limits which voltage will be used.
Upstream CCR driver only knows about QCS404 SoC and since IPQ6018 downstream uses it while upstream simply scales through a regulator I dont feel like reversing the magic with fuses and everything else.
So, I got OPP voltages for IPQ8071 from the stock FW.
[ 1.785770] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 19200 KHz, changing to: 1017600 KHz
Hm, 19.2 MHz sounds really low even for U-boot, gotta compare it to IPQ6018 to see whether we are missing a zero here.
1 Like
Do we have efuse access or we are still missing qfprom node in the dts?
Fuses are part of the CPR register space, so no need for qfprom.
I pushed the "working" scaling version.
Ideally, we would port IPQ8074 support to the CPR driver so that it would automatically do fine voltage adjustments depending on enabled peripherals.
2 Likes
hoping that they didn't massively changed the driver, we should be able to study a little the cpr node in our dts and try to add support in the driver o.o
the first problem I see is the fact that qcs404 use efuse and ipq807x doesn't...
(ok looking at the code could be that efuse are just hardcoded and not present in the dts)
They all use fuses its just that downstream CPR driver reads them directly.
Honestly, I dont think that this is a priority.
1 Like
Yes you are right. It's just that it looks so damn interesting how they engineered this madness ahahah
Yeah, talking about overengineered.
But, good thing is that they finally started using same IP in mobile SoC-s so they upstream a lot of drivers.
That makes our life a lot easier.
Also I notice that in the dts there are some reference about a npu regualtor... we have a ia accelerator in the cpu ? (start working on ssdk_shell ... Any idea how to use that tool?)
NPU is part of the NSS block.
S4 is the regulator for that block.
Should be two NSS cores at 1 GHz each.
(interesting the fact that they hardcoded the bootcmd in the mii uboot)
Anything unusual from swconfig?
root@OpenWrt:/# swconfig dev switch0 show
Global attributes:
enable_vlan: 1
max_frame_size: 12288
dump_arl: MAC: 4c:e1:73:4a:da:63 PORTMAP: 0x08 VID: 0x2 STATUS: 0x0
MAC: 28:d1:27:5a:e8:6b PORTMAP: 0x01 VID: 0x2 STATUS: 0x0
Port 0:
mib: Port 0 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
RxUniCast : 0
TxUniCast : 0
pvid: 0
link: port:0 link:up speed:unknown full-duplex
Port 1:
mib: Port 1 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
RxUniCast : 0
TxUniCast : 0
pvid: 1
link: port:1 link:down
Port 2:
mib: Port 2 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
RxUniCast : 0
TxUniCast : 0
pvid: 1
link: port:2 link:down
Port 3:
mib: Port 3 MIB counters
RxBroad : 142
RxPause : 0
RxMulti : 308
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 37
Rx128Byte : 380
Rx256Byte : 33
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 42918
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
RxUniCast : 0
TxUniCast : 0
pvid: 1
link: port:3 link:up speed:1000baseT full-duplex txflow rxflow
Port 4:
mib: Port 4 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
RxUniCast : 0
TxUniCast : 0
pvid: 1
link: port:4 link:down
Port 5:
mib: Port 5 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
RxUniCast : 0
TxUniCast : 0
pvid: 2
link: port:5 link:down
Port 6:
mib: XG Port 6 MIB counters
RxFrame : 0
RxByte : 0
RxByteGood : 0
RxBroadGood : 0
RxMultiGood : 0
RxFcsErr : 0
RxRuntErr : 0
RxJabberError : 0
RxUndersizeGood : 0
RxOversizeGood : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
RxMaxByte : 0
RxUnicastGood : 0
RxLengthError : 0
RxOutOfRangeError : 0
RxPause : 0
RxOverFlow : 0
RxVLANFrameGoodBad: 0
RxWatchDogError : 0
RxLPIUsec : 0
RxLPITran : 0
RxDropFrameGoodBad: 0
RxDropByteGoodBad : 0
TxByte : 0
TxFrame : 0
TxBroadGood : 0
TxMultiGood : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
TxMaxByte : 0
TxUnicast : 0
TxMulti : 0
TxBroad : 0
TxUnderFlowError : 0
TxByteGood : 0
TxByteGood : 0
TxPause : 0
TxVLANFrameGood : 0
TxLPIUsec : 0
TxLPITran : 0
pvid: 0
link: port:6 link:down
Port 7:
mib: Port 7 MIB counters
RxBroad : 0
RxPause : 0
RxMulti : 0
RxFcsErr : 0
RxAlignErr : 0
RxRunt : 0
RxFragment : 0
Rx64Byte : 0
Rx128Byte : 0
Rx256Byte : 0
Rx512Byte : 0
Rx1024Byte : 0
Rx1518Byte : 0
RxMaxByte : 0
RxTooLong : 0
RxGoodByte : 0
RxBadByte : 0
RxOverFlow : 0
Filtered : 0
TxBroad : 0
TxPause : 0
TxMulti : 0
TxUnderRun : 0
Tx64Byte : 0
Tx128Byte : 0
Tx256Byte : 0
Tx512Byte : 0
Tx1024Byte : 0
Tx1518Byte : 0
TxMaxByte : 0
TxOverSize : 0
TxByte : 0
TxCollision : 0
TxAbortCol : 0
TxMultiCol : 0
TxSingleCol : 0
TxExcDefer : 0
TxDefer : 0
TxLateCol : 0
RxUniCast : 0
TxUniCast : 0
pvid: 0
link: port:7 link:up speed:unknown full-duplex
VLAN 1:
vid: 1
ports: 1 2 3 4 6t
VLAN 2:
vid: 2
ports: 0t 5
Also can confirm that in the original firmware they don't use swconfig... so the dp driver mimics the dsa driver where every port is an interface.
@robimarko in your previous experience can the eth switch be malfunctioning due to another component not working? (regulator or something else)
I'm starting to have this fear since the problem is that the switch receive packet but doesn't send them (no communication between cpu and port?)
Also what is strange is the fact that on the oem firmware, the eth led comes up and on our firmware doesn't. Can't find anything that actually sets it in the oem firmware so I think it's something related to the switch and this gives me more suspect that something is wrong and is not working. But someone said that another guy that working on it made the switch working in kernel 5.4... Need to inspect his repo i think.
Could be, as LED-s should be driven by the PHY
(a little ot... nss firmware are public... if and when we get this supported real offload will get real! ipq807x: update NSS Firmware package · Telecominfraproject/wlan-ap@721e7cd · GitHub)
4 Likes
I pushed the ssdk_shell pkg...
All the qca pkg are set with the qsdk 11.3
Anyway the ess-switch queue configuration is a little tweaked as i removed the missing port in our router... i don't know (and honestly i don't think) they does cause any problem...
From what I notice there are 2 cpu port in this SoC with id 0 and 7 (notice them as in some configuration they have fixed-link)
(spoiler the ssdk_sh is not that usable ahaha)
1 Like
Port 0 should be the QCA8337 switch CPU port while 7 should be the 2.5G port.
I am hoping that ethernet is similar enough to IPQ40xx so that hacky ESSEDMA could be used to get networking.
1 Like
I'd like to ask to smart guys 
Did you pay attention, that there was post about source code from TPlink router, which are made on same base as AX3600. Or it is not usable for us? Because I didn't see, that you mention it in any way. I mean Ansuel and robimarko