[U-Boot] [PATCH] arm: Add option to disable code relocation

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Simon Glass]

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)
-- 
1.7.7.3

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Mike Frysinger]

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 ?
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120205/4957e825/attachment.pgp>

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Marek Vasut]

> 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?

M

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Marek Vasut]

> 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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Wolfgang Denk]

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

-- 
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
One does not thank logic.
	-- Sarek, "Journey to Babel", stardate 3842.4

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120205/3e57bbb4/attachment.pgp>

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Simon Glass]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Wolfgang Denk]

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

-- 
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
"The lesser of two evils -- is evil."             - Seymour (Sy) Leon

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Simon Glass]

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 at denx.de
> "The lesser of two evils -- is evil." ? ? ? ? ? ? - Seymour (Sy) Leon

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Simon Glass]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Simon Glass]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Wolfgang Denk]

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

-- 
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
I'm frequently appalled by the low regard you Earthmen have for life.
	-- Spock, "The Galileo Seven", stardate 2822.3

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Tom Rini]

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.

-- 
Tom

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Mike Frysinger]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20120206/cf2e515c/attachment.pgp>

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Tom Rini]

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.

-- 
Tom

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Wolfgang Denk]

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

-- 
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
Gew?hnlich glaubt der Mensch,  wenn er nur Worte h?rt,  es m?sse sich
dabei doch auch was denken lassen.                 -- Goethe, Faust I

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Dirk Behme]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Dirk Behme]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Aneesh V]

On Monday 06 February 2012 08:19 PM, Tom Rini wrote:
> 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).

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Wolfgang Denk]

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

-- 
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
Is not that the nature of men and women -- that the  pleasure  is  in
the learning of each other?
	-- Natira, the High Priestess of Yonada, "For the World is
	   Hollow and I Have Touched the Sky", stardate 5476.3.

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Wolfgang Denk]

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

-- 
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
What's the sound a name makes when it's dropped?

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Dirk Behme]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Dirk Behme]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Simon Glass]

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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Dirk Behme]

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 ;)

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Wolfgang Denk]

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

-- 
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
What is research but a blind date with knowledge?      -- Will Harvey

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Graeme Russ]

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

[U-Boot] [PATCH] arm: Add option to disable code relocation

[Simon Glass]

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