Move cpu reboot addr register to separate platform independent object

[TomKeddie]

I'm not sure this has any purpose so I'm suggesting we remove it.

[xobs]

The "addr" register is used to allow you to change the reset address of the CPU.

For example, when debugging an .ELF file using the VexRiscv debug channel, the first thing openocd does is reset the CPU. If we didn't adjust the reset address, it would jump back to address 0, and the user would start to debug the bootloader.

By adjusting the CPU reset address prior to jumping to the user's code, this behavior works as expected.

A comment to this effect might be helpful, since it's not the most obvious of reasons. But we definitely should leave it in.

[TomKeddie]

Thanks, how about this? I want to separate the chip specific stuff from the common stuff.

[xobs]

That works, and is much nicer asthetically!

The downside I see now is that with this patch, the addresses have suddenly changed and now new software is no longer compatible with the RISC-V CPUs that are in the wild.

Maybe this is a good case for adding a jump table for drivers at a known-good offset that can give us platform independence.

[TomKeddie]

I think you're suggesting we designate a set of per platform software drivers to abstract the hardware and access them through a jump table or swi mechanism? Sounds do-able.

I've realised I've missed the point a little, that fomu is presented to its customers as a update to tomu, as both a cpu platform and a fpga platform. So yes, it would seem like we need to better define the cpu platform if we want both platform independence and binary api backward compatibility.

[xobs]

I was having a chat with @mithro, and the idea came up to use a thunked syscall interface.

The idea being that you'd have a function at a well-known address, or an address defined in a LiteX CSR, or an address defined in a RISC-V MSR, that has a function signature such as:

int syscall(uint32_t family, uint32_t syscall, uint32_t arg1, void *arg2);

...or similar. Maybe the params would be different. But we'd define family and syscall as enum pairs. For example, "reboot" might be in the "system" family. Using 32-bit IFF-style tags, such a call might be:

syscall('syst', 'boot', 0x20040000, NULL);

Because the boot ROM is currently always memory-mapped, we could fix it at address 0x100, so any machine-level program could cast that value to a function pointer and make syscalls.

Then, as part of the BIOS for various platforms, you'd implement syscall:

__attribute__((section(".text.syscall")))
int syscall(uint32_t family, uint32_t call, uint32_t arg1, void *arg2) {
    switch (family) {
        case 'syst':
            return do_syst(call, arg1, arg2);
        default:
            return -EIMPL;
    }
}

static int do_syst(uint32_t call, uint32_t arg1, void *arg2) {
    switch (family) {
        case 'boot':
            return do_reboot(arg1);
        default:
            return -EIMPL;
    }
}

[TomKeddie]

Moving the conversation to #9 perhaps this PR should move to a new platform branch so we can prepare and deliver this cleanly?