[U-Boot] Enabling smc911x driver

[U-Boot] Enabling smc911x driver

[Steve Sakoman]

I'm attempting to enable the smc911x driver for the overo omap3 board.

Looking at the README and a couple of board config files, it seems
that defining CONFIG_DRIVER_SMC911X,  CONFIG_DRIVER_SMC911X_16_BIT (or
32_BIT), and CONFIG_DRIVER_SMC911X_BASE is all that is required.  I
have also enabled CONFIG_CMD_NET, CONFIG_CMD_DHCP and CONFIG_CMD_PING.

The build completes successfully, but it seems that the driver init is
never called, so I assume I am missing something.

Do I need to add an explicit init call to my board or cpu file?  At
first glance I don't see that other boards are doing this.

Thanks!

Steve

[U-Boot] Enabling smc911x driver

[Ben Warren]

Steve,

Steve Sakoman wrote:
> I'm attempting to enable the smc911x driver for the overo omap3 board.
>
> Looking at the README and a couple of board config files, it seems
> that defining CONFIG_DRIVER_SMC911X,  CONFIG_DRIVER_SMC911X_16_BIT (or
> 32_BIT), and CONFIG_DRIVER_SMC911X_BASE is all that is required.  I
> have also enabled CONFIG_CMD_NET, CONFIG_CMD_DHCP and CONFIG_CMD_PING.
>
> The build completes successfully, but it seems that the driver init is
> never called, so I assume I am missing something.
>
> Do I need to add an explicit init call to my board or cpu file?  At
> first glance I don't see that other boards are doing this.
>
>   
This driver uses the old-style API and so requires board/cpu init code 
to call eth_init().  I'm not familiar with your architecture, so don't 
know how or if this is implemented, but it should be easy to find 
another example that does this.
> Thanks!
>
> Steve
> ________
regards,
Ben

[U-Boot] Enabling smc911x driver

[Steve Sakoman]

On Tue, Apr 21, 2009 at 9:32 AM, Ben Warren <biggerbadderben@gmail.com> wrote:

> This driver uses the old-style API and so requires board/cpu init code to
> call eth_init(). ?I'm not familiar with your architecture, so don't know how
> or if this is implemented, but it should be easy to find another example
> that does this.

Thanks for the hint!  That helped quite a bit.

The hardware uses the new LAN9221 chip, so I needed to add the
following patch to the driver:

diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index 80d2ce0..a756142 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
@@ -378,6 +378,7 @@ static inline void smc911x_reg_write(u32 addr, u32 val)
 #define CHIP_9117	0x117
 #define CHIP_9118	0x118
 #define CHIP_9211	0x9211
+#define CHIP_9221	0x9221
 #define CHIP_9215	0x115a
 #define CHIP_9216	0x116a
 #define CHIP_9217	0x117a
