[U-Boot] Memory test post relocation

[U-Boot] Memory test post relocation

[DaveKucharczyk]

We have 2GB?s of RAM starting at 0x70000000 on our Freescale MX53 based
board. 

With old U-Boot we defined TEXT_BASE at the bottom of RAM at 0x70600000 and
CONFIG_SKIP_RELOCATE_UBOOT, presumably so that we can run memory tests all
the way to the top of RAM (this was brought over from the mx53loco board and
precedes me). Why else would CONFIG_SKIP_RELOCATE_UBOOT be set? 

In new U-Boot we are not skipping relocation. I define CONFIG_SYS_TEXT_BASE
= 0xeff89000 so that relocation offset is 0x00000000.

I run with DEBUG on to doublecheck where things get setup?

I run a memory test from 0x70000000 to 0xefe88cb0, but I get a mismatch fail
at 0xefe88aa4.

Shouldn?t I be able to run mem test all the way to the stack? I don?t see
anything else being setup under the stack.




--
View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Memory test post relocation

[Albert ARIBAUD]

Hello Dave,

On Thu, 13 Nov 2014 15:19:20 -0700 (MST), DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> We have 2GB?s of RAM starting at 0x70000000 on our Freescale MX53
> based board. 
> 
> With old U-Boot we defined TEXT_BASE at the bottom of RAM at
> 0x70600000 and CONFIG_SKIP_RELOCATE_UBOOT, presumably so that we can
> run memory tests all the way to the top of RAM (this was brought over
> from the mx53loco board and precedes me). Why else would
> CONFIG_SKIP_RELOCATE_UBOOT be set? 

CONFIG_SKIP_RELOCATE_UBOOT is not used in U-Boot nowadays [but is still
defined by target snapper9260, which means either that target is
utterly broken, or it does not actually need the option].

> In new U-Boot we are not skipping relocation. I define
> CONFIG_SYS_TEXT_BASE = 0xeff89000 so that relocation offset is
> 0x00000000.

Baaad, bad. The first time you change something in your code, your
relocation offset might change and this will make U-Boot crash and
burn in interesting ways.

Just define CONFIG_SYS_TEXT_BASE to some low address and let relocation
happen. You can find your actual relocation address in the global data
structure.

> I run with DEBUG on to doublecheck where things get setup?

(typically, builds with and without DEBUG will have differing relocation
addresses)

> I run a memory test from 0x70000000 to 0xefe88cb0, but I get a
> mismatch fail at 0xefe88aa4.
> 
> Shouldn?t I be able to run mem test all the way to the stack? I don?t
> see anything else being setup under the stack.

How do you know the lowest address used by your stack during your memory
test?

Amicalement,
-- 
Albert.

[U-Boot] Memory test post relocation

[DaveKucharczyk]

Hi Albert,
Thanks for the great information.

Albert ARIBAUD (U-Boot) wrote
>  Baaad, bad. The first time you change something in your code, your
> relocation offset might change and this will make U-Boot crash and burn in
> interesting ways.
> 
> Just define CONFIG_SYS_TEXT_BASE to some low address and let relocation
> happen. You can find your actual relocation address in the global data
> structure. 

If I set CONFIG_SYS_TEXT_BASE to a low address then I can't run a memory
test starting at the lowest address because that's where the U-Boot code
will be. 

I think the best thing would be to run a memory test on the full 2GB before
relocation happens. Is that possible? 

Albert ARIBAUD (U-Boot) wrote
> How do you know the lowest address used by your stack during your memory
> test?

I know the address of the stack pointer from DEBUG message...

I erroneously thought that was the beginning of the stack. The stack expands
down form that address, but how much?  I don't see a global data stack size
variable.

Before, we have #define CONFIG_STACKSIZE	(128 * 1024) set in the header
file.     

Basically what is the best way to run the memory test? If I can run it
before relocation then it would make things very simple. 



--
View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196181.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Memory test post relocation

[Fabio Estevam]

On Fri, Nov 14, 2014 at 12:18 PM, DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:

> Basically what is the best way to run the memory test? If I can run it
> before relocation then it would make things very simple.

You could boot the kernel and then run 'memtester' overnight utility
for example.

[U-Boot] Memory test post relocation

[DaveKucharczyk]

Fabio Estevam-2 wrote
> You could boot the kernel and then run 'memtester' overnight utility
> for example.

Let's say that it has to run in U-Boot otherwise a test fixture would have
to be redesigned. Running it as early as possible, like in U-Boot, saves a
lot of time in the case of bad boards.  





--
View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196183.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Memory test post relocation

[Albert ARIBAUD]

Hello Dave,

On Fri, 14 Nov 2014 07:18:58 -0700 (MST), DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> Hi Albert,
> Thanks for the great information.
> 
> Albert ARIBAUD (U-Boot) wrote
> >  Baaad, bad. The first time you change something in your code, your
> > relocation offset might change and this will make U-Boot crash and burn in
> > interesting ways.
> > 
> > Just define CONFIG_SYS_TEXT_BASE to some low address and let relocation
> > happen. You can find your actual relocation address in the global data
> > structure. 
> 
> If I set CONFIG_SYS_TEXT_BASE to a low address then I can't run a memory
> test starting at the lowest address because that's where the U-Boot code
> will be. 

No, that's not where it'll be; it'll relocate as high as it can.

> I think the best thing would be to run a memory test on the full 2GB before
> relocation happens. Is that possible? 

Not with U-Boot in DDR. :)

> Albert ARIBAUD (U-Boot) wrote
> > How do you know the lowest address used by your stack during your memory
> > test?
> 
> I know the address of the stack pointer from DEBUG message...

So you know it *at a given time*, but you have no assurance that it
won't go further down.

> I erroneously thought that was the beginning of the stack. The stack expands
> down form that address, but how much?  I don't see a global data stack size
> variable.

There is none physically, i.e. that's just the size you reserve for it,
but it could grow beyond that, although it's not likely. Still, that
means you don't test all DDR.

> Before, we have #define CONFIG_STACKSIZE	(128 * 1024) set in the header
> file.     
> 
> Basically what is the best way to run the memory test? If I can run it
> before relocation then it would make things very simple. 

If you happen to have an SPL running from some RAM and not from DDR,
then you could perform the full DDR test there.

Amicalement,
-- 
Albert.

[U-Boot] Memory test post relocation

[DaveKucharczyk]

Albert ARIBAUD (U-Boot) wrote
> No, that's not where it'll be; it'll relocate as high as it can.

I guess that's the confusing part. When I run with debug on I get the
following log. Halfway down it reports "Now running in RAM - U-Boot at:
eff89000", but there are still initcall's to lower memory after that. So I'm
thinking lower memory is still used at that point. Am I wrong? 

I did try a mem test starting at the lowest address and it worked, but I
would like to understand why the initcall's to low-mem after relocation. 
The mem test essentially erases those addresses, so initcall's to those
addresses are suspect at that point. 

Albert ARIBAUD (U-Boot) wrote
> If you happen to have an SPL running from some RAM and not from DDR,
> then you could perform the full DDR test there. .

I think the mx53 has internal sram, which is why we were able to run fully
from there before, since we had set CONFIG_SKIP_RELOCATE_UBOOT. I tried
setting CONFIG_SKIP_LOWLEVEL_INIT, but nothing works with that set. 




--
View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196196.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Memory test post relocation

[DaveKucharczyk]

btw, I'm using nabble to post, but notice my  code snippets don't show up in
the mailing list, which I assume most of you guys are using.




--
View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196197.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Memory test post relocation

[Albert ARIBAUD]

Hello DaveKucharczyk,

On Fri, 14 Nov 2014 09:07:50 -0700 (MST), DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> btw, I'm using nabble to post, but notice my  code snippets don't show up in
> the mailing list, which I assume most of you guys are using.

Maybe it's just as well -- if you post full diffs, then our Patchwork
is going to believe you're submitting a patch to U-Boot. :)

Amicalement,
-- 
Albert.

[U-Boot] Memory test post relocation

[Albert ARIBAUD]

Hello DaveKucharczyk,

