April 14, 2026

Allwinner H5 network driver -- driver sources in other projects

In general, this means U-Boot. We could examine the linux sources, but I generally find U-Boot drivers to be more or less straightforward. The main thing about U-Boot drivers is that they don't use interrupts.

I have many copies of the U-boot source on my machine. A good one is this: 

/Projects/ARM-sources/u-boot/drivers/net/sunxi_emac.c
Using ctags is almost essential, so: 
cd /Projects/ARM-sources/u-boot
ctags -R .
Some directories of interest: 
arch/arm/include/asm/arch-sunxi
arch/arm/mach-sunxi
arch/arm/dts
In particular, in the dts directory, look at: 
sun50i-h5.dtsi
sun50i-h3.dtsi
The only place I see the syscon register defined is in the dts file: 
syscon: system-control@1c00000
	compatible = "allwinner,sun50i-h5-system-control";
	reg = <0x01c00000 0x1000>;
I was particularly interested in accesses to the address 0x01c00030, which is the EMAC specific syscon register, but so far finding the code that deals with this has not been possible.

Allwinner lingo

First of all, Allwinner chips use two ethernet controllers: EMAC and GMAC. Our h3 and h5 chips both use the EMAC. In general the EMAC does not support 1000 Mbit ethernet, but apparently our EMAC does. The main thing is that gmac code is not relevant to the h5 or h3.

The H3 (and H5) use a fancier "sun8i EMAC", which has its own driver and has different registers than the original emac. This may be some form of Synopsis Designware device. If so, there actually seems to be decent documentation as part of the H3 and H5 manuals, which is unusual for any IP from Synopsis.

The H3 is in the "sun8i" family from Allwinner. The H5 is in the "sun50i" family. This peculiar nomenclature is probably some historical internal naming system used by Allwinner, but the names show up on files in the U-boot collection.

The term "sunxi" bears some explanation. This seems to be a consortium independent of Allwinner that worked on software for Allwinner devices. Whatever the case, "sunxi" supplies invaluable information and software. Allwinner on the other hand is something else entirely as far as being useful or helpful.

The situation is summed up in the following statement: "Allwinner offers cheap, high-powered hardware with poor official support, whereas Sunxi provides the software ecosystem and drivers to make them usable." It is an ugly situation. Moving to Rockchip devices seems to offer a better state of affairs. I knew none of this when I started working with the H3 and H5, but have learned by painful experience.

So Allwinner chips are cheap. Beyond that -- good luck.

Breadcrumbs

The U-Boot source is big and complex. Often the trick in any given directory, is figuring out which files are actually relevant to (i.e. compiled and linked into) a given build of U-Boot. The only sane method I have found to deal with this is to actually configure and build U-Boot for whatever board you are working with. After you do this, you can find object files in each directory to indicate which files were used in the build.

As an example, consider the directory "drivers/net" has 93 different network drivers, but after a build I find only sun8i_emac.o, showing me that only the file sun8i_emac.c is relevant for the Allwinner H5 build.

Similarly in the directory "drivers/phy" there are 34 phy chip drivers, but we find only phy-uclass.o -- so phy-uclass.c is the only file we need to concern ourselves with.

Of vital importance is the directory "drivers/net/phy" which has 38 C source files, but only phy.o appears. This leads us to phy.c It is not clear (to me) why we have both drivers/phy and drivers/net/phy, but it turns out that phy.c has autonegotiation logic and looks to be the most interesting.

Last but not least is the file "include/linux/mii.h" which contains all of the standard PHY device register definitions used by phy.c and phy-uclass.c.

sun8i_emac.c

As we have just discovered, the file of interest to us as far as a network driver is: 
drivers/net/sun8i_emac.c
This is the file to study. Searching on "syscon" turns up exactly what I wanted to find.

This driver uses a base address for the emac registers, along with a set of macros defining offsets to the various registers. Thusly writes to device registers look like this: 

writel(val, priv->mac_reg + EMAC_MII_DATA);
writel(mii_cmd, priv->mac_reg + EMAC_MII_CMD);
This is not the style I prefer, but it is perfectly fine.

Autonegotiation and U-Boot

Autonegotiation is the process where a host and network switch communicate to decide what speed and duplex they are going to use.

When U-Boot loads kyu, I see this message, but not until I attempt some network activity: 

ethernet@1c30000 Waiting for PHY auto negotiation to complete........ done
This comes from the routine genphy_update_link() in the file "drivers/net/phy/phy.c" that we discovered above. This is called from genphy_startup() in the same file.

The results of autonegotiation are determined by the routine genphy_parse_link() in the same file, which contains the comment: 

Stolen from Linux's mii.c and phy_device.c

The Realtek 8211

This is the external PHY used on my Allwinner H5 boards. As Kyu starts up, I dump the values of various registers in this chip. These are the values left after U-Boot autonegotiation. 
ADV   = 01e1
PEER  = cde1
BMCR  = 1140
BMSR  = 796d
PHY ID = 1cc915
CTRL1000  = 0300
STAT1000  = 0c00
The value in the ID register is exactly what the RTL8211 datasheet says it should be, which is comforting. The values in the CTRL/STAT1000 registers will tell us if the autoconfiguration is gigabit. The LED on my network switch says that gigabit was decided by autonegotiation.

The two bits set in CTRL1000 indicate capabilities we advertise during autonegotiation. The bit 0200 says 1000 Mbit full duplex. The bit 0100 would indicate 1000 Mbit half duplex, but for the RTL8211 this is a reserved "don't care" bit. The two bits set in STAT1000 indicate the capabilities our peer indicates, with the bit 0800 being 1000 Mbit full duplex and the bit 0400 being 100 Mbit half duplex.

Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org