Date: Mon, 17 Dec 2007 22:21:09 +0100 From: Rafal Jaworowski <raj@semihalf.com> To: Stanislav Sedov <stas@FreeBSD.org> Cc: freebsd-arm@freebsd.org Subject: Re: MMC cards support Message-ID: <4766E845.50304@semihalf.com> In-Reply-To: <20071214190825.GG17356@dracon.ht-systems.ru> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4766E845.50304>