[U-Boot] Commit ecee9... (Program net device MAC addresses after initializing) breakage

Kumar Gala galak at kernel.crashing.org
Mon Nov 8 15:38:39 CET 2010


On Nov 6, 2010, at 5:13 PM, Graeme Russ wrote:

> Hi All,
> 
> I finally got a few spare hours to do some U-Boot hacking and to my dismay
> found the build for my board (eNET) had broken. It builds OK, but crashed
> during Ethernet initialisation. I tried winding back to a last known good
> commit without much luck.
> 
> I realised I had upgraded to Ubuntu 10.10 lately, and thought maybe a
> tool-chain change was the culprit (was running gcc-4.4.1 and binutils 2.19
> from source, now running Ubuntu gcc 4.4.5 and Binutils 2.20)
> 
> But, I think that commit ecee9324d73555e744593f3e0d387bec4c566f55 may be
> 'not quite right'. My board uses the rtl8139 driver, and the following
> patch gets my board booting again:
> 
> diff --git a/drivers/net/rtl8139.c b/drivers/net/rtl8139.c
> index db8a727..3646148 100644
> --- a/drivers/net/rtl8139.c
> +++ b/drivers/net/rtl8139.c
> @@ -229,6 +229,7 @@ int rtl8139_initialize(bd_t *bis)
>                dev->halt = rtl_disable;
>                dev->send = rtl_transmit;
>                dev->recv = rtl_poll;
> +               dev->write_hwaddr = NULL;
> #ifdef CONFIG_MCAST_TFTP
>                dev->mcast = rtl_bcast_addr;
> #endif
> 
> Just before this code we see that dev is malloc'd:
> 
> dev = (struct eth_device *)malloc(sizeof *dev);
> 
> So there is no guarantee that dev is NULL'd.
> 
> Has anyone else run into similar problems?
> 
> I saw discussion a little while ago regarding implementing a version of
> malloc that returns cleared memory - did this gain any traction?

I believe we are seeing similar behavior w/e1000 driver.

- k


More information about the U-Boot mailing list