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

[Heiko Schocher <hs@denx.de>]

Hello Albert,

Albert ARIBAUD wrote:
> Le 24/02/2011 07:06, Po-Yu Chuang a ?crit :
>> Hi all,
>>
>> I am using relocation fixed a320evb (arm) u-boot.
>>
>> I noticed something weird about the output of
>> command flinfo.
>>
>> The size of u-boot.bin is 129156 (0x1F884), but the
>> protected range is only 0 ~ 0x1bfff.
>>
>> I guess that it is because u-boot protects _start ~ __bss_start,
>> but there are some other things in u-boot.bin after __bss_start,
>> e.g. .rel.dyn section and .dynsym section
> 
> You're most probable right about this -- this size error has to be 
> fixed. All reasers please see the 'BTW' at the end of my post.
> 
>> 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.
> 
>> 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 bin length is calculated in arch/arm/lib/board.c, but it seems
to me not correct ... :-(

in board_init_f():

gd->mon_len = _bss_end_ofs;

that seems correct to me, but later in board_init_r()

monitor_flash_len = _bss_start_ofs;

which is used for example in ./drivers/mtd/cfi_flash.c for protecting
the flash sectors ... so this should be fixed.

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

we have such a "_end" in u-boot.lds files.

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

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