Hi Albert,
On Thu, Feb 24, 2011 at 2:52 PM, Albert ARIBAUD albert.aribaud@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