Re: MI SONIC Ethernet driver for mac68k

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

Thanks for tests, 

stix%stix.id.au@localhost 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