Hello Niteesh, I am not in favour of a home grown solution. We should not re-invent the wheel. Working with device trees may appear to be simple, however, this could end up in a multi-person-month project easily. There are several existing solutions for device drivers based on device trees. What are our requirements? For example compare the Zephyr approach to device trees
https://docs.zephyrproject.org/latest/guides/dts/index.html with the one from Linux or FreeBSD. They are quite different. LK has also support for device trees: https://github.com/littlekernel/lk I didn't find general support in FreeRTOS. The Zircon Device Model seems to be a bit too complex for RTEMS: https://fuchsia.dev/fuchsia-src/concepts/drivers/device-model For a GSoC project, the scope must be clear. We have to decide if we want do a dynamic approach (Linux and FreeBSD) or a static one (Zephyr). Most device trees are intended to be used by Linux. Some device trees have a horrible structure (e.g. for clock and IO pin configuration, cross-references between device nodes). Linux can deal with this. It has abilities to allow arbitrary cross-references within the tree (includes reference counting). FreeBSD lacks support for this. They use special case nasty hacks with global variables do deal with this. We already have device tree support for RTEMS in libbsd (port from FreeBSD). What could be a feasible GSoC project is to move this support to the main RTEMS repository. With the new build system this would be very easy. However, we don't talk about here of an import of a hand full of files. The FreeBSD device tree support depends on the general device/bus support, synchronization primitives, string handling, printing, logging, module concept (linker sets), etc. What we also have to keep in mind is that the current device driver initialization runs before multi-tasking with interrupts disabled. A dynamic device tree based initialization must be probably done in a proper task context. This project involves general RTEMS Project decisions about the future development roadmap. We also need a mentor with enough time for such a GSoC project. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
