Ben Warren wrote: > Michael Durrant wrote: >> Ben Warren wrote: >> >>> Hi Michael, >>> >>> Michael Durrant wrote: >>> >>>> lib_m68k_board.patch >>>> - eth_init() requires eth_current which is initialized in >>>> eth_initialize() >>>> so eth_initialize (bd) should be called first then eth_init(bd) >>>> >>>> >>> Actually, eth_init() shouldn't be called in board.c at all. >>> >> >> Ok. I am open to suggestions here. >> >> Here is our rational for the change. We moved the eth_init() >> previously before eth_initialize (bd) to after as the eth_initialize >> over writes the current pointer. Our usage case is to ensure >> the Ethernet MAC address is retrieved from the eeprom and >> is used to initialized into the FEC registers in the MCF5282 >> before executing the customers application code. >> Since MAC initialization normally only happens when u-boot >> makes use of the Ethernet for network services such as ping >> or tftp we saw using eth_init() in board.c as an easy way to >> ensure the FEC registers are set up. >> >> > U-boot policy is that unused hardware is also un-initialized. In your > instance, if you're not going to use the network controller in U-boot, > you don't get to program its MAC address. You'll find this has been > discussed ad nauseum on this mailing list. > > Your options are to either use the FEC or read the EEPROM in the > customer application. Thanks for the feedback. I agree with supporting the existing policy. That said ... both Microblaze and Coldfire/M68K call eth_init() in board.c already.
Regards, Michael Durrant >> Regards, >> Michael Durrant >> >> > regards, > Ben > > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot