[U-Boot] Memory test post relocation
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.
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,
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-tp196088p19618... Sent from the U-Boot mailing list archive at Nabble.com.
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.
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-tp196088p19618... Sent from the U-Boot mailing list archive at Nabble.com.
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 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-tp196088p19619... Sent from the U-Boot mailing list archive at Nabble.com.
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-tp196088p19619... Sent from the U-Boot mailing list archive at Nabble.com.
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,
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 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-tp196088p19621... Sent from the U-Boot mailing list archive at Nabble.com.
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-tp196088p19622... Sent from the U-Boot mailing list archive at Nabble.com.
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-tp196088p19625... Sent from the U-Boot mailing list archive at Nabble.com.
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,
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,
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,
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
participants (4)
-
Albert ARIBAUD -
DaveKucharczyk -
Fabio Estevam -
Wolfgang Denk