[U-Boot] Enabling smc911x driver
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
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
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
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
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@lists.denx.de/msg12038.html
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
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
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
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
participants (3)
-
Ben Warren -
Daniel Mack -
Steve Sakoman