[U-Boot] mtest issue

[Jerry Van Baren]

Alexey Goncharov wrote:
> Hello everyone,
> 
> I have a LPC2468 board and currently play with u-boot. U-boot version
> is 1.1.6 from Embedded Artists. I've already made u-boot loading and

1.1.6 is really old.

> executing user commands. Everything seems works fine, except the
> memory test (mtest) command:
> 
> lpc-board# mtest
> 
> Pattern 00000000  Writing...  Reading...
> Mem error @ 0xA075AB74: found A0780000, expected 001D6ADD

What does the value A0780000 mean to your system?  That looks like a 
magic memory address.  Who would store that into memory?  That may be a 
clue for finding the culprit.

> Mem error @ 0xA075AB78: found 001D6ADD, expected 001D6ADE

Oh-oh, the found vs. expected are one different.  Since the memory test 
is writing and then verifying sequential numbers into sequential memory 
locations, this implies your hardware either read the wrong location 
(timing problem with the address lines or memory?) or the data was 
latched wrong so that the previous value was still on the data bus and 
latched rather than the correct value (a different flavor of timing 
problem).

> Pattern FFFFFFFF  Writing...
> 
> After the mtest started to check RAM with "0xFFFFFFFF" pattern the
> system stops to respond.

You need to compare the default mtest test range with your memory map 
and figure out where there is overlap.  We don't know anything about 
your u-boot configuration, hardware, or memory map, so we cannot help.

If you specify a smaller, known unused, area to the mtest command (help 
mtest), does it work?  Work your way through your "unused" memory map 
and find where it breaks.

> In case with CFG_ALT_MEMTEST defined mtest also fails with error:
> 
> Testing a0000000 ... a0780000:
> Iteration:      1
> FAILURE (read/write) @ 0xa075ab68: expected 0x001d6adb, actual 0xffe29525)

Note that the expected and actual are inverses:
   ~0x001d6adb == 0xffe29525
IIRC, the memory test stores the pattern, checks it, stores the 
~pattern, and then checks that.  This is smelling of a memory timing 
issue again.

> You can see the ram dump made with "md a075ab40" command:
> 
> a075ab30: ffe29532 ffe29531 ffe29530 ffe2952f             2...1...0.../...
> a075ab40: a075ab68 a0788b64 a079ad7c a079ad7c    h.u.d.x.|.y.|.y.
> a075ab50: 0000000d 0000000d a075ab68 a075ab74    ........h.u.t.u.
> a075ab60: 00000000 00000040 00000000 00000040    .... at .......@...
> a075ab70: 00000000 00000040 a079decc 00000002
> 
> This segment of RAM (addresses from 0xa075ab40) seems already
> initialized and used somehow by u-boot. I've checked second board in
> the same way. The result is the same, so any hardware problems are
> excepted. The question is: what is it?

We have no information, we have no clue.  Use your information (memory 
map, deductive reasoning, detective skills).

> Is it stack or something else?

Yes.

> Should i pay attention on that or just don't mind.

YES, YOU MUST PAY ATTENTION TO THAT!

> Is it possible to make mtest pass?

Yes, if your hardware and software work.  If mtest is failing, you have 
a hardware or software problem.  If you don't find and fix it, you will 
have an unreliable widget.

> As you may see, i'm totally new to u-boot and have no experience at
> all, that's why maybe my question will make you laugh. Anyway, could 
> you please, help me to find the shortest way to fix this issue.

Shortest: Send money to an expert to help you.  Ask Embedded Artists? 
Is it their board or a custom board?  Either way, they probably have the 
best knowledge of your board.

Most satisfying: Figure it out and fix it.

> Thank you for your time wasted on me,
> Alexey Goncharov, Russia

Good luck,
gvb