Well, yeah with the upstream generic BDF.
Its newer going to be user selectable as FW is in control and its reading its HW config from the BDF.
AX9000 is a bit of a weird case but not comparable as it has 2 radios covering 5G but their allowed frequencies dont overlap intentionally.
a_guy
437
Got it, I guess we can have 2 builds then at least - with different bdfs baked in?
Anyway, we could go back to this later. Making rtl9301 work is the top priority now.
Which driver is needed for spi-nor?
Ansuel
438
Can you try the modified BDF?
a_guy
439
I tired with the one you sent me
root@OpenWrt:/# sha256sum /lib/firmware/ath11k/QCN9074/hw1.0/board-2.bin
6e08bdfe2c3e19b1d31ae572905a69759309a5b34a62c0699134a69b61fd0349 /lib/firmware/ath11k/QCN9074/hw1.0/board-2.bin
a_guy
440
I guess nothing is there on this spi bus?
OEM:
[ 8.130501] m25p80 spi32766.0: unrecognized JEDEC id bytes: 00, 0, 0
OpenWrt:
[ 2.548666] spi-nor spi0.0: unrecognized JEDEC id bytes: 00 00 00 00 00 00
Not a JEDEC compatible SPI NOR at least
a_guy
443
Yes, after rebasing to lastest - to include the upstream fixes @robimarko had mentioned.
Ansuel
444
Good! Then I have to check and revert some changes... the idea is to have a BDF as close as the original one
a_guy
445
ok, but that bdf still blocks some legally allowed stuff like 177 5ghz channel. Is is possible to update it somehow?
Ansuel
446
we already had a similar discussion those channel from what i notice are for low emission device... qcom decided to block these channel due to very flow tx power emission (order of 13 db) and the fact that router are not low emission device...
I assume those freq are for phone hotspot or similar usage
a_guy
447
We did have that so I'm not gonna start it again. I'll just leave those links here
Ansuel
448
enabling those freq is doable just overkill and i would prefer qcom doing that...
a_guy
449
Perfect. At least it's good to know we are not blocked here. Let's go back to it after the rtl9301 is working. It will take a while anyway.
a_guy
450
This seems to initialize rtl9301 without SPI?
a_guy
451
any docs on how RTL SDK works?
on OEM /usr/bin/usrApp gives some sort of console
root@CR1000A:/dev# /usr/bin/usrApp
RTK User Space SDK Initialize
RTCORE Driver Module Initialize
IOAL init
IOAL init
Log init
Hardware-profile probe (RTL9303_8XGE)
Hardware-profile init
IOAL init
IOAL init
RTK Driver Module Initialize
MAC probe (unit 0)
Chip 9303 (found)
MAC init (unit 0)
PHY probe (unit 0)
Chip Construct (unit 0)
Chip Construct
Disable PHY Polling
PHY Reset
MAC Construct
Turn Off Serdes
Serdes Construct
PHY Construct
Turn On Serdes
Mac_Polling_PHY Config
Enable PHY Polling
Misc
PHY init (unit 0)
Mgmt_dev init (unit 0)
unit=0,sds=3 cali success.
failed to add object: Invalid argument
Start to run Diag Shell....
RTK.0> [Link Mon]PORT(3): STATUS(0)
unexpected switch port:27, link status:1
RTK.0> help
^Parse error
tesf23
452
You can type question mark for help menu
1 Like
tesf23
453
FYI
RTK.0> port get port all
state - state configuration
fiber - fiber config
down-speed - down speed config
phy - PHY
link-media - link media status
serdes - SerDes config
phy-link-status - phy link status
RTK.0> port get port all state
Port 8 :
Admin : Enable
Port 20 :
Admin : Enable
Port 24 :
Admin : Enable
Port 25 :
Admin : Enable
Port 27 :
Admin : Enable
Not sure what is on Port 27, maybe the WAN port since I added it to bridge.
root@CR1000A:/tmp/rtl-9303-shadow# cat port_status_8
link speed duplex
1 10000 1
root@CR1000A:/tmp/rtl-9303-shadow# cat port_status_20
link speed duplex
1 2500 1
root@CR1000A:/tmp/rtl-9303-shadow# cat port_status_24
link speed duplex
0 0 0
root@CR1000A:/tmp/rtl-9303-shadow# cat port_status_25
link speed duplex
1 2500 1
root@CR1000A:/tmp/rtl-9303-shadow# cat port_status_27
cat: can't open 'port_status_27': No such file or directory
1 Like
a_guy
454
I made small progress today, I guess: ethtool now recognizes dp5 phy (which is RTL9301's 'control' port? #27?)
5.128215] GMAC5(ffffff80029958c0) Invalid MAC@ - using 7a:aa:5a:ce:54:60
[ 5.132342] Generic PHY 90000.mdio-1:0f: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:0f, irq=POLL)
[ 5.139656] nss-dp 3a003000.dp5-syn lan: Registered netdev lan(qcom-id:5)
[ 5.148797] GMAC6(ffffff8003e2a8c0) Invalid MAC@ - using 2e:c1:f8:ad:2b:ac
[ 5.155517] Aquantia AQR113C 90000.mdio-1:08: FW 5.6, Build 7, Provisioning 1
[ 5.167540] Aquantia AQR113C 90000.mdio-1:08: attached PHY driver (mii_bus:phy_addr=90000.mdio-1:08, irq=POLL)
[ 5.169948] nss-dp 3a007000.dp6-syn wan: Registered netdev wan(qcom-id:6)
I set the DTS to point to mdio address 0F (took it from uboot's mii info)
IPQ807x# mii info
PHY 0x08: OUI = 0x0000, Model = 0x00, Rev = 0x00, 10baseT, HDX
PHY 0x0F: OUI = 0x90D1, Model = 0x37, Rev = 0x01, 10baseT, FDX
root@OpenWrt:/# ethtool lan
Settings for lan:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: No
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric Receive-only
Advertised auto-negotiation: No
Advertised FEC modes: Not reported
Speed: Unknown!
Duplex: Unknown! (255)
Auto-negotiation: on
master-slave cfg: preferred slave
master-slave status: unknown
Port: MII
PHYAD: 15
Transceiver: external
Link detected: no
root@OpenWrt:/#
It is only 1gbps port though?
this looks nearly identical to the shell we get on our switches, i bet its the same app; though I don't think we have source code for it (we might though actually :p) the previously linked repo also contains some other dumps (diff branches), and one of them might actually contain it.
Port 27 is almost always the 'CPU/Ext CPU port'. You can configure it to be on port28, but haven't seen this yet.
The 'internal' stuff, normally the internal serdes-es gets an mdio address somewhere at the end of the range. Do'nt remember exactly how that worked, probably -1 or something. This was done because the internal serdes do not have an MII connection, but a 'register' (or SPI in this case) based connection.
But in the end, the most important part, is to get to send bytes to the right SPI port and get replies back
the switch will be setup by the verizon firmware in this way as well, so this has to work.