* [U-Boot-Users] Spectacularly Weird U-Boot Behavior w/NE2000
@ 2005-01-14 17:05 Craig A. Vanderborgh
2005-01-14 18:21 ` Chuck Meade
2005-01-16 17:16 ` Wolfgang Denk
0 siblings, 2 replies; 4+ messages in thread
From: Craig A. Vanderborgh @ 2005-01-14 17:05 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 4+ messages in thread* [U-Boot-Users] Spectacularly Weird U-Boot Behavior w/NE2000
2005-01-14 17:05 [U-Boot-Users] Spectacularly Weird U-Boot Behavior w/NE2000 Craig A. Vanderborgh
@ 2005-01-14 18:21 ` Chuck Meade
2005-01-16 17:16 ` Wolfgang Denk
1 sibling, 0 replies; 4+ messages in thread
From: Chuck Meade @ 2005-01-14 18:21 UTC (permalink / raw)
To: u-boot
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 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.
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot-Users] Spectacularly Weird U-Boot Behavior w/NE2000
2005-01-14 17:05 [U-Boot-Users] Spectacularly Weird U-Boot Behavior w/NE2000 Craig A. Vanderborgh
2005-01-14 18:21 ` Chuck Meade
@ 2005-01-16 17:16 ` Wolfgang Denk
2005-01-24 10:56 ` Christian Pell
1 sibling, 1 reply; 4+ messages in thread
From: Wolfgang Denk @ 2005-01-16 17:16 UTC (permalink / raw)
To: u-boot
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
--
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot-Users] Spectacularly Weird U-Boot Behavior w/NE2000
2005-01-16 17:16 ` Wolfgang Denk
@ 2005-01-24 10:56 ` Christian Pell
0 siblings, 0 replies; 4+ messages in thread
From: Christian Pell @ 2005-01-24 10:56 UTC (permalink / raw)
To: u-boot
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,
--
Christian <c.pellegrin@exadron.com>
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2005-01-24 10:56 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-01-14 17:05 [U-Boot-Users] Spectacularly Weird U-Boot Behavior w/NE2000 Craig A. Vanderborgh
2005-01-14 18:21 ` Chuck Meade
2005-01-16 17:16 ` Wolfgang Denk
2005-01-24 10:56 ` Christian Pell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.