On Fri, 14 Nov 2014 08:54:20 -0700 (MST), DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> Albert ARIBAUD (U-Boot) wrote
> > No, that's not where it'll be; it'll relocate as high as it can.
> 
> I guess that's the confusing part. When I run with debug on I get the
> following log. Halfway down it reports "Now running in RAM - U-Boot at:
> eff89000", but there are still initcall's to lower memory after that. So I'm
> thinking lower memory is still used at that point. Am I wrong? 
>
> I did try a mem test starting at the lowest address and it worked, but I
> would like to understand why the initcall's to low-mem after relocation. 
> The mem test essentially erases those addresses, so initcall's to those
> addresses are suspect at that point. 

You're correct that they'd be suspect; but the calls are to high
addresses, only the debug printf() prints their address... minus the
reloc offset (why it does that is beyond me). So false alarm here.

So, no, you don't use lower mem once relocated. But you do use some
memory below the stack top, and you dont exactly know how much.

> Albert ARIBAUD (U-Boot) wrote
> > If you happen to have an SPL running from some RAM and not from DDR,
> > then you could perform the full DDR test there. .
> 
> I think the mx53 has internal sram, which is why we were able to run fully
> from there before, since we had set CONFIG_SKIP_RELOCATE_UBOOT. I tried
> setting CONFIG_SKIP_LOWLEVEL_INIT, but nothing works with that set. 

Still not sure what your config is. Can you indicate the board, commit
and toolchain you're using?

Amicalement,
-- 
Albert.

[U-Boot] Memory test post relocation

[DaveKucharczyk]

Albert ARIBAUD (U-Boot) wrote
> Still not sure what your config is. Can you indicate the board, commit
> and toolchain you're using?

We're using a board based on the Freescale mx53loco. 
u-boot-2014.07
toolchain = armv7l-timesys-linux-gnueabi
Libc = ldd (GNU libc) 2.12
gcc = gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)




--
View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196211.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Memory test post relocation

[DaveKucharczyk]

Old u-boot was u-boot-2009.08.

I guess the main source of frustration the last 3 weeks could be attributed
to my lack of experience with u-boot and the fact that we were working with
an old Freescale version of u-boot. Not to mention 5 years worth of changes
between the versions.  Most of the init functions seem to have moved in the
boot sequence between u-boot-2009.08 and u-boot-2014.07. For instance,
board_init was one of the first functions called before relocation to RAM,
but now it called after relocation. 

I have our board almost fully working with mainline u-boot-2014.07, but now
I'm just trying to understand a few how's and why's before continuing.   

In u-boot-2009.08 we set CONFIG_SKIP_RELOCATE_UBOOT. When I run with DEBUG
on I confirm that no relocation messages are reported, but this is due to
the fact that u-boot-2009.08 did not have debug messages pertaining to
relocation (that I can tell). I'm not sure how to confirm that relocation
didn't actually happen and where it actually runs from on the mx53, but I
can confirm that memory tests ran all the way to the end of RAM without
issue. We did run the test from within dram_init though, which would be
before relocation. Too bad that doesn't work in u-boot-2014.07.  



--
View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196228.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Memory test post relocation

[DaveKucharczyk]

If I set CONFIG_SYS_TEXT_BASE to start of RAM then I get no boot. Is there
some kind of vector setup at the beginning of RAM? 
Have a good weekend everybody. 
Cheers,
Dave




--
View this message in context: http://u-boot.10912.n7.nabble.com/Memory-test-post-relocation-tp196088p196254.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] Memory test post relocation

[Albert ARIBAUD]

Hello DaveKucharczyk,

On Fri, 14 Nov 2014 15:22:43 -0700 (MST), DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> If I set CONFIG_SYS_TEXT_BASE to start of RAM then I get no boot. Is there
> some kind of vector setup at the beginning of RAM? 

Possibly. Why not use 0x77800000 as mx53loco uses now? It's not like
the value matters much, as whatever it is, U-Boot will relocate itself
as high as possible.

> Have a good weekend everybody. 
> Cheers,
> Dave

Amicalement,
-- 
Albert.

[U-Boot] Memory test post relocation

[Albert ARIBAUD]

Hello DaveKucharczyk,