@@ -394,6 +395,7 @@ static const struct chip_id chip_ids[] =  {
 	{ CHIP_9117, "LAN9117" },
 	{ CHIP_9118, "LAN9118" },
 	{ CHIP_9211, "LAN9211" },
+	{ CHIP_9221, "LAN9221" },
 	{ CHIP_9215, "LAN9215" },
 	{ CHIP_9216, "LAN9216" },
 	{ CHIP_9217, "LAN9217" },

Now things seem to initialize properly:

U-Boot 2009.03 (Apr 22 2009 - 07:28:04)

OMAP3503-GP rev 2, CPU-OPP2 L3-165MHz
Gumstix Overo board + LPDDR/NAND
DRAM:  256 MB
NAND:  256 MiB
In:    serial
Out:   serial
Err:   serial
Initializing ethernet smc911x
smc911x: initializing
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 4a:18:56:55:9d:38
Die ID #4a4800020000000004031c1302012001
Hit any key to stop autoboot:  0
Overo #

But the interface doesn't seem to function:

Overo # dhcp
smc911x: initializing
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 4a:18:56:55:9d:38
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5

Retry count exceeded; starting again
<repeats>

I've also tried setting the ip address, net mask, etc explicitly.
This also has issues:

Overo # ping 192.168.0.1
smc911x: initializing
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 4a:18:56:55:9d:38
ping failed; host 192.168.0.1 is not alive

If I allow linux to boot, the net interface functions properly, so I
know that cabling, dhcp server, etc are not an issue.

Any advice on how to debug this?  I don't see any DEBUG flag in the code.

Thanks!

Steve

[U-Boot] Enabling smc911x driver

[Daniel Mack]

On Wed, Apr 22, 2009 at 07:52:40AM -0700, Steve Sakoman wrote:
> Now things seem to initialize properly:
> 
> U-Boot 2009.03 (Apr 22 2009 - 07:28:04)
> 
> OMAP3503-GP rev 2, CPU-OPP2 L3-165MHz
> Gumstix Overo board + LPDDR/NAND
> DRAM:  256 MB
> NAND:  256 MiB
> In:    serial
> Out:   serial
> Err:   serial
> Initializing ethernet smc911x
> smc911x: initializing
> smc911x: detected LAN9221 controller
> smc911x: phy initialized
> smc911x: MAC 4a:18:56:55:9d:38

How did you set this MAC address? Does the hardware read it from a
connected EEPROM or did you manually set it in your environment. If you
face the latter case, you could try applying the patch I sent in some
days ago. Without that patch, the hardware is not made aware of the
configured address and hence the internal filter will drop all
non-broadcast packets it receives.

With this patch applied, however, the LAN9220 chip works well on our own
PXA design.

Maybe that helps.

Daniel

[U-Boot] Enabling smc911x driver

[Daniel Mack]

On Wed, Apr 22, 2009 at 05:51:44PM +0200, Daniel Mack wrote:
> On Wed, Apr 22, 2009 at 07:52:40AM -0700, Steve Sakoman wrote:
> > Now things seem to initialize properly:
> > 
> > U-Boot 2009.03 (Apr 22 2009 - 07:28:04)
> > 
> > OMAP3503-GP rev 2, CPU-OPP2 L3-165MHz
> > Gumstix Overo board + LPDDR/NAND
> > DRAM:  256 MB
> > NAND:  256 MiB
> > In:    serial
> > Out:   serial
> > Err:   serial
> > Initializing ethernet smc911x
> > smc911x: initializing
> > smc911x: detected LAN9221 controller
> > smc911x: phy initialized
> > smc911x: MAC 4a:18:56:55:9d:38
> 
> How did you set this MAC address? Does the hardware read it from a
> connected EEPROM or did you manually set it in your environment. If you
> face the latter case, you could try applying the patch I sent in some
> days ago. Without that patch, the hardware is not made aware of the
> configured address and hence the internal filter will drop all
> non-broadcast packets it receives.

Here's a pointer to the patch:

	http://www.mail-archive.com/u-boot at lists.denx.de/msg12038.html

[U-Boot] Enabling smc911x driver

[Steve Sakoman]

On Wed, Apr 22, 2009 at 8:54 AM, Daniel Mack <daniel@caiaq.de> wrote:

>> How did you set this MAC address? Does the hardware read it from a
>> connected EEPROM or did you manually set it in your environment.

It is manually set in the environment since the prototype hardware
doesn't have the eeprom.

>> If you
>> face the latter case, you could try applying the patch I sent in some
>> days ago. Without that patch, the hardware is not made aware of the
>> configured address and hence the internal filter will drop all
>> non-broadcast packets it receives.

Applying the patch helped a great deal:

Overo # ping 192.168.0.1
smc911x: initializing
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC 4a:18:56:55:9d:38
host 192.168.0.1 is alive

Attempting dhcp still fails, but this is a big step forward.

Thanks much!

Steve

[U-Boot] Enabling smc911x driver

[Daniel Mack]

On Wed, Apr 22, 2009 at 10:31:52AM -0700, Steve Sakoman wrote:
> >> How did you set this MAC address? Does the hardware read it from a
> >> connected EEPROM or did you manually set it in your environment.
> 
> It is manually set in the environment since the prototype hardware
> doesn't have the eeprom.

Assuming you're going to boot Linux on that board, you will face the
next problem that U-Boot will reset the controller before the kernel
boots and thus vanishes the MAC address from the chip. I sent in another
patch for that which contionally disables this reset so that the Linux
driver can actually read the address again and use it (with the
SMSC911X_SAVE_MAC_ADDRESS flag set). But as Mike Frysinger pointed out,
this is not the intended way to go as the MAC is only programmed if
U-Boot ever performed any network transaction. So there is need for some
other approach, just wanted to let you know.

Daniel

[U-Boot] Enabling smc911x driver

[Steve Sakoman]

On Wed, Apr 22, 2009 at 10:31 AM, Steve Sakoman <sakoman@gmail.com> wrote:
> On Wed, Apr 22, 2009 at 8:54 AM, Daniel Mack <daniel@caiaq.de> wrote:
>
>>> How did you set this MAC address? Does the hardware read it from a
>>> connected EEPROM or did you manually set it in your environment.
>
> It is manually set in the environment since the prototype hardware
> doesn't have the eeprom.
>
>>> If you
>>> face the latter case, you could try applying the patch I sent in some
>>> days ago. Without that patch, the hardware is not made aware of the
>>> configured address and hence the internal filter will drop all
>>> non-broadcast packets it receives.
>
> Applying the patch helped a great deal:
>
> Overo # ping 192.168.0.1
> smc911x: initializing
> smc911x: detected LAN9221 controller
> smc911x: phy initialized
> smc911x: MAC 4a:18:56:55:9d:38
> host 192.168.0.1 is alive
>
> Attempting dhcp still fails, but this is a big step forward.

As a next step I attempted to load a file via tftp.  This works fine
if the file is <= 544 bytes in length:

Overo # tftp test.txt
smc911x: initializing
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC aa:bb:cc:dd:ee:ff
TFTP from server 192.168.0.210; our IP address is 192.168.0.223
Filename 'test.txt'.
Load address: 0x82000000
Loading: #
done
Bytes transferred = 544 (220 hex)

Files longer that 544 bytes result in a timeout error:

Overo # tftp test.txt
smc911x: initializing
smc911x: detected LAN9221 controller
smc911x: phy initialized
smc911x: MAC aa:bb:cc:dd:ee:ff
TFTP from server 192.168.0.210; our IP address is 192.168.0.223
Filename 'test.txt'.
Load address: 0x82000000
Loading: T T T T T T T T T T
Retry count exceeded; starting again

Any ideas what might be going wrong here?

Steve

[U-Boot] Enabling smc911x driver

[Daniel Mack]

On Wed, Apr 22, 2009 at 09:20:15PM -0700, Steve Sakoman wrote:
> Files longer that 544 bytes result in a timeout error:
> 
> Overo # tftp test.txt
> smc911x: initializing
> smc911x: detected LAN9221 controller
> smc911x: phy initialized
> smc911x: MAC aa:bb:cc:dd:ee:ff
> TFTP from server 192.168.0.210; our IP address is 192.168.0.223
> Filename 'test.txt'.
> Load address: 0x82000000
> Loading: T T T T T T T T T T
> Retry count exceeded; starting again
> 
> Any ideas what might be going wrong here?

Hmm. I had a similar issue a while ago and the reason was that on PXA3xx
CPUs, the timer register behaved differently than on PXA2xxs and that
was never tested. In fact, it was counting magnitudes faster there which
made the network code bail out way to early. This was fixed for the
platform I'm working with, but maybe you got a similar problem.

Other than that, there might be something weird with your network. I'd
suggest running wireshark on some host on that LAN and have a close look
on the packets.

Daniel