Synchronous Exception at mmio_write()

[schkwve]

Hi, I've stumbled across an issue when building upon the 3rd part. Immediately after the kernel is loaded in the higher half (at 0xffffffff80000000), I enable UART with mmio_write(UART_ENABLE, 1);. However, instead of completing the UART initialization function and outputting "Hello World", I get a Synchronous Exception at the address of mmio_write().

To better fit my coding style, I replaced the integer types as follows:

void mmio_write(uint32_t reg, uint8_t val)
{
    *(volatile uint8_t *)reg = val;
}

I'm using the Limine bootloader to boot my kernel with the UEFI firmware easily.

Do you have any idea what could be wrong? Here's the linker file I use.

[babbleberry]

Hi,

Without seeing the full code and dump it would be hard to debug for you.

Have you gone into the detail suggested, for example, here: https://stackoverflow.com/questions/71588569/uefi-arm64-synchronous-exception/75816557#75816557

Disassembling and understanding what's really happening when that call is made is key.

I have no experience (yet) of that bootloader you're using, or indeed loading the kernel high as you are. I wonder if this has something to do with it? I'm not convinced though.

Let me know how you get on. Or if you're still running into a brick wall, share some more info and I'll try to be more helpful!

All the best, Adam

[schkwve]

Here is the code. The main file, kernel.c, is located in /krnl.

The code at fault is exactly here.

Perhaps the issue might be in the use of the QEMU emulator instead of a real Raspberry Pi 4. As QEMU doesn't yet have the RPi4 machine target (latest one is RPi3b), it might be because the "wiring" is different in the virt machine target (which is regarded to as the closest to RPi4).

I'll try to fork QEMU and create a RPi4 machine target, seeing what I can do further.

[babbleberry]

Ah - QEMU may well be the problem. I know the peripheral addresses changed between the Pi3 and Pi4, for example. It's likely an unhelpful suggestion but I would definitely test on real hardware...

FWIW - none of this series is tested with QEMU, all on the hardware itself.

[schkwve]

Well it seems that QEMU indeed is the problem. I'm closing this issue as there's probably nothing more to discuss here.