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@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