[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Albert Aribaud]

This is an RFC so far. I'd like people who have issues with newer linkers to test this patch.

It is intended for arm926ejs, so you might have to 'port' it to your own ARM architecture.

It has been roughly tested with ELDK 4.2 and CodeSourcery arm-2010q1-202; both seem to run rather properly (no NAND issue at startup, 'help' and commands seem to be there).

Amicalement,
Albert.

Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
---
 arch/arm/cpu/arm926ejs/u-boot.lds |   18 +++++++++---------
 1 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/u-boot.lds b/arch/arm/cpu/arm926ejs/u-boot.lds
index 72f45f8..4e42543 100644
--- a/arch/arm/cpu/arm926ejs/u-boot.lds
+++ b/arch/arm/cpu/arm926ejs/u-boot.lds
@@ -45,15 +45,6 @@ SECTIONS
 
 	. = ALIGN(4);
 
-	__rel_dyn_start = .;
-	.rel.dyn : { *(.rel.dyn) }
-	__rel_dyn_end = .;
-
-	__dynsym_start = .;
-	.dynsym : { *(.dynsym) }
-
-	. = ALIGN(4);
-
 	. = .;
 	__u_boot_cmd_start = .;
 	.u_boot_cmd : { *(.u_boot_cmd) }
@@ -64,6 +55,15 @@ SECTIONS
 	.bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
 	_end = .;
 
+	__rel_dyn_start = .;
+	.rel.dyn : { *(.rel*) }
+	__rel_dyn_end = .;
+
+	__dynsym_start = .;
+	.dynsym : { *(.dynsym) }
+
+	. = ALIGN(4);
+
 	/DISCARD/ : { *(.dynstr*) }
 	/DISCARD/ : { *(.dynamic*) }
 	/DISCARD/ : { *(.plt*) }
-- 
1.7.1

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Alexander Holler]

Am 31.10.2010 18:43, schrieb Albert Aribaud:
> This is an RFC so far. I'd like people who have issues with newer linkers to test this patch.
>
> It is intended for arm926ejs, so you might have to 'port' it to your own ARM architecture.


Wow, that was going fast. That fixed the relocation here.

Thanks a lot!

Kind regards,

Alexander

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert Aribaud,

In message <1288547025-16877-1-git-send-email-albert.aribaud@free.fr> you wrote:
> This is an RFC so far. I'd like people who have issues with newer linkers to test this patch.
> 
> It is intended for arm926ejs, so you might have to 'port' it to your own ARM architecture.
> 
> It has been roughly tested with ELDK 4.2 and CodeSourcery arm-2010q1-202; both seem to run rather properly (no NAND issue at startup, 'help' and commands seem to be there).
> 
> Amicalement,

Doesn;t work for me on TX25 - with the CS tool chain, the board will
still freeze after printing "DRAM:  32 MiB", i. e. during or after
relocation.

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 the scientists have in their briefcases is terrifying."
- Nikita Khrushchev

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 31/10/2010 19:12, Wolfgang Denk a ?crit :
> Dear Albert Aribaud,
>
> In message<1288547025-16877-1-git-send-email-albert.aribaud@free.fr>  you wrote:
>> This is an RFC so far. I'd like people who have issues with newer linkers to test this patch.
>>
>> It is intended for arm926ejs, so you might have to 'port' it to your own ARM architecture.
>>
>> It has been roughly tested with ELDK 4.2 and CodeSourcery arm-2010q1-202; both seem to run rather properly (no NAND issue at startup, 'help' and commands seem to be there).
>>
>> Amicalement,
>
> Doesn;t work for me on TX25 - with the CS tool chain, the board will
> still freeze after printing "DRAM:  32 MiB", i. e. during or after
> relocation.
>
> Best regards,
>
> Wolfgang Denk

Can you e-mail me the ELF binary?

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Darius Augulis]

Hi Albert,

On 10/31/2010 07:43 PM, Albert Aribaud wrote:
> This is an RFC so far. I'd like people who have issues with newer linkers to test this patch.
>
> It is intended for arm926ejs, so you might have to 'port' it to your own ARM architecture.

Thanks! It works on arm1176/mini6410 and solves problem of missing commands.

tested with gcc 4.4.5 + binutils 2.20.1 toolchain from Buildroot.

But it's strange, because I done the same test of declaring variable in 
start.s:

.globl cmd_start
cmd_start:
         .word __u_boot_cmd_start

Then disassembled elf shows it's value:

57e00048 <cmd_start>:
57e00048:       00000000        .word   0x00000000

Commands are there and somehow working, but at least it's very strange.

Darius.

>
> It has been roughly tested with ELDK 4.2 and CodeSourcery arm-2010q1-202; both seem to run rather properly (no NAND issue at startup, 'help' and commands seem to be there).
>
> Amicalement,
> Albert.
>
> Signed-off-by: Albert Aribaud<albert.aribaud@free.fr>
> ---
>   arch/arm/cpu/arm926ejs/u-boot.lds |   18 +++++++++---------
>   1 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/cpu/arm926ejs/u-boot.lds b/arch/arm/cpu/arm926ejs/u-boot.lds
> index 72f45f8..4e42543 100644
> --- a/arch/arm/cpu/arm926ejs/u-boot.lds
> +++ b/arch/arm/cpu/arm926ejs/u-boot.lds
> @@ -45,15 +45,6 @@ SECTIONS
>
>   	. = ALIGN(4);
>
> -	__rel_dyn_start = .;
> -	.rel.dyn : { *(.rel.dyn) }
> -	__rel_dyn_end = .;
> -
> -	__dynsym_start = .;
> -	.dynsym : { *(.dynsym) }
> -
> -	. = ALIGN(4);
> -
>   	. = .;
>   	__u_boot_cmd_start = .;
>   	.u_boot_cmd : { *(.u_boot_cmd) }
> @@ -64,6 +55,15 @@ SECTIONS
>   	.bss (NOLOAD) : { *(.bss) . = ALIGN(4); }
>   	_end = .;
>
> +	__rel_dyn_start = .;
> +	.rel.dyn : { *(.rel*) }
> +	__rel_dyn_end = .;
> +
> +	__dynsym_start = .;
> +	.dynsym : { *(.dynsym) }
> +
> +	. = ALIGN(4);
> +
>   	/DISCARD/ : { *(.dynstr*) }
>   	/DISCARD/ : { *(.dynamic*) }
>   	/DISCARD/ : { *(.plt*) }

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCDB60B.4010207@free.fr> you wrote:
>
> Can you e-mail me the ELF binary?

Done. [off list to avoid the useless traffic]

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
Old programmers never die, they just become managers.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Alexander Holler]

Am 31.10.2010 19:12, schrieb Wolfgang Denk:
> Dear Albert Aribaud,
>
> In message<1288547025-16877-1-git-send-email-albert.aribaud@free.fr>  you wrote:
>> This is an RFC so far. I'd like people who have issues with newer linkers to test this patch.
>>
>> It is intended for arm926ejs, so you might have to 'port' it to your own ARM architecture.
>>
>> It has been roughly tested with ELDK 4.2 and CodeSourcery arm-2010q1-202; both seem to run rather properly (no NAND issue at startup, 'help' and commands seem to be there).
>>
>> Amicalement,
>
> Doesn;t work for me on TX25 - with the CS tool chain, the board will
> still freeze after printing "DRAM:  32 MiB", i. e. during or after
> relocation.

For the records: I'm using binutils 2.20.1 here and just booted a Linux 
from usb using the current HEAD of u-boot and the patch for the linker 
script compiled with gcc 4.5.2 on a kirkwood (which has an arm926ejs 
cpu). No problems with NAND, and my relocation-test-patch doesn't 
printed a warning. I've compiled u-boot with gcc 4.3.4 (and binutils 
2.20.1) too, works too.

So I'm very happy currently. ;)

Wolfgang: using find, I've found another linker script which might 
affect you: nand_spl/board/karo/tx25/u-boot.lds. Maybe thats your 
problem and needs a fix too.

Regards,

Alexander

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 31/10/2010 19:35, Darius Augulis a ?crit :

> But it's strange, because I done the same test of declaring variable in
> start.s:
>
> ..globl cmd_start
> cmd_start:
>           .word __u_boot_cmd_start
>
> Then disassembled elf shows it's value:
>
> 57e00048<cmd_start>:
> 57e00048:       00000000        .word   0x00000000

Indeed. :)

That's why, for instance, the _rel_dyn_start_ofs literal is defined as

	.word _rel_dyn_start - _start

... rather than simply as

	.word _rel_dyn start

... because the latter always produces 0 (it expects it to be fixed up 
by the relocation code, which causes a catch-22) while the former 
produces the expected difference which can then be fixed.

> Commands are there and somehow working, but at least it's very strange.

