<div dir="ltr"><div class="gmail_default" style="font-size:small">Hello,</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This mail is to regain attention for this topic and also to discuss a few details</div><div class="gmail_default" style="font-size:small">regarding the porting process.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><div class="gmail_default">In the previous thread, Sebastian mentioned that we will be hard wiring the OF</div><div class="gmail_default">functions with the FDT implementation. For reasons please have a look at previous thread.</div><div class="gmail_default"><a href="https://lists.rtems.org/pipermail/devel/2020-May/059762.html">https://lists.rtems.org/pipermail/devel/2020-May/059762.html</a><br></div><div class="gmail_default">This will be achieved by inlining the functions in openfirm.h with functions</div><div class="gmail_default">defined in ofw_fdt.c. This approach is valid for most functions but not all.</div><div class="gmail_default">Since not all functions have a one to one mapping.</div><div class="gmail_default"><br></div><div class="gmail_default">For example,</div><div class="gmail_default"> The OF_peer can be directly mapped to ofw_fdt_peer.</div><div class="gmail_default"> But for OF_getencprop it calls ofw_fdt_getprop after few manipulations.</div><div class="gmail_default">Inlining these functions doesn't seem like a good practice for me.<br></div><div class="gmail_default"><br></div><div class="gmail_default">One way to approach this would be to add the implementation for these functions in</div><div class="gmail_default">ofw_fdt.c but this would cause code redundancy if we plan to import openfirm.c</div><div class="gmail_default">in future since these functions are already defined in openfirm.c.</div><div class="gmail_default"><br></div><div class="gmail_default">Another approach will be to import openfirm.c also and redefine the OFW_*</div><div class="gmail_default">macro to directly call the respective functions.</div><div class="gmail_default"><br></div><div class="gmail_default">I don't really know if there is any other better way to approach this. Any suggestion on</div><div class="gmail_default">how to proceed. </div><div class="gmail_default"><br></div><div class="gmail_default">Once this is resolved I will proceed with the porting even if we haven't finalized the</div><div class="gmail_default">directory since it is just a matter of moving files once we are finalized.</div><div class="gmail_default"><br></div><div class="gmail_default">If you think this is too early to start with coding for GSoC please understand that my</div><div class="gmail_default">university exams haven't been conducted yet. And due to the COVID pandemic, the</div><div class="gmail_default">dates are quite uncertain. But it is mostly expected to happen during the coding period (july/aug)</div><div class="gmail_default">and this would eat up quite a lot of time. So just to be one the safe side I started</div><div class="gmail_default">quite early.</div><div class="gmail_default"><br></div><div class="gmail_default">Thank,</div><div class="gmail_default">Niteesh.</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 11, 2020 at 12:48 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/05/2020 09:11, Chris Johns wrote:<br>
> On 11/5/20 4:55 pm, Christian Mauderer wrote:<br>
>> On 11/05/2020 06:57, Chris Johns wrote:<br>
>>><br>
>>><br>
>>> On 11/5/20 2:03 pm, Niteesh G. S. wrote:<br>
>>>> On Mon, May 11, 2020 at 4:34 AM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a><br>
>>>> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>> wrote:<br>
>>>><br>
>>>> On 10/5/20 6:17 pm, Niteesh G. S. wrote:<br>
>>>> > This thread is a continuation of "GSoC 2020: Implementation<br>
>>>> 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<br>
>>>> information please<br>
>>>> > refer to the wiki.<br>
>>>> ><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<br>
>>>> support for FDT<br>
>>>> > based initialization. As part of this process, I will have to<br>
>>>> 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<br>
>>>> currently<br>
>>>> > not implemented<br>
>>>> > in RTEMS. Some drivers(eg: imx_iomux.c) which require these<br>
>>>> 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>?<br>
>>>> How does OFW related to FDT?<br>
>>>><br>
>>>><br>
>>>> We are only interested in the device tree interface provided by the OF.<br>
>>>> Functions like OF_getprop, OF_parent, etc.<br>
>>>><br>
>>><br>
>>> Why not call libfdt functions? I am wondering what there is in FreeBSD<br>
>>> that is calling these functions? I am not questioning the need, it is a<br>
>>> case of not understanding the dependency.<br>
>><br>
>> The use case for the OF_... and ofw_... functions is more or less a<br>
>> simple import from FreeBSD drivers. Beneath that there are some quite<br>
>> nice shortcuts in the OF_... and ofw_... functions that would have to be<br>
>> re-implemented in each driver (like ofw_bus_node_status_okay()).<br>
>><br>
>> Some drivers already use hacked versions of the functions. For example:<br>
>><br>
>> bsps/sparc64/shared/clock/ckinit.c<br>
>> bsps/arm/imx/start/imx_iomux.c<br>
>><br>
>> A use case where the OF_... stuff would have been handy:<br>
>><br>
>> For the imx pin initialization I would have loved to just use the<br>
>> fdt_pinctrl_configure_tree() from FreeBSD. But that one had a lot of<br>
>> OF_.. stuff. Therefore I had to reimplement that function in a<br>
>> imx_pinctrl_configure_children(). My implementation basically does<br>
>> exactly the same thing but uses fdt_... functions instead of the OF_...<br>
>> functions.<br>
> <br>
> Thanks. I think I understand. The scope seems to be the low level SoC<br>
> type initialisation. This makes sense.<br>
<br>
And maybe some low level drivers like serial or I2C. I don't think that<br>
we should go much further in complexity. Basically everything that is<br>
beyond getting the board up and running is more of a libbsd topic.<br>
<br>
> <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<br>
>>>> below?<br>
>>>><br>
>>>><br>
>>>> We had discussed this in the previous thread.<br>
>>>> <a href="https://lists.rtems.org/pipermail/devel/2020-May/059765.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059765.html</a><br>
>>>> For OF_* functions we will only have to import the following files.<br>
>>>> 1) openfirm.h<br>
>>>> 2) ofw_fdt.c<br>
>>><br>
>>> You say below some drivers are being imported from FreeBSD, it is these<br>
>>> I am asking about.<br>
>>><br>
>>>> Is seamless integration with rtems-libbsd required or does it also<br>
>>>> include copies of the same code?<br>
>>>><br>
>>>> I am sorry. I don't really understand what you are asking :(.<br>
>>><br>
>>> I am asking if the changes effect rtems-libbsd?<br>
>><br>
>> I think the first step will be copies. It depends a bit on how well the<br>
>> functions can be integrated into RTEMS (the "node" parameter maybe is a<br>
>> bit difficult) but I'm confident that the OF_... and ofw_... stuff can<br>
>> be replaced sooner or later.<br>
> <br>
> Sure, this is sensible. I am just mapping out in my head how this all<br>
> goes together.<br>
> <br>
<br>
That's fine and necessary. It's good if we find critical points before<br>
Niteesh starts to add stuff.<br>
<br>
For the OF and ofw parts I'm a bit worried about the node parameter. But<br>
I'm sure we find a solution.<br>
<br>
>>>> > In the previous thread, it has been decided to import the OFW<br>
>>>> functions from<br>
>>>> > FreeBSD but the directory where it has to be imported into<br>
>>>> RTEMS<br>
>>>> 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<br>
>>>> are being<br>
>>>> > imported<br>
>>>> > into RTEMS from FreeBSD for some BSPs.<br>
>>>> > Now, since a large amount of code being imported from FreeBSD<br>
>>>> it is<br>
>>>> > planned to<br>
>>>> > add to a synchronization script(Yet to discussed in detail) to<br>
>>>> stay in<br>
>>>> > sync with<br>
>>>> > FreeBSD.<br>
>>>> ><br>
>>>> > So now is it necessary to choose a directory that is future<br>
>>>> compatible<br>
>>>> > with the<br>
>>>> > synchronization script. We should also discuss if we want to<br>
>>>> have<br>
>>>> all<br>
>>>> > imports<br>
>>>> > under a single directory or have the imports in their<br>
>>>> respective<br>
>>>> > directories for eg<br>
>>>> > a device driver could be placed in its BSP directories than<br>
>>>> in a<br>
>>>> common<br>
>>>> > folder<br>
>>>> > along with other imports. But it should also be noted that the<br>
>>>> latter<br>
>>>> > makes it<br>
>>>> > difficult to sync and the former.<br>
>>>><br>
>>>> Gedare covered these issues in the other thread in an excellent<br>
>>>> post<br>
>>>> [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<br>
>>>> FreeBSD we<br>
>>>> need to be careful we do not pull on a thread and pull in large<br>
>>>> pieces<br>
>>>> of FreeBSD.<br>
>>>><br>
>>>> Gedare's point about making sure all imported pieces are from the<br>
>>>> 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<br>
>>>> NFS<br>
>>>> client code in FreeBSD being used with the legacy stack (there are<br>
>>>> BSPs<br>
>>>> with only legacy driver support still in use) and the existing<br>
>>>> client is<br>
>>>> only NFSv2.<br>
>>>><br>
>>>> We need a place to collect the common base parts of FreeBSD<br>
>>>> that are<br>
>>>> shared by the various imported pieces. Isolated pieces could<br>
>>>> 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<br>
>>>> pieces?<br>
>>>> Could the build system read in all the sync pieces and<br>
>>>> logically join<br>
>>>> them based on the upstream source and operate on them as a group?<br>
>>>> This<br>
>>>> way we can have drivers in a BSP, NFS in libnfs (or where ever).<br>
>>>><br>
>>>><br>
>>>> I am not really familiar with the new build system. So can we please<br>
>>>> wait<br>
>>>> until Sebastian answers this.<br>
>>><br>
>>> Sure.<br>
>><br>
>> Although note that I suggested to see the discussion as a _preparation_<br>
>> for that import. Doing the import right is quite a bit of work. It would<br>
>> change the target of Niteeshs GSoC project quite a lot. So we should<br>
>> make sure that a good location is selected and that the same rules like<br>
>> in libbsd are used. But I don't think that the actual script will be<br>
>> added in that project.<br>
> <br>
> Again this is sensible. Thank you for clarifying things.<br>
> <br>
> Chris<br>
<br>
Best regards<br>
<br>
Christian<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax: +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>