[U-Boot] Linker script u-boot.lds makes u-boot ELF not load with debugger
Hi,
I'm loading U-Boot to an i.MX6Q platform using ARM DSTREAM debugger and after running the DDR initialization script it fails to load the u-boot ELF binary complaining with:
loadfile "/home/hpalacio/git/u-boot-denx/u-boot" ERROR(CMD16-TAD11-NAL18): ! Failed to load "u-boot" ! Failed to write 160 bytes to address S:0x00010034 ! Bus error on memory operation. Target Message: Memory access caused precise abort. Debug Precise Abort Registers : DFSR = 0x00001808, DFAR = 0x00010034
If I revert the changes introduced to arch/arm/cpu/u-boot.lds in commit 47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7, then the u-boot ELF loads fine:
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds index 7336162d804f..cf5cc327a42b 100644 --- a/arch/arm/cpu/u-boot.lds +++ b/arch/arm/cpu/u-boot.lds @@ -127,14 +127,12 @@ SECTIONS KEEP(*(.__bss_end)); }
- .dynsym _image_binary_end : { *(.dynsym) } - .dynbss : { *(.dynbss) } - .dynstr : { *(.dynstr*) } - .dynamic : { *(.dynamic*) } - .plt : { *(.plt*) } - .interp : { *(.interp*) } - .gnu.hash : { *(.gnu.hash) } - .gnu : { *(.gnu*) } - .ARM.exidx : { *(.ARM.exidx*) } - .gnu.linkonce.armexidx : { *(.gnu.linkonce.armexidx.*) } + /DISCARD/ : { *(.dynsym) } + /DISCARD/ : { *(.dynstr*) } + /DISCARD/ : { *(.dynamic*) } + /DISCARD/ : { *(.plt*) } + /DISCARD/ : { *(.interp*) } + /DISCARD/ : { *(.gnu*) } + /DISCARD/ : { *(.ARM.exidx*) } + /DISCARD/ : { *(.gnu.linkonce.armexidx.*) } }
Does anybody know if I should do anything special in my debugger initialization script after commit 47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7 to have it load U-Boot normally?
Thank you. -- Héctor Palacios
Hi Héctor,
On Wed, May 18, 2016 at 1:28 PM, Palacios, Hector Hector.Palacios@digi.com wrote:
I'm loading U-Boot to an i.MX6Q platform using ARM DSTREAM debugger and after running the DDR initialization script it fails to load the u-boot ELF binary complaining with:
loadfile "/home/hpalacio/git/u-boot-denx/u-boot" ERROR(CMD16-TAD11-NAL18): ! Failed to load "u-boot" ! Failed to write 160 bytes to address S:0x00010034 ! Bus error on memory operation. Target Message: Memory access caused precise abort. Debug Precise Abort Registers : DFSR = 0x00001808, DFAR = 0x00010034
If I revert the changes introduced to arch/arm/cpu/u-boot.lds in commit 47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7, then the u-boot ELF loads fine:
[...]
Does anybody know if I should do anything special in my debugger initialization script after commit 47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7 to have it load U-Boot normally?
As explained in the commit message (http://git.denx.de/?p=u-boot.git;a=commitdiff;h=47ed5dd031d7d2c587e6afd386e7...), this change was required in order to make diagnostic tools such as readelf or objdump produce thorough output. A consequence is that some generated ELF files now have some program headers (see https://sourceware.org/binutils/docs/ld/PHDRS.html#PHDRS) that are incompatible with debuggers such as yours because they order these tools to write to non-writable addresses.
One solution is to program with the debugger u-boot.bin or another binary objcopied from the original ELF file.
Another solution is not to use any debugger to copy the image to the target RAM, but instead to program u-boot.imx to the boot device (NAND, SD, etc.), in which case you have to instruct the debugger to halt execution after reset. You will then even be able to see the ROM bootloader load and boot the binary image from the boot device. However, this solution may be a bit less convenient for frequent target programming.
In the longer term, it would be possible to check the current ELF program headers in order to fix the linker scripts for this use case, but doing this in a scalable way for all the targets might prove difficult and maybe not worth it. I think that being able to program a binary file with debuggers is sufficient. Albert, what do you think?
Best regards, Benoît
participants (2)
-
Benoît Thébaudeau -
Palacios, Hector