Yes, it baffled me too. :)

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Alexander Holler,

In message <4CCDB78D.506@ahsoftware.de> you wrote:
>
> So I'm very happy currently. ;)

Fine for you.  Enjoy it.


> Wolfgang: using find, I've found another linker script which might 
> affect you: nand_spl/board/karo/tx25/u-boot.lds. Maybe thats your 
> problem and needs a fix too.

Thanks - but the messages printed are from the "real" U-Boot, not from
the NAND SPL.  Adjusting nand_spl/board/karo/tx25/u-boot.lds does not
help either.

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
A father doesn't destroy his children.
	-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
	   stardate 3468.1.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 31/10/2010 19:38, Alexander Holler a ?crit :

> Wolfgang: using find, I've found another linker script which might
> affect you: nand_spl/board/karo/tx25/u-boot.lds. Maybe thats your
> problem and needs a fix too.

It seems you're right: looking at wolfgang's u-boot binaries, it seems 
it still has its rel.dyn before .bss, whereas the patch would put it 
after .bss.

> Regards,
>
> Alexander

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 31/10/2010 20:01, Wolfgang Denk a ?crit :
> Dear Alexander Holler,
>
> In message<4CCDB78D.506@ahsoftware.de>  you wrote:
>>
>> So I'm very happy currently. ;)
>
> Fine for you.  Enjoy it.
>
>
>> Wolfgang: using find, I've found another linker script which might
>> affect you: nand_spl/board/karo/tx25/u-boot.lds. Maybe thats your
>> problem and needs a fix too.
>
> Thanks - but the messages printed are from the "real" U-Boot, not from
> the NAND SPL.  Adjusting nand_spl/board/karo/tx25/u-boot.lds does not
> help either.

Still the u-boot.lds that was used for the build you sent me was not 
patched; and when I "make tx25_config; make" I can see that the 
u-boot.lds used is nand_spl/u-boot.lds, built from preprocessing 
nand_spl/board/karo/tx25/u-boot.lds. Can you check your build logs?

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCDBE71.1010805@free.fr> you wrote:
>
> Still the u-boot.lds that was used for the build you sent me was not 
> patched; and when I "make tx25_config; make" I can see that the 
> u-boot.lds used is nand_spl/u-boot.lds, built from preprocessing 
> nand_spl/board/karo/tx25/u-boot.lds. Can you check your build logs?

I just retried from scratch.  u-boot.map shows rel_dyn after bss, yet
I still see tha hang after relocation. Or rather a crash.

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
"Don't try to outweird me, three-eyes. I get stranger things than you
free with my breakfast cereal."
           - Zaphod Beeblebrox in  "Hitchhiker's Guide to the Galaxy"

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 31/10/2010 20:22, Wolfgang Denk a ?crit :

> I just retried from scratch.  u-boot.map shows rel_dyn after bss, yet
> I still see tha hang after relocation. Or rather a crash.

Can you enable DEBUG globally and capture the u-boot output in a terminal?

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCDC625.3010209@free.fr> you wrote:
> 
> Can you enable DEBUG globally and capture the u-boot output in a terminal?

Here it is:

U-Boot 2010.12-rc1-00027-g03ab00d-dirty (Oct 31 2010 - 20:57:21)

U-Boot code: 81200000 -> 81226E50  BSS: -> 81230758
CPU:   Freescale i.MX25 at 399 MHz

monitor len: 00030758
ramsize: 02000000
TLB table at: 81ff0000
Top of RAM usable for U-Boot at: 81ff0000
Reserving 193k for U-Boot at: 81fbf000
Reserving 1024k for malloc() at: 81ebf000
Reserving 24 Bytes for Board Info at: 81ebefe8
Reserving 92 Bytes for Global Data at: 81ebef8c
New Stack Pointer is: 81ebef88
RAM Configuration:
Bank #0: 80000000 32 MiB
relocation Offset is: 00dbf000



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
Hacking's just another word for nothing left to kludge.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Albert ARIBAUD]

Le 31/10/2010 20:59, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CCDC625.3010209@free.fr>  you wrote:
>>
>> Can you enable DEBUG globally and capture the u-boot output in a terminal?
>
> Here it is:
>
> U-Boot 2010.12-rc1-00027-g03ab00d-dirty (Oct 31 2010 - 20:57:21)
>
> U-Boot code: 81200000 ->  81226E50  BSS: ->  81230758

Weird... display_banner() is called before relocation and uses whatever 
the linker put in the literals; but these values above do not match 
those of the u-boot you sent me last.

According to the .map, the *whole* of the tx25 image ends at 0x81230398, 
and BSS itself goes from 0x812235f4 to 0x8122c700. So *before* 
relocation there already is an issue.

Can you double-check that the u-boot you sent me is the one you ran?

> monitor len: 00030758

Should have been 0x2c700.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCDD02D.2050304@free.fr> you wrote:
>
> > U-Boot code: 81200000 ->  81226E50  BSS: ->  81230758
> 
> Weird... display_banner() is called before relocation and uses whatever 
> the linker put in the literals; but these values above do not match 
> those of the u-boot you sent me last.
> 
> According to the .map, the *whole* of the tx25 image ends at 0x81230398, 
> and BSS itself goes from 0x812235f4 to 0x8122c700. So *before* 
> relocation there already is an issue.
> 
> Can you double-check that the u-boot you sent me is the one you ran?
> 
> > monitor len: 00030758
> 
> Should have been 0x2c700.

The difference probably comes from globally enabling DEBUG.

When I enable DEBUG only in board.c I see this instead:

U-Boot 2010.12-rc1-00027-g03ab00d-dirty (Oct 31 2010 - 20:31:12)

U-Boot code: 81200000 -> 81224E6C  BSS: -> 8122DF70
CPU:   Freescale i.MX25 at 399 MHz

monitor len: 0002DF70
ramsize: 02000000
TLB table at: 81ff0000
Top of RAM usable for U-Boot at: 81ff0000
Reserving 183k for U-Boot at: 81fc2000
Reserving 1024k for malloc() at: 81ec2000
Reserving 24 Bytes for Board Info at: 81ec1fe8
Reserving 92 Bytes for Global Data at: 81ec1f8c
New Stack Pointer is: 81ec1f88
RAM Configuration:
Bank #0: 80000000 32 MiB
relocation Offset is: 00dc2000



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
"There is no distinctly American criminal class except Congress."
- Mark Twain

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert Aribaud]

RFC again. WARNING -- apply *above* the previous one, not instead!

I *think* the current jump to nand_boot was wrong, because it
loads an offset but does not add it to the relocated base before
jumping to it. I thus applied the same sequence as board_init_r.

Wolfgang, please test to see if tx25 works with this.

Alexander, Darius, others who already tested the previous RFC patch,
please test for non-regression.

Amicalement,
Albert.

Signed-off-by: Albert Aribaud <albert.aribaud@free.fr>
---
 arch/arm/cpu/arm926ejs/start.S |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 6dcc9b4..098b426 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -276,7 +276,10 @@ clbss_l:str	r2, [r0]		/* clear loop...		    */
  */
 #ifdef CONFIG_NAND_SPL
 	ldr     r0, _nand_boot_ofs
-	mov	pc, r0
+	adr	r1, _start
+	add	lr, r0, r1
+	add	lr, lr, r9
+	mov	pc, lr
 
 _nand_boot_ofs:
 	.word nand_boot
-- 
1.7.1

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Albert Aribaud,

In message <1288560046-6458-1-git-send-email-albert.aribaud@free.fr> you wrote:
> RFC again. WARNING -- apply *above* the previous one, not instead!
> 
> I *think* the current jump to nand_boot was wrong, because it
> loads an offset but does not add it to the relocated base before
> jumping to it. I thus applied the same sequence as board_init_r.
> 
> Wolfgang, please test to see if tx25 works with this.

Doesn't work at all for me - zero cosole output; neither with ELDK nor
with CS toolchains.

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
Well, the way I see it, logic is only a way of being ignorant by num-
bers.                                 - Terry Pratchett, _Small Gods_

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 31/10/2010 22:51, Wolfgang Denk a ?crit :
> Dear Albert Aribaud,
>
> In message<1288560046-6458-1-git-send-email-albert.aribaud@free.fr>  you wrote:
>> RFC again. WARNING -- apply *above* the previous one, not instead!
>>
>> I *think* the current jump to nand_boot was wrong, because it
>> loads an offset but does not add it to the relocated base before
>> jumping to it. I thus applied the same sequence as board_init_r.
>>
>> Wolfgang, please test to see if tx25 works with this.
>
> Doesn't work at all for me - zero cosole output; neither with ELDK nor
> with CS toolchains.

That's when I wish I had a tx25 board here. :(

Back to staring at the source code...

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Alexander Holler]

On 31.10.2010 22:20, Albert Aribaud wrote:

