GSoC: RTEMS directory for FreeBSD imports
Niteesh G. S.
niteesh.gs at gmail.com
Thu May 14 16:59:58 UTC 2020
On Thu, May 14, 2020 at 4:30 PM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:
> On 13/05/2020 20:15, Niteesh G. S. wrote:
> > Hello,
> >
> > This mail is to regain attention for this topic and also to discuss a
> > few details
> > regarding the porting process.
> >
> > In the previous thread, Sebastian mentioned that we will be hard wiring
> > the OF
> > functions with the FDT implementation. For reasons please have a look at
> > previous thread.
> > https://lists.rtems.org/pipermail/devel/2020-May/059762.html
> > This will be achieved by inlining the functions in openfirm.h with
> functions
> > defined in ofw_fdt.c. This approach is valid for most functions but not
> all.
> > Since not all functions have a one to one mapping.
> >
> > For example,
> > The OF_peer can be directly mapped to ofw_fdt_peer.
> > But for OF_getencprop it calls ofw_fdt_getprop after few
> manipulations.
> > Inlining these functions doesn't seem like a good practice for me.
> >
> > One way to approach this would be to add the implementation for these
> > functions in
> > ofw_fdt.c but this would cause code redundancy if we plan to import
> > openfirm.c
> > in future since these functions are already defined in openfirm.c.
>
> Are the functions exact clones of the the ones in openfirm.c? In that
> case I would suggest to import openfirm.c and put #ifndef __rtems__
> around everything you don't need. Eveni if it means that you only use
> 10% of the file.
>
Yes, implementation of the mentioned
functions(OF_getencprop, OF_getencprop_alloc etc)
will be a copy of the ones in openfirm.c.
> >
> > Another approach will be to import openfirm.c also and redefine the OFW_*
> > macro to directly call the respective functions.
>
> That sounds like a better aproach.
>
We can also call the respective functions directly from the functions in
openfirm.c
instead of redefining the OFW_* macro. Which one do you prefer?
I will wait for a couple for everyone to participate in the discussion and
then start
implementing it.
>
> > I don't really know if there is any other better way to approach this.
> > Any suggestion on
> > how to proceed.
> >
> > Once this is resolved I will proceed with the porting even if we haven't
> > finalized the
> > directory since it is just a matter of moving files once we are
> finalized.
> >
> > If you think this is too early to start with coding for GSoC please
> > understand that my
> > university exams haven't been conducted yet. And due to the COVID
> > pandemic, the
> > dates are quite uncertain. But it is mostly expected to happen during
> > the coding period (july/aug)
> > and this would eat up quite a lot of time. So just to be one the safe
> > side I started
> > quite early.
> >
> > Thank,
> > Niteesh.
> >
> > On Mon, May 11, 2020 at 12:48 PM Christian Mauderer
> > <christian.mauderer at embedded-brains.de
> > <mailto:christian.mauderer at embedded-brains.de>> wrote:
> >
> > On 11/05/2020 09:11, Chris Johns wrote:
> > > On 11/5/20 4:55 pm, Christian Mauderer wrote:
> > >> On 11/05/2020 06:57, Chris Johns wrote:
> > >>>
> > >>>
> > >>> On 11/5/20 2:03 pm, Niteesh G. S. wrote:
> > >>>> On Mon, May 11, 2020 at 4:34 AM Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>
> > >>>> <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>> wrote:
> > >>>>
> > >>>> On 10/5/20 6:17 pm, Niteesh G. S. wrote:
> > >>>> > This thread is a continuation of "GSoC 2020:
> Implementation
> > >>>> of OFW
> > >>>> > functions".
> > >>>> >
> > >>>> > A summary of points discussed in that thread is given
> > below.
> > >>>> >
> > >>>> > Below is a short description of my GSoC project. For
> more
> > >>>> information please
> > >>>> > refer to the wiki.
> > >>>> >
> > >>>>
> https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization
> > >>>> > My GSoC project deals with refactoring the Beagle BSP
> > to add
> > >>>> support for FDT
> > >>>> > based initialization. As part of this process, I will
> > have to
> > >>>> import the
> > >>>> > pin mux driver
> > >>>> > into RTEMS which currently is present in libBSD.
> > >>>> > This would require having support for OFW functions
> > which are
> > >>>> currently
> > >>>> > not implemented
> > >>>> > in RTEMS. Some drivers(eg: imx_iomux.c) which require
> these
> > >>>> functions
> > >>>> > provide
> > >>>> > a local implementation using libFDT.
> > >>>>
> > >>>> I hope you do not mind if I wind back a couple of steps...
> > >>>>
> > >>>> OFW? Is this http://wiki.laptop.org/go/Open_Firmware?
> > >>>> How does OFW related to FDT?
> > >>>>
> > >>>>
> > >>>> We are only interested in the device tree interface provided by
> > the OF.
> > >>>> Functions like OF_getprop, OF_parent, etc.
> > >>>>
> > >>>
> > >>> Why not call libfdt functions? I am wondering what there is in
> > FreeBSD
> > >>> that is calling these functions? I am not questioning the need,
> > it is a
> > >>> case of not understanding the dependency.
> > >>
> > >> The use case for the OF_... and ofw_... functions is more or less
> a
> > >> simple import from FreeBSD drivers. Beneath that there are some
> quite
> > >> nice shortcuts in the OF_... and ofw_... functions that would
> > have to be
> > >> re-implemented in each driver (like ofw_bus_node_status_okay()).
> > >>
> > >> Some drivers already use hacked versions of the functions. For
> > example:
> > >>
> > >> bsps/sparc64/shared/clock/ckinit.c
> > >> bsps/arm/imx/start/imx_iomux.c
> > >>
> > >> A use case where the OF_... stuff would have been handy:
> > >>
> > >> For the imx pin initialization I would have loved to just use the
> > >> fdt_pinctrl_configure_tree() from FreeBSD. But that one had a lot
> of
> > >> OF_.. stuff. Therefore I had to reimplement that function in a
> > >> imx_pinctrl_configure_children(). My implementation basically does
> > >> exactly the same thing but uses fdt_... functions instead of the
> > OF_...
> > >> functions.
> > >
> > > Thanks. I think I understand. The scope seems to be the low level
> SoC
> > > type initialisation. This makes sense.
> >
> > And maybe some low level drivers like serial or I2C. I don't think
> that
> > we should go much further in complexity. Basically everything that is
> > beyond getting the board up and running is more of a libbsd topic.
> >
> > >
> > >>>> You discuss importing drivers from FreeBSD? Do you know
> > which core
> > >>>> FreeBSD pieces would need to also come over for the
> > drivers listed
> > >>>> below?
> > >>>>
> > >>>>
> > >>>> We had discussed this in the previous thread.
> > >>>> https://lists.rtems.org/pipermail/devel/2020-May/059765.html
> > >>>> For OF_* functions we will only have to import the following
> files.
> > >>>> 1) openfirm.h
> > >>>> 2) ofw_fdt.c
> > >>>
> > >>> You say below some drivers are being imported from FreeBSD, it
> > is these
> > >>> I am asking about.
> > >>>
> > >>>> Is seamless integration with rtems-libbsd required or does
> > it also
> > >>>> include copies of the same code?
> > >>>>
> > >>>> I am sorry. I don't really understand what you are asking :(.
> > >>>
> > >>> I am asking if the changes effect rtems-libbsd?
> > >>
> > >> I think the first step will be copies. It depends a bit on how
> > well the
> > >> functions can be integrated into RTEMS (the "node" parameter
> > maybe is a
> > >> bit difficult) but I'm confident that the OF_... and ofw_...
> > stuff can
> > >> be replaced sooner or later.
> > >
> > > Sure, this is sensible. I am just mapping out in my head how this
> all
> > > goes together.
> > >
> >
> > That's fine and necessary. It's good if we find critical points
> before
> > Niteesh starts to add stuff.
> >
> > For the OF and ofw parts I'm a bit worried about the node parameter.
> But
> > I'm sure we find a solution.
> >
> > >>>> > In the previous thread, it has been decided to import
> > the OFW
> > >>>> functions from
> > >>>> > FreeBSD but the directory where it has to be imported
> into
> > >>>> RTEMS
> > >>>> is not yet
> > >>>> > decided. This thread has been created to discuss it.
> > >>>> > It should also be noted that some drivers for example
> > I2C, SPI
> > >>>> are being
> > >>>> > imported
> > >>>> > into RTEMS from FreeBSD for some BSPs.
> > >>>> > Now, since a large amount of code being imported from
> > FreeBSD
> > >>>> it is
> > >>>> > planned to
> > >>>> > add to a synchronization script(Yet to discussed in
> > detail) to
> > >>>> stay in
> > >>>> > sync with
> > >>>> > FreeBSD.
> > >>>> >
> > >>>> > So now is it necessary to choose a directory that is
> future
> > >>>> compatible
> > >>>> > with the
> > >>>> > synchronization script. We should also discuss if we
> > want to
> > >>>> have
> > >>>> all
> > >>>> > imports
> > >>>> > under a single directory or have the imports in their
> > >>>> respective
> > >>>> > directories for eg
> > >>>> > a device driver could be placed in its BSP directories
> than
> > >>>> in a
> > >>>> common
> > >>>> > folder
> > >>>> > along with other imports. But it should also be noted
> > that the
> > >>>> latter
> > >>>> > makes it
> > >>>> > difficult to sync and the former.
> > >>>>
> > >>>> Gedare covered these issues in the other thread in an
> > excellent
> > >>>> post
> > >>>> [1]
> > >>>> and I would like to reference that as I agree with it.
> > >>>>
> > >>>> When importing from such a large and complex code base like
> > >>>> FreeBSD we
> > >>>> need to be careful we do not pull on a thread and pull in
> > large
> > >>>> pieces
> > >>>> of FreeBSD.
> > >>>>
> > >>>> Gedare's point about making sure all imported pieces are
> > from the
> > >>>> same
> > >>>> version is important and I think a base requirement.
> > >>>>
> > >>>> I am OK with some code being in rtems.git if there is a
> > clear use
> > >>>> outside of rtems-libbsd. FDT support is one use, another
> > is the
> > >>>> NFS
> > >>>> client code in FreeBSD being used with the legacy stack
> > (there are
> > >>>> BSPs
> > >>>> with only legacy driver support still in use) and the
> existing
> > >>>> client is
> > >>>> only NFSv2.
> > >>>>
> > >>>> We need a place to collect the common base parts of FreeBSD
> > >>>> that are
> > >>>> shared by the various imported pieces. Isolated pieces
> could
> > >>>> lead to
> > >>>> repeated imports common pieces if we do not do this.
> > >>>>
> > >>>> I believe Sebastian said the new build system should
> > handle the
> > >>>> synchronisation? This is a good idea. Could it manage
> > separated
> > >>>> pieces?
> > >>>> Could the build system read in all the sync pieces and
> > >>>> logically join
> > >>>> them based on the upstream source and operate on them as a
> > group?
> > >>>> This
> > >>>> way we can have drivers in a BSP, NFS in libnfs (or where
> > ever).
> > >>>>
> > >>>>
> > >>>> I am not really familiar with the new build system. So can we
> > please
> > >>>> wait
> > >>>> until Sebastian answers this.
> > >>>
> > >>> Sure.
> > >>
> > >> Although note that I suggested to see the discussion as a
> > _preparation_
> > >> for that import. Doing the import right is quite a bit of work.
> > It would
> > >> change the target of Niteeshs GSoC project quite a lot. So we
> should
> > >> make sure that a good location is selected and that the same
> > rules like
> > >> in libbsd are used. But I don't think that the actual script will
> be
> > >> added in that project.
> > >
> > > Again this is sensible. Thank you for clarifying things.
> > >
> > > Chris
> >
> > Best regards
> >
> > Christian
> > --
> > --------------------------------------------
> > 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.
> >
>
> --
> --------------------------------------------
> 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/20200514/7a31d931/attachment-0001.html>
More information about the devel
mailing list