GSoC: RTEMS directory for FreeBSD imports

Christian Mauderer christian.mauderer at embedded-brains.de
Thu May 14 18:19:50 UTC 2020


On 14/05/2020 18:59, Niteesh G. S. wrote:
> On Thu, May 14, 2020 at 4:30 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto: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 would suggest to use the method that is less invasive. For calling the
functions directly you most likely have to do something like that:

#ifndef __rtems__
    OFW_DO_SOMETHING(x, y);
#else /* __rtems__ */
    direct_call_to_function(x, y);
#endif

If someone changes the OFW_DO_SOMETHING line and (for example) add
another condition around it that will trigger a conflict on upgrade.

If you add

#ifdef __rtems__
#define OFW_DO_SOMETHING direct_call_to_function
#endif

that will apply fine on an upgrade. So I would use that one.

> 
> 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>
>     > <mailto: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>>
>     >     >>>> <mailto: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>
>     >     <mailto: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
>     <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.


More information about the devel mailing list