struct emac_desc {
volatile unsigned long status;
long size;
char * buf;
struct emac_desc *next;
} __aligned(ARM_DMA_ALIGN);
This is perfectly fine on a 32 bit system where a long is 32 bits and
where all pointers are 32 bits. The observant reader will notice that
every entry in this structure will become a 32 bit object on a 64 bit system.
No wonder the emac driver fails entirely on the 64 bit H5 chip!
We peek at sun8i_emac.c (the U-Boot driver) and see this:
struct emac_dma_desc {
u32 status;
u32 ctl_size;
u32 buf_addr;
u32 next;
} __aligned(ARCH_DMA_MINALIGN);
And that will certainly work properly.
We know now where our problem lies.
First I changed the structure, using my own set of typedefs. I rebuilt it for the h3 (32 bit) letting the compiler show me things it wanted me to specify casts for. Then I booted Kyu with these changes and it seems to work fine on the h3.
When I try to compile for the h5, I get a multitude of these warnings:
emac.c: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] emac.c: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
This if course makes perfect sense. The compiler does not know how to turn a 32 bit integer into a 64 bit pointer or vice-versa. On this chip, all addresses actually fit into 32 bits, and the upper 32 bits would be zeros -- but the compiler does not know this.
I ignore the warnings and just try to run it. I discover some debug code that I put in to drop packets for the H5. After removing this, it seems to work! I test it both ICMP and DNS and they both work. I can suppress the gcc warning by putting this line near the top of emac.c --
#pragma GCC diagnostic ignored "-Wunused-parameter"
Even TFTP works to fetch the Kyu symbol table.
I have another problem. My h3 and h5 both are using the same IP address! This leads to some problems. I unplug my h3 board, power cycle my switch, unplug and replug cables. Finally things seem to get sorted out. The h5 can now ping as well as respond to ping and to make DNS requests.
And some problems show up after a minute or two. I cease being able to send ICMP (and ping "trona" -- my boot host). And ping to the Kyu host stops working -- and then gives spurts of DUP responses. And I get this:
!!! *** Tx ring full, packet not sentThe Rx and Tx rings are each 64 in size, and the trouble seems to start right when some ring fills up.
Tom's electronics pages / tom@mmto.org