[U-Boot] Most ARM CPU's have buggy clear_bss?
Hi list,
the code for clearing bss section for most ARM cores looks like this or very similar:
clear_bss: #ifndef CONFIG_PRELOADER ldr r0, _bss_start_ofs ldr r1, _bss_end_ofs ldr r3, _TEXT_BASE /* Text base */ mov r4, r7 /* reloc addr */ add r0, r0, r4 add r1, r1, r4 mov r2, #0x00000000 /* clear */
clbss_l:str r2, [r0] /* clear loop... */ add r0, r0, #4 cmp r0, r1 bne clbss_l #endif /* #ifndef CONFIG_PRELOADER */
IMO, if relocation is skipped, r4 should be loaded with value of _TEXT_BASE, not reloc address? It seems like r3 is prepared for this but, it's somehow missing? It's not used at all. Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. I think this ASM code clears not bss area but something else.
Also relocation code looks a bit strange:
.globl relocate_code relocate_code: mov r4, r0 /* save addr_sp */ mov r5, r1 /* save addr of gd */ mov r6, r2 /* save addr of destination */ mov r7, r2 /* save addr of destination */
/* Set up the stack */ stack_setup: mov sp, r4
adr r0, _start ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 <- source end address */ cmp r0, r6 beq clear_bss
r0 is compared to r6, which contains reloc address. All instructions between loading r0 and comparison are confusing, because they do not impact comparison result. Also they do not matter in clear_bss so I think would be great to change code like this:
mov sp, r4
adr r0, _start cmp r0, r6 beq clear_bss ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 <- source end address */
Any comments are welcome!
Regards, Darius.
hi,
On Wed Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
IMO, if relocation is skipped, r4 should be loaded with value of _TEXT_BASE, not reloc address? It seems like r3 is prepared for this but, it's somehow missing? It's not used at all. Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. I think this ASM code clears not bss area but something else.
<snip>
Also relocation code looks a bit strange:
<snip>
r0 is compared to r6, which contains reloc address. All instructions between loading r0 and comparison are confusing, because they do not impact comparison result. Also they do not matter in clear_bss so I think would be great to change code like this:
mov sp, r4 adr r0, _start cmp r0, r6 beq clear_bss ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 <- source end address */Any comments are welcome!
Not sure which core are you referring to. I checked for arm926ejs, and we have conditional code inclusion based on the definition of CONFIG_SYS_ARM_WITHOUT_RELOC. So the start address in both the cases is determined based on whether relocation is enabled or not.
-sughosh
Hi,
On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu urwithsughosh@gmail.com wrote:
hi,
On Wed Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
IMO, if relocation is skipped, r4 should be loaded with value of _TEXT_BASE, not reloc address? It seems like r3 is prepared for this but, it's somehow missing? It's not used at all. Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. I think this ASM code clears not bss area but something else.
<snip>
Also relocation code looks a bit strange:
<snip>
r0 is compared to r6, which contains reloc address. All instructions between loading r0 and comparison are confusing, because they do not impact comparison result. Also they do not matter in clear_bss so I think would be great to change code like this:
mov sp, r4
adr r0, _start cmp r0, r6 beq clear_bss ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 <- source end address */
Any comments are welcome!
Not sure which core are you referring to. I checked for arm926ejs, and we have conditional code inclusion based on the definition of CONFIG_SYS_ARM_WITHOUT_RELOC. So the start address in both the cases is determined based on whether relocation is enabled or not.
The same is at least for arm926ejs, arm1136, arm1176. As you probably know CONFIG_SYS_ARM_WITHOUT_RELOC support will be removed soon and I'm talking about code which is under #ifndef CONFIG_SYS_ARM_WITHOUT_RELOC.
Darius.
-sughosh
hi,
On Wed Oct 27, 2010 at 11:22:17AM +0300, Darius Augulis wrote:
Hi,
On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu urwithsughosh@gmail.com wrote:
Not sure which core are you referring to. I checked for arm926ejs, and we have conditional code inclusion based on the definition of CONFIG_SYS_ARM_WITHOUT_RELOC. So the start address in both the cases is determined based on whether relocation is enabled or not.
The same is at least for arm926ejs, arm1136, arm1176. As you probably know CONFIG_SYS_ARM_WITHOUT_RELOC support will be removed soon and I'm talking about code which is under #ifndef CONFIG_SYS_ARM_WITHOUT_RELOC.
Umm. I am not sure i get you here. If CONFIG_SYS_ARM_WITHOUT_RELOC is not defined, it means we have enabled relocation, so all the address calculation should be w.r.t the relocation address.
-sughosh
On Wed, Oct 27, 2010 at 11:54 AM, Sughosh Ganu urwithsughosh@gmail.com wrote:
hi,
On Wed Oct 27, 2010 at 11:22:17AM +0300, Darius Augulis wrote:
Hi,
On Wed, Oct 27, 2010 at 11:01 AM, Sughosh Ganu urwithsughosh@gmail.com wrote:
Not sure which core are you referring to. I checked for arm926ejs, and we have conditional code inclusion based on the definition of CONFIG_SYS_ARM_WITHOUT_RELOC. So the start address in both the cases is determined based on whether relocation is enabled or not.
The same is at least for arm926ejs, arm1136, arm1176. As you probably know CONFIG_SYS_ARM_WITHOUT_RELOC support will be removed soon and I'm talking about code which is under #ifndef CONFIG_SYS_ARM_WITHOUT_RELOC.
Umm. I am not sure i get you here. If CONFIG_SYS_ARM_WITHOUT_RELOC is not defined, it means we have enabled relocation, so all the address calculation should be w.r.t the relocation address.
No, there could be several different relocation methods - with and without preloader etc. There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes boot sequence dramatically. And it isn't CONFIG_SYS_ARM_WITHOUT_RELOC dependent.
Darius.
-sughosh
On Wed Oct 27, 2010 at 11:58:30AM +0300, Darius Augulis wrote:
No, there could be several different relocation methods - with and without preloader etc. There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes boot sequence dramatically. And it isn't CONFIG_SYS_ARM_WITHOUT_RELOC dependent.
I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with relocation enabled unless we ensure that the TEXT_BASE would be same as the relocation address.
-sughosh
On Wed, Oct 27, 2010 at 12:09 PM, Sughosh Ganu sughoshg@juniper.net wrote:
On Wed Oct 27, 2010 at 11:58:30AM +0300, Darius Augulis wrote:
No, there could be several different relocation methods - with and without preloader etc. There is another definition CONFIG_SKIP_RELOCATE_UBOOT which changes boot sequence dramatically. And it isn't CONFIG_SYS_ARM_WITHOUT_RELOC dependent.
I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with relocation enabled unless we ensure that the TEXT_BASE would be same as the relocation address.
in case of nand_spl you don't need to to relocation twice because it's done by preloader.
-sughosh
Dear Darius Augulis,
In message AANLkTimWZv=XBC1s1G8-=D6nAJ09poqHYP9RXHeTTM4q@mail.gmail.com you wrote:
I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with relocation enabled unless we ensure that the TEXT_BASE would be same as the relocation address.
in case of nand_spl you don't need to to relocation twice because it's done by preloader.
Maybe, maybe not. The preloader is usually very simple and may not be clever enough to adjust the oad address to the avalable memory and such; also, U-Boot features like protected RAM, shared video buffers or log buffers may also require to dynamically adjust the final load address. In such cases relocation will be needed.
Best regards,
Wolfgang Denk
On 10/27/2010 01:40 PM, Wolfgang Denk wrote:
Dear Darius Augulis,
In messageAANLkTimWZv=XBC1s1G8-=D6nAJ09poqHYP9RXHeTTM4q@mail.gmail.com you wrote:
I don't think we can define CONFIG_SKIP_RELOCATE_UBOOT with relocation enabled unless we ensure that the TEXT_BASE would be same as the relocation address.
in case of nand_spl you don't need to to relocation twice because it's done by preloader.
Maybe, maybe not. The preloader is usually very simple and may not be clever enough to adjust the oad address to the avalable memory and such; also, U-Boot features like protected RAM, shared video buffers or log buffers may also require to dynamically adjust the final load address. In such cases relocation will be needed.
I confess I didn't understant you - why relocation could be needed in case of nand or other preloader? I have been thinking that main and single task of preloader is to copy uboot image from flash memory to main memory (SDRAM) where it's linked to (TEXT_BASE). Why one may need to relocate it twice (and where) ? IMO since uboot image is copied to TEXT_BASE it can run normaly, without fixing any address or relocating somewhere? It's enough to have dummy loader which initializes SDRAM and copies few pages from nand to SDRAM, isn't it? Why should it be more clever? Also I've been thinking that relocation is needed only when booting directly from NOR flash, to have possibility to erase and program flash memory. Could you please point me where I'm wrong?
Thanks, Darius
Best regards,
Wolfgang Denk
Dear Darius Augulis,
In message 4CC80609.6040003@gmail.com you wrote:
Maybe, maybe not. The preloader is usually very simple and may not be clever enough to adjust the oad address to the avalable memory and such; also, U-Boot features like protected RAM, shared video buffers or log buffers may also require to dynamically adjust the final load address. In such cases relocation will be needed.
I confess I didn't understant you - why relocation could be needed in case of nand or other preloader? I have been thinking that main and single task of preloader is to copy uboot image from flash memory to main memory (SDRAM) where it's linked to (TEXT_BASE). Why one may need
Yes, but this may or may not be the final position.
to relocate it twice (and where) ? IMO since uboot image is copied to TEXT_BASE it can run normaly, without fixing any address or relocating somewhere? It's enough to have dummy loader which initializes SDRAM and copies few pages from nand to SDRAM, isn't it? Why should it be more clever?
Assume we use the "protected RAM" feature, i. e. we reserve memory at the top of RAM. The user does a "setenv pram 0x400000;saveenv" to reserve 4 MB, then does a reboot. So next time the system boots U-Boot must respect the new setting, i. e. it has to be loaded 4 MB below top of RAM. Then user decides he needs 8 MB instead...
Also I've been thinking that relocation is needed only when booting directly from NOR flash, to have possibility to erase and program flash memory. Could you please point me where I'm wrong?
Relocation is needed to allow to put the U-Boot image to any suitable location in RAM, which is NOT known at compile time, as it may depend on the actual memory size (assume systems that come with different configurations, or where the user can plug in additional or bigger memory modules), and on a number of memory reservations that depende for example on environment variable settings.
Best regards,
Wolfgang Denk
On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty.
Maybe this is the same problem I reported here (commands not found): http://lists.denx.de/pipermail/u-boot/2010-October/080198.html
Hi Eric,
On 10/27/2010 06:12 PM, Eric Cooper wrote:
On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty.
Maybe this is the same problem I reported here (commands not found): http://lists.denx.de/pipermail/u-boot/2010-October/080198.html
looks similar, but not exactly the same. Mine output:
U-Boot 2010.09-00560-g5b4d583-dirty (Oct 27 2010 - 21:00:13) for MINI6410
U-Boot code: 57E00000 -> 57E2BDE4 BSS: -> 57E31680
CPU: S3C6400@532MHz Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz (SYNC Mode) Board: MINI6410 monitor len: 00031680 ramsize: 08000000 TLB table at: 57ff0000 Top of RAM usable for U-Boot at: 57ff0000 Reserving 197k for U-Boot at: 57fbe000 Reserving 1280k for malloc() at: 57e7e000 Reserving 24 Bytes for Board Info at: 57e7dfe8 Reserving 92 Bytes for Global Data at: 57e7df8c New Stack Pointer is: 57e7df88 RAM Configuration: Bank #0: 50000000 128 MiB relocation Offset is: 001be000 monitor flash len: 0002BDE4 Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught 256 MiB Using default environment
Destroy Hash Table: 57e31568 table = (null) Create Hash Table: N=79 INSERT: table 57e31568, filled 1/79 rv 57e7f42c ==> name="bootargs" value="console=ttySAC,115200" INSERT: table 57e31568, filled 2/79 rv 57e7f348 ==> name="bootcmd" value="nand read 0x50018000 0x60000 0x1c0000;bootm 0x50018000" INSERT: table 57e31568, filled 3/79 rv 57e7f438 ==> name="bootdelay" value="3" INSERT: table 57e31568, filled 4/79 rv 57e7f378 ==> name="baudrate" value="115200" INSERT: free(data = 57e7f2a0) INSERT: done In: serial Out: serial Err: serial Net: dm9000 ### main_loop entered: bootdelay=3
### main_loop: bootcmd="nand read 0x50018000 0x60000 0x1c0000;bootm 0x50018000" Hit any key to stop autoboot: 0 MINI6410 # help Unknown command 'help' - try 'help' MINI6410 #
I'm doing support for new board, so there could be some bugs in its config. But I still thinking that clear_bss code is buggy, because uboot reboots is DEBUG if defined and following simple patch isn't applied:
diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index 7f32db7..8337c4b 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -379,13 +379,16 @@ clear_bss: #ifndef CONFIG_PRELOADER ldr r0, _bss_start_ofs ldr r1, _bss_end_ofs - ldr r3, _TEXT_BASE /* Text base */ +#ifdef CONFIG_SKIP_RELOCATE_UBOOT + ldr r4, _TEXT_BASE /* Text base */ +#else mov r4, r7 /* reloc addr */ +#endif add r0, r0, r4 add r1, r1, r4 - mov r2, #0x00000000 /* clear */ + mov r2, #0x00000000 /* clear */
-clbss_l:str r2, [r0] /* clear loop... */ +clbss_l:str r2, [r0] /* clear loop */ add r0, r0, #4 cmp r0, r1 bne clbss_l
If DEBUG isn't defined then it does not reboot, but commands are missing in both cases. Unfortunately this patch does not solve this problem. I've calculated bss start and end addresses with and without '#ifdef CONFIG_SKIP_RELOCATE_UBOOT' and they are wrong without it.
Darius.
Hello Darius,
Darius Augulis wrote:
On 10/27/2010 06:12 PM, Eric Cooper wrote:
On Wed, Oct 27, 2010 at 10:26:06AM +0300, Darius Augulis wrote:
Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty.
Maybe this is the same problem I reported here (commands not found): http://lists.denx.de/pipermail/u-boot/2010-October/080198.html
looks similar, but not exactly the same. Mine output:
U-Boot 2010.09-00560-g5b4d583-dirty (Oct 27 2010 - 21:00:13) for MINI6410
U-Boot code: 57E00000 -> 57E2BDE4 BSS: -> 57E31680
CPU: S3C6400@532MHz Fclk = 532MHz, Hclk = 133MHz, Pclk = 66MHz (SYNC Mode) Board: MINI6410 monitor len: 00031680 ramsize: 08000000 TLB table at: 57ff0000 Top of RAM usable for U-Boot at: 57ff0000 Reserving 197k for U-Boot at: 57fbe000 Reserving 1280k for malloc() at: 57e7e000 Reserving 24 Bytes for Board Info at: 57e7dfe8 Reserving 92 Bytes for Global Data at: 57e7df8c New Stack Pointer is: 57e7df88 RAM Configuration: Bank #0: 50000000 128 MiB relocation Offset is: 001be000 monitor flash len: 0002BDE4 Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught
This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature)
256 MiB Using default environment
Destroy Hash Table: 57e31568 table = (null) Create Hash Table: N=79 INSERT: table 57e31568, filled 1/79 rv 57e7f42c ==> name="bootargs" value="console=ttySAC,115200" INSERT: table 57e31568, filled 2/79 rv 57e7f348 ==> name="bootcmd" value="nand read 0x50018000 0x60000 0x1c0000;bootm 0x50018000" INSERT: table 57e31568, filled 3/79 rv 57e7f438 ==> name="bootdelay" value="3" INSERT: table 57e31568, filled 4/79 rv 57e7f378 ==> name="baudrate" value="115200" INSERT: free(data = 57e7f2a0) INSERT: done In: serial Out: serial Err: serial Net: dm9000 ### main_loop entered: bootdelay=3
### main_loop: bootcmd="nand read 0x50018000 0x60000 0x1c0000;bootm 0x50018000" Hit any key to stop autoboot: 0 MINI6410 # help Unknown command 'help' - try 'help' MINI6410 #
I'm doing support for new board, so there could be some bugs in its config. But I still thinking that clear_bss code is buggy, because uboot reboots is DEBUG if defined and following simple patch isn't applied:
Maybe you look in the tx25 board port. This board boots also with nand_spl (but it is arm926ejs based).
Note: CONFIG_SKIP_RELOCATE_UBOOT seems to get obsolete to me.
What worked for me on the tx25 board was, that I set TEXT_BASE = relocation address, so I got relocation offset = 0 and code don;t gets copied twice, but this addr is not constant (code size changes, maybe pram features ...) so I dropped this approach for this board.
bye, Heiko
Dear Darius,
Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught
This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature)
I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working before relocation. Have a look at your timer implementation.
Best Regards, Reinhard
Hello Reinhard,
Reinhard Meyer wrote:
Dear Darius,
Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught
This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature)
I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working before relocation. Have a look at your timer implementation.
Huh.. thought the elf relocation fixed this problem?
bye, Heiko
On 28.10.2010 08:17, Heiko Schocher wrote:
Hello Reinhard,
Reinhard Meyer wrote:
Dear Darius,
Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught
This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature)
I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working _before relocation_. Have a look at your timer implementation.
Huh.. thought the elf relocation fixed this problem?
2x Huh.. How would it? I moved the timer static vars into global_data, THAT fixed the issue.
Reinhard
On 28.10.2010 08:20, Reinhard Meyer wrote:
On 28.10.2010 08:17, Heiko Schocher wrote:
Hello Reinhard,
Reinhard Meyer wrote:
Dear Darius,
Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught
This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature)
I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working _before relocation_. Have a look at your timer implementation.
Huh.. thought the elf relocation fixed this problem?
2x Huh.. How would it? I moved the timer static vars into global_data, THAT fixed the issue.
OK, I should have mentioned, that those variables are values that are calculated _before_ relocation in timer_init and needed to have those values for any subsequent timer use before and after relocation...
Reinhard
Hello Reinhard,
Reinhard Meyer wrote:
On 28.10.2010 08:20, Reinhard Meyer wrote:
On 28.10.2010 08:17, Heiko Schocher wrote:
Hello Reinhard,
Reinhard Meyer wrote:
Dear Darius,
Now running in RAM - U-Boot at: 57fbe000 NAND: raise: Signal # 8 caught raise: Signal # 8 caught raise: Signal # 8 caught
This looks suspect to me. Seems to me some early init (pin setup? clocks?) is not OK. If you have early inits, you must do that now in board_early_init_f() (and you have to define CONFIG_BOARD_EARLY_INIT_F to enable this feature)
I got _exactly_ the same NAND messages when ARM relocation was first used, because the timer.c did use static variables which are not working _before relocation_. Have a look at your timer implementation.
Huh.. thought the elf relocation fixed this problem?
2x Huh.. How would it? I moved the timer static vars into global_data, THAT fixed the issue.
OK, I should have mentioned, that those variables are values that are calculated _before_ relocation in timer_init and needed to have those values for any subsequent timer use before and after relocation...
Ah, ok!
bye, Heiko
Hello Darius,
Darius Augulis wrote:
the code for clearing bss section for most ARM cores looks like this or very similar:
clear_bss: #ifndef CONFIG_PRELOADER ldr r0, _bss_start_ofs ldr r1, _bss_end_ofs ldr r3, _TEXT_BASE /* Text base */ mov r4, r7 /* reloc addr */ add r0, r0, r4 add r1, r1, r4 mov r2, #0x00000000 /* clear */
clbss_l:str r2, [r0] /* clear loop... */ add r0, r0, #4 cmp r0, r1 bne clbss_l #endif /* #ifndef CONFIG_PRELOADER */
IMO, if relocation is skipped, r4 should be loaded with value of _TEXT_BASE, not reloc address?
Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete?
It seems like r3 is prepared for this but, it's somehow missing? It's not used at all.
Here you are right. I think r3 is an artifact from the GOT relocation. This should be reworked (added Albert Aribaud to cc, because he did the elf relocation work)
Maybe it could be reason why I'm facing strange problem, when after relocating uboot with nand_spl no one command is not working. I debugged that command table is empty. I think this ASM code clears not bss area but something else.
If you have defined CONFIG_SKIP_RELOCATE_UBOOT, yes. Please remove this define.
Also relocation code looks a bit strange:
.globl relocate_coderelocate_code: mov r4, r0 /* save addr_sp */ mov r5, r1 /* save addr of gd */ mov r6, r2 /* save addr of destination */ mov r7, r2 /* save addr of destination */
/* Set up the stack */stack_setup: mov sp, r4
adr r0, _start ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 <- source end address */ cmp r0, r6 beq clear_bssr0 is compared to r6, which contains reloc address. All instructions between loading r0 and comparison are confusing, because they do not impact comparison result. Also they do not matter in clear_bss so I think would be great to change code like this:
mov sp, r4 adr r0, _start cmp r0, r6 beq clear_bss ldr r2, _TEXT_BASE ldr r3, _bss_start_ofs add r2, r0, r3 /* r2 <- source end address */Any comments are welcome!
Yep, please send a patch for this issue.
bye, Heiko
Dear Heiko Schocher,
Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete?
Why don't we remove ALL that dead code ASAP from ARM start.S and board.c files?
All unmaintained ARM boards are now broken anyway, and those that are fixed are using elf relocation.
(I know that there is a 'promise' to keep ARM_WITHOUT_RELOC until next March, but does that really make sense anymore?)
Reinhard
On 10/28/2010 09:36 AM, Reinhard Meyer wrote:
Dear Heiko Schocher,
Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete?
Why don't we remove ALL that dead code ASAP from ARM start.S and board.c files?
All unmaintained ARM boards are now broken anyway, and those that are fixed are using elf relocation.
(I know that there is a 'promise' to keep ARM_WITHOUT_RELOC until next March, but does that really make sense anymore?)
Are we going to drop possibility to avoid relocation at all? In spite of there are some simple systems which would never need relocation and which prefer fast boot up time and simplicity rather than features like PRAM or dynamically changing memory size? Also there are lot of boards booting from nand, and very likely there would appear more such systems in future. They do relocation already in preloader and there are no chance to avoid to do it twice. In this case U-Boot is going to become big, fat and slow, high featured bootloader suitable for complex systems but not for simple ones which in most cases need only to boot kernel as fast as possible.
I would prefer to think about reworking existing code rather than removing it at all.
Darius.
Reinhard
Dear Darius Augulis,
In message 4CC91E8E.8030702@gmail.com you wrote:
Are we going to drop possibility to avoid relocation at all? In spite of
Yes, definitely.
We will keep the handling of the special case thatthe relocation offset is zero, so that an additional copy can be avoided, but that's all.
there are some simple systems which would never need relocation and which prefer fast boot up time and simplicity rather than features like PRAM or dynamically changing memory size?
When the relocation offset is zero there shouldnot be any significant delay.
Also there are lot of boards booting from nand, and very likely there would appear more such systems in future. They do relocation already in preloader and there are no chance to avoid to do it twice.
Same argument.
In this case U-Boot is going to become big, fat and slow, high featured bootloader suitable for complex systems but not for simple ones which in most cases need only to boot kernel as fast as possible.
If you make such a statement I would like that you come up with proven, measured facts, i. e. how much time / size does it cost on your specific "small" system?
Best regards,
Wolfgang Denk
Dear Reinhard Meyer,
In message 4CC919E4.6010904@emk-elektronik.de you wrote:
Dear Heiko Schocher,
Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete?
Why don't we remove ALL that dead code ASAP from ARM start.S and board.c files?
All unmaintained ARM boards are now broken anyway, and those that are fixed are using elf relocation.
(I know that there is a 'promise' to keep ARM_WITHOUT_RELOC until next March, but does that really make sense anymore?)
I think you are right. Let's have a poll.
Best regards,
Wolfgang Denk
Dear Heiko Schocher,
In message 4CC914D8.4070101@denx.de you wrote:
Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete?
sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC related to each other?
Best regards,
Wolfgang Denk
Hello Wolfgang,
Wolfgang Denk wrote:
Dear Heiko Schocher,
In message 4CC914D8.4070101@denx.de you wrote:
Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete?
sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC related to each other?
I thought, that with relocation we always relocate, so we don;t need longer CONFIG_SKIP_RELOCATE_UBOOT ... ?
bye, Heiko
Hello,
Am 28.10.2010 10:39, schrieb Wolfgang Denk:
Dear Heiko Schocher,
In message4CC914D8.4070101@denx.de you wrote:
Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete?
sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC related to each other?
I've got confused by that too. Currently there are 3 defines in regard to relocation:
CONFIG_SYS_ARM_WITHOUT_RELOC CONFIG_RELOC_FIXUP_WORKS CONFIG_SKIP_RELOCATE_UBOOT
Regards,
Alexander
Dear Alexander Holler,
Am 28.10.2010 10:39, schrieb Wolfgang Denk:
Dear Heiko Schocher,
In message4CC914D8.4070101@denx.de you wrote:
Hmm.. I think the question is, is CONFIG_SKIP_RELOCATE_UBOOT not obsolete?
sorry for a stupid question - how are CONFIG_SKIP_RELOCATE_UBOOT and CONFIG_SYS_ARM_WITHOUT_RELOC related to each other?
I've got confused by that too. Currently there are 3 defines in regard to relocation:
CONFIG_SYS_ARM_WITHOUT_RELOC
Introduced by Heiko as a try to unbreak old boards that are not converted to relocation yet. Basically it #else's between the old code and the new code. As far as I understand that define won't work anymore because of several other changes in u-boot that necessitate fixing the affected boards.
CONFIG_RELOC_FIXUP_WORKS
Not needed for ARM when ELF relocation is used. I don't know whether other architectures still need it. Do NOT set it on ARM or you get in trouble by some addresses being relocated twice.
CONFIG_SKIP_RELOCATE_UBOOT
The old way in ARM before ELF relocation was introduced. A misnomer because it seemingly skipped the *COPY* of the image from whereever it was loaded to the TEXT_BASE location. There was no real *RELOCATION* done there. This define probably does not work anymore. It was set on ARM boards where a preloader did load u-boot to the TEXT_BASE address.
In an up to date ARM system all those defines MUST NOT be set.
Best Regards, Reinhard
Dear Reinhard Meyer,
In message 4CC95B9E.3040108@emk-elektronik.de you wrote:
I've got confused by that too. Currently there are 3 defines in regard to relocation:
CONFIG_SYS_ARM_WITHOUT_RELOC
Introduced by Heiko as a try to unbreak old boards that are not converted to relocation yet. Basically it #else's between the old code and the new code. As far as I understand that define won't work anymore because of several other changes in u-boot that necessitate fixing the affected boards.
CONFIG_RELOC_FIXUP_WORKS
Not needed for ARM when ELF relocation is used. I don't know whether other architectures still need it. Do NOT set it on ARM or you get in trouble by some addresses being relocated twice.
Sure? My understanding is that it MUST be set since we have elf_reloc?
And I see this:
arch/arm/include/asm/config.h:#define CONFIG_RELOC_FIXUP_WORKS
CONFIG_SKIP_RELOCATE_UBOOT
The old way in ARM before ELF relocation was introduced. A misnomer because it seemingly skipped the *COPY* of the image from whereever it was loaded to the TEXT_BASE location. There was no real *RELOCATION* done there. This define probably does not work anymore. It was set on ARM boards where a preloader did load u-boot to the TEXT_BASE address.
In an up to date ARM system all those defines MUST NOT be set.
My understanding is that CONFIG_SYS_ARM_WITHOUT_RELOC and CONFIG_SKIP_RELOCATE_UBOOT should not be set (and I don;t know what happens if you do), but CONFIG_RELOC_FIXUP_WORKS is automaticlly set for all ARM systems now.
Best regards,
Wolfgang Denk
Dear Wolfgang Denk,
CONFIG_RELOC_FIXUP_WORKS
Not needed for ARM when ELF relocation is used. I don't know whether other architectures still need it. Do NOT set it on ARM or you get in trouble by some addresses being relocated twice.
Sure? My understanding is that it MUST be set since we have elf_reloc?
Sorry, of course that *MUST* be set. My mistake. The Logic is inverted here: FIXUP_WORKS = "do not do any extra fixups" ;)
Reinhard
Le 28/10/2010 13:38, Wolfgang Denk a écrit :
CONFIG_RELOC_FIXUP_WORKS
Not needed for ARM when ELF relocation is used. I don't know whether other architectures still need it. Do NOT set it on ARM or you get in trouble by some addresses being relocated twice.
Sure? My understanding is that it MUST be set since we have elf_reloc?
It is needed if code exists wich is conditioned on it, but such code should be cleaned up to keep only the "ifdef" part of it.
My understanding is that CONFIG_SYS_ARM_WITHOUT_RELOC and CONFIG_SKIP_RELOCATE_UBOOT should not be set (and I don;t know what happens if you do), but CONFIG_RELOC_FIXUP_WORKS is automaticlly set for all ARM systems now.
I'd agree with this.
Amicalement,
Am 28.10.2010 13:16, schrieb Reinhard Meyer:
CONFIG_SKIP_RELOCATE_UBOOT
The old way in ARM before ELF relocation was introduced. A misnomer because it seemingly skipped the *COPY* of the image from whereever it was loaded to the TEXT_BASE location. There was no real *RELOCATION* done there. This define probably does not work anymore. It was set on ARM boards where a preloader did load u-boot to the TEXT_BASE address.
In an up to date ARM system all those defines MUST NOT be set.
Thanks for that explanation.
In regard to CONFIG_SKIP_RELOCATE_UBOOT I've hit a typo in arch/arm/cpu/arm926ejs/start.S while trying to use this define to build a non relocatable u-boot. In line 383 there is
ldr pc, r0
which seems to should be
ldr pc, [r0]
But after fixing that I've just run into other problems compiling u-boot with CONFIG_SKIP_RELOCATE_UBOOT defined. I don't send a patch, because I assume that code is just dead will be eliminated in the near future.
Regards,
Alexander
Le 28/10/2010 13:46, Alexander Holler a écrit :
Am 28.10.2010 13:16, schrieb Reinhard Meyer:
CONFIG_SKIP_RELOCATE_UBOOT
The old way in ARM before ELF relocation was introduced. A misnomer because it seemingly skipped the *COPY* of the image from whereever it was loaded to the TEXT_BASE location. There was no real *RELOCATION* done there. This define probably does not work anymore. It was set on ARM boards where a preloader did load u-boot to the TEXT_BASE address.
In an up to date ARM system all those defines MUST NOT be set.
Thanks for that explanation.
In regard to CONFIG_SKIP_RELOCATE_UBOOT I've hit a typo in arch/arm/cpu/arm926ejs/start.S while trying to use this define to build a non relocatable u-boot. In line 383 there is
ldr pc, r0
which seems to should be
ldr pc, [r0]
I don't think it should. r0 is computed to be the address at which to branch, so the branch there is direct, not indirect. That could be changed to "mov pc, r0" for clarity, though.
Amicalement,
In regard to CONFIG_SKIP_RELOCATE_UBOOT I've hit a typo in arch/arm/cpu/arm926ejs/start.S while trying to use this define to build a non relocatable u-boot. In line 383 there is
ldr pc, r0
which seems to should be
ldr pc, [r0]
I don't think it should. r0 is computed to be the address at which to branch, so the branch there is direct, not indirect. That could be changed to "mov pc, r0" for clarity, though.
binutils 2.20.1 doesn't like "ldr pc, r0". So then it must be "mov pc, r0" if "ldr pc, [r0]" is wrong.
And above I used the wrong define, this code is only active when
CONFIG_SYS_ARM_WITHOUT_RELOC is defined.
Regards, Alexander
Le 29/10/2010 13:32, Alexander Holler a écrit :
In regard to CONFIG_SKIP_RELOCATE_UBOOT I've hit a typo in arch/arm/cpu/arm926ejs/start.S while trying to use this define to build a non relocatable u-boot. In line 383 there is
ldr pc, r0
which seems to should be
ldr pc, [r0]
I don't think it should. r0 is computed to be the address at which to branch, so the branch there is direct, not indirect. That could be changed to "mov pc, r0" for clarity, though.
binutils 2.20.1 doesn't like "ldr pc, r0". So then it must be "mov pc, r0" if "ldr pc, [r0]" is wrong.
"mov pc, r0" it is, then -- or better yet, replace
add r0, r0, r1 mov pc, r0
with
add pc, r0, r1
And above I used the wrong define, this code is only active when
CONFIG_SYS_ARM_WITHOUT_RELOC is defined.
Understood.
Do you want to submit a patch, or should I do it?
Regards, Alexander
Amicalement,
Dear Albert ARIBAUD,
In message 4CCAB365.2030105@free.fr you wrote:
And above I used the wrong define, this code is only active when
CONFIG_SYS_ARM_WITHOUT_RELOC is defined.
Understood.
Do you want to submit a patch, or should I do it?
Probably not worth the effort, as it seems we have an agreement to apply my cleanup patches, which will remove all this code anyway.
Best regards,
Wolfgang Denk
Hello,
Am 27.10.2010 09:26, schrieb Darius Augulis:
the code for clearing bss section for most ARM cores looks like this or very similar:
... [some code from start.S]
Currently I'm analyzing the same problem (on a kirkwood based hw). It turns out not to be a problem of clear_bss, but a problem of the relocation code. I'm having a problem using gcc 4.3.4 or gcc 4.5.1 along with binutils 2.20.1 and it seems that some stuff is not relocated. It looks like the BSS before relocation is used (e.g. for nand_chip in drivers/mtd/nand.c), but the BSS after relocation might be cleared (in start.S).
I assume it's because of some fixups start.S doesn't know about. But I don't know anything about those fixups, and have to read. So I still have no solution.
Just as a pointer.
Regards,
Alexander
Am 28.10.2010 11:03, schrieb Alexander Holler:
Hello,
Am 27.10.2010 09:26, schrieb Darius Augulis:
the code for clearing bss section for most ARM cores looks like this or very similar:
... [some code from start.S]
Currently I'm analyzing the same problem (on a kirkwood based hw). It turns out not to be a problem of clear_bss, but a problem of the relocation code. I'm having a problem using gcc 4.3.4 or gcc 4.5.1 along with binutils 2.20.1 and it seems that some stuff is not relocated. It looks like the BSS before relocation is used (e.g. for nand_chip in drivers/mtd/nand.c), but the BSS after relocation might be cleared (in start.S).
I assume it's because of some fixups start.S doesn't know about. But I don't know anything about those fixups, and have to read. So I still have no solution.
Just as a pointer.
To verify the problem:
Add
#define DEBUG
in top of arch/arm/lib/board.c
and
printf("nand_chip: %p\n",, &nand_chip[0]);
in nand_init() in drivers/mtd/nand/nand.c
and have a look at the output when u-boot comes up.
Regards,
Alexander
Hello again,
I'm leaving the problem description below, what fixed it all here was to add -fPIC to the CFLAGS to instruct the compiler to generate relocatable code (again).
This flag was replaced in commit 92d5ecba47feb9961c3b7525e947866c5f0d2de5
with -pie in LDFLAGS, which I don't understand (does not mean I have much experience how the compiler and linker are working in regard to relocatable code).
Regards,
Alexander
Am 28.10.2010 11:31, schrieb Alexander Holler:
Am 28.10.2010 11:03, schrieb Alexander Holler:
Hello,
Am 27.10.2010 09:26, schrieb Darius Augulis:
the code for clearing bss section for most ARM cores looks like this or very similar:
... [some code from start.S]
Currently I'm analyzing the same problem (on a kirkwood based hw). It turns out not to be a problem of clear_bss, but a problem of the relocation code. I'm having a problem using gcc 4.3.4 or gcc 4.5.1 along with binutils 2.20.1 and it seems that some stuff is not relocated. It looks like the BSS before relocation is used (e.g. for nand_chip in drivers/mtd/nand.c), but the BSS after relocation might be cleared (in start.S).
I assume it's because of some fixups start.S doesn't know about. But I don't know anything about those fixups, and have to read. So I still have no solution.
Just as a pointer.
To verify the problem:
Add
#define DEBUG
in top of arch/arm/lib/board.c
and
printf("nand_chip: %p\n",,&nand_chip[0]);
in nand_init() in drivers/mtd/nand/nand.c
and have a look at the output when u-boot comes up.
Regards,
Alexander _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Hi all,
Le 29/10/2010 10:50, Alexander Holler a écrit :
Hello again,
I'm leaving the problem description below, what fixed it all here was to add -fPIC to the CFLAGS to instruct the compiler to generate relocatable code (again).
This flag was replaced in commit 92d5ecba47feb9961c3b7525e947866c5f0d2de5
Did you reach tis commit by dissecting?
with -pie in LDFLAGS, which I don't understand (does not mean I have much experience how the compiler and linker are working in regard to relocatable code).
Regards,
Alexander
That needs some more analysis.
-fPIC without GOT relocation does nothing good, and with it, does not enough -- hence the ELF relocation patches replacing -fPIC with -pie, which is *intended* for relocating executables. these two machanisms are not meant to be used together.
Can you be more specific about this:
To verify the problem:
Add
#define DEBUG
in top of arch/arm/lib/board.c
and
printf("nand_chip: %p\n",,&nand_chip[0]);
in nand_init() in drivers/mtd/nand/nand.c
and have a look at the output when u-boot comes up.
Precisely what is the output in both cases?
Regards,
Alexander
Amicalement,
Am 29.10.2010 11:19, schrieb Albert ARIBAUD:
Hi all,
Le 29/10/2010 10:50, Alexander Holler a écrit :
Hello again,
I'm leaving the problem description below, what fixed it all here was to add -fPIC to the CFLAGS to instruct the compiler to generate relocatable code (again).
This flag was replaced in commit 92d5ecba47feb9961c3b7525e947866c5f0d2de5
Did you reach tis commit by dissecting?
No, I just used gitk and/or git gui blame to search when -fPIC disappeared.
with -pie in LDFLAGS, which I don't understand (does not mean I have much experience how the compiler and linker are working in regard to relocatable code).
That needs some more analysis.
-fPIC without GOT relocation does nothing good, and with it, does not enough -- hence the ELF relocation patches replacing -fPIC with -pie, which is *intended* for relocating executables. these two machanisms are not meant to be used together.
Can you be more specific about this:
Adding
printf("nand_chip: %p\n",&nand_chip[0]);
to nand_init() in drivers/mtd/nand.c
a non relocated address will be printed without -fPIC. After adding -fPIC to the CFLAGS the address is relocated. U-Boot fails there first because nand_chip[0] contains function pointers which are used while scanning the NAND. And because they aren't relocated, but only the relocated BSS will be cleared, the following code in nand_set_defaults() in drivers/mtd/nand/nand_base.c will not initialize cmdfunc
if (chip->cmdfunc == NULL) chip->cmdfunc = nand_command;
with the result that chip->cmdfunc is called later which just points to somewhere (because the not relocated BSS isn't cleared).
I'm having this problem with both gcc 4.3.4 and gcc 4.5.1 (along with binutils 2.20.1). I'm compiling native.
I've got the idea to add -fPIC while staring add the assembler output of nand.c, trying to understand whats happening.
I could send another mail to the list, when I've checked what happens when I'm cross-compiling using the ELDK (I think the ELDK uses 4.2.x), attaching 4 times nand.s (4.3.4.non-working, 4.5.1.non-working, 4.5.1.fPIC.working, 4.2.x.currently_unknown).
nand.s is about 55kB, don't know if I should send about 200k in one mail to ml.
Regards,
Alexander
Le 29/10/2010 13:56, Alexander Holler a écrit :
Am 29.10.2010 11:19, schrieb Albert ARIBAUD:
Hi all,
Le 29/10/2010 10:50, Alexander Holler a écrit :
Hello again,
I'm leaving the problem description below, what fixed it all here was to add -fPIC to the CFLAGS to instruct the compiler to generate relocatable code (again).
This flag was replaced in commit 92d5ecba47feb9961c3b7525e947866c5f0d2de5
Did you reach tis commit by dissecting?
No, I just used gitk and/or git gui blame to search when -fPIC disappeared.
Hmm... Git blame just lest you know what commit changed a line last, which is not enough to make sure that the change was the root cause.
with -pie in LDFLAGS, which I don't understand (does not mean I have much experience how the compiler and linker are working in regard to relocatable code).
That needs some more analysis.
-fPIC without GOT relocation does nothing good, and with it, does not enough -- hence the ELF relocation patches replacing -fPIC with -pie, which is *intended* for relocating executables. these two machanisms are not meant to be used together.
Can you be more specific about this:
Adding
printf("nand_chip: %p\n",&nand_chip[0]);
to nand_init() in drivers/mtd/nand.c
a non relocated address will be printed without -fPIC. After adding -fPIC to the CFLAGS the address is relocated. U-Boot fails there first because nand_chip[0] contains function pointers which are used while scanning the NAND.
Weird: I introduced -pie precisely because it relocates pointers in data structures while -fPIC does not -- I'd hit the issue myself. I assume I can test this with an OpenRD board, which has NAND also.
And because they aren't relocated, but only the relocated BSS will be cleared, the following code in nand_set_defaults() in drivers/mtd/nand/nand_base.c will not initialize cmdfunc
if (chip->cmdfunc == NULL) chip->cmdfunc = nand_command;with the result that chip->cmdfunc is called later which just points to somewhere (because the not relocated BSS isn't cleared).
Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT, the start.S code clears the relocated BSS. Are we in a case where you prevent part of the relocation process, such as by using CONFIG_SKIP_RELOCATE_UBOOT?
I'm having this problem with both gcc 4.3.4 and gcc 4.5.1 (along with binutils 2.20.1). I'm compiling native.
I've got the idea to add -fPIC while staring add the assembler output of nand.c, trying to understand whats happening.
I could send another mail to the list, when I've checked what happens when I'm cross-compiling using the ELDK (I think the ELDK uses 4.2.x), attaching 4 times nand.s (4.3.4.non-working, 4.5.1.non-working, 4.5.1.fPIC.working, 4.2.x.currently_unknown).
nand.s is about 55kB, don't know if I should send about 200k in one mail to ml.
Providing the location on the Net of the toolchains will be enough, (along with which version of nand.c you're using if that matters).
Regards,
Alexander
Amicalement,
Am 29.10.2010 14:08, schrieb Albert ARIBAUD:
with -pie in LDFLAGS, which I don't understand (does not mean I have much experience how the compiler and linker are working in regard to relocatable code).
That needs some more analysis.
-fPIC without GOT relocation does nothing good, and with it, does not enough -- hence the ELF relocation patches replacing -fPIC with -pie, which is *intended* for relocating executables. these two machanisms are not meant to be used together.
Can you be more specific about this:
Adding
printf("nand_chip: %p\n",&nand_chip[0]);
to nand_init() in drivers/mtd/nand.c
a non relocated address will be printed without -fPIC. After adding -fPIC to the CFLAGS the address is relocated. U-Boot fails there first because nand_chip[0] contains function pointers which are used while scanning the NAND.
Weird: I introduced -pie precisely because it relocates pointers in data structures while -fPIC does not -- I'd hit the issue myself. I assume I can test this with an OpenRD board, which has NAND also.
And because they aren't relocated, but only the relocated BSS will be cleared, the following code in nand_set_defaults() in drivers/mtd/nand/nand_base.c will not initialize cmdfunc
if (chip->cmdfunc == NULL) chip->cmdfunc = nand_command;
with the result that chip->cmdfunc is called later which just points to somewhere (because the not relocated BSS isn't cleared).
Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT, the start.S code clears the relocated BSS. Are we in a case where you prevent part of the relocation process, such as by using CONFIG_SKIP_RELOCATE_UBOOT?
The (wrong, not relocated) location of nand_chip (building without -fPIC) is inside the BSS before relocation through staŕt.S. This part of RAM will not be cleared because it shouldn't be used.
I'm having this problem with both gcc 4.3.4 and gcc 4.5.1 (along with binutils 2.20.1). I'm compiling native.
I've got the idea to add -fPIC while staring add the assembler output of nand.c, trying to understand whats happening.
I could send another mail to the list, when I've checked what happens when I'm cross-compiling using the ELDK (I think the ELDK uses 4.2.x), attaching 4 times nand.s (4.3.4.non-working, 4.5.1.non-working, 4.5.1.fPIC.working, 4.2.x.currently_unknown).
nand.s is about 55kB, don't know if I should send about 200k in one mail to ml.
Providing the location on the Net of the toolchains will be enough, (along with which version of nand.c you're using if that matters).
I'm using Gentoo where it's easy to swith the compiler (on a DockStar ~ Sheevaplug = Kirkwood Feroceon 88FR131) to compile the current HEAD of the master
Regards,
Alexander
Le 29/10/2010 14:31, Alexander Holler a écrit :
Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT, the start.S code clears the relocated BSS. Are we in a case where you prevent part of the relocation process, such as by using CONFIG_SKIP_RELOCATE_UBOOT?
The (wrong, not relocated) location of nand_chip (building without -fPIC) is inside the BSS before relocation through staŕt.S. This part of RAM will not be cleared because it shouldn't be used.
Er... nand_chip is declared as static global uninitialized, which makes it normal that it goes to BSS, and also normal that it has no fixups applied, as relocation happens before BSS can be accessed, that is, at a time where BSS is still completely uninitialized. Relocations to BSS just don't make sense, they're done only to constant code (.text and .data) emitted by the compiler/linker.
So if you call nand_init to fill nand_chip before relocation, don't expect it to be fixed up during relocation and useable after. That simply is not possible.
Providing the location on the Net of the toolchains will be enough, (along with which version of nand.c you're using if that matters).
I'm using Gentoo where it's easy to swith the compiler (on a DockStar ~ Sheevaplug = Kirkwood Feroceon 88FR131) to compile the current HEAD of the master
I'm sure it is, but it does not tell me where I can get these toolchains and test them :) (except for the ELDK one which I use routinely).
Regards,
Alexander
Amicalement,
Am 29.10.2010 15:37, schrieb Albert ARIBAUD:
Le 29/10/2010 14:31, Alexander Holler a écrit :
Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT, the start.S code clears the relocated BSS. Are we in a case where you prevent part of the relocation process, such as by using CONFIG_SKIP_RELOCATE_UBOOT?
The (wrong, not relocated) location of nand_chip (building without -fPIC) is inside the BSS before relocation through staŕt.S. This part of RAM will not be cleared because it shouldn't be used.
Er... nand_chip is declared as static global uninitialized, which makes it normal that it goes to BSS, and also normal that it has no fixups applied, as relocation happens before BSS can be accessed, that is, at a time where BSS is still completely uninitialized. Relocations to BSS just don't make sense, they're done only to constant code (.text and .data) emitted by the compiler/linker.
So if you call nand_init to fill nand_chip before relocation, don't expect it to be fixed up during relocation and useable after. That simply is not possible.
nand_init() is called inside board.c after relocation. But the relocation does not change the address of that nand_chip. At least this is what that printf("nand_chip: %p\n", &nand_chip[0]); inside nand_init() tells me.
Providing the location on the Net of the toolchains will be enough, (along with which version of nand.c you're using if that matters).
I'm using Gentoo where it's easy to swith the compiler (on a DockStar ~ Sheevaplug = Kirkwood Feroceon 88FR131) to compile the current HEAD of the master
I'm sure it is, but it does not tell me where I can get these toolchains and test them :) (except for the ELDK one which I use routinely).
I assume it's not possible. Gentoo is compiled from source. A minimal root containing binaries for binutils and gcc (4.4.x currently I think) is available at
http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3/
Therefore my offer to supply generated nand.s.
Regards,
Alexander
Le 29/10/2010 15:50, Alexander Holler a écrit :
Am 29.10.2010 15:37, schrieb Albert ARIBAUD:
Le 29/10/2010 14:31, Alexander Holler a écrit :
Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT, the start.S code clears the relocated BSS. Are we in a case where you prevent part of the relocation process, such as by using CONFIG_SKIP_RELOCATE_UBOOT?
The (wrong, not relocated) location of nand_chip (building without -fPIC) is inside the BSS before relocation through staŕt.S. This part of RAM will not be cleared because it shouldn't be used.
Er... nand_chip is declared as static global uninitialized, which makes it normal that it goes to BSS, and also normal that it has no fixups applied, as relocation happens before BSS can be accessed, that is, at a time where BSS is still completely uninitialized. Relocations to BSS just don't make sense, they're done only to constant code (.text and .data) emitted by the compiler/linker.
So if you call nand_init to fill nand_chip before relocation, don't expect it to be fixed up during relocation and useable after. That simply is not possible.
nand_init() is called inside board.c after relocation. But the relocation does not change the address of that nand_chip. At least this is what that printf("nand_chip: %p\n",&nand_chip[0]); inside nand_init() tells me.
Can you give specific values, i.e., can you copy-paste the output of these printf()s along with the version of the toolchain used, both in a "working" and "non-working" case?
Providing the location on the Net of the toolchains will be enough, (along with which version of nand.c you're using if that matters).
I'm using Gentoo where it's easy to swith the compiler (on a DockStar ~ Sheevaplug = Kirkwood Feroceon 88FR131) to compile the current HEAD of the master
I'm sure it is, but it does not tell me where I can get these toolchains and test them :) (except for the ELDK one which I use routinely).
I assume it's not possible. Gentoo is compiled from source. A minimal root containing binaries for binutils and gcc (4.4.x currently I think) is available at
http://distfiles.gentoo.org/releases/arm/autobuilds/current-stage3/
Therefore my offer to supply generated nand.s.
Hmm... In that case yes, you could supply it for that toolchain that cannot easily be used by others, if not via the list, at least by private e-mail.
Regards,
Alexander
Amicalement,
Hello,
I don't quote the rest, just read the mails before. ;)
Here is the what I've done with the current head and the resulting output: ------------------------------------------------------------------------ dockstar2 u-boot.git # vim drivers/mtd/nand/nand.c (adding printf) dockstar2 u-boot.git # vim arch/arm/lib/board.c (adding #define DEBUG) dockstar2 u-boot.git # make distclean awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg > .boards.depend Generating include/autoconf.mk dockstar2 u-boot.git # make sheevaplug_config awk '(NF && $1 !~ /^#/) { print $1 ": " $1 "_config; $(MAKE)" }' boards.cfg > .boards.depend Configuring for sheevaplug board... dockstar2 u-boot.git # make u-boot.bin Generating include/autoconf.mk Generating include/autoconf.mk.dep ... make[1]: Entering directory `/usr/src/u-boot.git/drivers/mtd/nand' gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x00700000 -I/usr/src/u-boot.git/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.5.1/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5te -Wall -Wstrict-prototypes -fno-stack-protector \ -o nand.o nand.c -c ... ------------------------------------------------------------------------
Output (I've changed CONFIG_SYS_TEXT_BASE to 0x00700000 along with some other patches neccessary for my board like different RAM size) to test u-boot through chainloading): ------------------------------------------------------------------------ Hit any key to stop autoboot: 0 Marvell>> tftpboot 0x700000 u-boot.bin Using egiga0 device TFTP from server 192.168.207.1; our IP address is 192.168.207.25 Filename 'u-boot.bin'. Load address: 0x700000 Loading: ########################## done Bytes transferred = 369168 (5a210 hex) Marvell>> g 0x700000 ## Starting application at 0x00700000 ...
U-Boot 2010.12-rc1-00009-g27b7641-dirty (Oct 29 2010 - 15:58:59) Seagate-DockStar
U-Boot code: 00700000 -> 0075A210 BSS: -> 007A0300 SoC: Kirkwood 88F6281_A0 monitor len: 000A0300 ramsize: 08000000 TLB table at: 07ff0000 Top of RAM usable for U-Boot at: 07ff0000 Reserving 640k for U-Boot at: 07f4f000 Reserving 1152k for malloc() at: 07e2f000 Reserving 48 Bytes for Board Info at: 07e2efd0 Reserving 92 Bytes for Global Data at: 07e2ef74 New Stack Pointer is: 07e2ef70 RAM Configuration: Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes Bank #2: e7dfe27e 4 GiB Bank #3: 7fdbe1ce 2.7 GiB relocation Offset is: 0784f000 monitor flash len: 0005A210 Now running in RAM - U-Boot at: 07f4f000 NAND: nand_chip: 0075d198 (this is &nand_chip[0]) (nothing else => killed through calling chip->cmdfunc) ------------------------------------------------------------------------
Output after adding -fPIC: ------------------------------------------------------------------------ Hit any key to stop autoboot: 0 Marvell>> tftpboot 0x700000 u-boot.bin Using egiga0 device TFTP from server 192.168.207.1; our IP address is 192.168.207.25 Filename 'u-boot.bin'. Load address: 0x700000 Loading: ########################## done Bytes transferred = 377360 (5c210 hex) Marvell>> g 0x700000 ## Starting application at 0x00700000 ...
U-Boot 2010.12-rc1-00009-g27b7641-dirty (Oct 29 2010 - 16:17:01) Seagate-DockStar
U-Boot code: 00700000 -> 0075C210 BSS: -> 007A2300 SoC: Kirkwood 88F6281_A0 monitor len: 000A2300 ramsize: 08000000 TLB table at: 07ff0000 Top of RAM usable for U-Boot at: 07ff0000 Reserving 648k for U-Boot at: 07f4d000 Reserving 1152k for malloc() at: 07e2d000 Reserving 48 Bytes for Board Info at: 07e2cfd0 Reserving 92 Bytes for Global Data at: 07e2cf74 New Stack Pointer is: 07e2cf70 RAM Configuration: Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes Bank #2: 0197f8ff 3.3 GiB Bank #3: 0f0c0cab 3.5 GiB relocation Offset is: 0784d000 monitor flash len: 0005C210 Now running in RAM - U-Boot at: 07f4d000 NAND: nand_chip: 07fac198 (this is &nand_chip[0]) 256 MiB nand_scan_bbt: Out of memory ERROR: Cannot import environment: errno = 0
at env_common.c:221/env_import() *** Warning - import failed, using default environment
ERROR: Environment import failed: errno = 12
at env_common.c:192/set_default_env() ------------------------------------------------------------------------
Up to now I haven't found the time to checked the error I'm getting here, but at least the output from the printf looks correct. Just ignore the wrong DRAM sizes, this is already fixed but I haven't that for these two tests.
The two nand.s are available at my server:
http://ahsoftware.de/nand.s.notworking.gcc.4.5.1_without-fpic
generated with:
gcc -g -Os -fno-common -ffixed-r8 -msoft-float -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x00700000 -I/usr/src/u-boot.git/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.5.1/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5te -Wall -Wstrict-prototypes -fno-stack-protector -S nand.c
http://ahsoftware.de/nand.s.working.gcc.4.5.1_with-fpic
generated with
gcc -g -Os -fno-common -ffixed-r8 -msoft-float -fPIC -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x00700000 -I/usr/src/u-boot.git/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/lib/gcc/armv5tel-softfloat-linux-gnueabi/4.5.1/include -pipe -DCONFIG_ARM -D__ARM__ -marm -mabi=aapcs-linux -mno-thumb-interwork -march=armv5te -Wall -Wstrict-prototypes -fno-stack-protector -S nand.c
Regards,
Alexander
Dear Alexander Holler,
In message 4CCADC10.9010205@ahsoftware.de you wrote:
...
U-Boot code: 00700000 -> 0075A210 BSS: -> 007A0300 SoC: Kirkwood 88F6281_A0 monitor len: 000A0300 ramsize: 08000000
That's 128 MB...
TLB table at: 07ff0000 Top of RAM usable for U-Boot at: 07ff0000 Reserving 640k for U-Boot at: 07f4f000 Reserving 1152k for malloc() at: 07e2f000 Reserving 48 Bytes for Board Info at: 07e2efd0 Reserving 92 Bytes for Global Data at: 07e2ef74 New Stack Pointer is: 07e2ef70 RAM Configuration: Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes
These look OK.
Bank #2: e7dfe27e 4 GiB Bank #3: 7fdbe1ce 2.7 GiB
But this is obviously garbage. And the printed sizes are garbage, too.
Where is this coming from?
Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes Bank #2: 0197f8ff 3.3 GiB Bank #3: 0f0c0cab 3.5 GiB
It seems you cannot even print sane numbers.
Did you verify that your inital stack is properly aligned?
Best regards,
Wolfgang Denk
Am 29.10.2010 16:44, schrieb Wolfgang Denk:
Dear Alexander Holler,
In message4CCADC10.9010205@ahsoftware.de you wrote:
...
U-Boot code: 00700000 -> 0075A210 BSS: -> 007A0300 SoC: Kirkwood 88F6281_A0 monitor len: 000A0300 ramsize: 08000000
That's 128 MB...
TLB table at: 07ff0000 Top of RAM usable for U-Boot at: 07ff0000 Reserving 640k for U-Boot at: 07f4f000 Reserving 1152k for malloc() at: 07e2f000 Reserving 48 Bytes for Board Info at: 07e2efd0 Reserving 92 Bytes for Global Data at: 07e2ef74 New Stack Pointer is: 07e2ef70 RAM Configuration: Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes
These look OK.
Bank #2: e7dfe27e 4 GiB Bank #3: 7fdbe1ce 2.7 GiB
But this is obviously garbage. And the printed sizes are garbage, too.
Where is this coming from?
I have forgotten to change *NR_BANKS from 4 to 1 for these tests, but I assume this is already fixed here without the need to change *NR_BANKS:
http://lists.denx.de/pipermail/u-boot/2010-October/080621.html
Regards,
Alexander
Dear Alexander Holler,
U-Boot 2010.12-rc1-00009-g27b7641-dirty (Oct 29 2010 - 15:58:59) Seagate-DockStar
U-Boot code: 00700000 -> 0075A210 BSS: -> 007A0300 SoC: Kirkwood 88F6281_A0 monitor len: 000A0300 ramsize: 08000000 TLB table at: 07ff0000 Top of RAM usable for U-Boot at: 07ff0000 Reserving 640k for U-Boot at: 07f4f000 Reserving 1152k for malloc() at: 07e2f000 Reserving 48 Bytes for Board Info at: 07e2efd0 Reserving 92 Bytes for Global Data at: 07e2ef74 New Stack Pointer is: 07e2ef70 RAM Configuration: Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes Bank #2: e7dfe27e 4 GiB
Humm, should you not attend to the problems in the order they occur? This can't be right, and might indicate a problem that is there already before NAND is accessed? Or even cause subsequent problems? If you declare having 4 RAM banks they should be properly initialized, if they do not exist.
RAM Configuration: Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes Bank #2: 0197f8ff 3.3 GiB Bank #3: 0f0c0cab 3.5 GiB
Same here.
Best Regards, Reinhard
Am 29.10.2010 16:50, schrieb Reinhard Meyer:
Dear Alexander Holler,
U-Boot 2010.12-rc1-00009-g27b7641-dirty (Oct 29 2010 - 15:58:59) Seagate-DockStar
U-Boot code: 00700000 -> 0075A210 BSS: -> 007A0300 SoC: Kirkwood 88F6281_A0 monitor len: 000A0300 ramsize: 08000000 TLB table at: 07ff0000 Top of RAM usable for U-Boot at: 07ff0000 Reserving 640k for U-Boot at: 07f4f000 Reserving 1152k for malloc() at: 07e2f000 Reserving 48 Bytes for Board Info at: 07e2efd0 Reserving 92 Bytes for Global Data at: 07e2ef74 New Stack Pointer is: 07e2ef70 RAM Configuration: Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes Bank #2: e7dfe27e 4 GiB
Humm, should you not attend to the problems in the order they occur? This can't be right, and might indicate a problem that is there already before NAND is accessed? Or even cause subsequent problems? If you declare having 4 RAM banks they should be properly initialized, if they do not exist.
RAM Configuration: Bank #0: 00000000 128 MiB Bank #1: 00000000 0 Bytes Bank #2: 0197f8ff 3.3 GiB Bank #3: 0f0c0cab 3.5 GiB
Same here.
Best Regards, Reinhard
Just to explain it: I had fixed that before and I've just checked out a clean branch and have applyed some patches which haven't included a fix for those wrong sizes which are displayed. But that doesn't change anything for the problem with the relocation (proofed before!).
Regards,
Alexander
Le 29/10/2010 16:37, Alexander Holler a écrit :
Hello,
I don't quote the rest, just read the mails before. ;)
Here is the what I've done with the current head and the resulting output:
The generated assembler code isn't really workable, at least I don't feel comfortable with it. Could you instead do an objdump -d -S .../nand.o > nand.lst and make the nand.lst files for each case available?
Regards,
Alexander
Amicalement,
Am 29.10.2010 16:54, schrieb Albert ARIBAUD:
Le 29/10/2010 16:37, Alexander Holler a écrit :
Hello,
I don't quote the rest, just read the mails before. ;)
Here is the what I've done with the current head and the resulting output:
The generated assembler code isn't really workable, at least I don't feel comfortable with it. Could you instead do an objdump -d -S .../nand.o > nand.lst and make the nand.lst files for each case available?
Here it is:
http://ahsoftware.de/nand.lst.notworking.gcc.4.5.1_without-fpic
and
http://ahsoftware.de/nand.lst.working.gcc.4.5.1_with-fpic
I could offer the output of "gcc ... -gstabs+ -Wa,-ahldn -c nand.c
nand.s" too, this is what I'm often using but it looks like the output
of objdump ;)
Regards,
Alexander
Le 29/10/2010 17:05, Alexander Holler a écrit :
Am 29.10.2010 16:54, schrieb Albert ARIBAUD:
Le 29/10/2010 16:37, Alexander Holler a écrit :
Hello,
I don't quote the rest, just read the mails before. ;)
Here is the what I've done with the current head and the resulting output:
The generated assembler code isn't really workable, at least I don't feel comfortable with it. Could you instead do an objdump -d -S .../nand.o> nand.lst and make the nand.lst files for each case available?
Here it is:
http://ahsoftware.de/nand.lst.notworking.gcc.4.5.1_without-fpic
and
http://ahsoftware.de/nand.lst.working.gcc.4.5.1_with-fpic
I could offer the output of "gcc ... -gstabs+ -Wa,-ahldn -c nand.c
nand.s" too, this is what I'm often using but it looks like the output
of objdump ;)
Regards,
Alexander
The assemble is better, but now I see that objdump does not show all of the code, particularly not all of the literals. Can you provide the ELF binary (not the pure binary) for both cases? This way I can readelf and objdump, plus I can compare this to my own builds.
Amicalement,
The assemble is better, but now I see that objdump does not show all of the code, particularly not all of the literals. Can you provide the ELF binary (not the pure binary) for both cases? This way I can readelf and objdump, plus I can compare this to my own builds.
I've just seen that too. ;)
http://ahsoftware.de/nand.o.notworking.gcc.4.5.1_without-fpic
and
http://ahsoftware.de/nand.o.working.gcc.4.5.1_with-fpic
Regards,
Alexander
Le 29/10/2010 17:32, Alexander Holler a écrit :
The assemble is better, but now I see that objdump does not show all of the code, particularly not all of the literals. Can you provide the ELF binary (not the pure binary) for both cases? This way I can readelf and objdump, plus I can compare this to my own builds.
I've just seen that too. ;)
http://ahsoftware.de/nand.o.notworking.gcc.4.5.1_without-fpic
and
http://ahsoftware.de/nand.o.working.gcc.4.5.1_with-fpic
Regards,
Alexander
Sorry, I meant the ELF u-boot binary, not the ELF object file of nand. I need all the relocation information to be sure, and it can only be found in the full ELF binary.
Amicalement,
Am 29.10.2010 17:38, schrieb Albert ARIBAUD:
Sorry, I meant the ELF u-boot binary, not the ELF object file of nand. I need all the relocation information to be sure, and it can only be found in the full ELF binary.
Done through other ways. Not that someone else gets the idea I'm distributing binaries and therefore have to offer the complete toolchain to be compliant with GPL. This is not what I currently want to do.
Yes, sometimes I'm read and try to understand licenses. ;)
Regards,
Alexander
participants (10)
-
Albert ARIBAUD -
Alexander Holler -
Darius Augulis -
Eric Cooper -
Heiko Schocher -
Heiko Schocher -
Reinhard Meyer -
Sughosh Ganu -
Sughosh Ganu -
Wolfgang Denk