> Alexander, Darius, others who already tested the previous RFC patch,
> please test for non-regression.

Still works here with that patch applied. But that isn't remarkable, because

>   #ifdef CONFIG_NAND_SPL

that isn't defined here. ;)

Regards,

Alexander

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 31/10/2010 23:28, Alexander Holler a ?crit :
> On 31.10.2010 22:20, Albert Aribaud wrote:
>
>> Alexander, Darius, others who already tested the previous RFC patch,
>> please test for non-regression.
>
> Still works here with that patch applied. But that isn't remarkable, because
>
>>    #ifdef CONFIG_NAND_SPL
>
> that isn't defined here. ;)

... and tx25 seems not to have it defined either, so my change should 
not have affected Wolfgang's tests. :/

Wolfgang, could you:

- make available to me the exact source tree you're compiling, including 
my patches as you applied them plus your changes to them, either as a 
clonable git repo or as a patch set to apply on the current u-boot 
master branch;

- indicate exactly how you build your u-boot;

- provide the u-boot binary that you last built (the one that has no 
output).

My goal here is to reproduce an u-boot identical to yours, in order to 
make sur I can produce controlled u-boots for tx25, and then build some 
specific tx25 u-boots for you to run.

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[sughosh ganu]

On Mon, Nov 1, 2010 at 4:34 AM, Albert ARIBAUD <albert.aribaud@free.fr>wrote:

> Le 31/10/2010 23:28, Alexander Holler a ?crit :
> > On 31.10.2010 22:20, Albert Aribaud wrote:
> >
> >> Alexander, Darius, others who already tested the previous RFC patch,
> >> please test for non-regression.
> >
> > Still works here with that patch applied. But that isn't remarkable,
> because
> >
> >>    #ifdef CONFIG_NAND_SPL
> >
> > that isn't defined here. ;)
>
> ... and tx25 seems not to have it defined either, so my change should
> not have affected Wolfgang's tests. :/
>

 I think it is defined in nand_spl/board/karo/tx25/Makefile. We do get a
nand_spl/u-boot-spl when we compile for the tx25 board, which has a
reference to nand_boot.

-sughosh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 01/11/2010 06:13, sughosh ganu a ?crit :
> On Mon, Nov 1, 2010 at 4:34 AM, Albert ARIBAUD<albert.aribaud@free.fr>wrote:
>
>> Le 31/10/2010 23:28, Alexander Holler a ?crit :
>>> On 31.10.2010 22:20, Albert Aribaud wrote:
>>>
>>>> Alexander, Darius, others who already tested the previous RFC patch,
>>>> please test for non-regression.
>>>
>>> Still works here with that patch applied. But that isn't remarkable,
>> because
>>>
>>>>     #ifdef CONFIG_NAND_SPL
>>>
>>> that isn't defined here. ;)
>>
>> ... and tx25 seems not to have it defined either, so my change should
>> not have affected Wolfgang's tests. :/
>>
>
>   I think it is defined in nand_spl/board/karo/tx25/Makefile. We do get a
> nand_spl/u-boot-spl when we compile for the tx25 board, which has a
> reference to nand_boot.

Thanks Sugish. Which commands do you use to build the tx25? I tried

	make distclean; make tx25_config; make

and

	./MAKEALL tx25

... but this ends up with the code in start.S as if NAND_SPL was not 
defined, i.e. calling board_inir_r, not nand_boot.

> -sughosh

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCE768B.1010809@free.fr> you wrote:
> 
> Thanks Sugish. Which commands do you use to build the tx25? I tried
> 
> 	make distclean; make tx25_config; make
> 
> and
> 
> 	./MAKEALL tx25

Both is correct.

> ... but this ends up with the code in start.S as if NAND_SPL was not
> defined, i.e. calling board_inir_r, not nand_boot.

There is u-boot (u-boot.bin) and nand_spl/u-boot-spl
(nand_spl/u-boot-spl.bin) which together result in u-boot-nand.bin
which then is booted from NAND. And there is u-boot.map and
nand_spl/u-boot-spl.map ...

More in following messages.

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
"If a computer can't directly address all the RAM you can  use,  it's
just a toy."         - anonymous comp.sys.amiga posting, non-sequitir

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCDF5FC.4060704@free.fr> you wrote:
>
> Wolfgang, could you:
>
> - make available to me the exact source tree you're compiling, including
> my patches as you applied them plus your changes to them, either as a
> clonable git repo or as a patch set to apply on the current u-boot
> master branch;

Please see git://git.denx.de/u-boot-testing.git , branch reloc-tests

> - indicate exactly how you build your u-boot;

Both with ELDK and CS tools:

./MAKELL tx25

> - provide the u-boot binary that you last built (the one that has no
> output).

Will send two tarballs (built with ELDK and CS) in PM.

> My goal here is to reproduce an u-boot identical to yours, in order to 
> make sur I can produce controlled u-boots for tx25, and then build some
> specific tx25 u-boots for you to run.

Thanks!

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
backups: always in season, never out of style.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 01/11/2010 10:15, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CCDF5FC.4060704@free.fr>  you wrote:
>>
>> Wolfgang, could you:
>>
>> - make available to me the exact source tree you're compiling, including
>> my patches as you applied them plus your changes to them, either as a
>> clonable git repo or as a patch set to apply on the current u-boot
>> master branch;
>
> Please see git://git.denx.de/u-boot-testing.git , branch reloc-tests
>
>> - indicate exactly how you build your u-boot;
>
> Both with ELDK and CS tools:
>
> ../MAKELL tx25
>
>> - provide the u-boot binary that you last built (the one that has no
>> output).
>
> Will send two tarballs (built with ELDK and CS) in PM.
>
>> My goal here is to reproduce an u-boot identical to yours, in order to
>> make sur I can produce controlled u-boots for tx25, and then build some
>> specific tx25 u-boots for you to run.
>
> Thanks!

Thanks. With all this I am able to rebuild u-boot identically to yours; 
our maps only differ by the absolute path of the source code.

Also, I understand why the second RFC change I did was harmful to tx25. 
Contrary to u-boot itself, u-boot-spl is not compiled to be position 
independent; it actually loads at a given address then copies itself, 
without relocating, to its home location.

I also think I might have found out what hit tx25.

include/configs/tx25 defines the size of u-boot which SPL will use to 
load from NAND into RAM. currently it is defined thus:

#define CONFIG_SYS_NAND_U_BOOT_SIZE	0x30000

However, looking at the output of 'readelf -a dump of u-boot' 
(whitespace compressed to preserve formatting):

Section Headers:
[Nr] Name        Type     Addr     Off    Size   ES Flg Lk Inf Al
[ 0]             NULL     00000000 000000 000000 00      0   0  0
[ 1] .text       PROGBITS 81200000 008000 01b550 00  AX  0   0 32
[ 2] .rodata     PROGBITS 8121b550 023550 006082 00   A  0   0  4
[ 3] .hash       HASH     812215d4 0295d4 00003c 04   A  9   0  4
[ 4] .data       PROGBITS 81221610 029610 001de4 00  WA  0   0  4
[ 5] .got.plt    PROGBITS 812233f4 02b3f4 00000c 04  WA  0   0  4
[ 6] .u_boot_cmd PROGBITS 81223400 02b400 0003f0 00  WA  0   0  4
[ 7] .bss        NOBITS   812237f0 02b7f0 009108 00  WA  0   0  8
[ 8] .rel.dyn    REL      8122c8f8 02c8f8 003c60 08   A  9   0  4
[ 9] .dynsym     DYNSYM   81230558 030558 0000a0 10   A  0   3  4

See how .rel.dyn crosses the limit of 0x812230000, and .dynsym is 
completely beyond this limit? That means the SPL won't load the whole of 
rel.dyn and won't load any of .dynsym, but u-boot does not know it, so:

- it will run the fixup loop beyond 0x81230000 nnd up to 0x81230558, at 
best doing no harm if no 'relocation record' in that area is of type 2 
or 23, at most corrupting memory randomly if any 'relocation record' in 
that area happens to be type 2 or 23;

- it will not apply the fixup records generated by the linker and which 
landed at 0x81230000 and beyond.

Wolfgang, please try the following:

- on u-boot-testing, branch reloc_tests, revert commit 7fab02d... 
(that's "arm926ejs: fix jump to RAM nand_boot") as this 'fix' is a mistake.

- in include/configs/tx25.h, increasing CONFIG_SYS_NAND_U_BOOT_SIZE to 
0x31000

Let me know if building tx25 after these two corrections makes things 
better.

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCEF2E4.5080003@free.fr> you wrote:
>
> Also, I understand why the second RFC change I did was harmful to tx25. 
> Contrary to u-boot itself, u-boot-spl is not compiled to be position 
> independent; it actually loads at a given address then copies itself, 
> without relocating, to its home location.

It copies _itself_? Not the U-Boot payload?

Heiko, is this intentional?  Do we really first load the whole image,
then copy the U-Boot payload to some other address, then relocate it
to yet another one?


> I also think I might have found out what hit tx25.
> 
> include/configs/tx25 defines the size of u-boot which SPL will use to 
> load from NAND into RAM. currently it is defined thus:
> 
> #define CONFIG_SYS_NAND_U_BOOT_SIZE	0x30000

Arghh...

> Wolfgang, please try the following:
> 
> - on u-boot-testing, branch reloc_tests, revert commit 7fab02d... 
> (that's "arm926ejs: fix jump to RAM nand_boot") as this 'fix' is a mistake.
> 
> - in include/configs/tx25.h, increasing CONFIG_SYS_NAND_U_BOOT_SIZE to 
> 0x31000
> 
> Let me know if building tx25 after these two corrections makes things 
> better.

Bingo.

Both the ELDK and the CS compiled versions run fine now:

with ELDK:

U-Boot 2010.12-rc1-00030-g7fec359 (Nov 01 2010 - 20:13:53)

U-Boot code: 81200000 -> 81224E64  BSS: -> 8122DF68
CPU:   Freescale i.MX25 at 399 MHz

monitor len: 0002DF68
ramsize: 02000000
TLB table at: 81ff0000
Top of RAM usable for U-Boot at: 81ff0000
Reserving 183k for U-Boot at: 81fc2000
Reserving 1024k for malloc() at: 81ec2000
Reserving 24 Bytes for Board Info at: 81ec1fe8
Reserving 92 Bytes for Global Data at: 81ec1f8c
New Stack Pointer is: 81ec1f88
RAM Configuration:
Bank #0: 80000000 32 MiB
relocation Offset is: 00dc2000
monitor flash len: 00024E64
Now running in RAM - U-Boot at: 81fc2000
...

with CS:

U-Boot 2010.12-rc1-00030-g7fec359 (Nov 01 2010 - 20:18:09)

U-Boot code: 81200000 -> 812237E8  BSS: -> 8122C8F0
CPU:   Freescale i.MX25 at 399 MHz

monitor len: 0002C8F0
ramsize: 02000000
TLB table at: 81ff0000
Top of RAM usable for U-Boot at: 81ff0000
Reserving 178k for U-Boot at: 81fc3000
Reserving 1024k for malloc() at: 81ec3000
Reserving 24 Bytes for Board Info at: 81ec2fe8
Reserving 92 Bytes for Global Data at: 81ec2f8c
New Stack Pointer is: 81ec2f88
RAM Configuration:
Bank #0: 80000000 32 MiB
relocation Offset is: 00dc3000
monitor flash len: 000237E8
Now running in RAM - U-Boot at: 81fc3000
...


Note that the CS tool chain gives somewhat smaller code...

Thanks a lot!


Guess we should submit the temporary changes now as formal patches?

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
You go slow, be gentle. It's no one-way street -- you  know  how  you
feel and that's all. It's how the girl feels too. Don't press. If the
girl feels anything for you at all, you'll know.
	-- Kirk, "Charlie X", stardate 1535.8

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 01/11/2010 20:23, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CCEF2E4.5080003@free.fr>  you wrote:
>>
>> Also, I understand why the second RFC change I did was harmful to tx25.
>> Contrary to u-boot itself, u-boot-spl is not compiled to be position
>> independent; it actually loads at a given address then copies itself,
>> without relocating, to its home location.
>
> It copies _itself_? Not the U-Boot payload?
>
> Heiko, is this intentional?  Do we really first load the whole image,
> then copy the U-Boot payload to some other address, then relocate it
> to yet another one?

I haven't been clear.

The boot ROM or IPL loads u-boot-spl in RAM at a fixed location and 
jumps to it.

u-boot-spl copies itself at its intended location if not already there, 
and jumps to tiself at that new location.

u-boot-spl loads u-boot at a fixed location and jumps to it.

u-boot relocates (copies and fixes up) itself at top of ram if not 
already there, and jumps to itself at that new location.

>> I also think I might have found out what hit tx25.
>>
>> include/configs/tx25 defines the size of u-boot which SPL will use to
>> load from NAND into RAM. currently it is defined thus:
>>
>> #define CONFIG_SYS_NAND_U_BOOT_SIZE	0x30000
>
> Arghh...
>
>> Wolfgang, please try the following:
>>
>> - on u-boot-testing, branch reloc_tests, revert commit 7fab02d...
>> (that's "arm926ejs: fix jump to RAM nand_boot") as this 'fix' is a mistake.
>>
>> - in include/configs/tx25.h, increasing CONFIG_SYS_NAND_U_BOOT_SIZE to
>> 0x31000
>>
>> Let me know if building tx25 after these two corrections makes things
>> better.
>
> Bingo.

Phew.

> Both the ELDK and the CS compiled versions run fine now:
>
> with ELDK:
>
> U-Boot 2010.12-rc1-00030-g7fec359 (Nov 01 2010 - 20:13:53)
>
> U-Boot code: 81200000 ->  81224E64  BSS: ->  8122DF68
> CPU:   Freescale i.MX25 at 399 MHz
>
> monitor len: 0002DF68
> ramsize: 02000000
> TLB table at: 81ff0000
> Top of RAM usable for U-Boot at: 81ff0000
> Reserving 183k for U-Boot at: 81fc2000
> Reserving 1024k for malloc() at: 81ec2000
> Reserving 24 Bytes for Board Info at: 81ec1fe8
> Reserving 92 Bytes for Global Data at: 81ec1f8c
> New Stack Pointer is: 81ec1f88
> RAM Configuration:
> Bank #0: 80000000 32 MiB
> relocation Offset is: 00dc2000
> monitor flash len: 00024E64
> Now running in RAM - U-Boot at: 81fc2000
> ....
>
> with CS:
>
> U-Boot 2010.12-rc1-00030-g7fec359 (Nov 01 2010 - 20:18:09)
>
> U-Boot code: 81200000 ->  812237E8  BSS: ->  8122C8F0
> CPU:   Freescale i.MX25 at 399 MHz
>
> monitor len: 0002C8F0
> ramsize: 02000000
> TLB table at: 81ff0000
> Top of RAM usable for U-Boot at: 81ff0000
> Reserving 178k for U-Boot at: 81fc3000
> Reserving 1024k for malloc() at: 81ec3000
> Reserving 24 Bytes for Board Info at: 81ec2fe8
> Reserving 92 Bytes for Global Data at: 81ec2f8c
> New Stack Pointer is: 81ec2f88
> RAM Configuration:
> Bank #0: 80000000 32 MiB
> relocation Offset is: 00dc3000
> monitor flash len: 000237E8
> Now running in RAM - U-Boot at: 81fc3000
> ....
>
> Note that the CS tool chain gives somewhat smaller code...
>
> Thanks a lot!

You're welcome. :)
>
> Guess we should submit the temporary changes now as formal patches?

Yes, I will now prepare a patchset for mainline master. Do I include the 
increase of tx25 size?

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCF1558.1040108@free.fr> you wrote:
>
> Yes, I will now prepare a patchset for mainline master. Do I include the 
> increase of tx25 size?

If you like - yes please (as separate commit, though).  Or I can do
that, if it saves you some trouble.

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
If in any problem you find yourself doing an immense amount of  work,
the answer can be obtained by simple inspection.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Graeme Russ]

On Tuesday, November 2, 2010, Albert ARIBAUD <albert.aribaud@free.fr> wrote:
> Le 01/11/2010 20:23, Wolfgang Denk a ?crit :
>> Dear Albert ARIBAUD,
>>
>> In message<4CCEF2E4.5080003@free.fr> ?you wrote:
>>>
>>> Also, I understand why the second RFC change I did was harmful to tx25.
>>> Contrary to u-boot itself, u-boot-spl is not compiled to be position
>>> independent; it actually loads at a given address then copies itself,
>>> without relocating, to its home location.
>>
>> It copies _itself_? Not the U-Boot payload?
>>
>> Heiko, is this intentional? ?Do we really first load the whole image,
>> then copy the U-Boot payload to some other address, then relocate it
>> to yet another one?
>
> I haven't been clear.
>
> The boot ROM or IPL loads u-boot-spl in RAM at a fixed location and
> jumps to it.
>
> u-boot-spl copies itself at its intended location if not already there,
> and jumps to tiself at that new location.
>
> u-boot-spl loads u-boot at a fixed location and jumps to it.
>
> u-boot relocates (copies and fixes up) itself at top of ram if not
> already there, and jumps to itself at that new location.
>

Wow, what a terrible waste!

Why does u-boot-spl need to relocate?

Can't u-boot-spl load AND relocate u-boot, or does u-boot-spl have
tight space constraints?

Regards

Graeme

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 01/11/2010 20:44, Graeme Russ a ?crit :
> On Tuesday, November 2, 2010, Albert ARIBAUD<albert.aribaud@free.fr>  wrote:
>> Le 01/11/2010 20:23, Wolfgang Denk a ?crit :
>>> Dear Albert ARIBAUD,
>>>
>>> In message<4CCEF2E4.5080003@free.fr>    you wrote:
>>>>
>>>> Also, I understand why the second RFC change I did was harmful to tx25.
>>>> Contrary to u-boot itself, u-boot-spl is not compiled to be position
>>>> independent; it actually loads at a given address then copies itself,
>>>> without relocating, to its home location.
>>>
>>> It copies _itself_? Not the U-Boot payload?
>>>
>>> Heiko, is this intentional?  Do we really first load the whole image,
>>> then copy the U-Boot payload to some other address, then relocate it
>>> to yet another one?
>>
>> I haven't been clear.
>>
>> The boot ROM or IPL loads u-boot-spl in RAM at a fixed location and
>> jumps to it.
>>
>> u-boot-spl copies itself at its intended location if not already there,
>> and jumps to tiself at that new location.
>>
>> u-boot-spl loads u-boot at a fixed location and jumps to it.
>>
>> u-boot relocates (copies and fixes up) itself at top of ram if not
>> already there, and jumps to itself at that new location.
>>
>
> Wow, what a terrible waste!
>
> Why does u-boot-spl need to relocate?

As I said, u-boot-spl does not relocate, it only copies itself to its 
link-time location and jumps there, and it does this only if loaded 
somewhere else to boot (if I may say so). *Usually* it will be loaded at 
the right place and thus won't copy itself and jump to itself.

It still takes up some space, though. The copy and jump could actually 
be #ifdef's on CONFIG_NAND_SPL if everyone thinks it is safe -- please 
comment quickly as I'm preparing a patch set and that could go in it if 
agreed to.

> Can't u-boot-spl load AND relocate u-boot, or does u-boot-spl have
> tight space constraints?

It has; it comes from a (usually small) NAND page.

> Regards
>
> Graeme

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCF1AA5.809@free.fr> you wrote:
>
> As I said, u-boot-spl does not relocate, it only copies itself to its
> link-time location and jumps there, and it does this only if loaded
> somewhere else to boot (if I may say so). *Usually* it will be loaded at
> the right place and thus won't copy itself and jump to itself.
>
> It still takes up some space, though. The copy and jump could actually
> be #ifdef's on CONFIG_NAND_SPL if everyone thinks it is safe -- please
> comment quickly as I'm preparing a patch set and that could go in it if
> agreed to.

I think the overhead for the test, copy & jump code is small enough to
always keep this in - id adds robustness at little cost. And if the
code is correctly loaded, and no copy takes place, there is basicly
zero runtime overhead either.

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
A person who is more than casually interested in computers should  be
well  schooled in machine language, since it is a fundamental part of
a computer.                                           -- Donald Knuth

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 01/11/2010 20:35, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> In message<4CCF1558.1040108@free.fr>  you wrote:
>>
>> Yes, I will now prepare a patchset for mainline master. Do I include the
>> increase of tx25 size?
>
> If you like - yes please (as separate commit, though).  Or I can do
> that, if it saves you some trouble.

I'll do a three-patch set: arm926ejs, nand_spl and tx25. That ok?

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Scott Wood]

On Tue, 2 Nov 2010 06:44:41 +1100
Graeme Russ <graeme.russ@gmail.com> wrote:

> Wow, what a terrible waste!
> 
> Why does u-boot-spl need to relocate?

Because it is typically initially loaded into a special hardware
buffer.  That buffer needs to be freed up to be used to load the
payload.

> Can't u-boot-spl load AND relocate u-boot, or does u-boot-spl have
> tight space constraints?

It has tight space constraints -- often 4 KiB, sometimes even less IIRC.

-Scott

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Albert ARIBAUD,
> 
> In message <4CCEF2E4.5080003@free.fr> you wrote:
>> Also, I understand why the second RFC change I did was harmful to tx25. 
>> Contrary to u-boot itself, u-boot-spl is not compiled to be position 
>> independent; it actually loads at a given address then copies itself, 
>> without relocating, to its home location.
> 
> It copies _itself_? Not the U-Boot payload?
> 
> Heiko, is this intentional?  Do we really first load the whole image,
> then copy the U-Boot payload to some other address, then relocate it
> to yet another one?

- preloader copies first page of nand (nand_spl code) to
  0xbb000000 (some cpu internal mem) and jumps to this address
- nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code)
- from there, it copies u-boot code from nand to CONFIG_SYS_NAND_U_BOOT_DST
  and jumps to CONFIG_SYS_NAND_U_BOOT_START
