[U-Boot] About mtest on boot

[U-Boot] About mtest on boot

[Érico Porto]

Hello,

I want to stop autoboot and use mtest to check if my ram is alright, but
0x07FD2C00 forward freezes, and 0x00000902 also freezes, mtest, when using
it. My ramsize is 0x08000000.

Does u-boot uses any parts of ram by itself, I mean, is there any known
spots where I can't test because it would crash my system?

Thanks

?rico V. Porto

[U-Boot] About mtest on boot

[Anatolij Gustschin]

Hi,

On Fri, 20 Jan 2012 08:07:41 -0200
?rico Porto <ericoporto2008@gmail.com> wrote:

> Hello,
> 
> I want to stop autoboot and use mtest to check if my ram is alright, but
> 0x07FD2C00 forward freezes, and 0x00000902 also freezes, mtest, when using
> it. My ramsize is 0x08000000.
> 
> Does u-boot uses any parts of ram by itself, I mean, is there any known
> spots where I can't test because it would crash my system?

U-Boot relocates itself into RAM. You can check the address using
'bdinfo' command (look at 'relocaddr' in the output). There are
also some data structures in RAM (global data, board info, stack,
malloc area) and also exception vectors. Where it is located in
RAM depends on your architecture and board configuration options.
You can try to define DEBUG in the arch board.c file to get more
info. Board config file should define CONFIG_SYS_MEMTEST_START and
CONFIG_SYS_MEMTEST_END to prevent crashing when mtest is invoked.

HTH,
Anatolij

[U-Boot] About mtest on boot

[Érico Porto]

Now I understood, LTIB is giving me an older u-boot version - 1.1.6 and not
2011.12. Will try to update it...

?rico V. Porto


On Fri, Jan 20, 2012 at 8:38 AM, Anatolij Gustschin <agust@denx.de> wrote:

> Hi,
>
> On Fri, 20 Jan 2012 08:07:41 -0200
> ?rico Porto <ericoporto2008@gmail.com> wrote:
>
> > Hello,
> >
> > I want to stop autoboot and use mtest to check if my ram is alright, but
> > 0x07FD2C00 forward freezes, and 0x00000902 also freezes, mtest, when
> using
> > it. My ramsize is 0x08000000.
> >
> > Does u-boot uses any parts of ram by itself, I mean, is there any known
> > spots where I can't test because it would crash my system?
>
> U-Boot relocates itself into RAM. You can check the address using
> 'bdinfo' command (look at 'relocaddr' in the output). There are
> also some data structures in RAM (global data, board info, stack,
> malloc area) and also exception vectors. Where it is located in
> RAM depends on your architecture and board configuration options.
> You can try to define DEBUG in the arch board.c file to get more
> info. Board config file should define CONFIG_SYS_MEMTEST_START and
> CONFIG_SYS_MEMTEST_END to prevent crashing when mtest is invoked.
>
> HTH,
> Anatolij
>

[U-Boot] About mtest on boot

[Érico Porto]

Okay, got 2011.12 working here.

Same problem, my system stalls when I try using mtest on low position of
the memory, but now I have the relocaddr var to tell me what is the
superior memory limit.

( I can't paste any output here because the list gives me a BASE ENCODE64
not allowed error... )

And if the system freezes during mtest, I can't ctrl+c out of it.

Is there any know workaround?

My system is much a like MPC8323ERDB. Other than that, seems I can run
linux fine on it after bootload, I just can't use mtest...

?rico V. Porto


On Fri, Jan 20, 2012 at 8:56 AM, ?rico Porto <ericoporto2008@gmail.com>wrote:

