GSoC: Porting OFW to RTEMS
Christian Mauderer
oss at c-mauderer.de
Thu May 28 15:47:54 UTC 2020
Hello Niteesh,
On 28/05/2020 17:08, Niteesh G. S. wrote:
> Hello Christian,
>
> On Thu, May 28, 2020 at 8:12 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto: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>
> > <mailto: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>>
> > > <mailto: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?
I would suggest that way. Please start with it and create a compilable
and ideally useable patch set and send it to the mailing list. That will
involve others developers much better than this thread.
Best regards
Christian
>
> 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>>
> > <mailto: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
> <mailto: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.
>
More information about the devel
mailing list