- u-boot run into board_init_f, calculates new relocation address
  and relocates ...

But there is a possibility to prevent one copy, if TEXT_BASE =
relocation address = CONFIG_SYS_NAND_U_BOOT_DST

In this case nand_spl code copies u-boot from nand to
CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
no need to copy code in relocate_code().

But as codesize changes (and with it relocation address) this
is not a perfect solution.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 02/11/2010 07:29, Heiko Schocher a ?crit :

> - preloader copies first page of nand (nand_spl code) to
>    0xbb000000 (some cpu internal mem) and jumps to this address
> - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code)
> - from there, it copies u-boot code from nand to CONFIG_SYS_NAND_U_BOOT_DST
>    and jumps to CONFIG_SYS_NAND_U_BOOT_START
> - u-boot run into board_init_f, calculates new relocation address
>    and relocates ...
>
> But there is a possibility to prevent one copy, if TEXT_BASE =
> relocation address = CONFIG_SYS_NAND_U_BOOT_DST
>
> In this case nand_spl code copies u-boot from nand to
> CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
> no need to copy code in relocate_code().
>
> But as codesize changes (and with it relocation address) this
> is not a perfect solution.
>
> bye,
> Heiko

Heiko,

Since SPL is loaded in internal RAM, and since U-BOOT itself is loaded 
only in DRAM, why does SPL need to relocate itself? Can it not run 
entirely from IRAM and then jump to U-BOOT?

If SPL needs to relocate, then why does it run only the copy loop but 
not the fixups loop?

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Heiko Schocher]

Hello Albert,

Albert ARIBAUD wrote:
> Le 02/11/2010 07:29, Heiko Schocher a ?crit :
> 
>> - preloader copies first page of nand (nand_spl code) to
>>    0xbb000000 (some cpu internal mem) and jumps to this address
>> - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl
>> code)
>> - from there, it copies u-boot code from nand to
>> CONFIG_SYS_NAND_U_BOOT_DST
>>    and jumps to CONFIG_SYS_NAND_U_BOOT_START
>> - u-boot run into board_init_f, calculates new relocation address
>>    and relocates ...
>>
>> But there is a possibility to prevent one copy, if TEXT_BASE =
>> relocation address = CONFIG_SYS_NAND_U_BOOT_DST
>>
>> In this case nand_spl code copies u-boot from nand to
>> CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
>> no need to copy code in relocate_code().
>>
>> But as codesize changes (and with it relocation address) this
>> is not a perfect solution.
>>
>> bye,
>> Heiko
> 
> Heiko,
> 
> Since SPL is loaded in internal RAM, and since U-BOOT itself is loaded
> only in DRAM, why does SPL need to relocate itself? Can it not run
> entirely from IRAM and then jump to U-BOOT?

Good question. This was the old behaviour. Check this, if we can
prevent it.

> If SPL needs to relocate, then why does it run only the copy loop but
> not the fixups loop?

in nand_spl//nand_boot_fsl_nfc.c:

void board_init_f (ulong bootflag)
{
	relocate_code (CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
		CONFIG_SYS_TEXT_BASE);
}

-> nand_spl code gets copied where it is compiled for ... no need
   for fixups.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4CCFAFE4.3000600@denx.de> you wrote:
> 
> - preloader copies first page of nand (nand_spl code) to
>   0xbb000000 (some cpu internal mem) and jumps to this address
> - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code)

Why is this relocation needed? I understand that this 0xbb000000
address is determined by the given hardware ans as such always fix?

> But as codesize changes (and with it relocation address) this
> is not a perfect solution.

Indeed. CONFIG_SYS_NAND_U_BOOT_SIZE should be dropped, and the avtual
value should be derived from the actual U-Boot image building
process.


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've seen it. It's rubbish."          - Marvin the Paranoid Android

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4CCFAFE4.3000600@denx.de> you wrote:
>> - preloader copies first page of nand (nand_spl code) to
>>   0xbb000000 (some cpu internal mem) and jumps to this address
>> - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code)
> 
> Why is this relocation needed? I understand that this 0xbb000000

Thats the question to solve ... don;t know, why nand_spl code
on arm (and other architectures?) do this ... I try to have a look
to find out, if we can run the nand_spl code complete from
this address, and immedietaly copy u-boot from nand to ram ...

> address is determined by the given hardware ans as such always fix?

Yep.

>> But as codesize changes (and with it relocation address) this
>> is not a perfect solution.
> 
> Indeed. CONFIG_SYS_NAND_U_BOOT_SIZE should be dropped, and the avtual
> value should be derived from the actual U-Boot image building
> process.

Yep.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Reinhard Meyer]

Dear Heiko Schocher,
> But there is a possibility to prevent one copy, if TEXT_BASE =
> relocation address = CONFIG_SYS_NAND_U_BOOT_DST
> 
> In this case nand_spl code copies u-boot from nand to
> CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
> no need to copy code in relocate_code().
> 
> But as codesize changes (and with it relocation address) this
> is not a perfect solution.

Worse: it would certainly crash since the original and relocated memory
areas must not overlap - they sure would with even the slightest size change.

That idea should not be promoted any further.

I would recommend that we add code to check for overlapping relocation into
board.c and print a panic message if an overlap is detected.

Best Regards,
Reinhard

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 02/11/2010 09:57, Reinhard Meyer a ?crit :
> Dear Heiko Schocher,
>> But there is a possibility to prevent one copy, if TEXT_BASE =
>> relocation address = CONFIG_SYS_NAND_U_BOOT_DST
>>
>> In this case nand_spl code copies u-boot from nand to
>> CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
>> no need to copy code in relocate_code().
>>
>> But as codesize changes (and with it relocation address) this
>> is not a perfect solution.
>
> Worse: it would certainly crash since the original and relocated memory
> areas must not overlap - they sure would with even the slightest size change.

I'm not sure I get you there. If u-boot was linked for a given address 
and happends to be loaded at that same address, then there is no need to 
relocate, right?

> I would recommend that we add code to check for overlapping relocation into
> board.c and print a panic message if an overlap is detected.

I *think* overlap would be correctly handled if we modify the copy code 
to copy from top to bottom, because we know that the destination is 
higher than the source.

The only tricky case would be when the target address is right in the 
middle of the source relocation code, because then the last iteratons of 
the copy code would corrupt this code; that can be avoided by making 
sure the SPL loads u-boot low enough in RAM.

> Best Regards,
> Reinhard

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Stefan Roese]

Hi Heiko,

On Tuesday 02 November 2010 09:55:46 Heiko Schocher wrote:
> >> - preloader copies first page of nand (nand_spl code) to
> >> 
> >>   0xbb000000 (some cpu internal mem) and jumps to this address
> >> 
> >> - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl
> >> code)
> > 
> > Why is this relocation needed? I understand that this 0xbb000000
> 
> Thats the question to solve ... don;t know, why nand_spl code
> on arm (and other architectures?) do this ... I try to have a look
> to find out, if we can run the nand_spl code complete from
> this address, and immedietaly copy u-boot from nand to ram ...

On PPC4xx we need to copy the code from the original location (4KiB loaded via 
the ROM IPL boot loader) to SDRAM and continue running it from there. This is 
necessary since we can't run from the original location (0xfffffxxx) and use 
the PPC4xx NAND controller at the same time.

So there is no relocation to TEXT_BASE on 4xx but "only" a copy to 
CONFIG_SYS_NAND_BOOT_SPL_DST.

Cheers,
Stefan

--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Sughosh Ganu]

hi Heiko,

On Tue Nov 02, 2010 at 09:55:46AM +0100, Heiko Schocher wrote:
> Hello Wolfgang,
> 
> Wolfgang Denk wrote:
> > Dear Heiko Schocher,
> > 
> > In message <4CCFAFE4.3000600@denx.de> you wrote:
> >> - preloader copies first page of nand (nand_spl code) to
> >>   0xbb000000 (some cpu internal mem) and jumps to this address
> >> - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl code)
> > 
> > Why is this relocation needed? I understand that this 0xbb000000
> 
> Thats the question to solve ... don;t know, why nand_spl code
> on arm (and other architectures?) do this ... I try to have a look
> to find out, if we can run the nand_spl code complete from
> this address, and immedietaly copy u-boot from nand to ram ...

  I am not sure about all the ARM boards using nand_spl, but atleast
  on the hawkboard for which i have submitted patches, i have removed
  the call to relocate_code in nand_spl in V5. This is not needed at
  least on this board, as the nand_spl gets copied directly to the
  RAM.


> >> But as codesize changes (and with it relocation address) this
> >> is not a perfect solution.
> > 
> > Indeed. CONFIG_SYS_NAND_U_BOOT_SIZE should be dropped, and the avtual
> > value should be derived from the actual U-Boot image building
> > process.
> 
> Yep.


 But i have a doubt here. In case of hawkboard, the very reason we
 have a nand_spl booting stage is because the initial bootloader(RBL
 from TI) does not use the ECC layout as used by the davinci nand
 driver in u-boot. We flash the nand_spl separately by booting over
 UART[1]. In case, we compute the u-boot size dynamically, it would be
 needed to flash the nand_spl each time we build u-boot.

 Can we make a change such that we define an upper limit for the
 u-boot size, and the build produces a warning/error in case the
 u-boot size goes above this limit. We can avoid flashing the nand_spl
 each time using this method.

[1] - Please check doc/README.hawkboard
http://comments.gmane.org/gmane.comp.boot-loaders.u-boot/88139

-sughosh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Reinhard Meyer]

Dear Albert ARIBAUD,
> Le 02/11/2010 09:57, Reinhard Meyer a ?crit :
>> Dear Heiko Schocher,
>>> But there is a possibility to prevent one copy, if TEXT_BASE =
>>> relocation address = CONFIG_SYS_NAND_U_BOOT_DST
>>>
>>> In this case nand_spl code copies u-boot from nand to
>>> CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation address,
>>> no need to copy code in relocate_code().
>>>
>>> But as codesize changes (and with it relocation address) this
>>> is not a perfect solution.
>>
>> Worse: it would certainly crash since the original and relocated memory
>> areas must not overlap - they sure would with even the slightest size
>> change.
> 
> I'm not sure I get you there. If u-boot was linked for a given address
> and happends to be loaded at that same address, then there is no need to
> relocate, right?

*if* the code size changes, "need" for relocation would arise...

>> I would recommend that we add code to check for overlapping relocation
>> into
>> board.c and print a panic message if an overlap is detected.
> 
> I *think* overlap would be correctly handled if we modify the copy code
> to copy from top to bottom, because we know that the destination is
> higher than the source.

No, in above case the (new) destination could be lower than the loaded
address (e.g. code size increased).

In any case it is not worth the effort to plan for overlapping relocations.
We can always load u-boot to a very low address of SDRAM and let it relocate.

> The only tricky case would be when the target address is right in the
> middle of the source relocation code, because then the last iteratons of
> the copy code would corrupt this code; that can be avoided by making
> sure the SPL loads u-boot low enough in RAM.

Exactly.

My original message was: "please to not give people the idea that they can
avoid relocation by loading u-boot at the exact address the relocation would
calculate. That is bound to *really* break at the slightest change to u-boot."

Best Regards,
Reinhard

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4CCFD27E.3080500@emk-elektronik.de> you wrote:
>
> I would recommend that we add code to check for overlapping relocation into
> board.c and print a panic message if an overlap is detected.

Why should we try to detect a problem when we can as well avoid the
problem?

The needed image isze if known when we build the image, we just have
to use it instead of manually defining a constant value.

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 faster I go, the behinder I get.                 -- Lewis Carroll

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 02/11/2010 10:34, Reinhard Meyer a ?crit :

> My original message was: "please to not give people the idea that they can
> avoid relocation by loading u-boot at the exact address the relocation would
> calculate. That is bound to *really* break at the slightest change to u-boot."

Oh, I see. What you mean is "if people force the loading of u-boot at a 
fixed address which happens to be its current relocated address, a 
change of size in u-boot will break because the relocated address will 
change but the forced address won't.

I was talking about a different thing, which is "if u-boot finds that 
the address at which it runs now is the address at which it should run, 
then it can skip relocation (copy and fixups)".

> Best Regards,
> Reinhard

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 02/11/2010 10:38, Wolfgang Denk a ?crit :
> Dear Reinhard Meyer,
>
> In message<4CCFD27E.3080500@emk-elektronik.de>  you wrote:
>>
>> I would recommend that we add code to check for overlapping relocation into
>> board.c and print a panic message if an overlap is detected.
>
> Why should we try to detect a problem when we can as well avoid the
> problem?
>
> The needed image isze if known when we build the image, we just have
> to use it instead of manually defining a constant value.

