[U-Boot] Most ARM CPU's have buggy clear_bss?

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Darius Augulis]

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.

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Sughosh Ganu]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Darius Augulis]

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
>

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Sughosh Ganu]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Darius Augulis]

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
>

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Sughosh Ganu]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Darius Augulis]

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
>

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Voodoo Programming: Things programmers do that  they  know  shouldn't
work  but they try anyway, and which sometimes actually work, such as
recompiling everything.                             - Karl Lehenbauer

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Darius Augulis]

On 10/27/2010 01:40 PM, Wolfgang Denk wrote:
> 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.

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
>

[U-Boot] Most ARM CPU's have buggy clear_bss?

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It is common sense to take a method and try it. If it fails, admit it
frankly and try another. But above all, try something.
                                              - Franklin D. Roosevelt

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Eric Cooper]

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 

-- 
Eric Cooper             e c c @ c m u . e d u

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Darius Augulis]

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 at 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.

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Heiko Schocher]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Reinhard Meyer]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Heiko Schocher]

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

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Reinhard Meyer]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Reinhard Meyer]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Heiko Schocher]

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_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!

Yep, please send a patch for this issue.

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Reinhard Meyer]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Darius Augulis]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
For every complex problem, there is a solution that is simple,  neat,
and wrong.                                               - Mark Twain

[U-Boot] Most ARM CPU's have buggy clear_bss?

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Sorry, but my karma just ran over your dogma.

[U-Boot] Most ARM CPU's have buggy clear_bss?

[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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There are three ways to get something  done:  do  it  yourself,  hire
someone, or forbid your kids to do it.

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Heiko Schocher]

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
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

Hello,

Am 28.10.2010 10:39, schrieb 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?
>

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Reinhard Meyer]

Dear Alexander Holler,
> Am 28.10.2010 10:39, schrieb 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?
>>
> 
> 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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Two wrongs don't make a right, but three rights make a left.

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Reinhard Meyer]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Albert ARIBAUD]

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

[U-Boot] CONFIG_SKIP_RELOCATE_UBOOT still used?

[Alexander Holler]

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

[U-Boot] CONFIG_SKIP_RELOCATE_UBOOT still used?

[Albert ARIBAUD]

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

[U-Boot] CONFIG_SKIP_RELOCATE_UBOOT still used?

[Alexander Holler]

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

[U-Boot] CONFIG_SKIP_RELOCATE_UBOOT still used?

[Albert ARIBAUD]

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

[U-Boot] CONFIG_SKIP_RELOCATE_UBOOT still used?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
We have phasers, I vote we blast 'em!
	-- Bailey, "The Corbomite Maneuver", stardate 1514.2

[U-Boot] Most ARM CPU's have buggy clear_bss?

[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.

Regards,

Alexander

[U-Boot] Most ARM CPU's have buggy clear_bss?

[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] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

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

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Albert ARIBAUD]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[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.

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Albert ARIBAUD]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
It's certainly  convenient  the  way  the  crime  (or  condition)  of
stupidity   carries   with   it  its  own  punishment,  automatically
admisistered without remorse, pity, or prejudice. :-)
         -- Tom Christiansen in <559seq$ag1$1@csnews.cs.colorado.edu>

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

Am 29.10.2010 16:44, schrieb Wolfgang Denk:
> 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?

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

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

> Regards,
>
> Alexander


Amicalement,
-- 
Albert.

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Albert ARIBAUD]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Albert ARIBAUD]

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

[U-Boot] Most ARM CPU's have buggy clear_bss?

[Alexander Holler]

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