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.comwrote:
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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
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@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@denx.de People have one thing in common: they are all different.
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
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@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@denx.de For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken
participants (2)
-
Wolfgang Denk -
Érico Porto