понедельник, 21 января 2008 г.

Что-то великоватый Image...

Собираю новое ядро (2.6.23) для своего LPC2468, и что-то странное происходит с Image...

В то время, как vmlinux вполне корректен на первый взгляд...
$ file vmlinux
vmlinux: ELF 32-bit LSB executable, ARM, version 1, statically linked, not stripped
$ ls -la vmlinux
-rwxr-xr-x 1 dron dron 1919833 Янв 21 10:08 vmlinux


Этого совершенно нельзя сказать про полученный, стандартными средствами, надо сказать, Image.
$ ls -la arch/arm/boot/Image
-rw-r--r-- 1 dron dron 2685758032 Янв 21 10:08 arch/arm/boot/Image
$ file arch/arm/boot/Image
arch/arm/boot/Image: X11 SNF font data, LSB first


Надо сказать что в старом ядре linux.bin собирался кастомной рулей:
linux.bin: vmlinux FORCE
    @$(OBJCOPY) $(OBJCOPYFLAGS) vmlinux $@
    @echo ' Kernel: $@ is ready'


Но лично я не вижу никаких принципиальных отличий от стандартной рули для Image:
$(obj)/Image: vmlinux FORCE
    $(call if_changed,objcopy)
    @echo ' Kernel: $@ is ready'


Которые собственно разворачиваются в
arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux linux.bin
arm-linux-objcopy -O binary -R .note -R .comment -S vmlinux arch/arm/boot/Image

соответственно. Пока даже мыслей нету - почему возникает такая ерунда.

Буду думать.

PS: Ну все ясно. Как говорится - нечего на objcopy пинять, коли vmlinux кривой. в него затесалась секция .note.gnu.build-id, замапленная на 0, в то время как основной код замаплен на 0xa0008000. вот и получается бинарь в 3 гига. Прибил секцию - пришло счастье...

$ ~/arm-linux/bin/arm-linux-objdump -h vmlinux
Sections:
Idx Name Size VMA LMA File off Algn
0 .note.gnu.build-id 00000024 00000000 00000000 00008000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_DISCARD
1 .text.head 00000184 a0008000 a0008000 00010000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE