<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Sat, May 9, 2020 at 11:56 AM Christian Mauderer <<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.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"><br>
<br>
On 08/05/2020 23:05, Gedare Bloom wrote:<br>
> On Fri, May 8, 2020 at 9:34 AM Christian Mauderer <<a href="mailto:oss@c-mauderer.de" target="_blank">oss@c-mauderer.de</a>> wrote:<br>
>><br>
>><br>
>> On 08/05/2020 17:26, Niteesh G. S. wrote:<br>
>>> On Fri, May 8, 2020 at 11:43 AM 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>
>>><br>
>>> On 07/05/2020 17:19, Niteesh G. S. wrote:<br>
>>> > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber<br>
>>> > <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>><br>
>>> > <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>>> wrote:<br>
>>> ><br>
>>> > On 07/05/2020 12:28, Niteesh G. S. wrote:<br>
>>> ><br>
>>> > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber<br>
>>> > > <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>><br>
>>> > <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>><br>
>>> > > <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>><br>
>>> > <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
>>> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>>>>> wrote:<br>
>>> > ><br>
>>> > > On 07/05/2020 09:35, Niteesh G. S. wrote:<br>
>>> > ><br>
>>> > > > This is what I was trying to convey in one of the previous<br>
>>> > mails.<br>
>>> > > ><br>
>>> <a href="https://lists.rtems.org/pipermail/devel/2020-May/059717.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059717.html</a><br>
>>> > > > But in that mail, I was planning to replace KOBJLOOKUP.<br>
>>> > > > Should I start working on it? From the top of my mind, the<br>
>>> > > following has<br>
>>> > > > to be done.<br>
>>> > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c<br>
>>> > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt<br>
>>> are static.<br>
>>> > > > Should we also import ofw_if.h? Because that is where<br>
>>> OFW_*<br>
>>> > > functions<br>
>>> > > > are defined or just add a ofw_rtems_map.h which<br>
>>> redefines them,<br>
>>> > > instead<br>
>>> > > > of importing ofw_if.h?<br>
>>> > ><br>
>>> > > The KOBJ stuff in the OFW support enables FreeBSD to<br>
>>> have three<br>
>>> > > different implementations of the OFW API which can be<br>
>>> selected at<br>
>>> > > runtime:<br>
>>> > ><br>
>>> > > sys/powerpc/ofw/ofw_real.c<br>
>>> > > sys/dev/ofw/ofw_standard.c<br>
>>> > > sys/dev/ofw/ofw_fdt.c<br>
>>> > ><br>
>>> > > In libbsd this is already short cut to the FDT<br>
>>> implementation:<br>
>>> > ><br>
>>> > > #ifndef __rtems__<br>
>>> > > static ofw_def_t *ofw_def_impl = NULL;<br>
>>> > > #else /* __rtems__ */<br>
>>> > > #define ofw_def_impl (&ofw_fdt)<br>
>>> > > #endif /* __rtems__ */<br>
>>> > ><br>
>>> > > To me this looks like the KOBJ stuff was just used to<br>
>>> enable some<br>
>>> > > sort<br>
>>> > > of object oriented programming. Do we need this<br>
>>> flexibility at<br>
>>> > > runtime<br>
>>> > > in RTEMS? I would say no. I would hard wire this to the FDT<br>
>>> > > implementation. If someone has a problem with it in the<br>
>>> > future, this<br>
>>> > > decision can be readdressed.<br>
>>> > ><br>
>>> > ><br>
>>> > > Ok. But what is the neatest way to hardwire this to the FDT<br>
>>> > > implementation?<br>
>>> > > One way as Christian mentioned would be to redefine OFW_*<br>
>>> functions to<br>
>>> > > call the functions in ofw_fdt.c directly. Is there any other<br>
>>> way?<br>
>>> ><br>
>>> > I would try to replace the function declarations in openfirm.h<br>
>>> with<br>
>>> > inline functions which call the ofw_fdt.c functions.<br>
>>> ><br>
>>> ><br>
>>> > Should I proceed with the above method? or should I wait for others<br>
>>> > to comment?<br>
>>> > If I can proceed, the following is what I will be doing.<br>
>>> > 1) import openfirm.h and ofw_fdt.c into RTEMS.<br>
>>> > 2) Add ofw_fdt.h with functions declarations for functions in<br>
>>> ofw_fdt.c<br>
>>> > 3) Add necessary compile-time guards. This would include using<br>
>>> __rtems__<br>
>>> > preprocessor directive to avoid FreeBSD stuff and change the function<br>
>>> > definitions in ofw_fdt.c from static to non-static.<br>
>>> > Am I missing something? or is there any other way to do this?<br>
>>><br>
>>> Maybe wait one or two more days for others to comment. For me the<br>
>>> direction sounds OK.<br>
>>><br>
>>> You maybe can start thinking about where you want to import the<br>
>>> files to.<br>
>>><br>
>>><br>
>>> Since this has scope for future development. I think we should put it in a<br>
>>> separate directory under cpukit/include/ofw for header files and cpukit/ofw<br>
>>> for the source files. What do you think?<br>
>>><br>
>>><br>
>><br>
>> If you plan to prepare a FreeBSD sync (regardless whether you implement<br>
>> it or someone else) another possibility could be to create a similar<br>
>> directory structure like in libbsd.<br>
>><br>
>> Another directory could be ./cpukit/libmisc/rtems-fdt.<br>
>><br>
>> But your suggestion is also possible.<br>
>><br>
>> Maybe wait for some further input.<br>
>><br>
<br>
First: I think it would be good to discuss a location as a _preparation_<br>
for a FreeBSD import. Implementing that would be a massive change of the<br>
target for Niteeshs project. If he want to do that, I don't have a<br>
problem with the change of direction. But I don't have a problem with<br>
the original target too.<br>
<br>
Niteesh: Are you interested in the FreeBSD import more then in your<br>
original target? I think that would mean that a big part of your project<br>
would target the new build system. I really don't want to urge you into<br>
any direction here. So please choose whatever you want.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I would like to continue with the original project rather than the FreeBSD</div></div><div class="gmail_default" style="font-size:small">sync. This is mainly due to the complexity involved with the project and</div><div class="gmail_default" style="font-size:small">my lack of knowledge.</div><div class="gmail_default" style="font-size:small"><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>
> <br>
> This thread got a bit massive. It might be nice to refactor to a clean<br>
> mail thread :) I'd be agreeable to the idea of a sync to freebsd for<br>
> external sources that we import to rtems.git, but the management of<br>
> that sync has to be done carefully and we must keep in mind the needs<br>
> of low-end targets. I wouldn't like to see too much feature creep from<br>
> freebsd into rtems in order to support some things meant for only a<br>
> few relatively resource-rich boards.<br>
<br>
Agreed. From my view it would be only for the low level stuff that we<br>
currently do in RTEMS too. Pin initialization, serial drivers, I2C, SPI.<br>
Everything more complex like USB, Ethernet should continue to live in<br>
libbsd.<br>
<br>
> <br>
> If we do this sync, I think it should be handled as a single<br>
> subdirectory that syncs all imports simultaneously. I don't want to be<br>
> managing several different imports from various versions of upstream<br>
> freebsd sources. This would mean something more like cpukit/libfreebsd<br>
> maybe. Avoid using libbsd, and I think calling it by the upstream name<br>
> is a good way to proceed. The design and planned implementation of<br>
> this process needs to be fleshed out and discussed on the ml, and<br>
> maybe a simple preliminary example/use case (fdt is ok) would be good<br>
> to sketch, as well as possible future additions and how they would be<br>
> incorporated.<br>
<br>
I'm not entirely sure about that. It could be an advantage to have<br>
arbitrary locations (also that makes the sync more difficult). Use case:<br>
BSP drivers. One example that we already have is the imx iomux driver:<br>
<br>
<a href="https://git.rtems.org/rtems/tree/bsps/arm/imx/start/imx_iomux.c" rel="noreferrer" target="_blank">https://git.rtems.org/rtems/tree/bsps/arm/imx/start/imx_iomux.c</a><br>
<br>
If that would be in a common directory it might makes it a bit more<br>
difficult to find which files belong to which BSP.<br>
<br>
But of course having a common directory makes it more clear which files<br>
are imported. So that's a big advantage too. So I'm not really sure<br>
about which would be the better direction.</blockquote><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>
> I also need to be convinced that this code must be pulled into<br>
> rtems.git and can't be compiled/linked separately.<br>
<br>
Example: A pinmux driver. The RAM doesn't work without correct pin muxing.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> Gedare<br>
> <br>
>> Best regards<br>
>><br>
>> Christian<br>
<br>
</blockquote></div></div>