Hi Heinrich, On Thu, Oct 25, 2018 at 5:48 AM Heinrich Schuchardt <xypron.g...@gmx.de> 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: >
No, the following command only remove the 16-bit codes from the u-boot image. Other sections are untouched. > objcopy --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot > u-boot-nodtb.bin > > But where are the R_386_RELATIVEs created? > It's in the u-boot.bin image. We don't touch it during the build process. > @Bin: do you have an understanding of how this works? > Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
