Perhaps 5 years ago I worked on the phy/mdio code for the Allwinner H3. It was all new to me and I was up to my ears with new information. I was having strange and confusing problems with basic MDIO reads and writes. I seemed like I had to read twice to get the result I expected.
The problem had nothing to do with reads, it was a basic error in my low level mdio write routine. You must write to the data register, then write to command register telling to write that data. Simple enough.
The problem now is that I have autonegotiation working, but the network driver is dead after it finishes. I have the happy confirmation that autonegotiation is working by looking at the LED on the little Netgear switch my board is connected two. Before autonegotiation it shows the single 10 mbit LED. During autonegotiation, all the speed LED go out. When autonegotiation finishes, the 100 mbit LED is on.
When I reboot it, the LED goes out briefly, then the single 10 mbit LED comes on. So the problem now is to get the emac to be happy after the autonegotiation does the transition to 100 Mbit.
sys/arch/arm/sunxi/sunxi_emac.c sys/arch/arm/sunxi/sunxi_emac.hSome quick searching turns up a routine "sunxi_emac_update_link" that is writing to registers based on speed and duplex. It writes to:
It has a routine "setup_phy" that seems to entirely work with the syscon register. As a side note, it sets the internal PHY address to "1".
drivers/net/sun8i_emac.c
One odd thing I have yet to explain:
Emac rx_count: 99 Emac tx_count: 103It is as though I have sent and received some packets and then everything locked up. And indeed I have. I seems that Kyu has done the whole symbol table transfer just fine after initializing the driver!! And properly too.
Why can we do this, then after we are done, all networking is stuck. And why does bypassing the PHY stuff make this all work?
Kyu / [email protected]