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