GSoC: RTEMS directory for FreeBSD imports
Christian Mauderer
christian.mauderer at embedded-brains.de
Thu May 14 11:00:36 UTC 2020
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.
>
> 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.
>
> 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.
More information about the devel
mailing list