[Arm-netbook] Mele A1000 ethernet

[lkcl luke]

On Wed, Jul 25, 2012 at 1:23 AM, Jorgen Lundman <lundman at lundman.net> wrote:
>
>
>>   so the subtle changes in registers etc. may be to do with how they
>> had to connect the "standard" DM9000 circuits onto an AHB/AMBA bus.
>> is there a lot of zero-padding for example?  i haven't looked at the
>> code, but are the registers by any chance all addressed as 8-bit
>> quantities spaced out on 32-bit or 64-bit boundaries with zeros in
>> between?  if so, it means that they literally just dropped the
>> DM9000's 8-bit bus directly onto a 32-bit (or 64-bit) AHB/AMBA data
>> bus!
>>
>
> That was indeed my thought when working with both sources. dm9000 would
> write a byte, on 8 bit alignment. Whereas wemac would write a byte on 32bit
> alignment, and leave 3 bytes alone. (sometimes)
>
> All calls used are indeed readl/writel, and the register offsets in the
> header is nicely *4.  Suppose that explains nicely why dm9000 and wemac
> registers do differs (but perhaps not as badly as I initially thought)

 if it's truly the same silicon circuit underneath they won't have
gone to the trouble of changing the logic significantly: it's just too
costly in verification time alone.  the less modifications of
previously-verified IC circuits the better, it's why they all buy
off-the-shelf hard macros in the first place.

> It even writes the MAC address with 32bit calls, and not like the dm9000
> with a byte at a time.

 well, the scenario i envisaged was one where they had not done any
kind of buffering.  if however they spent a little bit more time and
effort on this then they could well be doing something nice, such as
taking a 32-bit write and then carrying out 4 8-bit writes, or perhaps
even better they threw away the 8-bit parallel bus engine that is
normally used by a DM9000 IC and accessed its internal registers
directly: who knows, really - we only have the code known as wemac to
go on.

l.