On Fri, 14 Nov 2014 13:20:09 -0700 (MST), DaveKucharczyk
<david.kucharczyk@gmail.com> wrote:
> Old u-boot was u-boot-2009.08.
> 
> I guess the main source of frustration the last 3 weeks could be attributed
> to my lack of experience with u-boot and the fact that we were working with
> an old Freescale version of u-boot. Not to mention 5 years worth of changes
> between the versions.  Most of the init functions seem to have moved in the
> boot sequence between u-boot-2009.08 and u-boot-2014.07. For instance,
> board_init was one of the first functions called before relocation to RAM,
> but now it called after relocation. 

When porting from a 5-years old version, you should think less in terms
of function names and more in terms of functionality. Names can change,
but setting chip selects or base address registers remains the same.
It's a matter of porting the functionality.

> I have our board almost fully working with mainline u-boot-2014.07, but now
> I'm just trying to understand a few how's and why's before continuing.   
> 
> In u-boot-2009.08 we set CONFIG_SKIP_RELOCATE_UBOOT. When I run with DEBUG
> on I confirm that no relocation messages are reported, but this is due to
> the fact that u-boot-2009.08 did not have debug messages pertaining to
> relocation (that I can tell). I'm not sure how to confirm that relocation
> didn't actually happen and where it actually runs from on the mx53, but I
> can confirm that memory tests ran all the way to the end of RAM without
> issue. We did run the test from within dram_init though, which would be
> before relocation. Too bad that doesn't work in u-boot-2014.07.  

Wolfgang and myself at least have already toched on the subject:
testing /all/ of the DDR is simply *not* possible, so whether your
tests can go all the way to the end of the DDR (or start from as low as
the DDR start) is not really relevant, since in any case, they will
necessarily miss some other part of the DDR address space.

If you *need* to test all of the DDR, then you *must* do it from code
running in non-DDR RAM, eiher IRAM or locked cache; and since these are
usually small, you probably have to do it from SPL, no U-Boot (which
makes sense, since you should not load U-Boot into DDR before having
tested it).

Amicalement,
-- 
Albert.

[U-Boot] Memory test post relocation

[Albert ARIBAUD]

On Sat, 15 Nov 2014 13:26:49 +0100, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:

> Wolfgang and myself at least have already toched on the subject:

s/toched/touched/

Amicalement,
-- 
Albert.

[U-Boot] Memory test post relocation

[Wolfgang Denk]

Dear DaveKucharczyk,

In message <1415974738890-196181.post@n7.nabble.com> you wrote:
>
> If I set CONFIG_SYS_TEXT_BASE to a low address then I can't run a memory
> test starting at the lowest address because that's where the U-Boot code
> will be. 

If U-Boot is runnign from RAM there will always be areas where U-Boot
is sitting and which cannot be tested.

> I think the best thing would be to run a memory test on the full 2GB before
> relocation happens. Is that possible? 

Not when running from RAM.  This is only possible when running from
NOR flash or from some other memory region.  Once you loaded U-Boot to
RAM, the RAM will be, well, it will be used, and you cannot test all
of it.

> I erroneously thought that was the beginning of the stack. The stack expands
> down form that address, but how much?  I don't see a global data stack size
> variable.

The stack grows downward without bounds.  There is no limit on the
stack size.

> Before, we have #define CONFIG_STACKSIZE	(128 * 1024) set in the header
> file.     

This does not do what you think it might be doing.

> Basically what is the best way to run the memory test? If I can run it
> before relocation then it would make things very simple. 

You have to make sure to use the right terms.  "Before relocation" is
only useful here for example for systems booting from NOR flash, where
"before relocation" means that you are running from flash, and the
whole RAM is actually not used by U-Boot at all.  If you boot from
NAND or SDCard or similar, you will probably load U-Boot to RAM -
either though the ROM boot loader, or through SPL - and from this
moment the RAM is used, and certain areas cannot be tested any more.

If you use SPL, and the SPL is for example running from on-chip-memory
or other kind of static memory, then you could try adding the memory
test to SPL, i. e. perform the test before loading U-Boot to RAM at
all.

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
You can only live once, but if you do it right, once is enough.