* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
@ 2010-10-31 17:43 Albert Aribaud
2010-10-31 18:11 ` Alexander Holler
` (2 more replies)
0 siblings, 3 replies; 62+ messages in thread
From: Albert Aribaud @ 2010-10-31 17:43 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 17:43 [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert Aribaud
@ 2010-10-31 18:11 ` Alexander Holler
2010-10-31 18:12 ` Wolfgang Denk
2010-10-31 18:35 ` Darius Augulis
2 siblings, 0 replies; 62+ messages in thread
From: Alexander Holler @ 2010-10-31 18:11 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 17:43 [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert Aribaud
2010-10-31 18:11 ` Alexander Holler
@ 2010-10-31 18:12 ` Wolfgang Denk
2010-10-31 18:31 ` Albert ARIBAUD
2010-10-31 18:38 ` Alexander Holler
2010-10-31 18:35 ` Darius Augulis
2 siblings, 2 replies; 62+ messages in thread
From: Wolfgang Denk @ 2010-10-31 18:12 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 18:12 ` Wolfgang Denk
@ 2010-10-31 18:31 ` Albert ARIBAUD
2010-10-31 18:36 ` Wolfgang Denk
2010-10-31 18:38 ` Alexander Holler
1 sibling, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-10-31 18:31 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 17:43 [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert Aribaud
2010-10-31 18:11 ` Alexander Holler
2010-10-31 18:12 ` Wolfgang Denk
@ 2010-10-31 18:35 ` Darius Augulis
2010-10-31 18:53 ` Albert ARIBAUD
2 siblings, 1 reply; 62+ messages in thread
From: Darius Augulis @ 2010-10-31 18:35 UTC (permalink / raw)
To: u-boot
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*) }
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 18:31 ` Albert ARIBAUD
@ 2010-10-31 18:36 ` Wolfgang Denk
0 siblings, 0 replies; 62+ messages in thread
From: Wolfgang Denk @ 2010-10-31 18:36 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 18:12 ` Wolfgang Denk
2010-10-31 18:31 ` Albert ARIBAUD
@ 2010-10-31 18:38 ` Alexander Holler
2010-10-31 19:01 ` Wolfgang Denk
2010-10-31 19:01 ` [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert ARIBAUD
1 sibling, 2 replies; 62+ messages in thread
From: Alexander Holler @ 2010-10-31 18:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 18:35 ` Darius Augulis
@ 2010-10-31 18:53 ` Albert ARIBAUD
0 siblings, 0 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-10-31 18:53 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 18:38 ` Alexander Holler
@ 2010-10-31 19:01 ` Wolfgang Denk
2010-10-31 19:07 ` Albert ARIBAUD
2010-10-31 19:01 ` [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert ARIBAUD
1 sibling, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-10-31 19:01 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 18:38 ` Alexander Holler
2010-10-31 19:01 ` Wolfgang Denk
@ 2010-10-31 19:01 ` Albert ARIBAUD
1 sibling, 0 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-10-31 19:01 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 19:01 ` Wolfgang Denk
@ 2010-10-31 19:07 ` Albert ARIBAUD
2010-10-31 19:22 ` Wolfgang Denk
0 siblings, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-10-31 19:07 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 19:07 ` Albert ARIBAUD
@ 2010-10-31 19:22 ` Wolfgang Denk
2010-10-31 19:40 ` Albert ARIBAUD
0 siblings, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-10-31 19:22 UTC (permalink / raw)
To: u-boot
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"
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 19:22 ` Wolfgang Denk
@ 2010-10-31 19:40 ` Albert ARIBAUD
2010-10-31 19:59 ` Wolfgang Denk
0 siblings, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-10-31 19:40 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 19:40 ` Albert ARIBAUD
@ 2010-10-31 19:59 ` Wolfgang Denk
2010-10-31 20:23 ` Albert ARIBAUD
0 siblings, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-10-31 19:59 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 19:59 ` Wolfgang Denk
@ 2010-10-31 20:23 ` Albert ARIBAUD
2010-10-31 20:32 ` Wolfgang Denk
2010-10-31 21:20 ` [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Albert Aribaud
0 siblings, 2 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-10-31 20:23 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
2010-10-31 20:23 ` Albert ARIBAUD
@ 2010-10-31 20:32 ` Wolfgang Denk
2010-10-31 21:20 ` [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Albert Aribaud
1 sibling, 0 replies; 62+ messages in thread
From: Wolfgang Denk @ 2010-10-31 20:32 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-10-31 20:23 ` Albert ARIBAUD
2010-10-31 20:32 ` Wolfgang Denk
@ 2010-10-31 21:20 ` Albert Aribaud
2010-10-31 21:51 ` Wolfgang Denk
2010-10-31 22:28 ` Alexander Holler
1 sibling, 2 replies; 62+ messages in thread
From: Albert Aribaud @ 2010-10-31 21:20 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply related [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-10-31 21:20 ` [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Albert Aribaud
@ 2010-10-31 21:51 ` Wolfgang Denk
2010-10-31 21:55 ` Albert ARIBAUD
2010-10-31 22:28 ` Alexander Holler
1 sibling, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-10-31 21:51 UTC (permalink / raw)
To: u-boot
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_
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-10-31 21:51 ` Wolfgang Denk
@ 2010-10-31 21:55 ` Albert ARIBAUD
0 siblings, 0 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-10-31 21:55 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-10-31 21:20 ` [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Albert Aribaud
2010-10-31 21:51 ` Wolfgang Denk
@ 2010-10-31 22:28 ` Alexander Holler
2010-10-31 23:04 ` Albert ARIBAUD
1 sibling, 1 reply; 62+ messages in thread
From: Alexander Holler @ 2010-10-31 22:28 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-10-31 22:28 ` Alexander Holler
@ 2010-10-31 23:04 ` Albert ARIBAUD
2010-11-01 5:13 ` sughosh ganu
2010-11-01 9:15 ` Wolfgang Denk
0 siblings, 2 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-10-31 23:04 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-10-31 23:04 ` Albert ARIBAUD
@ 2010-11-01 5:13 ` sughosh ganu
2010-11-01 8:12 ` Albert ARIBAUD
2010-11-01 9:15 ` Wolfgang Denk
1 sibling, 1 reply; 62+ messages in thread
From: sughosh ganu @ 2010-11-01 5:13 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 5:13 ` sughosh ganu
@ 2010-11-01 8:12 ` Albert ARIBAUD
2010-11-01 9:13 ` Wolfgang Denk
0 siblings, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-01 8:12 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 8:12 ` Albert ARIBAUD
@ 2010-11-01 9:13 ` Wolfgang Denk
0 siblings, 0 replies; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-01 9:13 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-10-31 23:04 ` Albert ARIBAUD
2010-11-01 5:13 ` sughosh ganu
@ 2010-11-01 9:15 ` Wolfgang Denk
2010-11-01 17:03 ` Albert ARIBAUD
1 sibling, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-01 9:15 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 9:15 ` Wolfgang Denk
@ 2010-11-01 17:03 ` Albert ARIBAUD
2010-11-01 19:23 ` Wolfgang Denk
0 siblings, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-01 17:03 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 17:03 ` Albert ARIBAUD
@ 2010-11-01 19:23 ` Wolfgang Denk
2010-11-01 19:30 ` Albert ARIBAUD
2010-11-02 6:29 ` Heiko Schocher
0 siblings, 2 replies; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-01 19:23 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 19:23 ` Wolfgang Denk
@ 2010-11-01 19:30 ` Albert ARIBAUD
2010-11-01 19:35 ` Wolfgang Denk
2010-11-01 19:44 ` Graeme Russ
2010-11-02 6:29 ` Heiko Schocher
1 sibling, 2 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-01 19:30 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 19:30 ` Albert ARIBAUD
@ 2010-11-01 19:35 ` Wolfgang Denk
2010-11-01 20:04 ` Albert ARIBAUD
2010-11-01 19:44 ` Graeme Russ
1 sibling, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-01 19:35 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 19:30 ` Albert ARIBAUD
2010-11-01 19:35 ` Wolfgang Denk
@ 2010-11-01 19:44 ` Graeme Russ
2010-11-01 19:53 ` Albert ARIBAUD
2010-11-01 20:19 ` Scott Wood
1 sibling, 2 replies; 62+ messages in thread
From: Graeme Russ @ 2010-11-01 19:44 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 19:44 ` Graeme Russ
@ 2010-11-01 19:53 ` Albert ARIBAUD
2010-11-01 20:01 ` Wolfgang Denk
2010-11-01 20:19 ` Scott Wood
1 sibling, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-01 19:53 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 19:53 ` Albert ARIBAUD
@ 2010-11-01 20:01 ` Wolfgang Denk
0 siblings, 0 replies; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-01 20:01 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 19:35 ` Wolfgang Denk
@ 2010-11-01 20:04 ` Albert ARIBAUD
0 siblings, 0 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-01 20:04 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 19:44 ` Graeme Russ
2010-11-01 19:53 ` Albert ARIBAUD
@ 2010-11-01 20:19 ` Scott Wood
1 sibling, 0 replies; 62+ messages in thread
From: Scott Wood @ 2010-11-01 20:19 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-01 19:23 ` Wolfgang Denk
2010-11-01 19:30 ` Albert ARIBAUD
@ 2010-11-02 6:29 ` Heiko Schocher
2010-11-02 6:54 ` Albert ARIBAUD
` (2 more replies)
1 sibling, 3 replies; 62+ messages in thread
From: Heiko Schocher @ 2010-11-02 6:29 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 6:29 ` Heiko Schocher
@ 2010-11-02 6:54 ` Albert ARIBAUD
2010-11-02 7:10 ` Heiko Schocher
2010-11-02 8:33 ` Wolfgang Denk
2010-11-02 8:57 ` Reinhard Meyer
2 siblings, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-02 6:54 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 6:54 ` Albert ARIBAUD
@ 2010-11-02 7:10 ` Heiko Schocher
0 siblings, 0 replies; 62+ messages in thread
From: Heiko Schocher @ 2010-11-02 7:10 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 6:29 ` Heiko Schocher
2010-11-02 6:54 ` Albert ARIBAUD
@ 2010-11-02 8:33 ` Wolfgang Denk
2010-11-02 8:55 ` Heiko Schocher
2010-11-02 8:57 ` Reinhard Meyer
2 siblings, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-02 8:33 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 8:33 ` Wolfgang Denk
@ 2010-11-02 8:55 ` Heiko Schocher
2010-11-02 9:17 ` Stefan Roese
2010-11-02 9:21 ` Sughosh Ganu
0 siblings, 2 replies; 62+ messages in thread
From: Heiko Schocher @ 2010-11-02 8:55 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 6:29 ` Heiko Schocher
2010-11-02 6:54 ` Albert ARIBAUD
2010-11-02 8:33 ` Wolfgang Denk
@ 2010-11-02 8:57 ` Reinhard Meyer
2010-11-02 9:11 ` Albert ARIBAUD
2010-11-02 9:38 ` Wolfgang Denk
2 siblings, 2 replies; 62+ messages in thread
From: Reinhard Meyer @ 2010-11-02 8:57 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 8:57 ` Reinhard Meyer
@ 2010-11-02 9:11 ` Albert ARIBAUD
2010-11-02 9:34 ` Reinhard Meyer
2010-11-02 9:38 ` Wolfgang Denk
1 sibling, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-02 9:11 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 8:55 ` Heiko Schocher
@ 2010-11-02 9:17 ` Stefan Roese
2010-11-09 19:19 ` Scott Wood
2010-11-02 9:21 ` Sughosh Ganu
1 sibling, 1 reply; 62+ messages in thread
From: Stefan Roese @ 2010-11-02 9:17 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 8:55 ` Heiko Schocher
2010-11-02 9:17 ` Stefan Roese
@ 2010-11-02 9:21 ` Sughosh Ganu
1 sibling, 0 replies; 62+ messages in thread
From: Sughosh Ganu @ 2010-11-02 9:21 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 9:11 ` Albert ARIBAUD
@ 2010-11-02 9:34 ` Reinhard Meyer
2010-11-02 9:42 ` Albert ARIBAUD
2010-11-03 6:37 ` V, Aneesh
0 siblings, 2 replies; 62+ messages in thread
From: Reinhard Meyer @ 2010-11-02 9:34 UTC (permalink / raw)
To: u-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."
Best Regards,
Reinhard
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 8:57 ` Reinhard Meyer
2010-11-02 9:11 ` Albert ARIBAUD
@ 2010-11-02 9:38 ` Wolfgang Denk
2010-11-02 9:47 ` Albert ARIBAUD
1 sibling, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-02 9:38 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 9:34 ` Reinhard Meyer
@ 2010-11-02 9:42 ` Albert ARIBAUD
2010-11-03 6:37 ` V, Aneesh
1 sibling, 0 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-02 9:42 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 9:38 ` Wolfgang Denk
@ 2010-11-02 9:47 ` Albert ARIBAUD
2010-11-02 9:56 ` Sughosh Ganu
2010-11-02 13:28 ` Wolfgang Denk
0 siblings, 2 replies; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-02 9:47 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 9:47 ` Albert ARIBAUD
@ 2010-11-02 9:56 ` Sughosh Ganu
2010-11-02 11:16 ` Albert ARIBAUD
2010-11-02 13:28 ` Wolfgang Denk
1 sibling, 1 reply; 62+ messages in thread
From: Sughosh Ganu @ 2010-11-02 9:56 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 9:56 ` Sughosh Ganu
@ 2010-11-02 11:16 ` Albert ARIBAUD
2010-11-02 11:32 ` Sughosh Ganu
0 siblings, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-02 11:16 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 11:16 ` Albert ARIBAUD
@ 2010-11-02 11:32 ` Sughosh Ganu
0 siblings, 0 replies; 62+ messages in thread
From: Sughosh Ganu @ 2010-11-02 11:32 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 9:47 ` Albert ARIBAUD
2010-11-02 9:56 ` Sughosh Ganu
@ 2010-11-02 13:28 ` Wolfgang Denk
1 sibling, 0 replies; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-02 13:28 UTC (permalink / raw)
To: u-boot
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.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 9:34 ` Reinhard Meyer
2010-11-02 9:42 ` Albert ARIBAUD
@ 2010-11-03 6:37 ` V, Aneesh
2010-11-03 8:02 ` Wolfgang Denk
1 sibling, 1 reply; 62+ messages in thread
From: V, Aneesh @ 2010-11-03 6:37 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 6:37 ` V, Aneesh
@ 2010-11-03 8:02 ` Wolfgang Denk
2010-11-03 10:39 ` V, Aneesh
0 siblings, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-03 8:02 UTC (permalink / raw)
To: u-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?
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_
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 8:02 ` Wolfgang Denk
@ 2010-11-03 10:39 ` V, Aneesh
2010-11-03 11:27 ` Wolfgang Denk
0 siblings, 1 reply; 62+ messages in thread
From: V, Aneesh @ 2010-11-03 10:39 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 10:39 ` V, Aneesh
@ 2010-11-03 11:27 ` Wolfgang Denk
2010-11-03 12:03 ` V, Aneesh
0 siblings, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-03 11:27 UTC (permalink / raw)
To: u-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.
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 11:27 ` Wolfgang Denk
@ 2010-11-03 12:03 ` V, Aneesh
2010-11-03 12:08 ` Albert ARIBAUD
2010-11-03 13:00 ` Wolfgang Denk
0 siblings, 2 replies; 62+ messages in thread
From: V, Aneesh @ 2010-11-03 12:03 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 12:03 ` V, Aneesh
@ 2010-11-03 12:08 ` Albert ARIBAUD
2010-11-03 12:20 ` V, Aneesh
2010-11-03 13:00 ` Wolfgang Denk
1 sibling, 1 reply; 62+ messages in thread
From: Albert ARIBAUD @ 2010-11-03 12:08 UTC (permalink / raw)
To: u-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.
> Best regards,
> Aneesh
Amicalement,
--
Albert.
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 12:08 ` Albert ARIBAUD
@ 2010-11-03 12:20 ` V, Aneesh
0 siblings, 0 replies; 62+ messages in thread
From: V, Aneesh @ 2010-11-03 12:20 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 12:03 ` V, Aneesh
2010-11-03 12:08 ` Albert ARIBAUD
@ 2010-11-03 13:00 ` Wolfgang Denk
2010-11-03 14:07 ` V, Aneesh
1 sibling, 1 reply; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-03 13:00 UTC (permalink / raw)
To: u-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.
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 13:00 ` Wolfgang Denk
@ 2010-11-03 14:07 ` V, Aneesh
2010-11-03 18:25 ` Wolfgang Denk
0 siblings, 1 reply; 62+ messages in thread
From: V, Aneesh @ 2010-11-03 14:07 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-03 14:07 ` V, Aneesh
@ 2010-11-03 18:25 ` Wolfgang Denk
0 siblings, 0 replies; 62+ messages in thread
From: Wolfgang Denk @ 2010-11-03 18:25 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
* [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot
2010-11-02 9:17 ` Stefan Roese
@ 2010-11-09 19:19 ` Scott Wood
0 siblings, 0 replies; 62+ messages in thread
From: Scott Wood @ 2010-11-09 19:19 UTC (permalink / raw)
To: u-boot
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
^ permalink raw reply [flat|nested] 62+ messages in thread
end of thread, other threads:[~2010-11-09 19:19 UTC | newest]
Thread overview: 62+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-10-31 17:43 [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert Aribaud
2010-10-31 18:11 ` Alexander Holler
2010-10-31 18:12 ` Wolfgang Denk
2010-10-31 18:31 ` Albert ARIBAUD
2010-10-31 18:36 ` Wolfgang Denk
2010-10-31 18:38 ` Alexander Holler
2010-10-31 19:01 ` Wolfgang Denk
2010-10-31 19:07 ` Albert ARIBAUD
2010-10-31 19:22 ` Wolfgang Denk
2010-10-31 19:40 ` Albert ARIBAUD
2010-10-31 19:59 ` Wolfgang Denk
2010-10-31 20:23 ` Albert ARIBAUD
2010-10-31 20:32 ` Wolfgang Denk
2010-10-31 21:20 ` [U-Boot] [RFC] arm926ejs: fix jump to RAM nand_boot Albert Aribaud
2010-10-31 21:51 ` Wolfgang Denk
2010-10-31 21:55 ` Albert ARIBAUD
2010-10-31 22:28 ` Alexander Holler
2010-10-31 23:04 ` Albert ARIBAUD
2010-11-01 5:13 ` sughosh ganu
2010-11-01 8:12 ` Albert ARIBAUD
2010-11-01 9:13 ` Wolfgang Denk
2010-11-01 9:15 ` Wolfgang Denk
2010-11-01 17:03 ` Albert ARIBAUD
2010-11-01 19:23 ` Wolfgang Denk
2010-11-01 19:30 ` Albert ARIBAUD
2010-11-01 19:35 ` Wolfgang Denk
2010-11-01 20:04 ` Albert ARIBAUD
2010-11-01 19:44 ` Graeme Russ
2010-11-01 19:53 ` Albert ARIBAUD
2010-11-01 20:01 ` Wolfgang Denk
2010-11-01 20:19 ` Scott Wood
2010-11-02 6:29 ` Heiko Schocher
2010-11-02 6:54 ` Albert ARIBAUD
2010-11-02 7:10 ` Heiko Schocher
2010-11-02 8:33 ` Wolfgang Denk
2010-11-02 8:55 ` Heiko Schocher
2010-11-02 9:17 ` Stefan Roese
2010-11-09 19:19 ` Scott Wood
2010-11-02 9:21 ` Sughosh Ganu
2010-11-02 8:57 ` Reinhard Meyer
2010-11-02 9:11 ` Albert ARIBAUD
2010-11-02 9:34 ` Reinhard Meyer
2010-11-02 9:42 ` Albert ARIBAUD
2010-11-03 6:37 ` V, Aneesh
2010-11-03 8:02 ` Wolfgang Denk
2010-11-03 10:39 ` V, Aneesh
2010-11-03 11:27 ` Wolfgang Denk
2010-11-03 12:03 ` V, Aneesh
2010-11-03 12:08 ` Albert ARIBAUD
2010-11-03 12:20 ` V, Aneesh
2010-11-03 13:00 ` Wolfgang Denk
2010-11-03 14:07 ` V, Aneesh
2010-11-03 18:25 ` Wolfgang Denk
2010-11-02 9:38 ` Wolfgang Denk
2010-11-02 9:47 ` Albert ARIBAUD
2010-11-02 9:56 ` Sughosh Ganu
2010-11-02 11:16 ` Albert ARIBAUD
2010-11-02 11:32 ` Sughosh Ganu
2010-11-02 13:28 ` Wolfgang Denk
2010-10-31 19:01 ` [U-Boot] [RFC] arm926ejs: fix linker file for newer ld support Albert ARIBAUD
2010-10-31 18:35 ` Darius Augulis
2010-10-31 18:53 ` Albert ARIBAUD
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.