[U-Boot-Users] [PATCH] ARM: add support of CONFIG_LAST_STAGE_INIT for arm
Ben Warren
bwarren at qstreams.com
Mon Dec 10 21:28:40 CET 2007
Haavard Skinnemoen wrote:
> On Sun, 09 Dec 2007 17:38:13 +0100
> Michael Schwingen <rincewind at discworld.dascon.de> wrote:
>
>
>> If we could move board_late_init after eth_initialize (ie. directly
>> before calling main_loop), that would work in my case, and would remove
>> the necessity for my reset_phy patch.
>>
>
> Or even better, move eth_initialize into the board code. That would
> allow us to kill a ridiculous number of #ifdefs in net/eth.c and would
> allow the board to do any fixups it needs before and after the generic
> code.
>
>
eth_initialize() is definitely a mess, but I don't think moving it to
board code is the right thing to do. On the other hand, one thing I've
been thinking about was a new eth_initialze() that steps through an
array of board-defined controller configurations. This way we could
specify all sorts of information about controller type, PHY type,
addresses etc. on a per-controller basis, and of course provide default
macros to abstract away the mundane.
More to the problem seen here - IMHO, a MAC's initialize() function
shouldn't do anything other than populate and register one or more
ethernet devices with the network subsystem. Any PHY initialization
stuff should happen in the specific driver's init() function, which only
gets called when the port is used. If you want to do initialization of
any aspect of a controller that isn't used by u-boot, it should be in
board-specific init code, and there should be a board-instantiable
global function that is guaranteed to be after all the common code
(immediately before the main loop begins). I haven't looked at the code
in a while, but I gather one of the problems here was that
board_late_init() (or whatever it's called) comes before
eth_initialize(). If that's really the case, we need a
board_really_late_init().
Thoughts?
regards,
Ben
More information about the U-Boot
mailing list