occamy: Update register interface and peripherals

[paulsc96]

This PR

• Updates register_interface and therefore our fork of the regtool.py generator and regenerates existing regfiles.
• Updates and appropriately repatches the OpenTitan peripherals we use, most notably adding a non-stubbed SPI.
• Replaces the non-16550-conform OpenTitan UART with an existing SV port of the 16550-conform VHDL pulp_platform/apb_uart as used in CVA6.

So far, only basic issues have been ruled out; Occamy compiles and simulates. It will be ready to merge once:

• All peripherals needed to boot have been verified to work in a bare-metal Occamy boot ROM:
  • UART
  • SPI
  • I2C
• The Occamy device tree was updated with the new UART
• The PLIC and new driver-compliant UART have been shown to work with Linux in Occamy FPGA simulation (@niwis) (delegated to occamy: FPGA Linux boot hangs on init process #251).

[niwis]

The good news: the UART seems to be working! 🎉
The bad news: Linux does not boot anymore. This is the last output:

[   37.982674] Freeing unused kernel memory: 7928K
[   37.993771] This architecture does not have kernel memory protection.
[   38.009054] Run /init as init process
[   48.006306] random: dd: uninitialized urandom read (512 bytes read)
[  261.893203] random: crng init done

After that, Linux eventually loops in kernel space. To me, it looks like busybox is for some reason not able to access the console. This can be a SW issue (the Linux image is unchanged, though), or it could be related to some of the HW changes. The ILA suggests that busybox init is correctly called and executed, but the control path quickly becomes untracable.

Regarding next debugging steps: follow this busybox FAQ: https://busybox.net/FAQ.html#init
If hello world does not print, we should be able to pinpoint the issue using gdb / the ILA.

[paulsc96]

Since the updated regtool and peripherals are blocking a number of things, we will fast-track this PR and address the init issue (#251) in another PR.