From: Dave B. <dav...@va...> - 2012-09-11 04:09:44
|
I'm working on a custom OVERO expansion board that includes a LAN9221 Ethernet interface based on the circuit provided on the gumstix TOBI PCB. When I power up my current prototype boards, U-Boot fails to detect the LAN9221 IC. I'm currently working on troubleshooting this problem in the u-boot code (git://www.sakoman.com/git/u-boot.git;branch=omap3-v2011.09; commit ID: 0f331e606c80166c1bfe5cac40dfc0616708f31b). The console output from u-boot follows: Texas Instruments X-Loader 1.5.1 (Jul 9 2012 - 15:52:22) OMAP3503-GP ES3.1 Board revision: 0 Reading boot sector Loading u-boot.bin from mmc U-Boot 2011.09 (Sep 10 2012 - 20:10:41) OMAP3503-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz Gumstix Overo board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB MMC: OMAP SD/MMC: 0 *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Board revision: 0 Tranceiver detected on mmc2 No EEPROM on expansion board Die ID #25b200040000000004032d460e00d00a Net: smc911x: Unknown chip ID 0000 No ethernet found. Hit any key to stop autoboot: 3 Chip detection in u-boot is performed by the function smc911x_detect_chip() found in /drivers/net/smc911x.h: static int smc911x_detect_chip(struct eth_device *dev) { unsigned long val, i; val = smc911x_reg_read(dev, BYTE_TEST); if (val == 0xffffffff) { /* Special case -- no chip present */ return -1; } else if (val != 0x87654321) { printf(DRIVERNAME ": Invalid chip endian 0x%08lx\n", val); return -1; } val = smc911x_reg_read(dev, ID_REV) >> 16; for (i = 0; chip_ids[i].id != 0; i++) { if (chip_ids[i].id == val) break; } if (!chip_ids[i].id) { printf(DRIVERNAME ": Unknown chip ID %04lx\n", val); return -1; } dev->priv = (void *)&chip_ids[i]; return 0; } This routine carries out two steps needed to decide whether a supported chip is present: 1. Read the BYTE_TEST register on the LAN IC and confirm that the reply is the value 0x87654321. 2. Read the ID_REV register on the LAN IC and confirm that its value is that of a supported device (0x9221 in this case). After adding a couple of printf() statements to the above routine, I have confirmed that the smc911x driver is successfully read the BYTE_TEST register (offset 0x64 in the associated memory space mapped through the gpmc) However, it always reads a value of zero from the ID_REV register (offset 0x50). Things I have tried so far: * I have confirmed that the OVERO successfully boots and detects the LAN9221 chip on a TOBI board. * I have used a DMM to verify the continuity of address and data traces running between the LAN9221 IC and the associated pins on Overo connector J4. * I have tried setting the PARAGRANULARITY bit in the associated gpmc configuration in order to double the wait states used for accesses over the external address/data bus (the address/data bus traces in my design are approximately twice as long as those in the TOBI design). Unfortunately, this does not solve the problem. For what it's worth, I do have an unprogrammed EEPROM attached to the LAN9221. However, from the datasheet, it seems this shouldn't matter, since it should only be accessed to obtain a MAC address. I'd like to set up a walking-1's pattern across the address and data bus to detect shorts that I may have missed. So far, though, I have been unable to make this work within the driver code or board initialization. I feel like I'm running out of ideas here, so any helpful comments or advice would be appreciated. Best Regards, Dave Billin Graduate Research Assistant --MS Computer Engineering University of Idaho Moscow, Idaho 83844 e-mail: dav...@va... |
From: Nick W. <nic...@gm...> - 2012-09-11 05:51:12
|
This is probably not the problem, but is power connected to the LAN9221 correctly? The center pad of the LAN9221 should be solidly grounded, bypass caps located very near the power input pins, etc? Sometimes the weirdest problems can be power related. On Mon, Sep 10, 2012 at 9:09 PM, Dave Billin < dav...@va...> wrote: > I'm working on a custom OVERO expansion board that includes a LAN9221 > Ethernet interface based on the circuit provided on the gumstix TOBI PCB. > When I power up my current prototype boards, U-Boot fails to detect the > LAN9221 IC. I'm currently working on troubleshooting this problem in the > u-boot code (git://www.sakoman.com/git/u-boot.git;branch=omap3-v2011.09; > commit ID: 0f331e606c80166c1bfe5cac40dfc0616708f31b). The console output > from u-boot follows: > > Texas Instruments X-Loader 1.5.1 (Jul 9 2012 - 15:52:22) > OMAP3503-GP ES3.1 > Board revision: 0 > Reading boot sector > Loading u-boot.bin from mmc > > > U-Boot 2011.09 (Sep 10 2012 - 20:10:41) > > OMAP3503-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz > Gumstix Overo board + LPDDR/NAND > I2C: ready > DRAM: 256 MiB > NAND: 256 MiB > MMC: OMAP SD/MMC: 0 > *** Warning - bad CRC, using default environment > > In: serial > Out: serial > Err: serial > Board revision: 0 > Tranceiver detected on mmc2 > No EEPROM on expansion board > Die ID #25b200040000000004032d460e00d00a > Net: smc911x: Unknown chip ID 0000 > No ethernet found. > Hit any key to stop autoboot: 3 > > > Chip detection in u-boot is performed by the function > smc911x_detect_chip() found in /drivers/net/smc911x.h: > > static int smc911x_detect_chip(struct eth_device *dev) > { > unsigned long val, i; > > val = smc911x_reg_read(dev, BYTE_TEST); > if (val == 0xffffffff) { > /* Special case -- no chip present */ > return -1; > } else if (val != 0x87654321) { > printf(DRIVERNAME ": Invalid chip endian 0x%08lx\n", val); > return -1; > } > > val = smc911x_reg_read(dev, ID_REV) >> 16; > for (i = 0; chip_ids[i].id != 0; i++) { > if (chip_ids[i].id == val) break; > } > if (!chip_ids[i].id) { > printf(DRIVERNAME ": Unknown chip ID %04lx\n", val); > return -1; > } > > dev->priv = (void *)&chip_ids[i]; > > return 0; > } > > This routine carries out two steps needed to decide whether a supported > chip is present: > > 1. Read the BYTE_TEST register on the LAN IC and confirm that the > reply is the value 0x87654321. > 2. Read the ID_REV register on the LAN IC and confirm that its value > is that of a supported device (0x9221 in this case). > > After adding a couple of printf() statements to the above routine, I have > confirmed that the smc911x driver is successfully read the BYTE_TEST > register (offset 0x64 in the associated memory space mapped through the > gpmc) However, it always reads a value of zero from the ID_REV register > (offset 0x50). > > *Things I have tried so far:* > > > - I have confirmed that the OVERO successfully boots and detects the > LAN9221 chip on a TOBI board. > - I have used a DMM to verify the continuity of address and data > traces running between the LAN9221 IC and the associated pins on Overo > connector J4. > - I have tried setting the PARAGRANULARITY bit in the associated gpmc > configuration in order to double the wait states used for accesses over the > external address/data bus (the address/data bus traces in my design are > approximately twice as long as those in the TOBI design). Unfortunately, > this does not solve the problem. > > > For what it's worth, I do have an unprogrammed EEPROM attached to the > LAN9221. However, from the datasheet, it seems this shouldn't matter, > since it should only be accessed to obtain a MAC address. > I'd like to set up a walking-1's pattern across the address and data bus > to detect shorts that I may have missed. So far, though, I have been > unable to make this work within the driver code or board initialization. I > feel like I'm running out of ideas here, so any helpful comments or advice > would be appreciated. > > > Best Regards, > > Dave Billin > > Graduate Research Assistant --MS Computer Engineering > University of Idaho > Moscow, Idaho 83844 > > e-mail: dav...@va... > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > gumstix-users mailing list > gum...@li... > https://lists.sourceforge.net/lists/listinfo/gumstix-users > > |
From: Dave B. <dav...@va...> - 2012-09-11 14:18:39
|
Nick, Thanks. Those are certainly solid suggestions. I probably should have mentioned that I have already verified that all of the LAN9221 power planes are functioning (+3.3V, +1.8V, and the LAN9221-regulated 1.8V core voltage). Still, thanks all the same! Best Regards, Dave Billin Graduate Research Assistant --MS Computer Engineering University of Idaho Moscow, Idaho 83844 e-mail: dav...@va... ________________________________ From: Nick Wernicke [nic...@gm...] Sent: Monday, September 10, 2012 10:51 PM To: General mailing list for gumstix users. Subject: Re: [Gumstix-users] LAN9221 not recognized in TOBI-based design This is probably not the problem, but is power connected to the LAN9221 correctly? The center pad of the LAN9221 should be solidly grounded, bypass caps located very near the power input pins, etc? Sometimes the weirdest problems can be power related. |
From: Ben J. <mya...@gm...> - 2012-09-14 03:38:45
|
I had a problem like this a long time ago. One thing that I tried is to compile the LAN module as a separate module not in the kernel. You can recompile the LAN driver in debug mode where it prints out all of the registers. Then load the module with insmod. I think that it is also possible to set and read back registers. I used this to find some of mine issues. Ben On Tuesday, September 11, 2012, Dave Billin wrote: > Nick, > > Thanks. Those are certainly solid suggestions. I probably should have > mentioned that I have already verified that all of the LAN9221 power planes > are functioning (+3.3V, +1.8V, and the LAN9221-regulated 1.8V core > voltage). Still, thanks all the same! > > Best Regards, > > Dave Billin > > Graduate Research Assistant --MS Computer Engineering > University of Idaho > Moscow, Idaho 83844 > > e-mail: dav...@va... <javascript:_e({}, 'cvml', > 'dav...@va...');> > > > ------------------------------ > *From:* Nick Wernicke [nic...@gm... <javascript:_e({}, 'cvml', > 'nic...@gm...');>] > *Sent:* Monday, September 10, 2012 10:51 PM > *To:* General mailing list for gumstix users. > *Subject:* Re: [Gumstix-users] LAN9221 not recognized in TOBI-based design > > This is probably not the problem, but is power connected to the LAN9221 > correctly? The center pad of the LAN9221 should be solidly grounded, > bypass caps located very near the power input pins, etc? Sometimes > the weirdest problems can be power related. > > |