Emit htif node in device tree

[a0u]

Related issue: firesim/FireMarshal#152

Type of change: other enhancement

Impact: rtl change

This inserts an htif node into the boot ROM devicetree, which avoids the need for certain firmware hacks:

htif {
        compatible = "ucb,htif0";
};

In FireSim, this is required to convince OpenSBI to register the HTIF-based reset handler for graceful poweroff. It also eliminates a hardcoded fix in bbl for the same purpose: firesim/riscv-pk@bbae01a.

The change applies unconditionally to all Chipyard designs. Although possibly undesirable for chips that are intended to run untethered, I believe it is largely safe in practice:

• Currently all simulation infrastructure provides fesvr.
• SBI implementations generally prioritize real devices above HTIF if both are advertised in the FDT. For example, both bbl and OpenSBI will bind the SiFive serial driver if it detects the UART and ignore the HTIF console driver. OpenSBI can also support more specialized platform definitions that omit HTIF capability.
• Linux does not care about this.

I am open to suggestions if there is a better place to implement this than Subsystem.

Release Notes

[a0u]

This is expected to slightly conflict with #605.

[colinschmidt]

Are there any requirements on the configuration for it to support HTIF? Presumably if we built a chipyard config with no front ports of any kind(no tsi, no dmi, no jtag, etc.) htif wouldn't be supported.
I'm not sure its worth figuring this out but it might be worth writing it down somewhere given an external user might stumble across this.

[a0u]

We can check for inheritance of the associated traits with a match statement. I'm fine with restricting this to configurations with a known TSI or debug module. Hypothetically, HTIF could also be implemented without a front bus client by mapping tohost/fromhost to uncached memory and using a non-coherent DMA engine outside of the System level.

Baking HTIF in the device tree (like embedding kernel boot arguments) is itself a bit of a kludge since it is more a property of the simulation/software environment than the hardware. But without some way to inject a runtime DTB at the bootrom stage, this is the simpler approach.