January 14, 2026

Kyu - network - peek at the U-boot sources

We could also peek at the Linux driver for the h5, but we will start with U-boot.

I have a recent clone of the main U-boot distribution at /Projects/RK3328/sources/u-boot. I have used this to build U-boot for the RK3328. If I decide I want to do a build for the h5, I see that there is a file configs/orangepi_pc2_defconfig as well as nanopi_neo2_defconfig. The device trees for these are as follows and are full of useful and interesting information. 

cd arch/arm/dts
sun50i-h5-orangepi-pc2.dts
sun50i-h5-nanopi-neo2.dts
sun50i-h5.dtsi
sun50i-h5-cpu-opp.dtsi
Just for the record, I see these entires for the PC2: 
&emac {
    pinctrl-names = "default";
    pinctrl-0 = <&emac_rgmii_pins>;
    phy-supply = <®_gmac_3v3>;
    phy-handle = <&ext_rgmii_phy>;
    phy-mode = "rgmii-id";
    status = "okay";
};

&external_mdio {
    ext_rgmii_phy: ethernet-phy@1 {
        compatible = "ethernet-phy-ieee802.3-c22";
        reg = <1>;
    };
};
Grepping in the configs directory for "sun50i-h5" yields an interesting list, including the (but we are drifting off topic). 
bananapi_m2_plus_h5_defconfig
nanopi_neo2_defconfig
nanopi_neo_plus2_defconfig
nanopi_r1s_h5_defconfig
orangepi_pc2_defconfig
orangepi_prime_defconfig
orangepi_zero_plus2_defconfig
orangepi_zero_plus_defconfig

OK, but what about the driver?

There are two candidates: 
sun8i_emac.c
sunxi_emac.c
The sunxi driver says it is for the Allwinner A10 chip, and the register layout does not match the H3/H5 at all, so this is not what we want.

The file sun8i_emac.c is exactly what we want. It has 929 lines of code. It does not use a C structure for device registers as I do, but it does a scheme like this. (Interestingly the sunxi_emac.c driver uses a scheme with a C structure like I prefer to do). 

#define EMAC_RX_DMA_DESC    0x34
#define EMAC_MII_CMD        0x48
#define EMAC_MII_DATA       0x4c
writel((uintptr_t)&desc_table_p[0], (priv->mac_reg + EMAC_RX_DMA_DESC));
It does use a structure for the ring descriptors: 
struct emac_dma_desc {
    u32 status;
    u32 ctl_size;
    u32 buf_addr;
    u32 next;
} __aligned(ARCH_DMA_MINALIGN);
Note that the alignment restriction puts these on 64 byte boundaries, even though each descriptor is only 16 bytes in size. There is no problem with this (and it must be done apparently). The next pointer can point anywhere, and in theory these could be scattered all through memory if aligned properly. To set the "next" field, the following code is used: 
	desc_p->buf_addr = (uintptr_t)&rxbuffs[i * CFG_ETH_BUFSIZE];
	desc_p->next = (uintptr_t)&desc_table_p[i + 1];
typedef unsigned long int uintptr_t;
Indeed this casting works just fine on my 64 bit compiler and I can write this, which is entirely portable between 32 and 64 bit ARM. 
edp->next = (unsigned long) &edp[1];
I see some interesting cache handling code, such as this: 
invalidate_dcache_range(data_start,
                data_start + roundup(length, ARCH_DMA_MINALIGN));

Building U-Boot

Here is the scheme to build for the RK3328, edited to build for the H5 board. I skip BL31 for now, as I would have to build that separately first. 
cd /Projects/RK3328/sources/u-boot
## export BL31="/Projects/OrangePi/r1plus/sources/arm-trusted-firmware/build/rk3328/debug/bl31/bl31.elf"
export CROSS_COMPILE=aarch64-linux-gnu-
export LOCALVERSION="trebisky"
cd u-boot
make clean
## make orangepi-r1-plus-lts-rk3328_defconfig
make orangepi_pc2_defconfig
make >../h5build
The build fails due to the missing bl31 (as we knew it would), but not without giving us a useful list of files in the build log

Also worth remembering is that it leaves "bread crumbs" throughout the source tree in the form of *.o files.

In particular, only these files in drivers/net are compiled. We know this board has a realtek RTL8211E phy, but no driver specific to that is compiled. It must support the default Phy command set and require no specific driver. 
  CC      drivers/net/phy/phy.o
  CC      drivers/net/sun8i_emac.o
  CC      drivers/phy/phy-uclass.o

Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org