* [U-Boot] About mtest on boot @ 2012-01-20 10:07 Érico Porto 2012-01-20 10:38 ` Anatolij Gustschin 0 siblings, 1 reply; 10+ messages in thread From: Érico Porto @ 2012-01-20 10:07 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] About mtest on boot 2012-01-20 10:07 [U-Boot] About mtest on boot Érico Porto @ 2012-01-20 10:38 ` Anatolij Gustschin 2012-01-20 10:56 ` Érico Porto 0 siblings, 1 reply; 10+ messages in thread From: Anatolij Gustschin @ 2012-01-20 10:38 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] About mtest on boot 2012-01-20 10:38 ` Anatolij Gustschin @ 2012-01-20 10:56 ` Érico Porto 2012-01-20 18:22 ` Érico Porto 0 siblings, 1 reply; 10+ messages in thread From: Érico Porto @ 2012-01-20 10:56 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] About mtest on boot 2012-01-20 10:56 ` Érico Porto @ 2012-01-20 18:22 ` Érico Porto 2012-01-20 20:31 ` Érico Porto 0 siblings, 1 reply; 10+ messages in thread From: Érico Porto @ 2012-01-20 18:22 UTC (permalink / raw) To: u-boot 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 >> > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] About mtest on boot 2012-01-20 18:22 ` Érico Porto @ 2012-01-20 20:31 ` Érico Porto [not found] ` <CAL5DGCR2QH0f1bgm8x6wGsxdbqkcCdiYFMo6ST49CYwyHVnxXQ@mail.gmail.com> 0 siblings, 1 reply; 10+ messages in thread From: Érico Porto @ 2012-01-20 20:31 UTC (permalink / raw) To: u-boot 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 >>> >> >> > ^ permalink raw reply [flat|nested] 10+ messages in thread
[parent not found: <CAL5DGCR2QH0f1bgm8x6wGsxdbqkcCdiYFMo6ST49CYwyHVnxXQ@mail.gmail.com>]
* [U-Boot] About mtest on boot [not found] ` <CAL5DGCR2QH0f1bgm8x6wGsxdbqkcCdiYFMo6ST49CYwyHVnxXQ@mail.gmail.com> @ 2012-01-23 10:37 ` Érico Porto 2012-01-23 14:23 ` Wolfgang Denk 0 siblings, 1 reply; 10+ messages in thread From: Érico Porto @ 2012-01-23 10:37 UTC (permalink / raw) To: u-boot 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 > > > ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] About mtest on boot 2012-01-23 10:37 ` Érico Porto @ 2012-01-23 14:23 ` Wolfgang Denk 2012-01-23 14:35 ` Érico Porto 0 siblings, 1 reply; 10+ messages in thread From: Wolfgang Denk @ 2012-01-23 14:23 UTC (permalink / raw) To: 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 -- 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] About mtest on boot 2012-01-23 14:23 ` Wolfgang Denk @ 2012-01-23 14:35 ` Érico Porto 2012-01-23 14:45 ` Wolfgang Denk 0 siblings, 1 reply; 10+ messages in thread From: Érico Porto @ 2012-01-23 14:35 UTC (permalink / raw) To: u-boot 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. > ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] About mtest on boot 2012-01-23 14:35 ` Érico Porto @ 2012-01-23 14:45 ` Wolfgang Denk 2012-01-23 15:04 ` Érico Porto 0 siblings, 1 reply; 10+ messages in thread From: Wolfgang Denk @ 2012-01-23 14:45 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] About mtest on boot 2012-01-23 14:45 ` Wolfgang Denk @ 2012-01-23 15:04 ` Érico Porto 0 siblings, 0 replies; 10+ messages in thread From: Érico Porto @ 2012-01-23 15:04 UTC (permalink / raw) To: u-boot 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-01-23 15:04 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-20 10:07 [U-Boot] About mtest on boot Érico Porto
2012-01-20 10:38 ` Anatolij Gustschin
2012-01-20 10:56 ` Érico Porto
2012-01-20 18:22 ` Érico Porto
2012-01-20 20:31 ` Érico Porto
[not found] ` <CAL5DGCR2QH0f1bgm8x6wGsxdbqkcCdiYFMo6ST49CYwyHVnxXQ@mail.gmail.com>
2012-01-23 10:37 ` Érico Porto
2012-01-23 14:23 ` Wolfgang Denk
2012-01-23 14:35 ` Érico Porto
2012-01-23 14:45 ` Wolfgang Denk
2012-01-23 15:04 ` Érico Porto
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.