From owner-freebsd-arm@FreeBSD.ORG Sat Jun 9 10:57:11 2007 Return-Path: X-Original-To: arm@freebsd.org Delivered-To: freebsd-arm@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2DDB116A400 for ; Sat, 9 Jun 2007 10:57:11 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de (mail.smartterra.de [195.225.132.203]) by mx1.freebsd.org (Postfix) with ESMTP id B6FB113C4B0 for ; Sat, 9 Jun 2007 10:57:10 +0000 (UTC) (envelope-from bkoenig@alpha-tierchen.de) Received: from mail.liberty-hosting.de ([195.225.132.203]) by localhost (liberty-mail [195.225.132.203]) (amavisd-new, port 10024) with ESMTP id 54378-05; Sat, 9 Jun 2007 12:57:06 +0200 (CEST) Received: from home.alpha-tierchen.de (port-212-202-170-5.dynamic.qsc.de [212.202.170.5]) by mail.liberty-hosting.de (Postfix) with ESMTP id 3B8731807B8; Sat, 9 Jun 2007 12:57:06 +0200 (CEST) Received: from webmail.alpha-tierchen.de (localhost [127.0.0.1]) by home.alpha-tierchen.de (Postfix) with ESMTP id AAB5045046; Sat, 9 Jun 2007 12:57:04 +0200 (CEST) Received: from 2001:6f8:101e:0:20e:cff:fe6d:6adb (SquirrelMail authenticated user bkoenig) by webmail.alpha-tierchen.de with HTTP; Sat, 9 Jun 2007 12:57:04 +0200 (CEST) Message-ID: <58807.2001:6f8:101e:0:20e:cff:fe6d:6adb.1181386624.squirrel@webmail.alpha-tierchen.de> In-Reply-To: <20070609092708.GE16463@cicely12.cicely.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> Date: Sat, 9 Jun 2007 12:57:04 +0200 (CEST) From: =?iso-8859-1?Q?Bj=F6rn_K=F6nig?= To: ticso@cicely.de User-Agent: SquirrelMail/1.4.10a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at mail.smartterra.de Cc: arm@freebsd.org Subject: Re: if_ate handles the bytes of the MAC address in a "wrong" order X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jun 2007 10:57:11 -0000 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 >> about a most and least significant byte for the purpose of endianess. > > You started with it and you were wrong. Maybe my very first mail was capable of being misunderstood. I just repeated Atmel's specification and I think I did it correctly. It was neither my concern to talk about endianess nor to talk about right or wrong. It does not belong to this issue, because finally it doesn't matter how Atmel want to read and write the MAC address to the registers since it is their specification and they are allowed to specify whatever they want regarding their hardware. They even are allowed to expect that the six bytes are stored in the order ([6][-][1][4])([3][2][-][5]). > 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." low register: [ 31 ][ 30 ][ 29 ][ 28 ][ 27 ][ 26 ][ 25 ][ 24 ] 8 7 6 5 4 3 2 1 This is what they said (register bit in brackets, below the bit of the MAC address # 1-48 in transmission order). That consecutively means for the low register: [ 23 ][ 22 ][ 21 ][ 20 ][ 19 ][ 18 ][ 17 ][ 16 ] 16 15 14 13 12 11 10 9 [ 15 ][ 14 ][ 13 ][ 12 ][ 11 ][ 10 ][ 9 ][ 8 ] 24 23 22 21 20 19 18 17 [ 7 ][ 6 ][ 5 ][ 4 ][ 3 ][ 2 ][ 1 ][ 0 ] 32 31 30 29 28 27 26 25 Consequently you should fill the high register this way: [ 15 ][ 14 ][ 13 ][ 12 ][ 11 ][ 10 ][ 9 ][ 8 ] 40 39 38 37 36 35 34 33 [ 7 ][ 6 ][ 5 ][ 4 ][ 3 ][ 2 ][ 1 ][ 0 ] 48 47 46 45 44 43 42 41 Personally I don't want that because it requires changes in *all* Loaders as well as in FreeBSD and Linux drivers and so on. > The loader should be fixed and the kernel shouldn't change it, which > requires the read function to be fixed. I just want the ate driver's get function to be fixed according to its own set function. Nothing else. The loader don't need to be changed. Regards Björn