iansjack wrote:
I'm sure that you are correct. However, the fact is that the OP's system runs fine if you use the .elf kernel, but not if you use the stripped binary (that's with version 3.0.1 of qemu). It would be extremely helpful if you could point out to the OP why that could be the case.
Right. The
qemu code uses a fixed load address (FIRMWARE_ADDR_3) which should not be modified by the elf segments (see the explicit line "binfo.entry = firmware_addr;" after the "load_image_targphys" call). But if it works as an elf (strange), I'd guess it is very likely that OP is not linking the kernel to the correct address?
I'll test it too in the weekend with qemu 3.0.1 and with the latest version, just to be sure. There's a slim chance something changed in qemu internals (namely inside load_image_targphys or arm_load_kernel) which may cause trouble since I implemented the raspi3 support in qemu 2.12.
iansjack wrote:
In the meantime, the pragmatic approach for the OP to progress with his work is to miss out the unnecessary step of stripping the .elf kernel to produce a raw binary.
I understand what you wrote, and there's reason in the pragmatic approach I admit. But I disagree, since the real hardware boots a raw binary I don't think that's an unnecessary step. Emulator oddities or not, if the OP ever wants to run their code on a real hw, they will need a raw binary anyway. Therefore I think the correct approach would be to take a known-to-be-working raw binary example and start from there (imho).
EDIT: oh, there it is:
https://github.com/aaronjanse/rpi-os/blob/master/linker.ld#L5Code:
. = 0x8000;
/* For AArch64, use . = 0x80000; */
Clearly a bad linking address as I suspected. Should be
Code:
/* . = 0x8000; */
. = 0x80000;
Lesson to be learned: don't copy'n'paste blindly everything, read the comments at least
Cheers,
bzt