Maximum core count greater than 8?

## Background

I am working to emulate/simulate RISC-V systems (using multiple tools) with more than 8 cores and booting SMP Linux with the OpenSBI bootloader. I currently have a setup that works with both Dromajo and QEMU (v6.1.0) to boot OpenSBI v0.9 with Linux Kernel v5.9 and a simple Buildroot/Busybox filesystem. This system successfully boots in Dromajo with up to 8 cores, but fails at higher core counts due to the hard-coded core count limit of 8 in Dromajo (https://github.com/chipsalliance/dromajo/blob/3675ba09996dbe24286af45a969443a0ee3cfe6e/include/riscv_machine.h#L51).

I attempted to modify the source code and increase this limit, say to 32, but running with anything more than 8 cores results in either an error (e.g, with 9 cores: riscv_cpu_read_memory: invalid physical address 0x0000000000011000) or a segmentation fault of Dromajo itself. One potential conclusion is that the Dromajo generated device tree is invalid for core counts > 8 and it isn't allocating a large enough memory range for some device.

## Questions
What is the motivation for limiting Dromajo to simulating 8 cores maximum and what are the constraints or requirements for increasing the maximum core count?

Are there any short-term workarounds for running with > 8 cores (e.g., if this is indeed a device tree issue and it is possible to provide a custom device tree)?

## Branch/Commit

master at 3675ba09996dbe24286af45a969443a0ee3cfe6e

## Misc

Note that unmodified QEMU v6.1.0 has a similar hard-coded core limit for the riscv64-virt machine, but increasing this limit and rebuilding QEMU seems to cause no problems.

Start with include/riscv_machine.h at the hard-coded core-count limit, then trace how Dromajo generates its device tree and allocates ranges for additional cores. Reproduce the reported failure with 9 cores using the stated OpenSBI, Linux, and Buildroot/Busybox setup, and compare it with the working QEMU configuration. Done means identifying the constraints and documenting a viable path or workaround for more than 8 cores.

Written by the indexing model from the issue text.