> Now I understood, LTIB is giving me an older u-boot version - 1.1.6 and
> not 2011.12. Will try to update it...
>
> ?rico V. Porto
>
>
>
> On Fri, Jan 20, 2012 at 8:38 AM, Anatolij Gustschin <agust@denx.de> wrote:
>
>> Hi,
>>
>> On Fri, 20 Jan 2012 08:07:41 -0200
>> ?rico Porto <ericoporto2008@gmail.com> wrote:
>>
>> > Hello,
>> >
>> > I want to stop autoboot and use mtest to check if my ram is alright, but
>> > 0x07FD2C00 forward freezes, and 0x00000902 also freezes, mtest, when
>> using
>> > it. My ramsize is 0x08000000.
>> >
>> > Does u-boot uses any parts of ram by itself, I mean, is there any known
>> > spots where I can't test because it would crash my system?
>>
>> U-Boot relocates itself into RAM. You can check the address using
>> 'bdinfo' command (look at 'relocaddr' in the output). There are
>> also some data structures in RAM (global data, board info, stack,
>> malloc area) and also exception vectors. Where it is located in
>> RAM depends on your architecture and board configuration options.
>> You can try to define DEBUG in the arch board.c file to get more
>> info. Board config file should define CONFIG_SYS_MEMTEST_START and
>> CONFIG_SYS_MEMTEST_END to prevent crashing when mtest is invoked.
>>
>> HTH,
>> Anatolij
>>
>
>

[U-Boot] About mtest on boot

[Érico Porto]

I've partially solved the ctrl+c situatin inserting more check for it into
the code. But this isn't really what I was hoping...

Any known alternatives? Thanks.

?rico V. Porto


On Fri, Jan 20, 2012 at 4:22 PM, ?rico Porto <ericoporto2008@gmail.com>wrote:

> Okay, got 2011.12 working here.
>
> Same problem, my system stalls when I try using mtest on low position of
> the memory, but now I have the relocaddr var to tell me what is the
> superior memory limit.
>
> ( I can't paste any output here because the list gives me a BASE ENCODE64
> not allowed error... )
>
> And if the system freezes during mtest, I can't ctrl+c out of it.
>
> Is there any know workaround?
>
> My system is much a like MPC8323ERDB. Other than that, seems I can run
> linux fine on it after bootload, I just can't use mtest...
>
> ?rico V. Porto
>
>
>
> On Fri, Jan 20, 2012 at 8:56 AM, ?rico Porto <ericoporto2008@gmail.com>wrote:
>
>> Now I understood, LTIB is giving me an older u-boot version - 1.1.6 and
>> not 2011.12. Will try to update it...
>>
>> ?rico V. Porto
>>
>>
>>
>> On Fri, Jan 20, 2012 at 8:38 AM, Anatolij Gustschin <agust@denx.de>wrote:
>>
>>> Hi,
>>>
>>> On Fri, 20 Jan 2012 08:07:41 -0200
>>> ?rico Porto <ericoporto2008@gmail.com> wrote:
>>>
>>> > Hello,
>>> >
>>> > I want to stop autoboot and use mtest to check if my ram is alright,
>>> but
>>> > 0x07FD2C00 forward freezes, and 0x00000902 also freezes, mtest, when
>>> using
>>> > it. My ramsize is 0x08000000.
>>> >
>>> > Does u-boot uses any parts of ram by itself, I mean, is there any known
>>> > spots where I can't test because it would crash my system?
>>>
>>> U-Boot relocates itself into RAM. You can check the address using
>>> 'bdinfo' command (look at 'relocaddr' in the output). There are
>>> also some data structures in RAM (global data, board info, stack,
>>> malloc area) and also exception vectors. Where it is located in
>>> RAM depends on your architecture and board configuration options.
>>> You can try to define DEBUG in the arch board.c file to get more
>>> info. Board config file should define CONFIG_SYS_MEMTEST_START and
>>> CONFIG_SYS_MEMTEST_END to prevent crashing when mtest is invoked.
>>>
>>> HTH,
>>> Anatolij
>>>
>>
>>
>

[U-Boot] About mtest on boot

[Érico Porto]

isn't U-boot's address given by the relocadrr variable? If it is so, it is
already at the end of ram and I'm giving a smaller end address to the ram -
I'm getting relocaddr 0x07fcd000 and using this minus 0x01000 as ending
position...

?rico V. Porto


On Sat, Jan 21, 2012 at 2:21 PM, amruth vamadev <amruth.vamadev@gmail.com>wrote:

