Adding Support for Verizon CR1000A

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.

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?

Can you try the modified BDF?

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

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

So it does work o.o?

Yes, after rebasing to lastest - to include the upstream fixes @robimarko had mentioned.

Good! Then I have to check and revert some changes... the idea is to have a BDF as close as the original one

ok, but that bdf still blocks some legally allowed stuff like 177 5ghz channel. Is is possible to update it somehow?

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

We did have that so I'm not gonna start it again. I'll just leave those links here


enabling those freq is doable just overkill and i would prefer qcom doing that...

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.

This seems to initialize rtl9301 without SPI?

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

You can type question mark for help menu

1 Like

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

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 :slight_smile: the switch will be setup by the verizon firmware in this way as well, so this has to work.