Hi Heinrich, On Thu, Oct 25, 2018 at 2:25 PM Heinrich Schuchardt <[email protected]> wrote: > > On 10/24/2018 11:48 PM, Heinrich Schuchardt wrote: > > On 10/24/2018 08:58 PM, Hannes Schmelzer wrote: > >>> Hello Hannes, > >>> > >>> thanks for reporting the problem. > >>> > >>> There are two possible reasons: > >>> > >>> a) The build process introduces relocations of the reported type. > >>> b) The relocation records are overwritten before relocation. This > >>> happens if you update uninitialized globals. > >>> > >>> To analyze your problem further, please, provide instructions for > >>> building your version of U-Boot (repository, commit, config). That will > >>> allow to check for a). > >>> > >>> Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would > >>> allow to analyze case b). Are you able to reproduce the problem with > >>> QEMU? > >>> > >>> Best regards > >>> > >>> Heinrich > >>> > >> Hello Heinrich, > >> > >> thanks for this input. > >> The "trouble" occurs also with QEMU, have a look to console output below. > >> > >> Maybe you can investigate on this, I've pushed the branch to my github > >> account: > >> > >> https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb > >> config is "brpp065mb" > >> > >> please let me know if i can help. > >> > >> cheers, > >> Hannes > > > > And running qemu-x86_defonfig results in > > do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff84e38, > > offset = 0xfff00091 > > > > So the problem is not restricted to your board. > > > > I have had a first look at the relocations actually present in the > > u-boot ELF file. > > > > Your repo: > > make brpp065mb_defconfig > > make > > objdump -r u-boot | cut -c10-20 | sort | uniq > > > > R_386_32 > > R_386_NONE > > R_386_PC32 > > > > u-boot master: > > make qemu-x86_defconfig > > make > > objdump -r u-boot | cut -c10-20 | sort | uniq > > > > R_386_16 > > R_386_32 > > R_386_NONE > > R_386_PC16 > > R_386_PC32 > > > > The current relocation code only supports a single relocation type > > (R_386_RELATIVE). > > > > What I still do not understand is why most of the relocations that we > > actually see inside U-Boot are of type R_386_RELATIVE). So where are the > > relocations transformed on the way from u-boot to u-boot.bin? > > > > The following command drops some sections and creates an image without > > any relocation information: > > > > objcopy --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot > > u-boot-nodtb.bin > > > > But where are the R_386_RELATIVEs created? > > > > @Bin: do you have an understanding of how this works? > > > > Best regards > > > > Heinrich > > > > I delved a bit deeper into the biaries: > > For qemu-x86_defconfig objcopy eliminates all R_386_PC32 relocations > except the last one when creating u-boot-nofdt.bin. > > Hannes could you please, send me your u-boot-nodtb.bin, u-boot, and > u-boot.map. It seems my build system is not creating the relocation > record at 0x2000087 that was reported by you. > > Here are the file details for qemu-x86_defconfig: > > > Error message: > > do_elf_reloc_fixups32: > unsupported relocation type 0x2 at fff84e78, offset = 0xfff00091 > > > objdump -drS u-boot > > call car_uninit > fff00090: e8 fc ff ff ff > call fff00091 <board_init_f_r_trampoline+0xd> > fff00091: R_386_PC32 car_uninit > 1: > /* Re-enter U-Boot by calling board_init_f_r() */ > call board_init_f_r > fff00095: e8 a0 09 01 00 > call fff10a3a <board_init_f_r> > fff00096: R_386_PC32 board_init_f_r > > > Memory dump via gdb: > > 0xfff84e60: 0xfff73044 0x00000008 0xfff73048 0x00000008 > 0xfff84e70: 0xfff7304c 0x00000008 0xfff00091 0x00000102 > 0xfff84e80: 0xedfe0dd0 0x0b070000 0x38000000 0xd8050000 > 0xfff84e90: 0x28000000 0x11000000 0x10000000 0x00000000 > > > u-boot.map > > .rel.data.test_commands > 0x00000000fff84e00 0x60 arch/x86/cpu/start.o > .rel.u_boot_list_2_cmd_2_dm > 0x00000000fff84e60 0x20 arch/x86/cpu/start.o > 0x00000000fff84e80 __rel_dyn_end = . > 0x00000000fff84e80 . = ALIGN (0x4) > 0x00000000fff84e80 _end = . > > > u-boot-nodtb.bin: > > 00084E60 44 30 F7 FF 08 00 00 00 48 30 F7 FF 08 00 00 00 > 00084E70 4C 30 F7 FF 08 00 00 00 91 00 F0 FF 02 01 00 00 > --- u-boot-nodtb.bin --0x84E80/0x84E80---------------- > > > The same trailing R_386_PC32 I could see with Hannes example: > > 0004CFD8 10 32 04 02 08 00 00 00 18 32 04 02 08 00 00 00 > 0004CFE8 24 32 04 02 08 00 00 00 28 32 04 02 08 00 00 00 > 0004CFF8 2C 32 04 02 08 00 00 00 91 00 00 02 02 01 00 00 > --- u-boot-nodtb.bin --0x4D008/0x4D008-------
There is a bug in the start.S. I will send a patch soon. Regards, Bin _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
