Date: Fri, 8 Jun 2007 16:51:40 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= <bkoenig@alpha-tierchen.de> To: arm@freebsd.org Subject: if_ate handles the bytes of the MAC address in a "wrong" order Message-ID: <53385.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181314300.squirrel@webmail.alpha-tierchen.de>
next in thread | raw e-mail | index | archive | help
Hello, while reading code of the at91 ethernet driver (ate) I noticed that it uses an order of the MAC address registers which is not intended by Atmel. In FreeBSD you typically store the MAC address in an array of six octets, for example uint8_t eaddr[] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06 }; which will be represented as 01:02:03:04:05:06 (transmission order) . 0x01 is the most significant byte and 0x06 the least significant byte. The least significant bit of the most significant byte is the group/individual bit. So far so good. That's the theory. The specification of the Atmel AT91RM9200 controller clearly says something about how to store the MAC address in the two address registers (section 36.5.5, page 602). In fact that the first four bytes (01:02:03:04) are stored in the low register and the last two bytes (05:06) in the high register. Furthermore they write that the group/individual bit corresponds with with bit 24 of the address register which means that they really want that you store first byte in the low register, because bit 24 of the high register is unused. So the correct code would store the low register in eaddr[0-3] and the high register in eaddr[4-5], but actually the ate_get_mac function in src/sys/arm/at91/if_ate.c uses another order. This won't hurt as long as you use a loader that stores the bytes the same way as the driver read them. I wouldn't care if I wouldn't have this problem: Linux and the U-Boot loader stores the bytes it in a manner that is different from the FreeBSD method and also different from Atmel's suggestion. What do you think? Regards Björn
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53385.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181314300.squirrel>