<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Mon, May 11, 2020 at 4:34 AM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div></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">On 10/5/20 6:17 pm, Niteesh G. S. wrote:<br>
> This thread is a continuation of "GSoC 2020: Implementation of OFW <br>
> functions".<br>
> <br>
> A summary of points discussed in that thread is given below.<br>
> <br>
> Below is a short description of my GSoC project. For more information please<br>
> refer to the wiki.<br>
> <a href="https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization" rel="noreferrer" target="_blank">https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization</a><br>
> My GSoC project deals with refactoring the Beagle BSP to add support for FDT<br>
> based initialization. As part of this process, I will have to import the <br>
> pin mux driver<br>
> into RTEMS which currently is present in libBSD.<br>
> This would require having support for OFW functions which are currently <br>
> not implemented<br>
> in RTEMS. Some drivers(eg: imx_iomux.c) which require these functions <br>
> provide<br>
> a local implementation using libFDT.<br>
<br>
I hope you do not mind if I wind back a couple of steps...<br>
<br>
OFW? Is this <a href="http://wiki.laptop.org/go/Open_Firmware" rel="noreferrer" target="_blank">http://wiki.laptop.org/go/Open_Firmware</a>? </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
How does OFW related to FDT?<br></blockquote><div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">We are only interested in the device tree interface provided by the OF.</div><div class="gmail_default" style="font-size:small">Functions like OF_getprop, OF_parent, etc.</div></div><div><br></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">
<br>
You discuss importing drivers from FreeBSD? Do you know which core <br>
FreeBSD pieces would need to also come over for the drivers listed below?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">We had discussed this in the previous thread.</div><div class="gmail_default" style="font-size:small"><a href="https://lists.rtems.org/pipermail/devel/2020-May/059765.html">https://lists.rtems.org/pipermail/devel/2020-May/059765.html</a><br></div><div class="gmail_default" style="font-size:small">For OF_* functions we will only have to import the following files.</div><div class="gmail_default" style="font-size:small">1) openfirm.h</div><div class="gmail_default" style="font-size:small">2) ofw_fdt.c</div></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">
<span class="gmail_default" style="font-size:small"></span>Is seamless integration with rtems-libbsd required or does it also <br>
include copies of the same code?<br></blockquote><div> </div><div><div class="gmail_default" style="font-size:small">I am sorry. I don't really understand what you are asking :(.</div></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">
<br>
> In the previous thread, it has been decided to import the OFW functions from<br>
> FreeBSD but the directory where it has to be imported into RTEMS is not yet<br>
> decided. This thread has been created to discuss it.<br>
> It should also be noted that some drivers for example I2C, SPI are being <br>
> imported<br>
> into RTEMS from FreeBSD for some BSPs.<br>
> Now, since a large amount of code being imported from FreeBSD it is <br>
> planned to<br>
> add to a synchronization script(Yet to discussed in detail) to stay in <br>
> sync with<br>
> FreeBSD.<br>
> <br>
> So now is it necessary to choose a directory that is future compatible <br>
> with the<br>
> synchronization script. We should also discuss if we want to have all <br>
> imports<br>
> under a single directory or have the imports in their respective <br>
> directories for eg<br>
> a device driver could be placed in its BSP directories than in a common <br>
> folder<br>
> along with other imports. But it should also be noted that the latter <br>
> makes it<br>
> difficult to sync and the former.<br>
<br>
Gedare covered these issues in the other thread in an excellent post [1] <br>
and I would like to reference that as I agree with it.<br>
<br>
When importing from such a large and complex code base like FreeBSD we <br>
need to be careful we do not pull on a thread and pull in large pieces <br>
of FreeBSD.<br>
<br>
Gedare's point about making sure all imported pieces are from the same <br>
version is important and I think a base requirement.<br>
<br>
I am OK with some code being in rtems.git if there is a clear use <br>
outside of rtems-libbsd. FDT support is one use, another is the NFS <br>
client code in FreeBSD being used with the legacy stack (there are BSPs <br>
with only legacy driver support still in use) and the existing client is <br>
only NFSv2.<br>
<br>
We need a place to collect the common base parts of FreeBSD that are <br>
shared by the various imported pieces. Isolated pieces could lead to <br>
repeated imports common pieces if we do not do this.<br>
<br>
I believe Sebastian said the new build system should handle the <br>
synchronisation? This is a good idea. Could it manage separated pieces? <br>
Could the build system read in all the sync pieces and logically join <br>
them based on the upstream source and operate on them as a group? This <br>
way we can have drivers in a BSP, NFS in libnfs (or where ever).<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I am not really familiar with the new build system. So can we please wait</div><div class="gmail_default" style="font-size:small">until Sebastian answers this.</div><div class="gmail_default" style="font-size:small"><br></div><br></div><div><br></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">
Chris<br>
<br>
[1] <a href="https://lists.rtems.org/pipermail/devel/2020-May/059807.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059807.html</a><br>
</blockquote></div></div>