Skip to contentSkip to conversation

mtest

U-Boot-Users himbA 2 participants 7 messages Apr 2, 2004

lore
Share & tools
lore

himbA

author
#0 lore raw

Hi,

While experiencing some trouble with u-boot port to my custom PXA255 board I decided to run some memory tests. I used mtest in u-boot and got the following results:
=> mtest
Pattern 00000000 Writing... ^H^H^H^H^H^H^H^H^H^HReading...
Mem error @ 0xA3EDBAEC: found A3EDBB0C, expected 00F76EBB

Mem error @ 0xA3EDBAF0: found A3EDBAFC, expected 00F76EBC

Mem error @ 0xA3EDBAF4: found A3F1227C, expected 00F76EBD
[...]

Mem error @ 0xA3EDBC50: found A3EDBC48, expected 00F76F14

Mem error @ 0xA3EDBC54: found 00F76F14, expected 00F76F15
Pattern FFFFFFFF Writing... ^H^H^H^H^H^H^H^H^H^H?

													^^^^^^ HANG!

Memory test finds some errors during write/read 0x00000000 pattern and it hangs before it can read back 0xFFFFFFFF. I suppose this is not the expected board behaviour.

Has anybody any idea what is going on ?
Is this a config error ? (I should probably check the setting in configs/board.h)

regards, himba

Signature · 5 lines
..because under Linux "if something is possible in 
principle,
then it is already implemented or somebody is 
working on it".
							--LKI
#1 lore raw
Quoted 10 lines · In message <[email protected]> you wrote:

to my custom PXA255 board I decided to run some memory tests. I used mtest in u-boot and got the following results:
=> mtest
Pattern 00000000 Writing... ^H^H^H^H^H^H^H^H^H^HReading...
Mem error @ 0xA3EDBAEC: found A3EDBB0C, expected 00F76EBB

Mem error @ 0xA3EDBAF0: found A3EDBAFC, expected 00F76EBC

...

Quoted 4 lines

Memory test finds some errors during write/read 0x00000000 pattern and it hangs before it can read back 0xFFFFFFFF. I suppose this is not the expected board behaviour.

Well, it IS the expected behaviour in case of memory problem, when the behaviour of the system is completely undefined.

Quoted 1 line

Has anybody any idea what is going on ?

You have memory problems.

Quoted 2 lines

Is this a config error ? (I should probably check the setting in configs/board.h)

Ooops??? I think it is pretty clear what it means when a memory test returns memory errors. To me this means that either the memory test or the memory itself is broken. Since the test is working fine on many other boards it's probably your hardware.

Best regards,

Wolfgang Denk

Signature · 3 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Open the pod bay doors, HAL."                    - Dave Bowman, 2001
author
#2 lore raw

Wolfgang Denk wrote:
...

Quoted 6 lines

Ooops??? I think it is pretty clear what it means when a memory test returns memory errors. To me this means that either the memory test or the memory itself is broken. Since the test is working fine on many other boards it's probably your hardware.

Yes it is memory error - but can it be fixed with PXA memory register settings (eg. access time, refresh, other mem. flags) or is it that hardware is faulty (schematics or PCB routing) ?

Quoted 4 lines

Best regards,

Wolfgang Denk

regards, himba

Signature · 5 lines
..because under Linux "if something is possible in 
principle,
then it is already implemented or somebody is 
working on it".
							--LKI
#3 lore raw
Quoted 5 lines · In message <[email protected]> you wrote:

Yes it is memory error - but can it be fixed with PXA memory register settings (eg. access time, refresh, other mem. flags) or is it that hardware is faulty (schematics or PCB routing) ?

Sorry, my crystal ball is in dire need of an ectoplasmic upgrade. :-)

Best regards,

Wolfgang Denk

Signature · 5 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Probably the best operating system in the world  is  the  [operating
system] made for the PDP-11 by Bell Laboratories."
                                           - Ted Nelson, October 1977
author
#4 lore raw
Quoted 2 lines · Wolfgang Denk

Sorry, my crystal ball is in dire need of an ectoplasmic upgrade. :-)

:)

OK, I did some more research - my SDRAM config is

PHYS_SDRAM_1            0xa0000000
PHYS_SDRAM_1_SIZE       0x04000000
CFG_DRAM_BASE           0xa0000000
CFG_DRAM_SIZE           0x04000000

those memory errors mentioned in earlier post do not appear if I change CFG_MEMTEST_END from 0xa3efffff (- 63M) to 0xa3dfffff (- 62M). CFG_MEMTEST_START = 0xa0100000 (1M -). In config.mk TEXT_BASE = 0xa3f00000.

at bootup uboot displays
U-Boot code: A3F00000 -> A3F177B8 BSS: -> A3F1BAD8

Is there some uboot relevant stuff between 0xa3efffff - 0xa3dfffff that I run over when doing mtest on all 63Mb? Code and stack seem to be safe.

regards, himba

Signature · 5 lines
..because under Linux "if something is possible in 
principle,
then it is already implemented or somebody is 
working on it".
							--LKI
#5 lore raw
Quoted 7 lines · In message <[email protected]> you wrote:

at bootup uboot displays
U-Boot code: A3F00000 -> A3F177B8 BSS: -> A3F1BAD8

Is there some uboot relevant stuff between 0xa3efffff - 0xa3dfffff that I run over when doing mtest on all 63Mb? Code and stack seem to be safe.

What do you think where the stack and the malloc arena is in your configuration?

Best regards,

Wolfgang Denk

Signature · 4 lines
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
How many NASA managers does it take to screw in a lightbulb?  "That's
a known problem... don't worry about it."
author
#6 lore raw
Quoted 5 lines · Wolfgang Denk
Quoted 3 lines · In message <[email protected]> you wrote:

at bootup uboot displays
U-Boot code: A3F00000 -> A3F177B8 BSS: -> A3F1BAD8

Quoted 8 lines
Quoted 3 lines

Is there some uboot relevant stuff between 0xa3efffff - 0xa3dfffff that I run over when doing mtest on all 63Mb? Code and stack seem to be safe.

What do you think where the stack and the malloc arena is in your configuration?

I thought code starts at _TEXT_BASE (0xA3F00000) and stack is from 0xA3F177B8 to 0xA3F1BAD8 (u-boot header display suggested so). Your question was in place and I checked the start.S once again to find out that after reset and relocate we setup stack below _TEXT_BASE and not above. I corrected the CFG_MEMTEST_END to be just below malloc and stack.

Thanks!

regards, himba

Signature · 5 lines
..because under Linux "if something is possible in 
principle,
then it is already implemented or somebody is 
working on it".
							--LKI