[U-Boot] ColdFire/M68K board.c initialization / order matters [PATCH] -- resent in git format
Michael Durrant
mdurrant at arcturusnetworks.com
Thu Jan 21 17:12:25 CET 2010
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
>
>
More information about the U-Boot
mailing list