GSoC: Porting OFW to RTEMS

Wed May 27 17:32:34 UTC 2020

On Wed, May 27, 2020 at 12:04 AM Christian Mauderer <oss at c-mauderer.de>
wrote:

> Hello Niteesh,
>
> On 26/05/2020 19:56, Christian Mauderer wrote:
> > Hello Niteesh,
> >
> > On 25/05/2020 11:20, Niteesh G. S. wrote:
> >> Hello,
> >>
> >> I have completed the porting of the OFW code from FreeBSD to RTEMS.
> >> I do acknowledge the fact that we haven't decided on the directory for
> files
> >> to be placed in. The previous conversation had stopped quite a while
> ago.
> >> Christian suggested I work on the patch since that would also start the
> >> conversation again and also refactoring the patch to the correct
> directory
> >> will not be much of work.
> >>
> >> cpukit/libfreebsd was suggested as one of the directories to place the
> >> ported
> >> FreeBSD files. It is suggested to place all the source files under this
> >> directory.
> >> Since this will make the sync part easier. But this causes issues when
> >> porting
> >> BSP dependent files. Since RTEMS currently doesn't allow files in
> cpukit to
> >> reference bsp headers. I faced a similar issue during my porting process
> >> also.
> >> The OFW init function require bsp_fdt_get function to get a reference to
> >> the fdt
> >> blob. But I can't include the bsp/fdt.h header file from a source file
> >> under cpukit.
> >> We must decide the directory quickly because my project will import
> other
> >> FreeBSD sources like the pinmux driver for beaglebone into RTEMS.
> >
> > Do you have a suggestion for another directory?
> >
> > If cpukit makes problems (which it clearly does due to the BSP
> > dependencies) maybe something in bsps/shared?
> >
> >>
> >> https://github.com/gs-niteesh/rtems/commits/ofw_branch
> >
> > For small patches it would be better to send them to the list using "git
> > send-email". That allows to comment directly on the patches. But in this
> > case using a repo is OK because especially the import is quite big.
> >
> > I'll add comments for small stuff directly on github. I hope that works
> ;-)
>
> Finished adding comments for small stuff. Some bigger questions:
>
> - How do you plan to include ofw_if.h in some driver files? RTEMS
> currently puts every file that can be included with <some.h> into a path
> called "include".

Will ofw_if.h be included in driver files? As far as I have searched in the
FreeBSD sources, other than the OFW implementation none of the driver
files include this header. So this could be placed in the same directory as
the OFW sources and need not be added to the global include path.
If there is a case where it is included in some driver please let me know.

And also all the references to this header in the OFW implementations are
relative so in future, if we add other implementations, having it in the
same
directory would be the right choice.

> - You created quite some commits. I would suggest to merge all porting
> commits so that you have one import commit, one port commit and maybe
> one commit adding RTEMS specific files

I have squashed them into a single port commit.

>

- You have at least one completely hand written file (ofw_if.h). Maybe
> we should think about whether that is located well in the same directory
> as the imported code or whether a similar structure like used in libbsd
> would be better. One tree for imported files and one for RTEMS specific
> hand written ones.
>

Do we need a separate directory for RTEMS specific handwritten ones depends
on what we will be importing in the future? Since we intend only to import
mostly
driver related code I don't think there is a need for a separate directory.
I think
this way because I assuming we don't need any RTEMS specific file for the
drivers.
But if we plan to include some simple subsystem then having a separate
directory
will be nice.

This also makes me think about if having all sources under a single
directory under
cpukit a good idea. Since our main import targets are drivers placing them
in the
cpukit directory or any other directory other than their respective BSP
directory is not
a good idea. This would make writing the sync script harder but this will
decrease the
coupling and dependencies between various folders. The other way around
will be
to have all headers accessible in the global path i.e. files under cpukit
should be
able to access bsp related headers. This would increase the coupling but I
guess
it will make writing the script easier since it has to track only a single
directory.
I am not really sure which is a better tradeoff. If someone could shed some
light on
the complexity of the script it'll help in coming up with a conclusion
easier.
But from a logical perspective, Having the drivers in their respective
directories
seems to be a better idea to me.

> Please see all comments as advises. Feel free to argue against any of
> them if you think different ;-)
>
> Best regards
>
> Christian
>
> >
> > Best regards
> >
> > Christian
> >
> >> Please have a look at the last 6 patches for the ported work.
> >> Below is a short summary of the patch.
> >> * The openfirm.h is the OF interface that will provided to the user.
> >> * The openfirm.c contains the function definition for openfirm.h. The
> >> functions
> >> call the respective OFW_* functions which are responsible for choosing
> >> the correct implementation for OF interface.
> >> * ofw_if.h is the replacement for ofw_if.h in FreeBSD. This is an auto
> >> generated
> >> header in FreeBSD which choose the correct OF implementation(ofw_fdt,
> >> ofw_std,
> >> ofw_32bit, ofw_real). In RTEMS we directly map to the FDT
> implementation as
> >> suggested by Sebastian.
> >> * ofw_fdt.c contains the fdt implementation of OF interface.
> >>
> >> Thanks,
> >> Niteesh.
> >>
> > _______________________________________________
> > devel mailing list
> > devel at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200527/eefb3b72/attachment.html>