ColdFire/M68K board.c initialization / order matters [PATCH]
This patch set created against u-boot-2009.11 release
lib_m68k_board.patch
- eth_init() requires eth_current which is initialized ineth_initialize()
so eth_initialize (bd) should be called first then eth_init(bd)
--
Michael Durrant
mdurrant at arcturusnetworks.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lib_m68k_board.patch
Type: application/octet-stream
Size: 574 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20100119/cb53aa97/attachment.obj
[U-Boot] ColdFire/M68K board.c initialization / order matters [PATCH] -- resent in git format
lib_m68k_board.patch
- eth_init() requires eth_current which is initialized ineth_initialize()
so eth_initialize (bd) should be called first then eth_init(bd)
--- lib_m68k/board.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-)
lib_m68k/board.c +3 -3
@@ -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
[U-Boot] ColdFire/M68K board.c initialization / order matters [PATCH] -- resent in git format
Hi Michael,
Quoted 6 lines · Michael Durrant
lib_m68k_board.patch
-eth_init()requireseth_currentwhich is initialized ineth_initialize()
soeth_initialize(bd) should be called first theneth_init(bd)
Actually, eth_init() shouldn't be called in board.c at all.
regards,
Ben
[U-Boot] ColdFire/M68K board.c initialization / order matters [PATCH] -- resent in git format
Quoted 10 lines · Ben Warren
Hi Michael,
Quoted 6 lines · Michael Durrant
lib_m68k_board.patch
-eth_init()requireseth_currentwhich is initialized ineth_initialize()
soeth_initialize(bd) should be called first theneth_init(bd)Actually,
eth_init()shouldn't be called inboard.cat 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
Quoted 2 lines
regards,
Ben
[U-Boot] ColdFire/M68K board.c initialization / order matters [PATCH] -- resent in git format
Quoted 25 lines · Michael Durrant
Quoted 4 lines · Ben Warren
Hi Michael,
Michael Durrant wrote:
Quoted 9 lines
Quoted 7 lines
lib_m68k_board.patch
-eth_init()requireseth_currentwhich is initialized ineth_initialize()
soeth_initialize(bd) should be called first theneth_init(bd)Actually,
eth_init()shouldn't be called inboard.cat all.Ok. I am open to suggestions here.
Here is our rational for the change. We moved the
eth_init()previously beforeeth_initialize(bd) to after as theeth_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.
Quoted 6 lines
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()inboard.cas 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.
Quoted 4 lines
Regards,
Michael Durrant
regards,
Ben
[U-Boot] ColdFire/M68K board.c initialization / order matters [PATCH] -- resent in git format
Quoted 30 lines · Ben Warren
Quoted 17 lines · Michael Durrant
Quoted 4 lines · Ben Warren
Hi Michael,
Michael Durrant wrote:
Quoted 8 lines
Quoted 6 lines
lib_m68k_board.patch
-eth_init()requireseth_currentwhich is initialized ineth_initialize()
soeth_initialize(bd) should be called first theneth_init(bd)Actually,
eth_init()shouldn't be called inboard.cat all.Ok. I am open to suggestions here.
Quoted 12 lines
Here is our rational for the change. We moved the
eth_init()previously beforeeth_initialize(bd) to after as theeth_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 usingeth_init()inboard.cas an easy way to ensure the FEC registers are set up.
Quoted 7 lines
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
Quoted 8 lines
Quoted 4 lines
Regards,
Michael Durrantregards,
Ben