These is a valid point that the SPL isn't necessarily rebuilt and 
flashed every time u-boot itself is built and flashed, so whatever 
constant the SPL would carry would only be valid for the u-boot that was 
built alongside.

Now a solution would be that the actual u-boot size be flashed along 
with it, for instance as a literal defined as '.word _end - _start' 
right after the vectors. The SPL could load a first NAND block, read the 
literal, round it to a multiple of NAND blocks by default, and then read 
this quantity.

That would remove the dependency at the cost of extra code in the SPL, 
though, and not all boards might be able to afford it.

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Sughosh Ganu]

hi Albert,

On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:

> Now a solution would be that the actual u-boot size be flashed along 
> with it, for instance as a literal defined as '.word _end - _start' 
> right after the vectors. The SPL could load a first NAND block, read the 
> literal, round it to a multiple of NAND blocks by default, and then read 
> this quantity.
> 
> That would remove the dependency at the cost of extra code in the SPL, 
> though, and not all boards might be able to afford it.

  Another issue is that the nand_spl might be compiled and flashed
  to the NAND as a separate entity, using a separate flashing
  mechanism. If we use the dynamic calculation of the u-boot size,
  this would necessitate building and flashing the nand_spl each time
  along with u-boot.

-sughosh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 02/11/2010 10:56, Sughosh Ganu a ?crit :
> hi Albert,
>
> On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:
>
>> Now a solution would be that the actual u-boot size be flashed along
>> with it, for instance as a literal defined as '.word _end - _start'
>> right after the vectors. The SPL could load a first NAND block, read the
>> literal, round it to a multiple of NAND blocks by default, and then read
>> this quantity.
>>
>> That would remove the dependency at the cost of extra code in the SPL,
>> though, and not all boards might be able to afford it.
>
>    Another issue is that the nand_spl might be compiled and flashed
>    to the NAND as a separate entity, using a separate flashing
>    mechanism. If we use the dynamic calculation of the u-boot size,
>    this would necessitate building and flashing the nand_spl each time
>    along with u-boot.

Not with the solution I describe, as the once-flashed SPL would fetch 
the actual size from the actual u-boot.

> -sughosh

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Sughosh Ganu]

On Tue Nov 02, 2010 at 12:16:55PM +0100, Albert ARIBAUD wrote:
> Le 02/11/2010 10:56, Sughosh Ganu a ?crit :
>> hi Albert,
>>
>> On Tue Nov 02, 2010 at 10:47:49AM +0100, Albert ARIBAUD wrote:
>>
>>> Now a solution would be that the actual u-boot size be flashed along
>>> with it, for instance as a literal defined as '.word _end - _start'
>>> right after the vectors. The SPL could load a first NAND block, read the
>>> literal, round it to a multiple of NAND blocks by default, and then read
>>> this quantity.
>>>
>>> That would remove the dependency at the cost of extra code in the SPL,
>>> though, and not all boards might be able to afford it.
>>
>>    Another issue is that the nand_spl might be compiled and flashed
>>    to the NAND as a separate entity, using a separate flashing
>>    mechanism. If we use the dynamic calculation of the u-boot size,
>>    this would necessitate building and flashing the nand_spl each time
>>    along with u-boot.
>
> Not with the solution I describe, as the once-flashed SPL would fetch  
> the actual size from the actual u-boot.

 Yes that is correct. I was referring to the other solution of fixing
 the size through the script.

-sughosh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CCFDE45.3060306@free.fr> you wrote:
>
> These is a valid point that the SPL isn't necessarily rebuilt and 
> flashed every time u-boot itself is built and flashed, so whatever 
> constant the SPL would carry would only be valid for the u-boot that was 
> built alongside.

I have to admit that I was not aware that there are systems were SPL
and U-Boot itself are not bundled into a single image, but handled
separately. [I have to admit that I don;t like such a setup; it cries
for incompatibilities and other trouble.]

> Now a solution would be that the actual u-boot size be flashed along 
> with it, for instance as a literal defined as '.word _end - _start' 
> right after the vectors. The SPL could load a first NAND block, read the 
> literal, round it to a multiple of NAND blocks by default, and then read 
> this quantity.
> 
> That would remove the dependency at the cost of extra code in the SPL, 
> though, and not all boards might be able to afford it.

Indeed. Maybe be can combine several approaches:

- In case SPL and U-Boot are combined into a single image anyway, we
  can use a compile-time compution of the needed length, without
  additional code in the SPL.
- Where this is not prossible (i. e. SPL and U-Boot are separate), we
  can try and optionally provide the solution you suggest.
- Where memory is toot ight to allow for that code, the old style of a
  static #define will be used as a fallback.

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
Due to lack of disk space, this fortune database has been discontinued.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[V, Aneesh]

Dear Reinhard, Wolfgang, 

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de [mailto:u-boot-
> bounces at lists.denx.de] On Behalf Of Reinhard Meyer
> Sent: Tuesday, November 02, 2010 3:04 PM
> To: Albert ARIBAUD
> Cc: u-boot at lists.denx.de; hs at denx.de
> Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
> 
> Dear Albert ARIBAUD,
> > Le 02/11/2010 09:57, Reinhard Meyer a ?crit :
> >> Dear Heiko Schocher,
> >>> But there is a possibility to prevent one copy, if TEXT_BASE =
> >>> relocation address = CONFIG_SYS_NAND_U_BOOT_DST
> >>>
> >>> In this case nand_spl code copies u-boot from nand to
> >>> CONFIG_SYS_NAND_U_BOOT_DST. As this is equal to the relocation
> address,
> >>> no need to copy code in relocate_code().
> >>>
> >>> But as codesize changes (and with it relocation address) this
> >>> is not a perfect solution.
> >>
> >> Worse: it would certainly crash since the original and relocated
> memory
> >> areas must not overlap - they sure would with even the slightest
> size
> >> change.
> >
> > I'm not sure I get you there. If u-boot was linked for a given
> address
> > and happends to be loaded at that same address, then there is no
> need to
> > relocate, right?
> 
> *if* the code size changes, "need" for relocation would arise...
> 
> >> I would recommend that we add code to check for overlapping
> relocation
> >> into
> >> board.c and print a panic message if an overlap is detected.
> >
> > I *think* overlap would be correctly handled if we modify the copy
> code
> > to copy from top to bottom, because we know that the destination
> is
> > higher than the source.
> 
> No, in above case the (new) destination could be lower than the
> loaded
> address (e.g. code size increased).
> 
> In any case it is not worth the effort to plan for overlapping
> relocations.
> We can always load u-boot to a very low address of SDRAM and let it
> relocate.
> 
> > The only tricky case would be when the target address is right in
> the
> > middle of the source relocation code, because then the last
> iteratons of
> > the copy code would corrupt this code; that can be avoided by
> making
> > sure the SPL loads u-boot low enough in RAM.
> 
> Exactly.
> 
> My original message was: "please to not give people the idea that
> they can
> avoid relocation by loading u-boot at the exact address the
> relocation would
> calculate. That is bound to *really* break at the slightest change
> to u-boot."

Shouldn't we provide a CONFIG option by which users can disable
Elf relocation? 

On production systems you know exactly how much memory you have.
Relocation may not be very useful. On the other hand faster boot is a 
bigger concern. Shouldn't we support this case?

Best regards,
Aneesh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear "V, Aneesh",

In message <FF55437E1F14DA4BAEB721A458B6701706FD313705@dbde02.ent.ti.com> you wrote:
> 
> Shouldn't we provide a CONFIG option by which users can disable
> Elf relocation?

Why should we?  It would just make the code even more complicated, and
require a lot of additional test cases.

> On production systems you know exactly how much memory you have.
> Relocation may not be very useful. On the other hand faster boot is a
> bigger concern. Shouldn't we support this case?

If time in your concern, then did you measure the time the relocation
costs you?  How long is it on your system?

Please be aware that a whole number of other features depend on doing
real relocation. Also, it brings us a lot closer to use common code
across architectures, instead of having to maintain several different
(and differently behaving) implementations.

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
If programming was easy, they wouldn't need something as  complicated
as a human being to do it, now would they?
                       - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[V, Aneesh]

Dear Wolfgang,

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Wednesday, November 03, 2010 1:33 PM
> To: V, Aneesh
> Cc: Reinhard Meyer; Albert ARIBAUD; u-boot at lists.denx.de; hs at denx.de
> Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
> 
> Dear "V, Aneesh",
> 
> In message
> <FF55437E1F14DA4BAEB721A458B6701706FD313705@dbde02.ent.ti.com> you
> wrote:
> >
> > Shouldn't we provide a CONFIG option by which users can disable
> > Elf relocation?
> 
> Why should we?  It would just make the code even more complicated,
> and
> require a lot of additional test cases.
> 
> > On production systems you know exactly how much memory you have.
> > Relocation may not be very useful. On the other hand faster boot
> is a
> > bigger concern. Shouldn't we support this case?
> 
> If time in your concern, then did you measure the time the
> relocation
> costs you?  How long is it on your system?
> 

