Hi Ben, > Hi Detlev, > > On Wed, Mar 31, 2010 at 6:44 AM, Detlev Zundel <d...@denx.de> wrote: > > Hi Ben, > > > Hold on a second. This patch is wrong. As Mike has pointed out, the > > net library already gets the MAC address from the environment. The > > correct flow is: > > > > 1. Read from hardware in initialize() function > > 2. Read from environment in net/eth.c after initialize() > > 3. Give priority to the value in the environment if a conflict > > 4. Program hardware in the device's init() function. > > > > If somebody wants to subvert the 'design philosophy', the right way is > > to call eth_dev->init() in board code. > > This would mean that for the real problem of a missing mac address, the > device then is initialized completely adding the autonegotation timeout > to every bootup sequence, correct? > > > My suggestion here is a crude hack, and definitely does more than needed. It > has the advantage of having narrow scope (is limited to the board in > question).
This specific problem in the meantime hit me on multiple arm boards with different network interfaces so I think it has a broader audience than a single board. > If it is, then it doesn't solve my problem in an acceptable way. On the > other hand a different route occured to Wolfgang and me in a lengthy > discussion. This will need a little broader interpretation of the > design guidelines, but as I still cannot see any downside to this and it > will also fix some inconsistent behaviour _that we currently have_ > ("setenv ethaddr ...", do not do any network transfer and boot linux), I > want to follow this route. > > I will try to implement this in form of a patch in order to keep the > discussion close to the effects on the code base. > > > I'm looking forward to seeing what you come up with. I personally don't have > a > problem with adding the few ns to boot-up time that programming an SOC's MAC > would take, but dislike the piece-meal approach that's been done so far. I fully agree. Previously I was under the impression that we already have a "fast initialization" (probe) and a "full initialization" (init) of the network interfaces, where programming the mac would (on a first stab) fit into the probe part (and some drivers obviously do/did this). In the meantime it seems like it is a broader problem of keeping "ethaddr" and friends in sync with the real hardware. Although this is something I personally always took for granted, it currently is most of the time but not always correct. If we solve the latter problem in a nice way, the initial problem will simply disappear (or so I hope) ;) Cheers Detlev -- You live and learn -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot