Hi Albert,
On Thu, Feb 24, 2011 at 2:52 PM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> Hi Po-Yu Chuang,
>
> Le 24/02/2011 07:06, Po-Yu Chuang a écrit :
>> That is quite strange.
>> According to arch/arm/cpu/arm920t/u-boot.lds,
>> .rel.dyn and .dynsym sections should be placed before __bss_start.
>> However, objdump shows that they are not at where they should be.
>>
>> Do I understand correctly?
>
> Not quite. Actually, relocation sections should start from the same
> location as BSS -- they are overlaid at the same location, and this is
> voluntary.
>
> The relocation sections are only needed and useful before relocation, where
> BSS should not be used anyway.
>
> BSS only exists after relocation, where relocation tables are no more
> useful.
>
> Thus, to minimize RAM and FLASH footprints, the two are overlaid at the same
> location.
I got it. Thanks for your explanation.
>> Does anybody have similar situation?
>
> Just about all people who use ARM U-Boot since the overlay was introduced.
> :)
>
>> 0001bf1c g .bss 00000000 __bss_start
>
>> 0001bf1c g .rel.dyn 00000000 __rel_dyn_start
>
>> 0001f73c g .dynsym 00000000 __dynsym_start
>> 0001f73c g .rel.dyn 00000000 __rel_dyn_end
>
> This is normal as far as layout is concerned: BSS and .rel.dyn start at the
> same offset, and .dynsym follows .rel.dyn.
>
> You're right that U-Boot protection should cover the whole of U-Boot,
> including the relocation tables. I *think* protection uses a monitor length
> define for this. Can you verify this point, and check what your "monitor
> length" define amounts to? Maybe it does not cover the relocation tables any
> more.
The monitor length is not defined by macro. It is calculated.
In drivers/mtd/cfi_flash.c:
/* Monitor protection ON by default */
#if (CONFIG_SYS_MONITOR_BASE >= CONFIG_SYS_FLASH_BASE) && \
(!defined(CONFIG_MONITOR_IS_IN_RAM))
flash_protect (FLAG_PROTECT_SET,
CONFIG_SYS_MONITOR_BASE,
CONFIG_SYS_MONITOR_BASE + monitor_flash_len - 1,
flash_get_info(CONFIG_SYS_MONITOR_BASE));
#endif
monitor_flash_len is defined in arch/arm/lib/board.c and is calculated
by board_init_r():
monitor_flash_len = _bss_start_ofs;
Which is in arch/arm/cpu/arm920t/start.S in my case:
.globl _bss_start_ofs
_bss_start_ofs:
.word __bss_start - _start
So I guess we should use another way to calculate monitor_flash_len.
>
> BTW,
>
> Would it not be better to compute the actual image size rather than rely on
> a define?
>
> In the U-Boot image itself, knowing the image size could be achieved in ARM
> by using a general _end symbol that would be set after the last image output
> section, so _end-_start would equal the image size.
But _end means end of bss section, right?
I think _end is not the right choice.
> For code other than the U-Boot image itself (loaders, utilities), a 'du -b
> u-boot.bin | cut -f 1' should be ok, provided the image is built first,
> which I think is already the case.
best regards,
Po-Yu Chuang