January 12, 2026

Kyu - network - give the H5 emac driver a try

I am hoping that we will inherit the PHY setup from U-Boot and the H3 driver will "just work" and receive some packets.

The first thing to do is to edit h5/board.h (board/board.h) and uncomment WANT_NET. Then make clean ; make and reboot.
We get this: 

BSD panic: tcp_init
This comes from tcp_init() in tcp_bsd/tcp_subr.c It has nothing to do with the emac driver. A sanity check is testing the size of the tcpiphdr structure. We will need to look at this someday. It has to do with either types or alignment on arm64.

Build Kyu without TCP

I add a fourth option WANT_TCP_NONE to kyu.h and rebuild. I get a synchronous abort. I can almost guess why. A null pointer in tcp_ops. I will need to supply a routine to initialize the tcp_ops structure with pointers to stub routines for tcp_NONE.

I do this and now I can compile and boot up Kyu without error!
I get a variety of messages from the EMAC driver as it initializes. 

n 1 - gives me basic statistics
n 11 - gives me the "debug" with full display of the rings.

Not receiving packets yet

I have an idea about this. The emac itself has a register where you set the negotiated speed and duplex. The usual idea is that you talk to the PHY chip and find out what was agreed on during autonegotiation, and then set these values in the emac register. I am just setting a constant value based on what worked with the H3 board I first used to get this running.

An easy and foolproof way to find out what was negotiated is to look at the LED on my network switch! I look and see that 1000 Mbit has been arranged, and this surely is not what has been set for the emac chip.

When Kyu starts up, it prints: 

emac CTL0 = 00000001
This register has only 4 defined bits. 
bit 0 -- 1 is full duplex
bit 1 -- 0 is loopback off
bits 3:2 -- 00 is 1000 Mbit
So this looks correct. I never set values in this register myself. I am not getting data. But I see this message once: 
emac interrupt --   status:40000127
This must happen right after I write to the emac int_ena register to enable interrupts. Experiment shows that it happens before I enable the Rx or Tx units. After I add some delay, I see a second interrupt after I enable Rx and TX: 
emac interrupt --   status:4000002b
The upper "4" is undefined. In the first interrupt, 0x100 is a Rx interrupt. The lower 8 bits are all related to Tx.

Have any comments? Questions? Drop me a line!

Tom's electronics pages / tom@mmto.org