<div dir="ltr"><div dir="ltr">On Sun, Feb 2, 2020 at 2:55 PM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Niteesh,<br>
<br>
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<br>
<br>
<a href="https://docs.zephyrproject.org/latest/guides/dts/index.html" rel="noreferrer" target="_blank">https://docs.zephyrproject.org/latest/guides/dts/index.html</a><br>
<br>
with the one from Linux or FreeBSD. They are quite different.<br>
<br>
LK has also support for device trees:<br>
<br>
<a href="https://github.com/littlekernel/lk" rel="noreferrer" target="_blank">https://github.com/littlekernel/lk</a></blockquote><div><br></div><div>I couldn't find any doc related to device trees for LK! </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
I didn't find general support in FreeRTOS.<br>
<br>
The Zircon Device Model seems to be a bit too complex for RTEMS:<br>
<br>
<a href="https://fuchsia.dev/fuchsia-src/concepts/drivers/device-model" rel="noreferrer" target="_blank">https://fuchsia.dev/fuchsia-src/concepts/drivers/device-model</a><br>
<br></blockquote><div> </div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
This project involves general RTEMS Project decisions about the future development roadmap.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
We also need a mentor with enough time for such a GSoC project.<br>
</blockquote></div></div>