[U-Boot] [RFC] arm926ejs: fix linker file for newer ld support
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*) }
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
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
Le 31/10/2010 19:12, Wolfgang Denk a écrit :
Dear Albert Aribaud,
In message1288547025-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,
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
Am 31.10.2010 19:12, schrieb Wolfgang Denk:
Dear Albert Aribaud,
In message1288547025-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
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
Le 31/10/2010 20:01, Wolfgang Denk a écrit :
Dear Alexander Holler,
In message4CCDB78D.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,
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
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,
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
Le 31/10/2010 20:59, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CCDC625.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,
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
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
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
Le 31/10/2010 22:51, Wolfgang Denk a écrit :
Dear Albert Aribaud,
In message1288560046-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,
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
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,
On Mon, Nov 1, 2010 at 4:34 AM, Albert ARIBAUD albert.aribaud@free.frwrote:
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
Le 01/11/2010 06:13, sughosh ganu a écrit :
On Mon, Nov 1, 2010 at 4:34 AM, Albert ARIBAUDalbert.aribaud@free.frwrote:
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_SPLthat 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,
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
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
Le 01/11/2010 10:15, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CCDF5FC.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,
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
Le 01/11/2010 20:23, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CCEF2E4.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,
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
Le 01/11/2010 20:35, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CCF1558.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,
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 message4CCEF2E4.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
Le 01/11/2010 20:44, Graeme Russ a écrit :
On Tuesday, November 2, 2010, Albert ARIBAUDalbert.aribaud@free.fr wrote:
Le 01/11/2010 20:23, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CCEF2E4.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,
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
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
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
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,
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
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
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
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@denx.de
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
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
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
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,
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
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,
Dear Reinhard, Wolfgang,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot- bounces@lists.denx.de] On Behalf Of Reinhard Meyer Sent: Tuesday, November 02, 2010 3:04 PM To: Albert ARIBAUD Cc: u-boot@lists.denx.de; hs@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
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
Dear Wolfgang,
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Wednesday, November 03, 2010 1:33 PM To: V, Aneesh Cc: Reinhard Meyer; Albert ARIBAUD; u-boot@lists.denx.de; hs@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
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
Dear Wofgang,
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Wednesday, November 03, 2010 4:58 PM To: V, Aneesh Cc: Reinhard Meyer; Albert ARIBAUD; u-boot@lists.denx.de; hs@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
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,
Dear Albert, Wolfgang,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Wednesday, November 03, 2010 5:38 PM To: V, Aneesh Cc: Wolfgang Denk; u-boot@lists.denx.de; hs@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
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
Dear Wolfgang,
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Wednesday, November 03, 2010 6:30 PM To: V, Aneesh Cc: Reinhard Meyer; Albert ARIBAUD; u-boot@lists.denx.de; hs@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
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
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
Le 02/11/2010 10:38, Wolfgang Denk a écrit :
Dear Reinhard Meyer,
In message4CCFD27E.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,
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
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,
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
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
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,
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 Aribaudalbert.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*) }
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,
participants (13)
-
Albert ARIBAUD -
Albert Aribaud
-
Alexander Holler -
Darius Augulis -
Graeme Russ -
Heiko Schocher -
Reinhard Meyer -
Scott Wood -
Stefan Roese -
Sughosh Ganu -
sughosh ganu
-
V, Aneesh -
Wolfgang Denk