On Sun, Feb 2, 2020 at 2:55 PM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> 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 couldn't find any doc related to device trees for 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 > > Thank you for all this information. I learned a lot of approaches to the same problem. But how did you get all this information? Did you just google it now? or is it from experience? > 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. > Christian also said this, that's why I started this conversation even though it is too early for GSoC. Can we all discuss the scope of the project or if it is just too much for GSoC, I will look for some other interesting ones. > 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