> Hi
> Erico
> Possibly you are overwriting your u-boot code hence causing the
> hang.You need to move your uboot code to end of DDR and you should be
> able to test your RAM.You need to change the entry point and reset
> vector and you can read using readelf using u-boot.
> Thanks
> Amruth p.v
>
> On Sat, Jan 21, 2012 at 2:01 AM, ?rico Porto <ericoporto2008@gmail.com>
> wrote:
> > I've partially solved the ctrl+c situatin inserting more check for it
> into
> > the code. But this isn't really what I was hoping...
> >
> > Any known alternatives? Thanks.
> >
> > ?rico V. Porto
> >
> >
> > On Fri, Jan 20, 2012 at 4:22 PM, ?rico Porto <ericoporto2008@gmail.com
> >wrote:
> >
> >> Okay, got 2011.12 working here.
> >>
> >> Same problem, my system stalls when I try using mtest on low position of
> >> the memory, but now I have the relocaddr var to tell me what is the
> >> superior memory limit.
> >>
> >> ( I can't paste any output here because the list gives me a BASE
> ENCODE64
> >> not allowed error... )
> >>
> >> And if the system freezes during mtest, I can't ctrl+c out of it.
> >>
> >> Is there any know workaround?
> >>
> >> My system is much a like MPC8323ERDB. Other than that, seems I can run
> >> linux fine on it after bootload, I just can't use mtest...
> >>
> >> ?rico V. Porto
> >>
> >>
> >>
> >> On Fri, Jan 20, 2012 at 8:56 AM, ?rico Porto <ericoporto2008@gmail.com
> >wrote:
> >>
> >>> Now I understood, LTIB is giving me an older u-boot version - 1.1.6 and
> >>> not 2011.12. Will try to update it...
> >>>
> >>> ?rico V. Porto
> >>>
> >>>
> >>>
> >>> On Fri, Jan 20, 2012 at 8:38 AM, Anatolij Gustschin <agust@denx.de
> >wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> On Fri, 20 Jan 2012 08:07:41 -0200
> >>>> ?rico Porto <ericoporto2008@gmail.com> wrote:
> >>>>
> >>>> > Hello,
> >>>> >
> >>>> > I want to stop autoboot and use mtest to check if my ram is alright,
> >>>> but
> >>>> > 0x07FD2C00 forward freezes, and 0x00000902 also freezes, mtest, when
> >>>> using
> >>>> > it. My ramsize is 0x08000000.
> >>>> >
> >>>> > Does u-boot uses any parts of ram by itself, I mean, is there any
> known
> >>>> > spots where I can't test because it would crash my system?
> >>>>
> >>>> U-Boot relocates itself into RAM. You can check the address using
> >>>> 'bdinfo' command (look at 'relocaddr' in the output). There are
> >>>> also some data structures in RAM (global data, board info, stack,
> >>>> malloc area) and also exception vectors. Where it is located in
> >>>> RAM depends on your architecture and board configuration options.
> >>>> You can try to define DEBUG in the arch board.c file to get more
> >>>> info. Board config file should define CONFIG_SYS_MEMTEST_START and
> >>>> CONFIG_SYS_MEMTEST_END to prevent crashing when mtest is invoked.
> >>>>
> >>>> HTH,
> >>>> Anatolij
> >>>>
> >>>
> >>>
> >>
> >
> > _______________________________________________
> > U-Boot mailing list
> > U-Boot at lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> >
>

[U-Boot] About mtest on boot

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?=C9rico_Porto?=,

In message <CAG1KTJeGL3m69Knr9TOkHqgzrKsNRzZjqFCH9fnvM5G+6Wa7NA@mail.gmail.com> you wrote:
>
> isn't U-boot's address given by the relocadrr variable? If it is so, it is
> already at the end of ram and I'm giving a smaller end address to the ram -
> I'm getting relocaddr 0x07fcd000 and using this minus 0x01000 as ending
> position...

