Devicetree RFC

[RobertZ2011]

No description provided.

[asasine]

We often multi-source parts for the same functionality but with the same binary. Differentiating between the two parts is only possible once the binary starts and hardware markers are read from the board. The hardware driver may differ between the peripherals. How does this proposal handle a scenario like this?

[RobertZ2011]

We often multi-source parts for the same functionality but with the same binary. Differentiating between the two parts is only possible once the binary starts and hardware markers are read from the board. The hardware driver may differ between the peripherals. How does this proposal handle a scenario like this?

Great question! The simplest way would be to define everything in the devicetree and then only use certain devices at runtime. So something like

let Devicetree { sensor, sensor_alt } = devicetree::devicetree();

match sensor_config {
    SensorType::Regular => start_task(sensor),
    SensorType::Alt => start_task(sensor_alt)
}

I worked on a Zephyr-based project and this is essentially how we handled the situation: everything in the devicetree was being instantiated but only the active devices were ever used in code. The unused devices still took up space in RAM, but the increase in usage wasn't significant. With Rust we can probably do better since we can drop the unused one, while everything had to be defined as static when using Zephyr.

[rogurr]

Do you know of any open-source projects that use device tree for the entire platform?

For instance, a platform uses a UART between the EC and SOC. Speed/handshake info is needed in the EC, UEFI, and OS environments so worst case scenario is it is duplicated in 3 places.

There are ways to help keep things in sync, but I'd like to investigate how feasible it is using a single reference for all config top to bottom.

[JamesHuard]

Will ODP crates still be compatible with projects that do not leverage a device tree for initialization?

[JamesHuard]

Is the only thing we're trying to improve here board_init/setup phase? Or is this planning to scale into other things like driver APIs, service interfaces, etc.?

[RobertZ2011]

Correct, the only real restriction on APIs would be that traits for things like I2C busses, GPIOs, etc have to be shared by everything. The proof-of-concept uses traits from embedded-hal for broad compatibility.

[RobertZ2011]

Do you know of any open-source projects that use device tree for the entire platform?

For instance, a platform uses a UART between the EC and SOC. Speed/handshake info is needed in the EC, UEFI, and OS environments so worst case scenario is it is duplicated in 3 places.

There are ways to help keep things in sync, but I'd like to investigate how feasible it is using a single reference for all config top to bottom.

I'm not personally aware of a project that does this, but Zephyr supports #include in their devicetrees. We could do the same thing to allow putting the UART into its own file that gets included in both.

[RobertZ2011]

Will ODP crates still be compatible with projects that do not leverage a device tree for initialization?

Yes, this functionality would be purely optional.