We will do this measurement and get back to you. 

> Please be aware that a whole number of other features depend on
> doing
> real relocation. Also, it brings us a lot closer to use common code

If the preloader loads the u-boot to the location that it is built for 
everything should work fine once bss is initialized, right?

Best regards,
Aneesh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear "V, Aneesh",

In message <FF55437E1F14DA4BAEB721A458B6701706FD3137F3@dbde02.ent.ti.com> you wrote:
> 
> If the preloader loads the u-boot to the location that it is built for 
> everything should work fine once bss is initialized, right?

There is no such thing as a "location that it is built for", as the
location in RAM may differ, depending on enabled features - for
example, pRAM size or (shared) frame buffer size may change depending
on environment variable settings. In the result, the location of
U-Boot in RAM shifts.  You cannot know the final address at build
time.

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
"In matters of principle, stand like a rock;  in  matters  of  taste,
swim with the current."                            - Thomas Jefferson

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[V, Aneesh]

Dear Wofgang, 

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Wednesday, November 03, 2010 4:58 PM
> To: V, Aneesh
> Cc: Reinhard Meyer; Albert ARIBAUD; u-boot at lists.denx.de; hs at denx.de
> Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
> 
> Dear "V, Aneesh",
> 
> In message
> <FF55437E1F14DA4BAEB721A458B6701706FD3137F3@dbde02.ent.ti.com> you
> wrote:
> >
> > If the preloader loads the u-boot to the location that it is built
> for
> > everything should work fine once bss is initialized, right?
> 
> There is no such thing as a "location that it is built for", as the
> location in RAM may differ, depending on enabled features - for
> example, pRAM size or (shared) frame buffer size may change
> depending
> on environment variable settings. In the result, the location of
> U-Boot in RAM shifts.  You cannot know the final address at build
> time.

Just curious. Why don't we allocate memory for such needs below the
u-boot (lower address) like we do for malloc area and stack. This way
the location where u-boot is relocated will only depend on the SDRAM 
size and size of u-boot itself, right?

Best regards,
Aneesh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Albert ARIBAUD]

Le 03/11/2010 13:03, V, Aneesh a ?crit :

> Just curious. Why don't we allocate memory for such needs below the
> u-boot (lower address) like we do for malloc area and stack. This way
> the location where u-boot is relocated will only depend on the SDRAM
> size and size of u-boot itself, right?

My guess is that the same memory will be allocated by the OS after 
u-boot, and allocating at the same location in both occasions allows for 
things like flicker-free boot splashes and such.

And if you allocate this below u-boot, you end up with a split memory 
map with some allocated space in the middle of useable OS or user space.

So we allocate that at top of RAM, and later on, Linux can use all the 
memory below as a single contiguous area.

> Best regards,
> Aneesh

Amicalement,
-- 
Albert.

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[V, Aneesh]

Dear Albert, Wolfgang,

> -----Original Message-----
> From: Albert ARIBAUD [mailto:albert.aribaud at free.fr]
> Sent: Wednesday, November 03, 2010 5:38 PM
> To: V, Aneesh
> Cc: Wolfgang Denk; u-boot at lists.denx.de; hs at denx.de
> Subject: Re: [RFC] arm926ejs: fix jump to RAM nand_boot
> 
> Le 03/11/2010 13:03, V, Aneesh a ?crit :
> 
> > Just curious. Why don't we allocate memory for such needs below
> the
> > u-boot (lower address) like we do for malloc area and stack. This
> way
> > the location where u-boot is relocated will only depend on the
> SDRAM
> > size and size of u-boot itself, right?
> 
> My guess is that the same memory will be allocated by the OS after
> u-boot, and allocating at the same location in both occasions allows
> for
> things like flicker-free boot splashes and such.
> 
> And if you allocate this below u-boot, you end up with a split
> memory
> map with some allocated space in the middle of useable OS or user
> space.
> 
> So we allocate that at top of RAM, and later on, Linux can use all
> the
> memory below as a single contiguous area.

I get it now. 

But in any case, there are many boards that do not use these features
like ours. Skipping relocation, if the support is provided may be
useful for such boards.

Anyway, as I said earlier, we will come back with data on how much 
time can be saved by skipping relocation. 

Best regards,
Aneesh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear "V, Aneesh",

In message <FF55437E1F14DA4BAEB721A458B6701706FD313852@dbde02.ent.ti.com> you wrote:
>
> Just curious. Why don't we allocate memory for such needs below the
> u-boot (lower address) like we do for malloc area and stack. This way
> the location where u-boot is relocated will only depend on the SDRAM=20
> size and size of u-boot itself, right?

That would mean that all the memory where U-Boot was located is lost
for use in Linux, as we reserve these areas by adjusting the "mem="
boot argument.  Allocation of such memory blocks must start at the
top, ang do downwards. And U-Boot lies below that, then.

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
And now remains  That we find out the cause of this effect, Or rather
say, the cause of this defect...           -- Hamlet, Act II, Scene 2

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[V, Aneesh]

Dear Wolfgang,

> -----Original Message-----
> From: Wolfgang Denk [mailto:wd at denx.de]
> Sent: Wednesday, November 03, 2010 6:30 PM
> To: V, Aneesh
> Cc: Reinhard Meyer; Albert ARIBAUD; u-boot at lists.denx.de; hs at denx.de
> Subject: Re: [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
> 
> Dear "V, Aneesh",
> 
> In message
> <FF55437E1F14DA4BAEB721A458B6701706FD313852@dbde02.ent.ti.com> you
> wrote:
> >
> > Just curious. Why don't we allocate memory for such needs below
> the
> > u-boot (lower address) like we do for malloc area and stack. This
> way
> > the location where u-boot is relocated will only depend on the
> SDRAM=20
> > size and size of u-boot itself, right?
> 
> That would mean that all the memory where U-Boot was located is lost
> for use in Linux, as we reserve these areas by adjusting the "mem="
> boot argument.  Allocation of such memory blocks must start at the
> top, ang do downwards. And U-Boot lies below that, then.

Thanks. It's clear now. 

Also, I checked the time it takes to do relocation. 

On OMAP4430 with Cortex-A9 at 1GHz and LPDDR2 SDRAM at 400MHz it
took a mere 16 ms to do the relocation of u-boot image that was
about 146 KB.

I agree with you. Skipping relocation is not worth the complexity. 

Best regards,
Aneesh

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Wolfgang Denk]

Dear "V, Aneesh",

In message <FF55437E1F14DA4BAEB721A458B6701706FD313899@dbde02.ent.ti.com> you wrote:
> 
> Also, I checked the time it takes to do relocation. 
> 
> On OMAP4430 with Cortex-A9 at 1GHz and LPDDR2 SDRAM at 400MHz it
> took a mere 16 ms to do the relocation of u-boot image that was
> about 146 KB.
> 
> I agree with you. Skipping relocation is not worth the complexity. 

Thanks a lot for the testing.

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
Successful and fortunate crime is called virtue.             - Seneca

[U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot

[Scott Wood]

On Tue, 2 Nov 2010 10:17:23 +0100
Stefan Roese <sr@denx.de> wrote:

> Hi Heiko,
> 
> On Tuesday 02 November 2010 09:55:46 Heiko Schocher wrote:
> > >> - preloader copies first page of nand (nand_spl code) to
> > >> 
> > >>   0xbb000000 (some cpu internal mem) and jumps to this address
> > >> 
> > >> - nand_spl does lowlevelinit, relocate itself to TEXT_BASE (nand_spl
> > >> code)
> > > 
> > > Why is this relocation needed? I understand that this 0xbb000000
> > 
> > Thats the question to solve ... don;t know, why nand_spl code
> > on arm (and other architectures?) do this ... I try to have a look
> > to find out, if we can run the nand_spl code complete from
> > this address, and immedietaly copy u-boot from nand to ram ...
> 
> On PPC4xx we need to copy the code from the original location (4KiB loaded via 
> the ROM IPL boot loader) to SDRAM and continue running it from there. This is 
> necessary since we can't run from the original location (0xfffffxxx) and use 
> the PPC4xx NAND controller at the same time.

We have the same restriction on FSL NAND controllers -- certainly the
eLBC, and I think also the NFC which is used on ARM, though I'm less
familiar with that one.

> So there is no relocation to TEXT_BASE on 4xx but "only" a copy to 
> CONFIG_SYS_NAND_BOOT_SPL_DST.

It looks like you do memory init from assembly code to pull that off.
On 83xx/85xx we do an actual relocation of the NAND SPL.  Not sure
about ARM.

-Scott