[U-Boot] ColdFire/M68K board.c initialization / order matters [PATCH]
Signed-off-by: David Wu davidwu@arcturusnetworks.com Signed-off-by: Michael Durrant mdurrant@arcturusnetworks.com
This patch set created against u-boot-2009.11 release
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)
-- Michael Durrant mdurrant@arcturusnetworks.com
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)
Signed-off-by: David Wu davidwu@arcturusnetworks.com Signed-off-by: Michael Durrant mdurrant@arcturusnetworks.com --- lib_m68k/board.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib_m68k/board.c b/lib_m68k/board.c index 732023d..c17394b 100644 --- a/lib_m68k/board.c +++ b/lib_m68k/board.c @@ -639,13 +639,13 @@ void board_init_r (gd_t *id, ulong dest_ #endif #if defined(CONFIG_CMD_NET) WATCHDOG_RESET(); -#if defined(FEC_ENET) - eth_init(bd); -#endif #if defined(CONFIG_NET_MULTI) puts ("Net: "); eth_initialize (bd); #endif +#if defined(FEC_ENET) + eth_init(bd); +#endif #endif
#ifdef CONFIG_POST -- 1.4.3.4
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.
regards, Ben
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.
Regards, Michael Durrant
regards, Ben
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.
Regards, Michael Durrant
regards, Ben
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
participants (2)
-
Ben Warren -
Michael Durrant