[U-Boot] ARM: Incorrect ROM protection range?

[Albert ARIBAUD <albert.aribaud@free.fr>]

Le 01/03/2011 09:31, Po-Yu Chuang a ?crit :
> Dear Wolfgang,
>
> On Fri, Feb 25, 2011 at 4:00 PM, Po-Yu Chuang<ratbert.chuang@gmail.com>  wrote:
>> Dear Wolfgang and Albert,
>>
>> On Fri, Feb 25, 2011 at 3:15 PM, Wolfgang Denk<wd@denx.de>  wrote:
>>> Dear Albert ARIBAUD,
>>>
>>> In message<4D674D85.40904@free.fr>  you wrote:
>>>>
>>>> All this, of course, if Wolfgang agrees to this suggestion.
>>>
>>> I fully agree.
>>
>> All right, but please give me some time.
>> I need to study how to use sed to do this. :-p
>
> I tried the following command and it seems work:
>
> for f in `find * -type f`; do sed -i 's/\<_end\>/__bss_end/g' $f; done
>
>
> but when I tried to build, I got some error in standalone example:
>
>
> make[1]: Entering directory `/home/ratbert/linux/u-boot/examples/standalone'
> arm-none-linux-gnueabi-gcc  -g  -Os   -fno-common -ffixed-r8
> -msoft-float  -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0
> -I/home/ratbert/linux/u-boot/include -fno-builtin -ffreestanding
> -nostdinc -isystem
> /home/ratbert/linux/arm-none-linux-gnueabi-4.4.0_ARMv4/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.0/include
> -pipe  -DCONFIG_ARM -D__ARM__ -marm  -mabi=aapcs-linux
> -mno-thumb-interwork -march=armv4 -Wall -Wstrict-prototypes
> -fno-stack-protector -fno-toplevel-reorder   -o hello_world.o
> hello_world.c -c
> arm-none-linux-gnueabi-gcc  -g  -Os   -fno-common -ffixed-r8
> -msoft-float  -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0
> -I/home/ratbert/linux/u-boot/include -fno-builtin -ffreestanding
> -nostdinc -isystem
> /home/ratbert/linux/arm-none-linux-gnueabi-4.4.0_ARMv4/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.0/include
> -pipe  -DCONFIG_ARM -D__ARM__ -marm  -mabi=aapcs-linux
> -mno-thumb-interwork -march=armv4 -Wall -Wstrict-prototypes
> -fno-stack-protector -fno-toplevel-reorder   -o stubs.o stubs.c -c
> arm-none-linux-gnueabi-ld  -r -o libstubs.o  stubs.o
> arm-none-linux-gnueabi-ld -g -Ttext 0xc100000 \
>                          -o hello_world -e hello_world hello_world.o libstubs.o \
>
> -L/home/ratbert/linux/arm-none-linux-gnueabi-4.4.0_ARMv4/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.0/fa526
> -lgcc
> libstubs.o: In function `app_startup':
> /home/ratbert/linux/u-boot/examples/standalone/stubs.c:206: undefined
> reference to `__bss_end'
> make[1]: *** [hello_world] Error 1
> make[1]: Leaving directory `/home/ratbert/linux/u-boot/examples/standalone'
> make: *** [examples/standalone] Error 2
>
>
> It looks like that _end as end of BSS section is a convention to GNU toolchain.
> Should I simply fix it by hand, or should we reconsider the whole naming thing?

Indeed, since the link command line does not mention a linker file, then 
the default toolchain linker file was invoked. You can see the linker 
script using ld --verbose (be sure to use the toolchain's ld, not your 
host's). Mine (ELDK4.2 and CodeSourcery 2010q1) define __bss_start and 
__bss_start__ before the BSS section, and _bss_end__ and __bss_end__ 
after it, then __end__ and _end after that. No surprise that __bss_end 
did not work.

But examples (ang more generally, standalone applications) are not 
supposed to use symbols from U-Boot linker files; so there is no reason 
to replace __bss_end in these.

Still, we *could* align on the ELDK/CS linkers' output and use 
_bss_end__ and/or __bss_end__ rather than __bss_end for U-Boot, unless 
some other toolchain has radically different default linker scripts. 
Comments anyone?

> best regards,
> Po-Yu Chuang

Amicalement,
-- 
Albert.