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

Po-Yu Chuang ratbert.chuang at gmail.com
Thu Feb 24 08:11:01 CET 2011


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


More information about the U-Boot mailing list