Skip to contentSkip to conversation

ColdFire/M68K board.c initialization / order matters [PATCH]

U-Boot Michael Durrant 2 participants 6 messages Jan 19, 2010 – Jan 21, 2010

lore
Share & tools
lore
#0 lore raw

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

#1 lore raw

[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 in
eth_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
index 732023d..c17394b 100644
@@ -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

#2 lore raw

[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() 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

#3 lore raw

[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() 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

Quoted 2 lines

regards,
Ben

#4 lore raw

[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() 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.

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() 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.

Quoted 4 lines

Regards,
Michael Durrant

regards,
Ben

#5 lore raw

[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() 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.

Quoted 12 lines

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.

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 Durrant

regards,
Ben