From owner-freebsd-arm@FreeBSD.ORG Mon Dec 17 21:21:23 2007 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB3E616A417 for ; Mon, 17 Dec 2007 21:21:23 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from mail.semihalf.com (mail.semihalf.com [83.15.139.206]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4CA13C455 for ; Mon, 17 Dec 2007 21:21:23 +0000 (UTC) (envelope-from raj@semihalf.com) Received: from localhost (unknown [127.0.0.1]) by mail.semihalf.com (Postfix) with ESMTP id EF4571448C; Mon, 17 Dec 2007 22:25:06 +0100 (CET) Received: from mail.semihalf.com ([127.0.0.1]) by localhost (mail.semihalf.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07542-02; Mon, 17 Dec 2007 22:25:05 +0100 (CET) Received: from [77.113.50.146] (apn-77-113-50-146.gprs.plus.pl [77.113.50.146]) by mail.semihalf.com (Postfix) with ESMTP id 30D95145AB; Mon, 17 Dec 2007 22:25:04 +0100 (CET) Message-ID: <4766E845.50304@semihalf.com> Date: Mon, 17 Dec 2007 22:21:09 +0100 From: Rafal Jaworowski MIME-Version: 1.0 To: Stanislav Sedov References: <20071213222654.GE17356@dracon.ht-systems.ru> <20071214090128.GM31230@cicely12.cicely.de> <20071214115226.0b2cb7e2@peedub.jennejohn.org> <20071214.062511.74732956.imp@bsdimp.com> <20071214153201.18c4c5ea@peedub.jennejohn.org> <47629E53.30404@semihalf.com> <20071214190825.GG17356@dracon.ht-systems.ru> In-Reply-To: <20071214190825.GG17356@dracon.ht-systems.ru> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at semihalf.com Cc: freebsd-arm@freebsd.org Subject: Re: MMC cards support 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: Mon, 17 Dec 2007 21:21:23 -0000 Stanislav Sedov wrote: > On Fri, Dec 14, 2007 at 04:16:35PM +0100 Rafal Jaworowski mentioned: >> We're probably getting a bit OT here, but just to clarify U-Boot networking >> model of operation that was mentioned: MAC address is usually programmed by a >> U-Boot network controller driver into relevant h/w registers upon every >> network access, so provided a given interface was used at least once in U-Boot >> (whatever net command), it should have the MAC addresss programmed correctly >> when running in the kernel. Otherwise it is left untouched, which happens in >> most of the cases with multiple integrated controllers -- usually only the >> first one gets ever used, others are left unconfigured... >> > > Well, I downloaded the entire kernel via tftp, so the controller was probably > configured correctly. Probably, u-boot resets it after transfer (have not checked > this yet). > Typically U-Boot would not reset the MAC address, at least I'm not aware of any net driver there that would do so. I had a look at AT91 net driver and the whole picture is quite confusing: - U-Boot net driver programs the address into EMAC_SA2L/EMAC_SA2H - FreeBSD/arm tries to retrieve it from ETH_SA1L/ETH_SA1H I don't know AT91 family, so am not sure which one should be used and where the above disconnect comes from (some byte ordering confusion?), but this might be the direct cause of your troubles.. > The idea of bd_t support looks promising anyway, especially if we'll continue our > expansion in the embedded world (almost all powerpc and arm embedded boards are > moving toward using u-boot exclusively). This way we'll get a good cooperation > with another projects. I'll look into this after I get ate0 and usb working. > Well, the bd_t struct is very much platform/architecture dependent, even within the same arch it can vary *a lot* depending on family member (see the PowerPC version of bd_t), so it does not provide a uniform interface. For this reason (among others) we came up with this new API that was mentioned in one of the previous emails. So far it has been integrated with embedded FreeBSD/powerpc running off U-Boot, but is designed and implemented so it can be used with ARM, MIPS etc. with minimal effort: only a lowest layer glue is dependent on the arch. If you're interested in details, the FreeBSD-U-Boot interface topic is just being discussed on the u-boot-users ML. Rafal