Re: [U-Boot-Users] [DNX#2006101042000015] [PATCH] load_elf_image() uses progr [...]

Hello list,
inside the automatic U-Boot patch tracking system a new ticket [DNX#2006101042000015] was created:
<snip>
Hi all,
I have just tested the patch to boot qnx on a ppc target with the bootelf command. Basically this patch seems to work, if there is no overlapping. Here you see an u-boot log, showing the overlapping case:
=> tftp 50000 /qnx/6.3/esd/ppcbe/boot/fs/cpci405net.ifs ENET Speed is 100 Mbps - FULL duplex connection Using ppc_4xx_eth0 device TFTP from server 10.0.0.190; our IP address is 10.0.17.112 Filename '/qnx/6.3/esd/ppcbe/boot/fs/cpci405net.ifs'. Load address: 0x50000 Loading: #################################################################
################################################################# ##################################################### done Bytes transferred = 933492 (e3e74 hex) => bootelf 50000 ## Attemping to load ELF image at 0x00050000 ## Extracting (1) program headers at offset 0x00000034 (32 bytes) ## WARNING: VADDR WITHIN ELF HEADER MEMORY SPACE. ## ATTEMPTING TO MOVE ELF IMAGE. ## -> shdr=0x000500a4 ## -> position=0x00113e75 (vaddr+memsz) ----------------??????????----Why is the new position misaligned.---
## -> size=0x00000055 (shdr[84]->offs+sz=1+fd140440) ------------??????????----------------------????????---This values look strange.---
## Retrying load_elf_image(0x00113e75) ## Attemping to load ELF image at 0x00113e75 ## Extracting (1) program headers at offset 0x00000034 (32 bytes) -> TYPE:LOAD program header. Attempting to allocate memory. -> Moving program section 0 from 0x00113ff5 to 0x00030180 (933108 bytes) ## Returning entry point at address 0x00032ab0 ## Starting application at 0x00032ab0 ... NIP: 00032AB4 XER: 20000000 LR: 03F9D800 REGS: 03f6a348 TRAP: 0700 DAR: 03FBE1BC MSR: 00029000 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 00
GPR00: 03F9D7E0 03F6A438 40000000 00000001 03F6A664 00000001 00000001 00D4BD18 GPR08: 03F94E24 07F24D41 2FADCF87 00000003 2BA7DEF3 03F63E3F 03FBD800 03FCB000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 GPR24: 00000000 00000000 00000002 00000000 03F6A660 03F6A74C 03FBE418 00032AB0 ** Illegal Instruction ** Call backtrace: Program Check Exception
Here you see the objdump info of the qnx boot image:
...$ ntoppc-objdump -x cpci405net.ifs
cpci405net.ifs: file format elf32-powerpc cpci405net.ifs architecture: powerpc:common, flags 0x00000102: EXEC_P, D_PAGED start address 0x00032ab0
Program Header: LOAD off 0x00000180 vaddr 0x00030180 paddr 0x00030180 align 2**8 filesz 0x000e3cf4 memsz 0x000e3cf4 flags rwx
Sections: Idx Name Size VMA LMA File off Algn 0 000e3cf4 00030180 00030180 00000180 2**8 CONTENTS, ALLOC, LOAD, CODE ntoppc-objdump: cpci405net.ifs: no symbols
Look at the above ??????? marks.
-Michael
Wood, Jarrod Jay schrieb:
I have modified the common/cmd_elf.c:load_elf_image function to support loading ELF images via reading the program headers instead of the section headers, which according to the TIS ELF v1.2 standard is the correct method. This was modified due to errors loading various ELF images such as the INTEGRITY RTOS. In addition, the current version also does not check to see if the ELF headers will be overwritten when the program sections are extracted, resulting in a machine check when reading the next section. The modified version moves the ELF image out of the way.
CHANGELOG:
- Modified common/cmd_elf.c:load_elf_image() to use program headers
instead of section headers to match TIS ELF v1.2 specification. The function also will detect and report if the ELF image will be
</snip>
Your U-Boot support team
participants (1)
-
DENX Support System