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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
