GSoC: Porting OFW to RTEMS
Niteesh G. S.
niteesh.gs at gmail.com
Thu May 28 15:08:40 UTC 2020
Hello Christian,
On Thu, May 28, 2020 at 8:12 PM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:
> Hello Niteesh,
>
> On 28/05/2020 16:34, Niteesh G. S. wrote:
> >
> >
> > On Wed, May 27, 2020 at 11:25 PM Christian Mauderer <oss at c-mauderer.de
> > <mailto:oss at c-mauderer.de>> wrote:
> >
> > On 27/05/2020 19:32, Niteesh G. S. wrote:
> > >
> > >
> > > On Wed, May 27, 2020 at 12:04 AM Christian Mauderer
> > <oss at c-mauderer.de <mailto:oss at c-mauderer.de>
> > > <mailto:oss at c-mauderer.de <mailto: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 are right. I didn't have a detailed enough look. The functions
> like
> > OFW_GETPROP (declared in ofw_if.h) are only used in openfirm.c. So
> that
> > location is OK.
> >
> > >
> > >
> > > - 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.
> >
> > Things like that tend to grow. So even if we don't want to import
> much
> > for now, it's quite possible that it will be more in the future.
> > Therefore I would use the future-proof approach even if it is a bit
> > overkill for now.
> >
> > OK.
> >
> >
> >
> > >
> > > 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.
> >
> > That really depends. I agree that we only want to import low-level
> > drivers.
> >
> > But also note that it's not always easy to say that driver A belongs
> > exactly to BSP B. For example take a look at some PowerPC chips and
> some
> > ARM chips. PowerPC has been used a lot by Freescale. Freescale now
> > belongs to NXP. NXP started to use the Freescale peripherals but
> with an
> > ARM core. Therefore now there are quite some modules that use the
> same
> > driver in ARM chips and in Freescale chips. If you import that
> driver to
> > an PowerPC you maybe would have to move it later to some shared
> section
> > if you want to use it in an ARM BSP.
> >
> >
> > I didn't know this I thought we only share across the same
> > architectures. So I
> > didn't take this into consideration.
>
> Yes, it's a bit unusual. But it gets more common with programmable
> logic. I think we have at least two or three FPGA based cores too. The
> peripherals for those can theoretically be the same for all cores.
>
>
OK.
> >
> > So why not just put all the drivers imported from FreeBSD in a shared
> > section right from the start. Keep the directory structure but move
> it
> > to bsps. I think I suggested it earlier already: What about
> > bsps/shared/freebsd or bsps/shared/bsdports?
> >
> >
> > We place the shared drivers in the shared section that is okay. But what
> > about drivers which are unique something like the Beagle I2C or something
> > similar will they be in their respective folders?
>
> Does it hurt if a driver is placed in the shared folder even if it is
> unique? You don't know whether the hardware vendor decides to use it in
> some other chip too in the future.
>
> Advantage is that we could keep the FreeBSD structure beyond this one
> folder.
OK. A shared folder seems to be the right option for the drivers.
>
>
> >
> > Why shouldn't we create a separate directory for the ports? Something on
> > a top-level. Which can reference headers from both cpukit and bsps.
> > This way we can have all imported source files under a single directory
> and
> > can share them across bsps. Is there any disadvantage in using a new
> > directory
> > for this?
>
> This is possible too. But I would expect that it will cause a _long_
> discussion whether it is a good idea, what would be a good name, ...
>
> What's the big advantage?
>
> cpukit has mostly core specific stuff and hardware independant sub
> systems. We don't plan to import bigger stuff like that (at least I hope
> that) but just basic drivers. Drivers are most of the time located in
> the bsps directory.
>
If it is just drivers and board dependent stuff then a shared folder under
bsps
seems to be a good option. Even if we want to import something that is bsps
independent it should work with the same directory structure but it
wouldn't be
the most correct thing.
What if we stick with a shared folder under bsps currently and restructure
when we import something independent of bsps since this is more of a
rare case. How much work will it be?
Best regards
>
> Christian
>
> >
> >
> >
> > Best regards
> >
> > Christian
> >
> > >
> > >
> > > 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 <mailto:devel at rtems.org>
> > <mailto:devel at rtems.org <mailto:devel at rtems.org>>
> > > > http://lists.rtems.org/mailman/listinfo/devel
> > > >
> > >
> >
>
> --
> --------------------------------------------
> embedded brains GmbH
> Herr Christian Mauderer
> Dornierstr. 4
> D-82178 Puchheim
> Germany
> email: christian.mauderer at embedded-brains.de
> Phone: +49-89-18 94 741 - 18
> Fax: +49-89-18 94 741 - 08
> PGP: Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200528/4f64a0da/attachment-0001.html>
More information about the devel
mailing list