[U-Boot-Users] mtest

[U-Boot-Users] mtest

[himbA]

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

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

[U-Boot-Users] mtest

[Wolfgang Denk]

In message <406D1751.1040304@email.si> 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
...
> 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.

> Has anybody any idea what is going on ?

You have memory problems.

> 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

-- 
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

[U-Boot-Users] mtest

[himbA]

Wolfgang Denk wrote:
...
> 
> 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) ?

> Best regards,
> 
> Wolfgang Denk
> 

regards, himba
-- 
..because under Linux "if something is possible in 
principle,
then it is already implemented or somebody is 
working on it".
							--LKI

[U-Boot-Users] mtest

[Wolfgang Denk]

In message <406D2E60.4050008@email.si> 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

-- 
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

[U-Boot-Users] mtest

[himbA]

Wolfgang Denk wrote:

> 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
-- 
..because under Linux "if something is possible in 
principle,
then it is already implemented or somebody is 
working on it".
							--LKI

[U-Boot-Users] mtest

[Wolfgang Denk]

In message <406D56A5.2090102@email.si> 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

-- 
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."

[U-Boot-Users] mtest

[VanBaren, Gerald]

> -----Original Message-----
> From: u-boot-users-admin at lists.sourceforge.net
> [mailto:u-boot-users-admin at lists.sourceforge.net]On Behalf Of himbA
> Sent: Friday, April 02, 2004 7:04 AM
> To: u-boot-users at lists.sourceforge.net
> Subject: Re: [U-Boot-Users] mtest
>
>
> Wolfgang Denk wrote:
>
> > 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
> --
> ..because under Linux "if something is possible in
> principle,
> then it is already implemented or somebody is
> working on it".
> 							--LKI


Dear LKI:

Your initial message said the error messages were:

  Mem error @ 0xA3EDBAEC: found A3EDBB0C, expected 00F76EBB
  Mem error @ 0xA3EDBAF0: found A3EDBAFC, expected 00F76EBC
  Mem error @ 0xA3EDBAF4: found A3F1227C, expected 00F76EBD

Note that the "found" data consists mostly of the address.  This makes me think (not being familiar with the PXA255) that your processor has a multiplexed address & data bus and the memory (either itself or the data line buffers if you are using buffers) are not being enabled properly on the read cycle -- either late or not at all.  The result is that the address goes out on the bus and is still hanging around on the bus when the data gets latched in the processor.  The proper operation of the memory/buffers would be to drive the memory data onto the bus before the data is latched by the processor.

gvb



******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege.  If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager.  Please do not copy it for any purpose, or disclose its contents to any other person.  The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.  The recipient should check this e-mail and any attachments for the presence of viruses.  The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************

[U-Boot-Users] mtest

[himbA]

Wolfgang Denk wrote:
> In message <406D56A5.2090102@email.si> 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?
> 

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

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

[U-Boot-Users] mtest

[himbA]

VanBaren, Gerald (AGRE) wrote:

> 
> Dear LKI:
> 
> Your initial message said the error messages were:
> 
>   Mem error @ 0xA3EDBAEC: found A3EDBB0C, expected 00F76EBB
>   Mem error @ 0xA3EDBAF0: found A3EDBAFC, expected 00F76EBC
>   Mem error @ 0xA3EDBAF4: found A3F1227C, expected 00F76EBD
> 
> Note that the "found" data consists mostly of the address.  This makes me think (not being familiar with the PXA255) that your processor has a multiplexed address & data bus and the memory (either itself or the data line buffers if you are using buffers) are not being enabled properly on the read cycle -- either late or not at all.  The result is that the address goes out on the bus and is still hanging around on the bus when the data gets latched in the processor.  The proper operation of the memory/buffers would be to drive the memory data onto the bus before the data is latched by the processor.
> 

I guess that were values on stack that I ran over 
with mtest - containing address pointers.

I resolved the problem by setting the right 
MEMTEST_END value (below u-boot stacK/data  )


> gvb
> 
> 
>
regards, himba



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