[U-Boot] ColdFire/M68K board.c initialization / order matters [PATCH] -- resent in git format

[Michael Durrant <mdurrant@arcturusnetworks.com>]

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
>
>