Future directions

[et-tommythorn]

I'm opening up a discussion here an the future of Dromajo. There are a number of pain-points that will take some non-trivial changes to address. In no particular order:

• Lack of modularity (there's a desire to build alternative execution models, but we can't pull out pieces without a rewrite)
• Ad-hoc and redundancy of command-line args and configuration file. This is a big mess and it's especially suffering with the incremental contribution that adds to this. One possible option is to generalize the configuration file, making it proper JSON, allowing multiple, and making all(?) command line arguments behave as miniature JSON files (eg. --foobar=baz would be interpreted as { "foobar": "baz" }.
• Improve performance. There are many low-hanging opportunities for speeding up the simulation, but any work on this is pending a structural clean-up
• The future of C/C++. Definitely a contentious issue, but I (Tommy) am no fan of C++, but the modularity isn't easily achieved with C. I think Dromajo could be vastly cleaner if ported to/reimplemented in Rust.

[et-tommythorn]

Related, there's a common request to parse a given device tree, rather than create it. It really seems to reflect the different usage models; software uses just want to provide a few images (say, opensbi, kernel, and rootfs) whereas cosimulation wants to use the exact configuration that the DUT uses.

Some open questions in this regard:

• How feasible is it to configure Dromajo based on a device tree? Obviously we can't support all configuration, but even constrained it's not clear what issues we'll run into.
• Can a device tree replace the configuration file? Some parameters have no parallel in the device tree, but that might not be a problem (though, do we need to hide stuff from the booted image?). A bigger issue might be that device trees aren't as easy to write as a "simple" JSON config file.
• Where do we load the device tree? What if more than one is provided?

[renau]

If we do the DTB, the repo should have a couple of working ones and the boot.cfg/cmd-line to require to point to it.

It will reduce some of the options that we have (these are redundant with the DTB)

      --memory_size sets the memory size in MiB (default 256 MiB)
      --memory_addr sets the memory start address (default 0x10000)
      --mmio_range START:END [START,END) mmio range for cosim (overridden by config file)
      --plic START:SIZE set PLIC start address and size in B (defaults to 0x10000000:0x2000000)
      --clint START:SIZE set CLINT start address and size in B (defaults to 0x2000000:0xc0000)

If we do fdt, we may want to document a bit how to patch/dump with the fdtdump/fdtget/....

[et-tommythorn]

Indeed, we have loads of redundancies. We could still allow command-line overwrites, but I'd suggest that (like what I suggested for JSON), we make --foo.bar=value translate into a singleton FDT something like

/dts-v1/;

/ {
     foo { bar = <value>; };
  };

Example: --chosen.bootargs=\"root=/dev/ram rw ...\".

I'll look at adding a fdt parser (lots around).

[renau]

A similar pattern in command line and conf would be nice. Even a simpler -c foo.bar="root...." would be neat