U-boot Memory Test

[modyrater]

Texas Instruments X-Loader 1.41 (Sep 17 2010 - 12:00:04)
mmc read: Invalid size
Starting OS Bootloader from MMC/SD1 ...


U-Boot 1.1.4-gcebe815a-dirty (Oct 19 2010 - 17:45:52)

Load address: 0x80e80000
DRAM:  512 MB
Flash:  0 kB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   KS8851SNL
Hit any key to stop autoboot:  0
PANDA # mtest 0x80100000 0x90000000 0xaabb
Pattern 0000AABB  Writing...  X-Loader hangs

this " special" ES2.0 board is populated with Micron MT42L128M64D4KJ-25 IT ES:A

[Koen Kooi]

Op 20 dec 2010, om 18:10 heeft modyrater het volgende geschreven:

> Texas Instruments X-Loader 1.41 (Sep 17 2010 - 12:00:04)
> mmc read: Invalid size
> Starting OS Bootloader from MMC/SD1 ...
>
>
> U-Boot 1.1.4-gcebe815a-dirty (Oct 19 2010 - 17:45:52)

That's a 5 year old version of uboot......

[prpplague]

modyrater,


the version of u-boot you are using is part of the L24.x series from
TI, most of the open source community is going to be using the
mainline u-boot.

with that said, the mtest should perform correctly.

dave

[Woodruff, Richard]

> From: panda...@googlegroups.com [mailto:panda...@googlegroups.com]
> On Behalf Of prpplague

> On Dec 20, 11:10 am, modyrater <mark.lazarew...@gmail.com> wrote:
> > Texas Instruments X-Loader 1.41 (Sep 17 2010 - 12:00:04)

> > Load address: 0x80e80000

> > PANDA # mtest 0x80100000 0x90000000 0xaabb
> > Pattern 0000AABB Writing... X-Loader hangs

Your test command will overwrite your in DDR u-boot executable. Of course it will crash. Maybe it crashes for other reasons also but first you need to start with a valid address.

Start at like 80200000 and you will be safe unless you configured a big malloc area or what not. This seems unlikely as few people seem to touch many of the layout options anymore.

Regards,
Richard W.

[Nishanth Menon]

Just one interesting related note:
Upstream u-boot will now relocate automatically to the DDR boundary
(outer edge) automatically no matter what the LOAD_ADDRESS is. in
previous versions, one'd have to be careful to ensure memtest did not
overwrite parts of u-boot text and data area as well as heap/stack as
well - the addresses actually available to mtest was fragmented.

So, depending on the bootloader version used, the usage of lower address
for mtest can be valid

--
Regards,
Nishanth Menon

[Nishanth Menon]

Nishanth Menon wrote, on 12/23/2010 05:15 AM:
> Woodruff, Richard wrote, on 12/22/2010 07:44 PM:
>>
>>> From: panda...@googlegroups.com [mailto:panda...@googlegroups.com]
>>> On Behalf Of prpplague
>>
>>> On Dec 20, 11:10 am, modyrater<mark.lazarew...@gmail.com> wrote:
>>>> Texas Instruments X-Loader 1.41 (Sep 17 2010 - 12:00:04)
>>
>>>> Load address: 0x80e80000
>>
>>>> PANDA # mtest 0x80100000 0x90000000 0xaabb
>>>> Pattern 0000AABB Writing... X-Loader hangs
>>
>> Your test command will overwrite your in DDR u-boot executable. Of
>> course it will crash. Maybe it crashes for other reasons also but
>> first you need to start with a valid address.
>>
>> Start at like 80200000 and you will be safe unless you configured a
>> big malloc area or what not. This seems unlikely as few people seem to
>> touch many of the layout options anymore.
>
> Just one interesting related note:
> Upstream u-boot will now relocate automatically to the DDR boundary
> (outer edge) automatically no matter what the LOAD_ADDRESS is. in

a little more details on 2010.12 - the latest formal release here:
http://marc.info/?l=u-boot&m=129304896226298&w=2

[Woodruff, Richard]

> From: Nishanth Menon [mailto:menon.n...@gmail.com]
> Sent: Thursday, December 23, 2010 5:15 AM

> Just one interesting related note:
> Upstream u-boot will now relocate automatically to the DDR boundary
> (outer edge) automatically no matter what the LOAD_ADDRESS is. in
> previous versions, one'd have to be careful to ensure memtest did not
> overwrite parts of u-boot text and data area as well as heap/stack as
> well - the addresses actually available to mtest was fragmented.

Hugh. Probably its is generally useful.

Back in OMAP2 days there were perhaps 10 different memory combinations used with boards using 1 or 2 chip selects. Additionally memory controller also had many bugs. I choose the address somewhat in the middle of the 1st chip select as it was common to all combinations.

Early probe I only configured 1 chip select after probing then relocated. Then later on the code determined the rest of the properties and configured a 2nd chip select if it was there.

The above allow 1 binary to work over a couple years of board variations. I was very happy with this. Other HLOS loaders took a 1 image per board variant and it created a lot of obstacles to the fanned out end users.

Anyway, an auto move is right if you can uniquely determine your memory type very early. This wasn't the case with our early sdr and ddr modules. I hope its configurable.

... there is less an issue today at the top end as many of the parts can have their sizes probed with a mr sequence added in a later jdec extension. Omap1,2,3 controller don't support this however... omap4 does.

> So, depending on the bootloader version used, the usage of lower
> address for mtest can be valid

Does memtest check to not overwrite itself? If not it would still die just later.

Regards,
Richard W.

[menon.n...@gmail.com]

On Thu, Dec 23, 2010 at 7:05 AM, Woodruff, Richard <r-woo...@ti.com> wrote:
>
>> So, depending on the bootloader version used, the usage of lower
>> address for mtest can be valid
>
> Does memtest check to not overwrite itself?  If not it would still die just later.

Have'nt checked recently, but last I used it (during beagle days in
2008-early 2009), it would'nt do all the necessary checks as it
dependent on the user to know it. but given this relocation changes,
there should be global variables around to make it transparent to user
- at least for arm - not sure about ppc, x86 etc..
Regards,
Nishanth Menon