Date: Sat, 9 Jun 2007 13:27:59 +0200 From: Bernd Walter <ticso@cicely12.cicely.de> To: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= <bkoenig@alpha-tierchen.de> Cc: arm@freebsd.org, ticso@cicely.de Subject: Re: if_ate handles the bytes of the MAC address in a "wrong" order Message-ID: <20070609112758.GH16463@cicely12.cicely.de> In-Reply-To: <58807.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181386624.squirrel@webmail.alpha-tierchen.de> References: <53385.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181314300.squirrel@webmail.alpha-tierchen.de> <20070608.120902.-399284744.imp@bsdimp.com> <20070608225912.GB16463@cicely12.cicely.de> <63859.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181372440.squirrel@webmail.alpha-tierchen.de> <20070609092708.GE16463@cicely12.cicely.de> <58807.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181386624.squirrel@webmail.alpha-tierchen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 09, 2007 at 12:57:04PM +0200, Björn König wrote:
> Bernd schrieb:
> > On Sat, Jun 09, 2007 at 09:00:40AM +0200, Björn König wrote:
> >> [...] I think it's inappropriate and confusing to talk
> > I also prefer to talk about first, sendond, ... byte, but the order is
> > important to understand the datasheet.
> > The datasheet is clear that the first 4 bytes belong into the first
> > register, but it doesn't tell anything about the order of the bytes
> > within the registers.
>
> They do, they give a hint:
>
> "The first bit (i.e., the LSB of the first byte) of the destination
> address is the group/individual bit and is set one for multicast addresses
> and zero for unicast. This bit corresponds to bit 24 of the first word of
> the specific address register. The MSB of the first byte of the
> destination address corresponds to bit 31 of the specific
> address register."
Mmhh - you seem to be right about the bit 24 thing.
But then they put the first 4 bytes into the register they've named the
low one.
The datasheet is inconsistent here and this wouldn't be the first wrong
point in there - originaly the datasheet had completely wrong layout
for the status registers and the MCI part had errors in it as well.
The text in the datasheet is based on their EMAC ASIC core description
and obviously inserted without proper review.
In short: I don't trust the bit 24 description.
Why should it work if we fill the registers wrong?
This influences the receive filter, so it shouldn't receive packets
for it's own MAC if setup wrong.
FreeRTOS sample for AT91SAM7X256 does the same order:
static void prvSetupMACAddress(void)
{
/* Must be written SA1L then SA1H. */
AT91C_BASE_EMAC->EMAC_SA1L = ((unsigned portLONG) cMACAddress[3] << 24 ) |
((unsigned portLONG) cMACAddress[2] << 16) |
((unsigned portLONG) cMACAddress[1] << 8) |
cMACAddress[0];
AT91C_BASE_EMAC->EMAC_SA1H = ((unsigned portLONG) cMACAddress[5] << 8 ) |
cMACAddress[4];
}
The datasheet for the SAM7X prove this code with an explizit sample.
But the SAM7X have sightly better EMAC hardware, so it doesn't have to
be the same as the one in RM9200.
--
B.Walter http://www.bwct.de http://www.fizon.de
bernd@bwct.de info@bwct.de support@fizon.de
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070609112758.GH16463>