0x01000 = 4 kB is way too small.  Consider that U-Boot will need space
to reserver for it's malloc arena, for global data, and for the stack.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
People have one thing in common: they are all different.

[U-Boot] About mtest on boot

[Érico Porto]

Ok, this makes sense, but I think you mean:

memory start at 0x00000000

mtest {
start address: right after (malloc area+global data + stack)
end address: relocaddr
}

memory end at 0x08000000

...

?rico V. Porto


On Mon, Jan 23, 2012 at 12:23 PM, Wolfgang Denk <wd@denx.de> wrote:

> Dear =?ISO-8859-1?Q?=C9rico_Porto?=,
>
> In message <
> CAG1KTJeGL3m69Knr9TOkHqgzrKsNRzZjqFCH9fnvM5G+6Wa7NA at mail.gmail.com> you
> wrote:
> >
> > isn't U-boot's address given by the relocadrr variable? If it is so, it
> is
> > already at the end of ram and I'm giving a smaller end address to the
> ram -
> > I'm getting relocaddr 0x07fcd000 and using this minus 0x01000 as ending
> > position...
>
> 0x01000 = 4 kB is way too small.  Consider that U-Boot will need space
> to reserver for it's malloc arena, for global data, and for the stack.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> People have one thing in common: they are all different.
>

[U-Boot] About mtest on boot

[Wolfgang Denk]

Dear =?ISO-8859-1?Q?=C9rico_Porto?=,

Please stop top posting / full quoting.

In message <CAG1KTJebU-QhhH2=iBFOjSJJvAynH4hRfuzoBnwZ20UZq-5JLw@mail.gmail.com> you wrote:
>
> Ok, this makes sense, but I think you mean:

No, I mean what I mean, not what you think I mean.

> memory start at 0x00000000
> 
> mtest {
> start address: right after (malloc area+global data + stack)
> end address: relocaddr
> }
> 
> memory end at 0x08000000

Wrong.

Assuming you have a simple configuration (no pRAM, no log buffer, no
video buffer etc.) then the memory map (as explained in the README,
btw) is like that:

top of RAM (in your case 0x08000000 - 1)
...	U-Boot code, data and bss
relocaddr
...	Malloc Arena
...	Board Info Data and permanent copy of global data
...	Stack (growing downward)


Depending on the size of your malloc arena you need to stay far enough
away from relocaddr;  try with 1 MB or more.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                           -- H. L. Mencken

[U-Boot] About mtest on boot

[Érico Porto]

Oh, found the Memory Management section, thanks! And it also explains that
stuff should be written after 0x0000 2000 because of the exception vector -
actually, I thinks this is a bit bigger here in my system, but now makes
sense why I was also getting crashes at the beginning of the memory!

?rico V. Porto


On Mon, Jan 23, 2012 at 12:45 PM, Wolfgang Denk <wd@denx.de> wrote:

> Dear =?ISO-8859-1?Q?=C9rico_Porto?=,
>
> Please stop top posting / full quoting.
>
> In message <CAG1KTJebU-QhhH2=
> iBFOjSJJvAynH4hRfuzoBnwZ20UZq-5JLw at mail.gmail.com> you wrote:
> >
> > Ok, this makes sense, but I think you mean:
>
> No, I mean what I mean, not what you think I mean.
>
> > memory start at 0x00000000
> >
> > mtest {
> > start address: right after (malloc area+global data + stack)
> > end address: relocaddr
> > }
> >
> > memory end at 0x08000000
>
> Wrong.
>
> Assuming you have a simple configuration (no pRAM, no log buffer, no
> video buffer etc.) then the memory map (as explained in the README,
> btw) is like that:
>
> top of RAM (in your case 0x08000000 - 1)
> ...     U-Boot code, data and bss
> relocaddr
> ...     Malloc Arena
> ...     Board Info Data and permanent copy of global data
> ...     Stack (growing downward)
>
>
> Depending on the size of your malloc arena you need to stay far enough
> away from relocaddr;  try with 1 MB or more.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> For every complex problem, there is a solution that is simple,  neat,
> and wrong.                                           -- H. L. Mencken
>