Am Montag, den 22.02.2021, 20:56 +0100 schrieb Reinoud Zandijk:
Hi Daniel,
On Mon, Feb 22, 2021 at 07:23:26PM +0100, Daniel Schwierzeck wrote:
Am Montag, den 22.02.2021, 18:05 +0100 schrieb Reinoud Zandijk:
Patch 0001 re-enables FDT inclusion into the u-boot binary to make them boot again. The code might not have adjusted well enough in the past to handle the separate one.
what exactly is the issue? Do you see it just on real hardware?
Booting all Malta variants in Qemu is contained in official U-Boot CI and showed no boot failures until now. Unfortuneately I don't have Malta hardware myself for testing.
If I remove it, the machine just spins in Qemu, no output, nothing. If I add it, it works fine again. I found out by bisecting. I have no idea why the tests aren't picking this up. Could it be a qemu/gcc/binutils combination issue? A symbol not set as expected?
qemu 5.1.0 gcc 8.3.0 binutils 2.32
which board config did you try exactly? malta or maltael?
For maltael and malta64el an extra U-Boot binary named u-boot-swap.bin is generated which is booted with Qemu. See also [1] respectively all conf.malta*_qemu configs for working Qemu configurations for all Malta variants.
The reason for that extra image is that the original MIPS YAMON loader builds a combined EB/EL image and links it to EB. With some assembly magic the start code determines immediately after the reset vector which endianess the CPU is running and branches to the according EB or LE image. This is replicated in the Qemu Malta machine implementation. The Malta EL machine code excepts a bootloader in EB format and swaps the code back to EL before executing it. To workaround this, we need to feed this u-boot-swap.bin to Qemu.
[1] https://gitlab.denx.de/u-boot/u-boot-test-hooks/-blob/master/bin/travis-ci/c...