[U-Boot] omap4: LDFLAGS=build-id flag generates wrong u-boot.bin
Nishanth Menon
nm at ti.com
Wed Oct 13 01:28:12 CEST 2010
Hi,
While generating MeeGo u-boot repository for omap4_panda configuration,
I ran into a curious issue, I happened to add LDFLAGS=--build-id and it
ended up generating a 2.5GB u-boot.bin.
digging a little further, I see the linking stage adding --build-id
arm-none-linux-gnueabi-ld --build-id -Bstatic -T u-boot.lds -Ttext
0x9ff00000 $UNDEF_SYM arch/arm/cpu/armv7/start.o --start-group
lib/libgeneric.a lib/lzma/liblzma.a lib/lzo/liblzo.a
arch/arm/cpu/armv7/libarmv7.a arch/arm/cpu/armv7/omap4/libomap4.a
arch/arm/lib/libarm.a fs/cramfs/libcramfs.a fs/fat/libfat.a
fs/fdos/libfdos.a fs/jffs2/libjffs2.a fs/reiserfs/libreiserfs.a
fs/ext2/libext2fs.a fs/yaffs2/libyaffs2.a fs/ubifs/libubifs.a
net/libnet.a disk/libdisk.a drivers/bios_emulator/libatibiosemu.a
drivers/block/libblock.a drivers/dma/libdma.a drivers/fpga/libfpga.a
drivers/gpio/libgpio.a drivers/hwmon/libhwmon.a drivers/i2c/libi2c.a
drivers/input/libinput.a drivers/misc/libmisc.a drivers/mmc/libmmc.a
drivers/mtd/libmtd.a drivers/mtd/nand/libnand.a
drivers/mtd/onenand/libonenand.a drivers/mtd/ubi/libubi.a
drivers/mtd/spi/libspi_flash.a drivers/net/libnet.a
drivers/net/phy/libphy.a drivers/pci/libpci.a drivers/pcmcia/libpcmcia.a
drivers/power/libpower.a drivers/spi/libspi.a drivers/rtc/librtc.a
drivers/serial/libserial.a drivers/twserial/libtws.a
drivers/usb/gadget/libusb_gadget.a drivers/usb/host/libusb_host.a
drivers/usb/musb/libusb_musb.a drivers/usb/phy/libusb_phy.a
drivers/video/libvideo.a drivers/watchdog/libwatchdog.a
common/libcommon.a lib/libfdt/libfdt.a api/libapi.a post/libpost.a
arch/arm/cpu/armv7/omap-common/libomap-common.a
board/ti/panda/libpanda.a --end-group
/home/nmenon/Src/opensource/u-boot/arch/arm/lib/eabi_compat.o -L
/opt/arm/arm-2010q1/bin/../lib/gcc/arm-none-linux-gnueabi/4.4.1/armv4t
-lgcc -Map u-boot.map -o u-boot
This results in the following section being added to u-boot
Disassembly of section .note.gnu.build-id:
00000000 <.note.gnu.build-id>:
0: 00000004 andeq r0, r0, r4
4: 00000014 andeq r0, r0, r4, lsl r0
8: 00000003 andeq r0, r0, r3
c: 00554e47 subseq r4, r5, r7, asr #28
10: 3c3c6218 lfmcc f6, 4, [ip], #-96 ; 0xffffffa0
14: 015620ef cmpeq r6, pc, ror #1
18: 723aeceb eorsvc lr, sl, #60160 ; 0xeb00
1c: 5eade957 mcrpl 9, 5, lr, cr13, cr7, {2}
20: 1cf9a5e7 cfldr64ne mvdx10, [r9], #924 ; 0x39c
Disassembly of section .text:
9ff00000 <_start>:
9ff00000: ea000012 b 9ff00050 <reset>
<snip>
and that explained my 2.5GB as "arm-none-linux-gnueabi-objcopy
--gap-fill=0xff -O binary u-boot u-boot.bin" tried to fill up the 0x0 to
0x9ff00000 with 0xff :)
I am just curious if someone had seen and fixed something like this
elsewhere..
--
Regards,
Nishanth Menon
More information about the U-Boot
mailing list