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

[Albert ARIBAUD]

Hi Po-Yu Chuang,

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.

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.

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