[U-Boot-Users] Spectacularly Weird U-Boot Behavior w/NE2000

Hello Everybody,
I have just completed a port to our board of u-boot-1.1.3, from CVS. Everything is actually working very well, so kudos to everybody for all of the fine work done in the past few months.
I have incorporated Christian's NE2000 driver for PCMCIA, and have configured it for my PXA255 custom board according to his instructions and the instructions in the README.PXA_CF in /doc. I am have had some success with this - and an amazing problem.
I can successfully activate the PCMCIA card using "pinit on". When I do this, I see the following:
$ pinit on PCMCIA Card detected Low Power Ethernet LAN Adapter Socket Communications, Inc Revis Network Adapter Card
So u-boot can read the CIS and figure out that I have a socket LPE. Nice. Then, I try to do a ping - and it works:
$ ping 10.250.1.7 NE2000 - eeprom ESA: 09:09:84:8a:08:0c host 10.250.1.7 is alive $
Wonderful. But now, after doing the ping, u-boot's "view" of flash memory gets corrupted. For example, look at this:
$ md 80000 00080000: 56190080 65070080 40300080 18670080 ...V...e..0@..g. 00080010: 00000080 00000080 dfc00080 00020080 ................ 00080020: 2e340080 762d0080 2d310080 31610080 ..4...-v..1-..a1 00080030: 52450080 41440080 72650080 006c0080 ..ER..DA..er..l. 00080040: e1a00080 e1a00080 e1a00080 e1a00080 ................ 00080050: e1a00080 e1a00080 e1a00080 e1a00080 ................ 00080060: ea000080 016f0080 00000080 000b0080 ......o......... 00080070: e1a00080 e3a00080 e10f0080 e3120080 ................ 00080080: 1a000080 e3a00080 ef120080 e10f0080 ................ 00080090: e3820080 e1210080 e3cf0080 e2820080 ......!......... 000800a0: e4920080 e1320080 1aff0080 ee070080 ......2......... 000800b0: ee070080 ee110080 e3c00080 e3c00080 ................ 000800c0: ee010080 e3a00080 00000080 00000080 ................ 000800d0: 00000080 00000080 00000080 00000080 ................ 000800e0: e28f0080 e8900080 e0500080 e3300080 ..........P...0. 000800f0: 0a000080 e0850080 e0860080 e08c0080 ................
Notice how the high-order 16 bits of each long word are always "0080"? This is completely bogus. However, flash has not actually been corrupted. If I do a reset, and then do an "md 8000", everything is perfectly right.
Now don't get me wrong - I hardly expect you u-boot experts to "debug my program". It's just that this is SO strange, I hardly know where to start. Please just toss me one small bone here and answer this question: What could possibly be going on here? Is the NE2000 driver messing up the memory controller, or is it something else? By the way, after the "ping" is done the PXA register settings continue to look good, so I doubt if it's a register-related problem. But then again, maybe I'm missing something.
Please let me know what you think - I'm pretty stuck at the moment.
Thanks in advance, craig vanderborgh voxware incorporated

Hi Craig,
I have incorporated Christian's NE2000 driver for PCMCIA, and have configured it for my PXA255 custom board according to his instructions and the instructions in the README.PXA_CF in /doc. I am have had some success with this - and an amazing problem.
...(snipped)
Wonderful. But now, after doing the ping, u-boot's "view" of flash memory gets corrupted. For example, look at this:
$ md 80000 00080000: 56190080 65070080 40300080 18670080 ...V...e..0@..g. 00080010: 00000080 00000080 dfc00080 00020080 ................ 00080020: 2e340080 762d0080 2d310080 31610080 ..4...-v..1-..a1 00080030: 52450080 41440080 72650080 006c0080 ..ER..DA..er..l. 00080040: e1a00080 e1a00080 e1a00080 e1a00080 ................ 00080050: e1a00080 e1a00080 e1a00080 e1a00080 ................ 00080060: ea000080 016f0080 00000080 000b0080 ......o......... 00080070: e1a00080 e3a00080 e10f0080 e3120080 ................ 00080080: 1a000080 e3a00080 ef120080 e10f0080 ................ 00080090: e3820080 e1210080 e3cf0080 e2820080 ......!......... 000800a0: e4920080 e1320080 1aff0080 ee070080 ......2......... 000800b0: ee070080 ee110080 e3c00080 e3c00080 ................ 000800c0: ee010080 e3a00080 00000080 00000080 ................ 000800d0: 00000080 00000080 00000080 00000080 ................ 000800e0: e28f0080 e8900080 e0500080 e3300080 ..........P...0. 000800f0: 0a000080 e0850080 e0860080 e08c0080 ................
Notice how the high-order 16 bits of each long word are always "0080"? This is completely bogus. However, flash has not actually been corrupted. If I do a reset, and then do an "md 8000", everything is perfectly right.
You mean "md 80000" right? You had 80000 above, now you say 8000.
If that is not the issue (and I am sure it is just a typo), then it sounds as if you have 2 flash devices, 16 bits wide each, making up these 32-bit words. And it looks like the low-order 16-bits from flash are reporting flash status rather than flash data. Flash commands that are improperly finished (not completed) by putting the flash back into "read data" mode can leave the flash reporting its status instead of returning its data contents.
Just something to check. But the fact that a reset clears up the problem says that I am probably right, since the flash data is actually still there -- the reset puts the flash back into "read data" mode.
Tell us what happens. Chuck

In message 41E7FBD2.5020808@voxware.com you wrote:
I can successfully activate the PCMCIA card using "pinit on". When I do this, I see the following:
...
So u-boot can read the CIS and figure out that I have a socket LPE. Nice. Then, I try to do a ping - and it works:
...
Wonderful. But now, after doing the ping, u-boot's "view" of flash memory gets corrupted. For example, look at this:
...
Notice how the high-order 16 bits of each long word are always "0080"? This is completely bogus. However, flash has not actually been
This is not bogus. It just seems that sopmething put one of your flash chips into command mode. Assuming your hardware is stable, then some part of the code must have written some data which happened to look like a flash comand to the flash area.
If ythis is reproducable, then some parts of your PCMCIA / network / ping code write to bogus addresses in emory space. But if it's reproducable it shpould be easy to catch: just set some "data write address range" break point on the address range where your flash resides. This should catch the illegal write.
Best regards,
Wolfgang Denk

On Sun, 2005-01-16 at 18:16 +0100, Wolfgang Denk wrote:
If ythis is reproducable, then some parts of your PCMCIA / network / ping code write to bogus addresses in emory space. But if it's reproducable it shpould be easy to catch: just set some "data write address range" break point on the address range where your flash resides. This should catch the illegal write.
Hi,
sorry was OOO last week, I'll look at the code I contributed to see if I can find out some mistake (like some write to bogus address). Anyway it works right for me, but I'll recheck!
Bye,
participants (4)
-
Christian Pell
-
Chuck Meade
-
Craig A. Vanderborgh
-
Wolfgang Denk