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 at ..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,

...(snipped)

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

...

...

...

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

Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"What if" is a trademark of Hewlett Packard, so stop using it in your
sentences without permission, or risk being sued.

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,

Christian <[email protected]>