et-tommythorn
commented
5 months ago Your chance appears pretty significant and changes the existing behavior of Dromajo as far as I can tell, but I might not follow it completely. Two things that jumped out: you changed in back to execute a single cycle in dromajo which makes it hopelessly slow for interactive usage and this should only be needed for cosimulation. Why did you need this?
Secondly, BOOT_BASE_ADDR was changed to 0x00010040. I'm confused about how that wouldn't break all existing images. It's possibly we need to add more flexibility to Dromajo, but for ET it has to be able to mimic the hardware and it uses a reset vector of 0x100000.
The method of booting the system from multiple boot ROM files, as implemented in PR #76, is not the most elegant solution.
For instance, when the system only has a single boot memory, which is usually the case, it becomes challenging to place multiple generated files into that single memory space without resorting to messy workarounds.
The proposed solution is to create a single boot code file that will be divided into N sections, where N is the number of cores. Each core will generate its own recovery code and write it to its designated section. In addition to the recovery code, each core will initiate with a preamble code that reads the hart_id and calculates the PC based on that ID.
I started implementing this, please let me know if you have any suggestions or concerns.