Re: MI SONIC Ethernet driver for mac68k

Thanks for tests, 

stixstix.id.au wrote:

> Ok, tried that, no change that I can see.

Hmm. We have to investigate which difference causes the
problem..

> Dumping out the CAMs on the live system with gdb, the
first two appear
> to contain "something". If read as
little-endian int16's, the first is
> the local MAC address (08:00:07:2e:2f:74).

CAM entries are set up in
dev/ic/dp83932.c:sonic_set_camentry() function,
and the first entry will have the host's adress by the
following line:
        /* Put our station address in the first CAM slot.
*/
        sonic_set_camentry(sc, entry,
CLLADDR(ifp->if_sadl));
As you can see in the function, MAC address values are
stored
in LSB first, and htosonic32() or htosonic16() (defined in
dp83932var.h)
do nothing if both the host and Sonic chip are in big
endian.
So values in the first entry are written correctly.

> The second is
> 01:00:5e:00:ff:00 which I don't recognise.

If you don't setup any multicast address, the only first
entry
(which contains host's address) is set up and the number of
"entry" is 1.
With a quick grance at the sonic's manual, the Sonic chip
requires
the "camvalid" value after the last cda
descriptors, so in that case
the necessary value is "1" at the first uint16_t
member (cda_entry)
in the second cda structure.
So, I can't see any particular problem in the values, but
there are
still some difference between old MD mac68k/dev/if_sn.c and
current MI dp83932.c around CAM code:

1) MD one zero'ed out CAM table first
   (current one doesn't so you saw the garbages in unused
region)
2) MD one always wrote "16" to the CDC register
for an entry number
   and zero'ed out unused entries
3) MD one wrote the RCR register before CAM was programmed

I'll check DP83932 manual and see which sequences are
proper.
Maybe there are some quirks among revisions since
my CS slot one works fine with current MI code..
---
Izumi Tsutsui