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