[U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. We should be warned if other relocation types appear in the relocation sections.
This type of message has helped to identify code overwriting a relocation section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de --- arch/x86/lib/relocate.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c index ed10755d9c..01e619d20b 100644 --- a/arch/x86/lib/relocate.c +++ b/arch/x86/lib/relocate.c @@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int text_base, uintptr_t size, Elf64_Addr *offset_ptr_ram;
do { + unsigned long long type = ELF64_R_TYPE(re_src->r_info); + + if (type != R_X86_64_RELATIVE) { + printf("%s: unsupported relocation type 0x%llx " + "at %p, ",__func__, type, re_src); + printf("offset = 0x%llx\n", re_src->r_offset); + continue; + } + /* Get the location from the relocation entry */ offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
@@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int text_base, uintptr_t size, Elf32_Addr *offset_ptr_ram;
do { + unsigned int type = ELF32_R_TYPE(re_src->r_info); + + if (type != R_386_RELATIVE) { + printf("%s: unsupported relocation type 0x%x " + "at %p, ",__func__, type, re_src); + printf("offset = 0x%x\n", re_src->r_offset); + continue; + } + /* Get the location from the relocation entry */ offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
On Sat, Oct 13, 2018 at 9:30 AM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. We should be warned if other relocation types appear in the relocation sections.
This type of message has helped to identify code overwriting a relocation section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
arch/x86/lib/relocate.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
Reviewed-by: Bin Meng bmeng.cn@gmail.com
On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. We should be warned if other relocation types appear in the relocation sections.
This type of message has helped to identify code overwriting a relocation section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
arch/x86/lib/relocate.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c index ed10755d9c..01e619d20b 100644 --- a/arch/x86/lib/relocate.c +++ b/arch/x86/lib/relocate.c @@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int text_base, uintptr_t size, Elf64_Addr *offset_ptr_ram;
do {
unsigned long long type = ELF64_R_TYPE(re_src->r_info);if (type != R_X86_64_RELATIVE) {printf("%s: unsupported relocation type 0x%llx ""at %p, ",__func__, type, re_src);printf("offset = 0x%llx\n", re_src->r_offset);continue;}- /* Get the location from the relocation entry */ offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
@@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int text_base, uintptr_t size, Elf32_Addr *offset_ptr_ram;
do {
unsigned int type = ELF32_R_TYPE(re_src->r_info);if (type != R_386_RELATIVE) {printf("%s: unsupported relocation type 0x%x ""at %p, ",__func__, type, re_src);printf("offset = 0x%x\n", re_src->r_offset);continue;}- /* Get the location from the relocation entry */ offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
Hi Heinrich, i just merged recent u-boot master into my devbranch and ran it on my board:
-- U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
CPU: x86, vendor AMD, device 5a2h DRAM: 119.6 MiB do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0, offset = 0x2000087 do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8, offset = 0x2000091 Bus 0: OK ---
now i get such relocation warnings, can you help me in this how to deal with that?
I'm starting u-boot as a payload from coreboot.
thanks!
cheers, Hannes
On 10/23/2018 11:13 AM, Hannes Schmelzer wrote:
On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. We should be warned if other relocation types appear in the relocation sections.
This type of message has helped to identify code overwriting a relocation section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
arch/x86/lib/relocate.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c index ed10755d9c..01e619d20b 100644 --- a/arch/x86/lib/relocate.c +++ b/arch/x86/lib/relocate.c @@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int text_base, uintptr_t size, Elf64_Addr *offset_ptr_ram; do { + unsigned long long type = ELF64_R_TYPE(re_src->r_info);
+ if (type != R_X86_64_RELATIVE) { + printf("%s: unsupported relocation type 0x%llx " + "at %p, ",__func__, type, re_src); + printf("offset = 0x%llx\n", re_src->r_offset); + continue; + }
/* Get the location from the relocation entry */ offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset; @@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int text_base, uintptr_t size, Elf32_Addr *offset_ptr_ram; do { + unsigned int type = ELF32_R_TYPE(re_src->r_info);
+ if (type != R_386_RELATIVE) { + printf("%s: unsupported relocation type 0x%x " + "at %p, ",__func__, type, re_src); + printf("offset = 0x%x\n", re_src->r_offset); + continue; + }
/* Get the location from the relocation entry */ offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
Hi Heinrich, i just merged recent u-boot master into my devbranch and ran it on my board:
-- U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
CPU: x86, vendor AMD, device 5a2h DRAM: 119.6 MiB do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0, offset = 0x2000087 do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8, offset = 0x2000091 Bus 0: OK
now i get such relocation warnings, can you help me in this how to deal with that?
I'm starting u-boot as a payload from coreboot.
thanks!
cheers, Hannes
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
On 10/24/2018 02:35 AM, Heinrich Schuchardt wrote:
On 10/23/2018 11:13 AM, Hannes Schmelzer wrote:
On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:
Currently we support only relocations of type ELF64_R_TYPE or ELF32_R_TYPE. We should be warned if other relocation types appear in the relocation sections.
This type of message has helped to identify code overwriting a relocation section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt xypron.glpk@gmx.de
arch/x86/lib/relocate.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c index ed10755d9c..01e619d20b 100644 --- a/arch/x86/lib/relocate.c +++ b/arch/x86/lib/relocate.c @@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int text_base, uintptr_t size, Elf64_Addr *offset_ptr_ram; do { + unsigned long long type = ELF64_R_TYPE(re_src->r_info);
+ if (type != R_X86_64_RELATIVE) { + printf("%s: unsupported relocation type 0x%llx " + "at %p, ",__func__, type, re_src); + printf("offset = 0x%llx\n", re_src->r_offset); + continue; + }
/* Get the location from the relocation entry */ offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset; @@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int text_base, uintptr_t size, Elf32_Addr *offset_ptr_ram; do { + unsigned int type = ELF32_R_TYPE(re_src->r_info);
+ if (type != R_386_RELATIVE) { + printf("%s: unsupported relocation type 0x%x " + "at %p, ",__func__, type, re_src); + printf("offset = 0x%x\n", re_src->r_offset); + continue; + }
/* Get the location from the relocation entry */ offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
Hi Heinrich, i just merged recent u-boot master into my devbranch and ran it on my board:
-- U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
CPU: x86, vendor AMD, device 5a2h DRAM: 119.6 MiB do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0, offset = 0x2000087 do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8, offset = 0x2000091 Bus 0: OK
now i get such relocation warnings, can you help me in this how to deal with that?
I'm starting u-boot as a payload from coreboot.
thanks!
cheers, Hannes
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
-------- schmelzerh@scm-ws10 /tmp $ qemu-system-i386 -bios coreboot.rom -serial stdio
coreboot-4.8-1857-g076ce2f-dirty Fri Oct 19 09:25:23 UTC 2018 romstage starting... CBMEM: IMD: root @ 07fff000 254 entries. IMD: root @ 07ffec00 62 entries. CBFS: 'Master Header Locator' located CBFS at [200:3ffc0) CBFS: Locating 'fallback/ramstage' CBFS: Found @ offset 3d40 size ad33 Decompressing stage fallback/ramstage @ 0x07fbcfc0 (128696 bytes) Loading module at 07fbd000 with entry 07fbd000. filesize: 0x15810 memsize: 0x1f678 Processing 1261 relocs. Offset value of 0x071bd000
coreboot-4.8-1857-g076ce2f-dirty Fri Oct 19 09:25:23 UTC 2018 ramstage starting... Enumerating buses... CPU_CLUSTER: 0 enabled DOMAIN: 0000 enabled QEMU: firmware config interface detected QEMU: max_cpus is 1 CPU: APIC: 00 enabled scan_bus: scanning of bus CPU_CLUSTER: 0 took 0 usecs PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/1237] enabled PCI: 00:01.0 [8086/7000] enabled PCI: 00:01.1 [8086/7010] enabled PCI: 00:01.3 [8086/7113] enabled PCI: 00:02.0 [1234/1111] enabled PCI: 00:03.0 [8086/100e] enabled scan_bus: scanning of bus PCI: 00:01.0 took 0 usecs scan_bus: scanning of bus PCI: 00:01.3 took 0 usecs scan_bus: scanning of bus DOMAIN: 0000 took 0 usecs scan_bus: scanning of bus Root Device took 0 usecs done found VGA at PCI: 00:02.0 Setting up VGA for PCI: 00:02.0 Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: 0000 Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Allocating resources... Reading resources... QEMU: 11 files in fw_cfg QEMU: etc/boot-fail-wait [size=4] QEMU: etc/smbios/smbios-tables [size=329] QEMU: etc/smbios/smbios-anchor [size=31] QEMU: etc/e820 [size=20] QEMU: genroms/kvmvapic.bin [size=9216] QEMU: etc/system-states [size=6] QEMU: etc/acpi/tables [size=131072] QEMU: etc/table-loader [size=4096] QEMU: etc/tpm/log [size=0] QEMU: etc/acpi/rsdp [size=36] QEMU: bootorder [size=0] QEMU: e820/ram: 0x00000000 +0x08000000 QEMU: reserve ioports 0x0510-0x0511 [firmware-config] QEMU: reserve ioports 0x5658-0x5658 [vmware-port] QEMU: reserve ioports 0xae00-0xae0f [pci-hotplug] QEMU: reserve ioports 0xaf00-0xaf1f [cpu-hotplug] QEMU: reserve ioports 0xafe0-0xafe3 [piix4-gpe0] Done reading resources. Setting resources... PCI: 00:01.1 20 <- [0x0000005840 - 0x000000584f] size 0x00000010 gran 0x04 io PCI: 00:02.0 10 <- [0x00fd000000 - 0x00fdffffff] size 0x01000000 gran 0x18 prefmem PCI: 00:02.0 18 <- [0x00fe070000 - 0x00fe070fff] size 0x00001000 gran 0x0c mem PCI: 00:02.0 30 <- [0x00fe060000 - 0x00fe06ffff] size 0x00010000 gran 0x10 romem PCI: 00:03.0 10 <- [0x00fe040000 - 0x00fe05ffff] size 0x00020000 gran 0x11 mem PCI: 00:03.0 14 <- [0x0000005800 - 0x000000583f] size 0x00000040 gran 0x06 io PCI: 00:03.0 30 <- [0x00fe000000 - 0x00fe03ffff] size 0x00040000 gran 0x12 romem Done setting resources. Done allocating resources. Enabling resources... PCI: 00:00.0 cmd <- 00 PCI: 00:01.0 cmd <- 00 PCI: 00:01.1 cmd <- 01 PCI: 00:01.3 cmd <- 00 PCI: 00:02.0 cmd <- 03 PCI: 00:03.0 cmd <- 03 done. Initializing devices... Root Device init ... CPU_CLUSTER: 0 init ... Initializing CPU #0 CPU: vendor Intel device 663 CPU: family 06, model 06, stepping 03 Setting up local APIC... apic_id: 0x00 done. CPU #0 initialized PCI: 00:00.0 init ... Assigning IRQ 10 to 0:1.3 Assigning IRQ 11 to 0:3.0 PCI: 00:01.0 init ... RTC Init PCI: 00:01.1 init ... IDE: Primary IDE interface: on IDE: Secondary IDE interface: on IDE: Access to legacy IDE ports: off PCI: 00:02.0 init ... PCI: 00:03.0 init ... Devices initialized Finalize devices... Devices finalized Copying Interrupt Routing Table to 0x000f0000... done. Copying Interrupt Routing Table to 0x07fb3000... done. PIRQ table: 128 bytes. QEMU: found ACPI tables in fw_cfg. QEMU: loading "etc/acpi/rsdp" to 0x7f8f000 (len 36) QEMU: loading "etc/acpi/tables" to 0x7f8f040 (len 131072) QEMU: loaded ACPI tables from fw_cfg. ACPI tables: 131136 bytes. smbios_write_tables: 07f8e000 DOMAIN: 0000 (QEMU Northbridge i440fx) QEMU: found smbios tables in fw_cfg (len 329). QEMU: coreboot type0 table found at 0x7f8e020. QEMU: loading smbios tables to 0x7f8e065 SMBIOS tables: 430 bytes. Writing table forward entry at 0x00000500 Wrote coreboot table at: 00000500, 0x10 bytes, checksum b7e3 Writing coreboot table at 0x07fb4000 0. 0000000000000000-0000000000000fff: CONFIGURATION TABLES 1. 0000000000001000-000000000009ffff: RAM 2. 00000000000c0000-0000000007f8dfff: RAM 3. 0000000007f8e000-0000000007fbcfff: CONFIGURATION TABLES 4. 0000000007fbd000-0000000007fdcfff: RAMSTAGE 5. 0000000007fdd000-0000000007ffffff: CONFIGURATION TABLES 6. 00000000ff800000-00000000ffffffff: RESERVED CBFS: 'Master Header Locator' located CBFS at [200:3ffc0) FMAP: Found "FLASH" version 1.1 at 0. FMAP: base = fffc0000 size = 40000 #areas = 3 Wrote coreboot table at: 07fb4000, 0x264 bytes, checksum 8587 coreboot table: 636 bytes. IMD ROOT 0. 07fff000 00001000 IMD SMALL 1. 07ffe000 00001000 CONSOLE 2. 07fde000 00020000 TIME STAMP 3. 07fdd000 00000910 RAMSTAGE 4. 07fbc000 00021000 COREBOOT 5. 07fb4000 00008000 IRQ TABLE 6. 07fb3000 00001000 ACPI 7. 07f8f000 00024000 SMBIOS 8. 07f8e000 00000800 IMD small region: IMD ROOT 0. 07ffec00 00000400 CAR GLOBALS 1. 07ffe9c0 00000240 COREBOOTFWD 2. 07ffe980 00000028 CBFS: 'Master Header Locator' located CBFS at [200:3ffc0) CBFS: Locating 'fallback/payload' CBFS: Found @ offset 10080 size 21842 Loading segment from ROM address 0xfffd02b8 code (compression=1) New segment dstaddr 0x02000000 memsize 0x4d3e0 srcaddr 0xfffd02f0 filesize 0x2180a Loading Segment: addr: 0x02000000 memsz: 0x000000000004d3e0 filesz: 0x000000000002180a using LZMA Loading segment from ROM address 0xfffd02d4 Entry Point 0x02000020 Jumping to boot code at 02000020(07fb4000)
U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
CPU: x86, vendor Intel, device 663h DRAM: 127.4 MiB do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0, offset = 0x2000087 do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8, offset = 0x2000091 Bus 0: OK Device 0: not available Loading Environment from FAT... Divide Error -----------
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
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-------
Best regards
Heinrich
Hi Heinrich,
On Thu, Oct 25, 2018 at 2:25 PM Heinrich Schuchardt xypron.glpk@gmx.de 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_uninitfff00090: 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
Hi Heinrich,
On Thu, Oct 25, 2018 at 5:48 AM Heinrich Schuchardt xypron.glpk@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
participants (3)
-
Bin Meng -
Hannes Schmelzer -
Heinrich Schuchardt