[U-Boot] [PATCH v3 2/2] MIPS: Stop building position independent code

[Paul Burton]

On Monday, 31 July 2017 03:52:57 PDT Daniel Schwierzeck wrote:
> 2017-07-30 18:04 GMT+02:00 Álvaro Fernández Rojas <noltari at gmail.com>:
> > El 30/07/2017 a las 16:05, Daniel Schwierzeck escribió:
> >> Am 30.07.2017 um 14:27 schrieb Álvaro Fernández Rojas:
> >>> I've been a bit busy lately and I couldn't test this until now, but I
> >>> have to say that this commit breaks u-boot bmips support :(
> >>> 
> >>> BTW, I tried this on several bmips boards (one of them is a Netgear
> >>> CG3100D, which uses u-boot.bin instead of u-boot.elf)
> >>> 
> >>> Do you have any idea on what could be hapenning?
> >> 
> >> maybe you need to specify "--emit-relocs" too when linking u-boot.elf
> >> from u-boot-elf.o. But u-boot-elf.o should already contain the correct
> >> .reloc section with the updated relocation entries so you don't need to
> >> rerun the reloc-tool on u-boot.elf.
> > 
> > I tried that and it doesn't work.
> > However, I've just found out that if I remove the relocs call it boots
> > again... https://gist.github.com/Noltari/ce3a6a9dda69e74caf7ba33c9c8ade9a
> 
> I wonder how this can work. Even the u-boot.elf now contains
> position-dependent code so that an update of the relocation entries is
> required there too. Without the updated entries, U-Boot can't execute
> after jumping from relocate_code() to board_init_r(). Did you use a
> clean build if U-Boot?

Indeed - without the .rel section being generated by the mips-relocs tool I'd 
expect relocate_code() to either apply some bogus relocations or none at all 
(depending what's in the memory starting from __rel_start) and then, if it 
gets there at all, for the "relocated" U-Boot to fall over pretty quickly.

Fernandez - I don't suppose you're aware of an emulated version of any of the 
supported bmips systems? That would be an easy way for me to take a look. FYI 
the systems I use most (Boston & Malta) also use u-boot.bin or derivatives 
thereof & I'm sure the .rel section is copied across to it, so I doubt it has 
anything to do with binary formats.

Thanks,
    Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20170731/31682bc0/attachment.sig>