[U-Boot] [PATCH] arm: Add option to disable code relocation
This permits disabling the code relation in U-Boot which is useful when debugging with an ICE.
To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
Signed-off-by: Simon Glass sjg@chromium.org --- arch/arm/config.mk | 2 ++ arch/arm/cpu/armv7/start.S | 3 +-- arch/arm/include/asm/global_data.h | 3 +++ arch/arm/lib/board.c | 10 ++++++++++ 4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 45f9dca..46b52af 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -79,5 +79,7 @@ endif
# needed for relocation ifndef CONFIG_NAND_SPL +ifndef CONFIG_SYS_SKIP_ARM_RELOCATION LDFLAGS_u-boot += -pie endif +endif diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index ef08a55..82eac7c 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -183,8 +183,7 @@ stack_setup: mov sp, r4
adr r0, _start - cmp r0, r6 - moveq r9, #0 /* no relocation. relocation offset(r9) = 0 */ + subs r9, r6, r0 /* r9 <- relocation offset */ beq clear_bss /* skip relocation */ mov r1, r6 /* r1 <- scratch for copy_loop */ ldr r3, _image_copy_end_ofs diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index c3ff789..23a6077 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -77,6 +77,9 @@ typedef struct global_data { unsigned long tlb_addr; #endif const void *fdt_blob; /* Our device tree, NULL if none */ +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION + ulong malloc_end; /* End of malloc region (addr + 1) */ +#endif void **jt; /* jump table */ char env_buf[32]; /* buffer for getenv() before reloc. */ #if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 3d78274..81293c3 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -355,6 +355,7 @@ void board_init_f(ulong bootflag) #endif /* CONFIG_FB_ADDR */ #endif /* CONFIG_LCD */
+#ifndef CONFIG_SYS_SKIP_ARM_RELOCATION /* * reserve memory for U-Boot code, data & bss * round down to next 4 kB limit @@ -363,6 +364,7 @@ void board_init_f(ulong bootflag) addr &= ~(4096 - 1);
debug("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10, addr); +#endif
#ifndef CONFIG_SPL_BUILD /* @@ -419,6 +421,10 @@ void board_init_f(ulong bootflag) dram_init_banksize(); display_dram_config(); /* and display it */
+#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION + gd->malloc_end = addr; + addr = _TEXT_BASE; +#endif gd->relocaddr = addr; gd->start_addr_sp = addr_sp; gd->reloc_off = addr - _TEXT_BASE; @@ -478,7 +484,11 @@ void board_init_r(gd_t *id, ulong dest_addr) #endif
/* The Malloc area is immediately below the monitor copy in DRAM */ +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION + malloc_start = gd->malloc_end - TOTAL_MALLOC_LEN; +#else malloc_start = dest_addr - TOTAL_MALLOC_LEN; +#endif mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
#if !defined(CONFIG_SYS_NO_FLASH)
On Sunday 05 February 2012 07:05:13 Marek Vasut wrote:
On Sunday 05 February 2012 01:44:19 Simon Glass wrote:
This permits disabling the code relation in U-Boot which is useful when debugging with an ICE.
To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
any reason for "ARM" in there ?
Because this is only for ARM?
yes, *this* patch only touches arm code, but that doesn't mean it needs to be scoped that way from the start -mike
Hi Mike, Wolfgang,
On Sun, Feb 5, 2012 at 12:38 PM, Mike Frysinger vapier@gentoo.org wrote:
On Sunday 05 February 2012 07:05:13 Marek Vasut wrote:
On Sunday 05 February 2012 01:44:19 Simon Glass wrote:
This permits disabling the code relation in U-Boot which is useful when debugging with an ICE.
To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
any reason for "ARM" in there ?
Because this is only for ARM?
yes, *this* patch only touches arm code, but that doesn't mean it needs to be scoped that way from the start
This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch.
Regards, Simon
-mike
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Dear Simon Glass,
In message CAPnjgZ2Z0ojdLHz6yd5UuWru7pmJBLeogHzhK7rWGWk46xxqpA@mail.gmail.com you wrote:
This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch.
Sorry, as I see it your chances to get this in are epsilon.
Best regards,
Wolfgang Denk
Hi Wolfgang, Simon,
On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2Z0ojdLHz6yd5UuWru7pmJBLeogHzhK7rWGWk46xxqpA@mail.gmail.com you wrote:
This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch.
Sorry, as I see it your chances to get this in are epsilon.
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
And this can be wrapped:
#ifdef CONFIG_SYS_SKIP_RELOC SKIP_INIT(RELOC) #endif
Done ;)
Regards,
Graeme
Hi Graeme,
On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Wolfgang, Simon,
On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2Z0ojdLHz6yd5UuWru7pmJBLeogHzhK7rWGWk46xxqpA@mail.gmail.com you wrote:
This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch.
Sorry, as I see it your chances to get this in are epsilon.
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
And this can be wrapped:
#ifdef CONFIG_SYS_SKIP_RELOC SKIP_INIT(RELOC) #endif
Done ;)
Which reminds me - did you do that pull request for your x86 refactor? If not, what is the plan?
Regards, Simon
Regards,
Graeme
Hi Simon
On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Wolfgang, Simon,
On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2Z0ojdLHz6yd5UuWru7pmJBLeogHzhK7rWGWk46xxqpA@mail.gmail.com you wrote:
This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch.
Sorry, as I see it your chances to get this in are epsilon.
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
And this can be wrapped:
#ifdef CONFIG_SYS_SKIP_RELOC SKIP_INIT(RELOC) #endif
Done ;)
Which reminds me - did you do that pull request for your x86 refactor? If not, what is the plan?
I pushed the changes into the x86 sub-repo but noticed a minor glitch which breaks the build. On top of that, I've upgraded my dev machine to a 64-bit arch, moved from Ubuntu to Fedora and got a dud motherboard in the mix. So my dev machine is only just now back online, but I need to sort out the last few 64-bit build issues (which require U-Boot patches) and fix up the x86 sub-repo before sending the pull request.
Sorry for the dealy, but hopefully I'll have it all sorted by the end of the week
Regards,
Graeme
Hi Graeme,
On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon
On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Sun, Feb 5, 2012 at 3:23 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Wolfgang, Simon,
On Mon, Feb 6, 2012 at 9:44 AM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2Z0ojdLHz6yd5UuWru7pmJBLeogHzhK7rWGWk46xxqpA@mail.gmail.com you wrote:
This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch.
Sorry, as I see it your chances to get this in are epsilon.
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
And this can be wrapped:
#ifdef CONFIG_SYS_SKIP_RELOC SKIP_INIT(RELOC) #endif
Done ;)
Which reminds me - did you do that pull request for your x86 refactor? If not, what is the plan?
I pushed the changes into the x86 sub-repo but noticed a minor glitch which breaks the build. On top of that, I've upgraded my dev machine to a 64-bit arch, moved from Ubuntu to Fedora and got a dud motherboard in the mix. So my dev machine is only just now back online, but I need to sort out the last few 64-bit build issues (which require U-Boot patches) and fix up the x86 sub-repo before sending the pull request.
Sorry for the dealy, but hopefully I'll have it all sorted by the end of the week
OK thanks for the update. Would be keen to get my generic board stuff tested on x86 also, but that might be a separate problem. For initcalls, are you still thinking of looking at that?
Regards, Simon
Regards,
Graeme
Hi Simon,
On Mon, Feb 6, 2012 at 10:41 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon
[snip]
Sorry for the dealy, but hopefully I'll have it all sorted by the end of the week
OK thanks for the update. Would be keen to get my generic board stuff tested on x86 also, but that might be a separate problem. For initcalls, are you still thinking of looking at that?
I have already started work on it - I have a dedicated linker script which produces the binary file containin the dependancy information and the helper-tool to process it is underway - It currently strips out all the textual information, just need to build the code which sorts it and generates the C file
Regards,
Graeme
Hi Simon,
On 02/06/2012 10:41 AM, Simon Glass wrote:
Hi Graeme,
On Sun, Feb 5, 2012 at 3:37 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon
On Mon, Feb 6, 2012 at 10:32 AM, Simon Glass sjg@chromium.org wrote:
Hi Graeme,
[snip]
Which reminds me - did you do that pull request for your x86 refactor? If not, what is the plan?
I pushed the changes into the x86 sub-repo but noticed a minor glitch which breaks the build. On top of that, I've upgraded my dev machine to a 64-bit arch, moved from Ubuntu to Fedora and got a dud motherboard in the mix. So my dev machine is only just now back online, but I need to sort out the last few 64-bit build issues (which require U-Boot patches) and fix up the x86 sub-repo before sending the pull request.
OK, it turned out there was no glitch - In the process of upgrading my dev PC my local git repo git a bit confused (I think the timestamps went off into lala land). Anyway, I backed-up all my dev patches and re-cloned a fresh copy from git.denx.de and all appears to build fine
Sorry for the dealy, but hopefully I'll have it all sorted by the end of the week
OK thanks for the update. Would be keen to get my generic board stuff tested on x86 also, but that might be a separate problem. For initcalls, are you still thinking of looking at that?
If you want to fetch the x86 repo, you can work off it until Wolfgang does the pull
Regards,
Graeme
Dear Graeme Russ,
In message CALButC+==qGs5EaAHtQqU4zEjqvg-3187eWaqU-fv3dWp5QQ7w@mail.gmail.com you wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Dear Graeme Russ,
In message CALButC+==qGs5EaAHtQqU4zEjqvg-3187eWaqU-fv3dWp5QQ7w@mail.gmail.com you wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
It would be like a board not populated with USB hardware on a arch that globally defines it saying SKIP_INIT(USB) to avoid linking in the USB initialisation (maybe not the best example, but you get the point)
Or if a pre-loader initialises SDRAM the board can specify SKIP_INIT(SDRAM)
The point is we can specify a 'standard' set of init 'components' and boards can trivially disable any of these components as they see fit with zero impact on any other part of the U-Boot code base
And they can add their own init components, again with zero impact on the U-Boot code base
Regards,
Graeme
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Wolfgang,
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Dear Graeme Russ,
In message CALButC+==qGs5EaAHtQqU4zEjqvg-3187eWaqU-fv3dWp5QQ7w@mail.gmail.com you wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
To pick up Wolfgang's argument, but why do we want to skip relocation? You can debug through it, it's documented (official wiki has GDB, over in TI-land, the wiki page for CCS has the bits for doing it in that Eclipse-based env, other debuggers I'm sure have a similar "now add symbols at this offset from link" option) and the end result makes it very easy for end-users to break their world (default kernel load addrs being where U-Boot would be).
I can see this, along with not at all allowed tricks like loading and running U-Boot from U-Boot being in the realm of not supported tricks the sufficiently clever can do.
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
To pick up Wolfgang's argument, but why do we want to skip relocation? You can debug through it, it's documented (official wiki has GDB, over in TI-land, the wiki page for CCS has the bits for doing it in that Eclipse-based env, other debuggers I'm sure have a similar "now add symbols at this offset from link" option) and the end result makes it very easy for end-users to break their world (default kernel load addrs being where U-Boot would be).
if you have a static platform which never changes, isn't the relocation a waste of time ? i can understand wanting relocation by default for platforms where memory sizes are unknown, but it's not uncommon for people to have fixed hardware when they deploy.
although, with SPL picking up direct-to-Linux booting, this argument might not matter that much anymore. -mike
On Mon, Feb 6, 2012 at 12:27 PM, Mike Frysinger vapier@gentoo.org wrote:
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
To pick up Wolfgang's argument, but why do we want to skip relocation? You can debug through it, it's documented (official wiki has GDB, over in TI-land, the wiki page for CCS has the bits for doing it in that Eclipse-based env, other debuggers I'm sure have a similar "now add symbols at this offset from link" option) and the end result makes it very easy for end-users to break their world (default kernel load addrs being where U-Boot would be).
if you have a static platform which never changes, isn't the relocation a waste of time ? i can understand wanting relocation by default for platforms where memory sizes are unknown, but it's not uncommon for people to have fixed hardware when they deploy.
although, with SPL picking up direct-to-Linux booting, this argument might not matter that much anymore.
Yes, there's lots of tricks a deployment system can take to speed things up, and I agree, SPL loading Linux will make some of these less desirable.
Hi Mike,
On Tue, Feb 7, 2012 at 6:27 AM, Mike Frysinger vapier@gentoo.org wrote:
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
To pick up Wolfgang's argument, but why do we want to skip relocation? You can debug through it, it's documented (official wiki has GDB, over in TI-land, the wiki page for CCS has the bits for doing it in that Eclipse-based env, other debuggers I'm sure have a similar "now add symbols at this offset from link" option) and the end result makes it very easy for end-users to break their world (default kernel load addrs being where U-Boot would be).
if you have a static platform which never changes, isn't the relocation a waste of time ? i can understand wanting relocation by default for platforms where memory sizes are unknown, but it's not uncommon for people to have fixed hardware when they deploy.
Also, if SPL can determine total SDRAM, copy U-Boot to the final location and perform the relocations, there is no need for relocation to be done by U-Boot. As I understand it, SPL loads U-Boot into a fixed address and then U-Boot copies itself to top-of-RAM. We can save one copy
Regards,
Graeme
On 06.02.2012 21:25, Graeme Russ wrote:
Hi Mike,
On Tue, Feb 7, 2012 at 6:27 AM, Mike Frysinger vapier@gentoo.org wrote:
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
To pick up Wolfgang's argument, but why do we want to skip relocation? You can debug through it, it's documented (official wiki has GDB, over in TI-land, the wiki page for CCS has the bits for doing it in that Eclipse-based env, other debuggers I'm sure have a similar "now add symbols at this offset from link" option) and the end result makes it very easy for end-users to break their world (default kernel load addrs being where U-Boot would be).
if you have a static platform which never changes, isn't the relocation a waste of time ? i can understand wanting relocation by default for platforms where memory sizes are unknown, but it's not uncommon for people to have fixed hardware when they deploy.
Also, if SPL can determine total SDRAM, copy U-Boot to the final location and perform the relocations, there is no need for relocation to be done by U-Boot. As I understand it, SPL loads U-Boot into a fixed address and then U-Boot copies itself to top-of-RAM. We can save one copy
Yes, exactly, saving this one copy was the the reason for me to start this thread.
Thanks
Dirk
Dear Dirk Behme,
In message 4F30C794.50206@de.bosch.com you wrote:
Also, if SPL can determine total SDRAM, copy U-Boot to the final location and perform the relocations, there is no need for relocation to be done by U-Boot. As I understand it, SPL loads U-Boot into a fixed address and then U-Boot copies itself to top-of-RAM. We can save one copy
Yes, exactly, saving this one copy was the the reason for me to start this thread.
Is nobody _reading_ what I try to explain again and again and again?
If SPL was to determing the relocation address, it would also have to read the environment, because there are a number of environment variables which can cause (dynamically) the relocation address to change.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wed, Feb 8, 2012 at 10:23 AM, Wolfgang Denk wd@denx.de wrote:
Dear Dirk Behme,
In message 4F30C794.50206@de.bosch.com you wrote:
Also, if SPL can determine total SDRAM, copy U-Boot to the final location and perform the relocations, there is no need for relocation to be done by U-Boot. As I understand it, SPL loads U-Boot into a fixed address and then U-Boot copies itself to top-of-RAM. We can save one copy
Yes, exactly, saving this one copy was the the reason for me to start this thread.
Is nobody _reading_ what I try to explain again and again and again?
If SPL was to determing the relocation address, it would also have to read the environment, because there are a number of environment variables which can cause (dynamically) the relocation address to change.
But this is not neccessarily the case for every board (or even every arch)
For those boards/arches which CAN calculate the relocation address (either because it is fixed do to npn-variable RAM size, or fixed in relation to the maximum RAM address) why should we prohibit a method of skipping the redundant copy operation in a way which is 100% transparent to everyone else?
Regards,
Graeme
Dear Graeme Russ,
In message CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A@mail.gmail.com you wrote:
If SPL was to determing the relocation address, it would also have to read the environment, because there are a number of environment variables which can cause (dynamically) the relocation address to change.
But this is not neccessarily the case for every board (or even every arch)
Not neccessarily, but possible.
For those boards/arches which CAN calculate the relocation address (either because it is fixed do to npn-variable RAM size, or fixed in relation to the maximum RAM address) why should we prohibit a method of skipping the redundant copy operation in a way which is 100% transparent to everyone else?
Can we please focus on unifying the boot process first, before we try to come up with micro-optimizations?
Most of the people who complain here that they need to skip relocation are probably wrong in at least two accounts:
- They are not actually talking about relocation at all. - They don't base their accessment on any real, measured timings, or otherwise they would start optimizing completely different areas of the code.
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Wed, Feb 8, 2012 at 10:36 AM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A@mail.gmail.com you wrote:
If SPL was to determing the relocation address, it would also have to read the environment, because there are a number of environment variables which can cause (dynamically) the relocation address to change.
But this is not neccessarily the case for every board (or even every arch)
Not neccessarily, but possible.
For those boards/arches which CAN calculate the relocation address (either because it is fixed do to npn-variable RAM size, or fixed in relation to the maximum RAM address) why should we prohibit a method of skipping the redundant copy operation in a way which is 100% transparent to everyone else?
Can we please focus on unifying the boot process first, before we try to come up with micro-optimizations?
Agreed - And as I have stated before, this capability will come about as a natural side-effect of the boot process unification (see current x86 repo ready for pull for illustrative example plus the INIT_CALL code I am currently working on). So there is no need to look at hackish ways to sidestep 'relocation' until then (at which point they won't be needed anyway)
Most of the people who complain here that they need to skip relocation are probably wrong in at least two accounts:
- They are not actually talking about relocation at all.
Correct - The 'issue' is the additional in-RAM copy
- They don't base their accessment on any real, measured timings, or
otherwise they would start optimizing completely different areas of the code.
Yes - x86 achieved a not insignificant performance boost after I added the ability to enable the SDRAM cache before copying U-Boot to RAM :)
Regards,
Graeme
On 08.02.2012 00:48, Graeme Russ wrote:
Hi Wolfgang,
On Wed, Feb 8, 2012 at 10:36 AM, Wolfgang Denk wd@denx.de wrote:
Dear Graeme Russ,
In message CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A@mail.gmail.com you wrote:
If SPL was to determing the relocation address, it would also have to read the environment, because there are a number of environment variables which can cause (dynamically) the relocation address to change.
But this is not neccessarily the case for every board (or even every arch)
Not neccessarily, but possible.
For those boards/arches which CAN calculate the relocation address (either because it is fixed do to npn-variable RAM size, or fixed in relation to the maximum RAM address) why should we prohibit a method of skipping the redundant copy operation in a way which is 100% transparent to everyone else?
Can we please focus on unifying the boot process first, before we try to come up with micro-optimizations?
Agreed - And as I have stated before, this capability will come about as a natural side-effect of the boot process unification (see current x86 repo ready for pull for illustrative example plus the INIT_CALL code I am currently working on). So there is no need to look at hackish ways to sidestep 'relocation' until then (at which point they won't be needed anyway)
Most of the people who complain here that they need to skip relocation are probably wrong in at least two accounts:
- They are not actually talking about relocation at all.
Correct - The 'issue' is the additional in-RAM copy
Yes.
Best regards
Dirk
On 08.02.2012 00:36, Wolfgang Denk wrote:
Dear Graeme Russ,
In message CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A@mail.gmail.com you wrote:
If SPL was to determing the relocation address, it would also have to read the environment, because there are a number of environment variables which can cause (dynamically) the relocation address to change.
But this is not neccessarily the case for every board (or even every arch)
Not neccessarily, but possible.
For those boards/arches which CAN calculate the relocation address (either because it is fixed do to npn-variable RAM size, or fixed in relation to the maximum RAM address) why should we prohibit a method of skipping the redundant copy operation in a way which is 100% transparent to everyone else?
Can we please focus on unifying the boot process first, before we try to come up with micro-optimizations?
Most of the people who complain here that they need to skip relocation are probably wrong in at least two accounts:
- They are not actually talking about relocation at all.
- They don't base their accessment on any real, measured timings, or otherwise they would start optimizing completely different areas of the code.
Maybe they are looking at all areas (including the different ones) of possible optimizations. And this thread is only one topic (note 1).
Best regards
Dirk
note 1: I agree that the different topics will give more improvement. E.g. [1]. Looking at that thread, unfortunately there is less discussion than here while it will give more improvement :(
[1] http://lists.denx.de/pipermail/u-boot/2012-February/117270.html
Hi Dirk,
On Tue, Feb 7, 2012 at 10:51 PM, Dirk Behme dirk.behme@de.bosch.com wrote:
On 08.02.2012 00:36, Wolfgang Denk wrote:
Dear Graeme Russ,
In message CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A@mail.gmail.com you wrote:
If SPL was to determing the relocation address, it would also have to read the environment, because there are a number of environment variables which can cause (dynamically) the relocation address to change.
But this is not neccessarily the case for every board (or even every arch)
Not neccessarily, but possible.
For those boards/arches which CAN calculate the relocation address (either because it is fixed do to npn-variable RAM size, or fixed in relation to the maximum RAM address) why should we prohibit a method of skipping the redundant copy operation in a way which is 100% transparent to everyone else?
Can we please focus on unifying the boot process first, before we try to come up with micro-optimizations?
Most of the people who complain here that they need to skip relocation are probably wrong in at least two accounts:
- They are not actually talking about relocation at all.
- They don't base their accessment on any real, measured timings, or
otherwise they would start optimizing completely different areas of the code.
Maybe they are looking at all areas (including the different ones) of possible optimizations. And this thread is only one topic (note 1).
Best regards
Dirk
note 1: I agree that the different topics will give more improvement. E.g. [1]. Looking at that thread, unfortunately there is less discussion than here while it will give more improvement :(
[1] http://lists.denx.de/pipermail/u-boot/2012-February/117270.html
But turning on the cache should be trivial - it is already supported so you just need to implement the enable_dcache() function(?) I think.
Also make sure that the I-Cache is on as early as possible. Relocation is done with the d-cache off so is slow. Takes about 40ms for me from memory, but we do have things which can speed it up. But d-cache matters more than just about anything.
Regards, Simon
U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
On 08.02.2012 08:12, Simon Glass wrote:
Hi Dirk,
On Tue, Feb 7, 2012 at 10:51 PM, Dirk Behme dirk.behme@de.bosch.com wrote:
On 08.02.2012 00:36, Wolfgang Denk wrote:
Dear Graeme Russ,
In message CALButCKfG+guStJP+M5E=NSr34VPhzgbREbxQuXD6028sw6x6A@mail.gmail.com you wrote:
If SPL was to determing the relocation address, it would also have to read the environment, because there are a number of environment variables which can cause (dynamically) the relocation address to change.
But this is not neccessarily the case for every board (or even every arch)
Not neccessarily, but possible.
For those boards/arches which CAN calculate the relocation address (either because it is fixed do to npn-variable RAM size, or fixed in relation to the maximum RAM address) why should we prohibit a method of skipping the redundant copy operation in a way which is 100% transparent to everyone else?
Can we please focus on unifying the boot process first, before we try to come up with micro-optimizations?
Most of the people who complain here that they need to skip relocation are probably wrong in at least two accounts:
- They are not actually talking about relocation at all.
- They don't base their accessment on any real, measured timings, or
otherwise they would start optimizing completely different areas of the code.
Maybe they are looking at all areas (including the different ones) of possible optimizations. And this thread is only one topic (note 1).
Best regards
Dirk
note 1: I agree that the different topics will give more improvement. E.g. [1]. Looking at that thread, unfortunately there is less discussion than here while it will give more improvement :(
[1] http://lists.denx.de/pipermail/u-boot/2012-February/117270.html
But turning on the cache should be trivial - it is already supported so you just need to implement the enable_dcache() function(?)
As I understand it, the issue seems to be the non-cache-aware drivers.
Best regards
Dirk
Btw.: If possible, let's discuss the cache topic in the cache thread ;)
Hi Simon,
On Wed, Feb 8, 2012 at 6:12 PM, Simon Glass sjg@chromium.org wrote:
Hi Dirk,
But turning on the cache should be trivial - it is already supported so you just need to implement the enable_dcache() function(?) I think.
Also make sure that the I-Cache is on as early as possible. Relocation is done with the d-cache off so is slow. Takes about 40ms for me from
I have shown that this does not need to be the case - For x86 relocation is performed in the following sequence:
1) CPU Init, Disable Cache, Setup 'Cache-As-RAM', init global data and stack in 'Cache-As-RAM' 2) Init SDRAM 3) Allocate new stack in SDRAM 4) Pivot U-Boot so now SDRAM stack is being used but code is still being executed in Flash 5) Copy global data from CAR to SDRAM 6) Init cache (trashes CAR, but that's OK - it's not being used anymore) 7) Copy U-Boot from Flash to SDRAM 8) Perform relocation fixups 9) Jump to in-RAM copy of U-Boot 10) Continue init sequence...
memory, but we do have things which can speed it up. But d-cache matters more than just about anything.
Regards,
Graeme
Hi Simon,
On Wed, Feb 8, 2012 at 6:12 PM, Simon Glass sjg@chromium.org wrote:
Also make sure that the I-Cache is on as early as possible. Relocation is done with the d-cache off so is slow. Takes about 40ms for me from
Have a close look at the latest x86 patches (not yet pulled into mainline) as an example of how this does not need to be the case. The sequence I now use is:
1) Initialise 'Cache-As-RAM' (CAR) - Cache cannot be used to cache SDRAM, otherwise the Stack and Global Data get trashed 2) Create Stack and Global Data in CAR 3) Initialise SDRAM 4) Create a new stack in SDRAM 5) 'Pivot' U-Boot - Move stack from CAR to SDRAM (U-Boot still running in Flash) 6) Copy Global Data into SDRAM (adjust the global data pointer to point to the in-RAM copy) 7) CAR is no longer used - Enable caching of SDRAM 8) Copy U-Boot to RAM 9) Perform relocation adjustments to in-RAM copy 10) Jump to in-RAM copy 11) Continue initialisation
memory, but we do have things which can speed it up. But d-cache matters more than just about anything.
Now it may be the case (going by Wolfgang's comments) that some amount of high-memory needs to be reserved, and the amount to be reserved is not known until environment has been read. So there may be a need to put the initial in-RAM stack and global data somewhere 'safe' while high- memory space is calculated and U-Boot copied into RAM. Stack and global- data can then be moved again (stack probably doesn't need moving, just re-initialised at a new location) just below U-Boot. This would still be a lot cheaper than copying U-Boot with D-Cache off
Regards,
Graeme
Hi Graeme,
On Wed, Feb 8, 2012 at 7:38 PM, Graeme Russ graeme.russ@gmail.com wrote:
Hi Simon,
On Wed, Feb 8, 2012 at 6:12 PM, Simon Glass sjg@chromium.org wrote:
Also make sure that the I-Cache is on as early as possible. Relocation is done with the d-cache off so is slow. Takes about 40ms for me from
Have a close look at the latest x86 patches (not yet pulled into mainline) as an example of how this does not need to be the case. The sequence I now use is:
1) Initialise 'Cache-As-RAM' (CAR) - Cache cannot be used to cache SDRAM, otherwise the Stack and Global Data get trashed 2) Create Stack and Global Data in CAR 3) Initialise SDRAM 4) Create a new stack in SDRAM 5) 'Pivot' U-Boot - Move stack from CAR to SDRAM (U-Boot still running in Flash) 6) Copy Global Data into SDRAM (adjust the global data pointer to point to the in-RAM copy) 7) CAR is no longer used - Enable caching of SDRAM 8) Copy U-Boot to RAM 9) Perform relocation adjustments to in-RAM copy 10) Jump to in-RAM copy 11) Continue initialisation
memory, but we do have things which can speed it up. But d-cache matters more than just about anything.
Yes I went through these carefully at the time - remember the discussion about board_init_f_r()? I hope we can do something similar on generic board, but of course in general there is a trade-off between the time to set up the MMU tables and the time to do the copy.
Now it may be the case (going by Wolfgang's comments) that some amount of high-memory needs to be reserved, and the amount to be reserved is not known until environment has been read. So there may be a need to put the initial in-RAM stack and global data somewhere 'safe' while high- memory space is calculated and U-Boot copied into RAM. Stack and global- data can then be moved again (stack probably doesn't need moving, just re-initialised at a new location) just below U-Boot. This would still be a lot cheaper than copying U-Boot with D-Cache off
Yes. With a chance of 'epsilon' of this patch getting in, I am dropping it. While I agree what you have done is much better than what was there, I have my eyes on the higher goal of unifying the board init code for all archs.
Will revisit when/if generic board goes into mainline. If you have time, please take a look at that series.
Regards, Simon
Regards,
Graeme
Dear Dirk Behme,
In message 4F321B8C.3090907@de.bosch.com you wrote:
- They are not actually talking about relocation at all.
- They don't base their accessment on any real, measured timings, or otherwise they would start optimizing completely different areas of the code.
Maybe they are looking at all areas (including the different ones) of possible optimizations. And this thread is only one topic (note 1).
If you look at Aneesh's previous postings you will see that no systematic attempts for optimization have been made. This is a classical case of premature optimization.
Best regards,
Wolfgang Denk
Le 06/02/2012 20:27, Mike Frysinger a écrit :
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
To pick up Wolfgang's argument, but why do we want to skip relocation? You can debug through it, it's documented (official wiki has GDB, over in TI-land, the wiki page for CCS has the bits for doing it in that Eclipse-based env, other debuggers I'm sure have a similar "now add symbols at this offset from link" option) and the end result makes it very easy for end-users to break their world (default kernel load addrs being where U-Boot would be).
if you have a static platform which never changes, isn't the relocation a waste of time ? i can understand wanting relocation by default for platforms where memory sizes are unknown, but it's not uncommon for people to have fixed hardware when they deploy.
Relocation may not be a waste of time if the static platform boots U-Boot from NOR, as relocation will be needed to move U-Boot to RAM in working order.
Now if the platform is static and has a preloader of sorts, then one can predict (or just observe) where U-Boot would want to relocate, and set the preloader once and for all (for a given release of U-Boot, that is) to load U-Boot directly at that address. U-Boot will skip copy and relocation if it already resides at the right address.
although, with SPL picking up direct-to-Linux booting, this argument might not matter that much anymore.
Agreed, although one could make a point that SPL direct-to-Linux is not the most common case currently and may not be applicable to all cases anyway.
-mike
Amicalement,
Dear Albert ARIBAUD,
In message 4F304376.3020400@aribaud.net you wrote:
Now if the platform is static and has a preloader of sorts, then one can predict (or just observe) where U-Boot would want to relocate, and set the preloader once and for all (for a given release of U-Boot, that is) to load U-Boot directly at that address. U-Boot will skip copy and relocation if it already resides at the right address.
This may, or may not work.
Assume you have PRAM enabled in your configuration, then the relocation address depends on the size of the PRAM area, which is defined by the value of an environment variable - i. e. it can be different for each boot.
In the general case, the relocation address is NOT predictable.
Best regards,
Wolfgang Denk
On 06.02.2012 22:17, Albert ARIBAUD wrote:
Le 06/02/2012 20:27, Mike Frysinger a écrit :
On Monday 06 February 2012 09:49:27 Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russ wrote:
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Graeme Russ wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
To pick up Wolfgang's argument, but why do we want to skip relocation? You can debug through it, it's documented (official wiki has GDB, over in TI-land, the wiki page for CCS has the bits for doing it in that Eclipse-based env, other debuggers I'm sure have a similar "now add symbols at this offset from link" option) and the end result makes it very easy for end-users to break their world (default kernel load addrs being where U-Boot would be).
if you have a static platform which never changes, isn't the relocation a waste of time ? i can understand wanting relocation by default for platforms where memory sizes are unknown, but it's not uncommon for people to have fixed hardware when they deploy.
Relocation may not be a waste of time if the static platform boots U-Boot from NOR, as relocation will be needed to move U-Boot to RAM in working order.
Now if the platform is static and has a preloader of sorts, then one can predict (or just observe) where U-Boot would want to relocate, and set the preloader once and for all (for a given release of U-Boot, that is) to load U-Boot directly at that address. U-Boot will skip copy and relocation if it already resides at the right address.
For the i.MX6 preloader, i.e. the i.MX6 boot ROM, the issue I observed is that the copy *and* relocation will be skipped [1]. The skipped copy is fine, skipping the relocation breaks things, though:
Getting the address where U-Boot will relocate to, and setting this as CONFIG_SYS_TEXT_BASE will result in skipping the copy. Fine. But the whole 'fix .rel.dyn relocations' in e.g. arch/arm/cpu/armv7/start.S is skipped, too. And this breaks things.
Best regards
Dirk
[1] http://lists.denx.de/pipermail/u-boot/2012-February/117134.html
On Monday 06 February 2012 08:19 PM, Tom Rini wrote:
On Mon, Feb 6, 2012 at 1:43 AM, Graeme Russgraeme.russ@gmail.com wrote:
Hi Wolfgang,
On 02/06/2012 06:51 PM, Wolfgang Denk wrote:
Dear Graeme Russ,
In messageCALButC+==qGs5EaAHtQqU4zEjqvg-3187eWaqU-fv3dWp5QQ7w@mail.gmail.com you wrote:
I think the immediate focus should be on centralising the init sequence processing into /common/init.c and then bringing the new'initcall' architecture online
Agreed.
Once these have been done, any board can just specific:
SKIP_INIT(RELOC)
I will probably object to his, too - for the same reasons.
Considering this is a 'free' artefact of how the init sequence functions, and that it is board specific and totally non-invasive for anyone else (i.e. no ugly ifdef's anywhere else in the code) I'm surprised you would object...
To pick up Wolfgang's argument, but why do we want to skip relocation? You can debug through it, it's documented (official wiki has GDB, over in TI-land, the wiki page for CCS has the bits for doing it in that Eclipse-based env, other debuggers I'm sure have a similar "now add symbols at this offset from link" option) and the end result makes it very easy for end-users to break their world (default kernel load addrs being where U-Boot would be).
Why do all that circus if it's not adding any value for a given platform. Also, in the previous thread on this I had pointed out a specific case where this was hurting us. On a slow FPGA platform the delay due to the relocation was getting magnified and un-necessarily wasting our time.
best regards, Aneesh
Hi Wolfgang,
On Sun, Feb 5, 2012 at 2:44 PM, Wolfgang Denk wd@denx.de wrote:
Dear Simon Glass,
In message CAPnjgZ2Z0ojdLHz6yd5UuWru7pmJBLeogHzhK7rWGWk46xxqpA@mail.gmail.com you wrote:
This patch shows how to do this sort of thing on ARM. I would like to see this feature in mainline, but it makes more sense to do it properly if/when generic relocation is in. Then it will automatically work for all archs. For now it is a useful patch.
Sorry, as I see it your chances to get this in are epsilon.
OK, I was hoping for a little higher.
Regards, Simon
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 "The lesser of two evils -- is evil." - Seymour (Sy) Leon
This permits disabling the code relation in U-Boot which is useful when debugging with an ICE.
To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
Signed-off-by: Simon Glass sjg@chromium.org
arch/arm/config.mk | 2 ++ arch/arm/cpu/armv7/start.S | 3 +-- arch/arm/include/asm/global_data.h | 3 +++ arch/arm/lib/board.c | 10 ++++++++++ 4 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 45f9dca..46b52af 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -79,5 +79,7 @@ endif
# needed for relocation ifndef CONFIG_NAND_SPL +ifndef CONFIG_SYS_SKIP_ARM_RELOCATION LDFLAGS_u-boot += -pie endif +endif diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index ef08a55..82eac7c 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -183,8 +183,7 @@ stack_setup: mov sp, r4
adr r0, _start
- cmp r0, r6
- moveq r9, #0 /* no relocation. relocation offset(r9) = 0 */
- subs r9, r6, r0 /* r9 <- relocation offset */ beq clear_bss /* skip relocation */ mov r1, r6 /* r1 <- scratch for copy_loop */ ldr r3, _image_copy_end_ofs
diff --git a/arch/arm/include/asm/global_data.h b/arch/arm/include/asm/global_data.h index c3ff789..23a6077 100644 --- a/arch/arm/include/asm/global_data.h +++ b/arch/arm/include/asm/global_data.h @@ -77,6 +77,9 @@ typedef struct global_data { unsigned long tlb_addr; #endif const void *fdt_blob; /* Our device tree, NULL if none */ +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION
- ulong malloc_end; /* End of malloc region (addr + 1) */
+#endif void **jt; /* jump table */ char env_buf[32]; /* buffer for getenv() before reloc. */ #if defined(CONFIG_POST) || defined(CONFIG_LOGBUFFER) diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 3d78274..81293c3 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -355,6 +355,7 @@ void board_init_f(ulong bootflag) #endif /* CONFIG_FB_ADDR */ #endif /* CONFIG_LCD */
+#ifndef CONFIG_SYS_SKIP_ARM_RELOCATION /* * reserve memory for U-Boot code, data & bss * round down to next 4 kB limit @@ -363,6 +364,7 @@ void board_init_f(ulong bootflag) addr &= ~(4096 - 1);
debug("Reserving %ldk for U-Boot at: %08lx\n", gd->mon_len >> 10, addr); +#endif
#ifndef CONFIG_SPL_BUILD /* @@ -419,6 +421,10 @@ void board_init_f(ulong bootflag) dram_init_banksize(); display_dram_config(); /* and display it */
+#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION
- gd->malloc_end = addr;
- addr = _TEXT_BASE;
+#endif gd->relocaddr = addr; gd->start_addr_sp = addr_sp; gd->reloc_off = addr - _TEXT_BASE; @@ -478,7 +484,11 @@ void board_init_r(gd_t *id, ulong dest_addr) #endif
/* The Malloc area is immediately below the monitor copy in DRAM */ +#ifdef CONFIG_SYS_SKIP_ARM_RELOCATION
- malloc_start = gd->malloc_end - TOTAL_MALLOC_LEN;
+#else malloc_start = dest_addr - TOTAL_MALLOC_LEN; +#endif mem_malloc_init (malloc_start, TOTAL_MALLOC_LEN);
#if !defined(CONFIG_SYS_NO_FLASH)
Why would you need this one ? Is there any user for this patch?
M
Dear Simon Glass,
In message 1328424259-12914-1-git-send-email-sjg@chromium.org you wrote:
This permits disabling the code relation in U-Boot which is useful when debugging with an ICE.
To use it define CONFIG_SYS_SKIP_ARM_RELOCATION in your board.
Signed-off-by: Simon Glass sjg@chromium.org
NAK.
We are trying really hard to unify the code, i. e. to make all architectures behave the same. I will not accept any such architecture-specific implementation.
All the more, there is really ne need for this. Relocation does not cause any specific problems to debugging. We know exaclt when it happens, and it happens exaclty once during the life time of U-Boot. And all you have to do is load the symbol tables to the right address. Before relcation this just works, and after relocation you just need to issue a single GDB command.
This is even documented.
Adding this options also creates the risk that people who don't really understand the inner workings of U-Boot will try and use this for other purposes. Read: mis-use it.
Sorry, but NAK.
Best regards,
Wolfgang Denk
participants (9)
-
Albert ARIBAUD -
Aneesh V -
Dirk Behme -
Graeme Russ -
Marek Vasut -
Mike Frysinger -
Simon Glass -
Tom Rini -
Wolfgang Denk