[U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27

Ben Warren biggerbadderben at gmail.com
Thu Nov 19 04:30:14 CET 2009


Alfred,

On Wed, Nov 18, 2009 at 5:54 PM, alfred steele <alfred.jaquez at gmail.com>wrote:

> On Mon, Nov 16, 2009 at 8:59 PM, Ben Warren <biggerbadderben at gmail.com>
> wrote:
> > Hi Alfred,
> >
> > alfred steele wrote:
> >>>
> >>> Thanks for your submission!
> >>>
> >>
> >> What is the current design on the mxc fec interface's attainment of a
> >> MAC address. From the kernel driver it looks like it looks at the
> >> IIM(IC identification registers) on the MXC platform(like mx51/35) to
> >> look for a programmed mac address and then the set the fec mac to the
> >> same .
> >>
> >> Looks like with the current mxc_fec driver there is not support for
> >> the same. I am thinking of a mechanism to hardcode a fake MAC which
> >> would subsequently be picked up by the kernel without using the
> >> bd_info structure.
> >> Any comments/suggestions?
> >>
> >> -Alfred.
> >>
> >
> > I don't know much about this driver, but it appears to be doing things
> > incorrectly.  The correct flow is as follows.  It is documented in
> > 'doc/README.enetaddr':
> >
> > 1. The driver's initialize() function read from NVRAM if available.  MAC
> > address is stuffed into dev->enetaddr.  The initialize() function should
> not
> > try to get the address from the environment, which is where the imx27
> driver
> > goes wrong.
> > 2. After all drivers have been initialized, eth_initialize() ( in
> net/eth.c)
> > reads from the environment.  If the value in the environment is valid and
> > the value in dev->enetaddr is valid and both are different, the user is
> > warned.  The value in the environment overwrites the value in
> dev->enetaddr
> > 3. When a network operation is performed, the driver's init() function is
> > called, which is where the address is programmed into the device.
> >
> > As you can see, if the device is never used, step 3 is never exected and
> the
> > device is never programmed.  This is how it's supposed to work, since the
> > U-boot design philosophy dictates that hardware is never touched unless
> it
> > is used in U-boot.  I'm pretty sure hard-coding a fake MAC address would
> run
> > afoul of this rule.
> Is there a way to pass the information to kernel using either the
> dev->enetaddr  without programming the IIM module register. Would i
> have to use bd_info structure or can we do without it.? This problem
> is specific to the mx27 i guess.
> -Alfred
>
I'm pretty sure it's a much-discussed ARM peculiarity.  Not at all my area
of expertise, so I'll leave it to others to suggest options.

regards,
Ben


More information about the U-Boot mailing list