Device tree

[christiaanb]

As we can read on https://www.devicetree.org/

The devicetree is a data structure for describing hardware. Rather than hard coding every detail of a device into an operating system, many aspects of the hardware can be described in a data structure that is passed to the operating system at boot time.

I think we shouldn't re-invent the wheel, and just repurpose devicetree to describe our memory-mapped registers.
I envision a couple of aspects:

1. Some TemplateHaskell code to generate a memory-mapper configuration from a device tree
2. We have a rom containing the serialized device tree, this rom is memory-mapped to a sensible place.
3. We have firmware code that reads this rom
4. We have firmware code that interprets this as a device tree (e.g. using https://crates.io/crates/device_tree)
5. We have the firmware use the device tree to know where all our memory-mapped registers live.
6. Some simulation code to interpret special "simulation-only" registers such as the character device

This way we don't have to create different firmwares for different configurations. Even before we have the memory-mapper live in hardware, we can already start on this issue to make the location of the character device configurable.

[hydrolarus]

Regarding point number 1, to generate a memory-mapper configuration, the configuration needs to be loaded into a (TemplateHaskell) program. There are no Haskell packages to read device tree files from what I can tell, which opens up the question on how this case should be handled:

1. create a package to read flattened devicetrees in Haskell
2. use a configuration file that is in a different format (TOML,JSON,...) which is then used to generate both the memory map and the final device tree configuration

I think 1. would be a lot of work and we really only are interested in a few key numbers, so 2. seems like the better choice. With 2. we add another configuration layer on top and move the "source of truth" to a different file.

To me it seems like 2. is less work and allows us to get started quicker, also we wouldn't have to maintain a package to read FDTs which are way overkill for this use case.

[martijnbastiaan]

I agree with that assessment. (2) seems like the way to go. We should pick either TOML or YAML; JSON always ends up being a pain due to it not supporting comments and multi-line strings.

[martijnbastiaan]

#67 mentions it partially implements this issue. What's still missing @cuddlefishie?

[hydrolarus]

Creating and reading the device tree works already, I think I wrote that it's a partial implementation to this issue because of the point 2. in my comment above! There is no central configuration file anywhere at the moment that configures both the hardware and the device tree, they have to be kept in sync manually at the moment

[kleinreact]

#315 offers direct access to property values of a device tree specification in Haskell via TH. This should be sufficient to resolve this issue.

[martijnbastiaan]

Superseded by #481.