[U-Boot] Linker script u-boot.lds makes u-boot ELF not load with debugger

[Benoît Thébaudeau]

Hi Héctor,

On Wed, May 18, 2016 at 1:28 PM, Palacios, Hector
<Hector.Palacios at 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=47ed5dd031d7d2c587e6afd386e79ccec1a1b7f7),
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