<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Thu, May 14, 2020 at 4:30 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de">christian.mauderer@embedded-brains.de</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 13/05/2020 20:15, Niteesh G. S. wrote:<br>
> Hello,<br>
> <br>
> This mail is to regain attention for this topic and also to discuss a<br>
> few details<br>
> regarding the porting process.<br>
> <br>
> In the previous thread, Sebastian mentioned that we will be hard wiring<br>
> the OF<br>
> functions with the FDT implementation. For reasons please have a look at<br>
> previous thread.<br>
> <a href="https://lists.rtems.org/pipermail/devel/2020-May/059762.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059762.html</a><br>
> This will be achieved by inlining the functions in openfirm.h with functions<br>
> defined in ofw_fdt.c. This approach is valid for most functions but not all.<br>
> Since not all functions have a one to one mapping.<br>
> <br>
> For example,<br>
> The OF_peer can be directly mapped to ofw_fdt_peer.<br>
> But for OF_getencprop it calls ofw_fdt_getprop after few manipulations.<br>
> Inlining these functions doesn't seem like a good practice for me.<br>
> <br>
> One way to approach this would be to add the implementation for these<br>
> functions in<br>
> ofw_fdt.c but this would cause code redundancy if we plan to import<br>
> openfirm.c<br>
> in future since these functions are already defined in openfirm.c.<br>
<br>
Are the functions exact clones of the the ones in openfirm.c? In that<br>
case I would suggest to import openfirm.c and put #ifndef __rtems__<br>
around everything you don't need. Eveni if it means that you only use<br>
10% of the file.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Yes, implementation of the mentioned functions(OF_getencprop, OF_getencprop_alloc etc)</div><div class="gmail_default" style="font-size:small">will be a copy of the ones in openfirm.c.</div><div class="gmail_default" style="font-size:small"> <br></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>
> Another approach will be to import openfirm.c also and redefine the OFW_*<br>
> macro to directly call the respective functions.<br>
<br>
That sounds like a better aproach.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">We can also call the respective functions directly from the functions in openfirm.c</div><div class="gmail_default" style="font-size:small">instead of redefining the OFW_* macro. Which one do you prefer?</div><br></div><div><div class="gmail_default" style="font-size:small">I will wait for a couple for everyone to participate in the discussion and then start</div><div class="gmail_default" style="font-size:small">implementing it.</div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> I don't really know if there is any other better way to approach this.<br>
> Any suggestion on<br>
> how to proceed. <br>
> <br>
> Once this is resolved I will proceed with the porting even if we haven't<br>
> finalized the<br>
> directory since it is just a matter of moving files once we are finalized.<br>
> <br>
> If you think this is too early to start with coding for GSoC please<br>
> understand that my<br>
> university exams haven't been conducted yet. And due to the COVID<br>
> pandemic, the<br>
> dates are quite uncertain. But it is mostly expected to happen during<br>
> the coding period (july/aug)<br>
> and this would eat up quite a lot of time. So just to be one the safe<br>
> side I started<br>
> quite early.<br>
> <br>
> Thank,<br>
> Niteesh.<br>
> <br>
> On Mon, May 11, 2020 at 12:48 PM Christian Mauderer<br>
> <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>> wrote:<br>
> <br>
> 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>><br>
> >>>> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a> <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<br>
> 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<br>
> to add<br>
> >>>> support for FDT<br>
> >>>> > based initialization. As part of this process, I will<br>
> 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<br>
> 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<br>
> 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<br>
> FreeBSD<br>
> >>> that is calling these functions? I am not questioning the need,<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> which core<br>
> >>>> FreeBSD pieces would need to also come over for the<br>
> 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<br>
> is these<br>
> >>> I am asking about.<br>
> >>><br>
> >>>> Is seamless integration with rtems-libbsd required or does<br>
> 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<br>
> well the<br>
> >> functions can be integrated into RTEMS (the "node" parameter<br>
> maybe is a<br>
> >> bit difficult) but I'm confident that the OF_... and ofw_...<br>
> 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<br>
> 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<br>
> 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<br>
> FreeBSD<br>
> >>>> it is<br>
> >>>> > planned to<br>
> >>>> > add to a synchronization script(Yet to discussed in<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> large<br>
> >>>> pieces<br>
> >>>> of FreeBSD.<br>
> >>>><br>
> >>>> Gedare's point about making sure all imported pieces are<br>
> 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<br>
> clear use<br>
> >>>> outside of rtems-libbsd. FDT support is one use, another<br>
> is the<br>
> >>>> NFS<br>
> >>>> client code in FreeBSD being used with the legacy stack<br>
> (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<br>
> handle the<br>
> >>>> synchronisation? This is a good idea. Could it manage<br>
> 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<br>
> group?<br>
> >>>> This<br>
> >>>> way we can have drivers in a BSP, NFS in libnfs (or where<br>
> ever).<br>
> >>>><br>
> >>>><br>
> >>>> I am not really familiar with the new build system. So can we<br>
> please<br>
> >>>> wait<br>
> >>>> until Sebastian answers this.<br>
> >>><br>
> >>> Sure.<br>
> >><br>
> >> Although note that I suggested to see the discussion as a<br>
> _preparation_<br>
> >> for that import. Doing the import right is quite a bit of work.<br>
> 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<br>
> 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>
> <mailto:<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>
> <br>
<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></div>