GSoC: RTEMS directory for FreeBSD imports
Niteesh G. S.
niteesh.gs at gmail.com
Wed May 13 18:15:59 UTC 2020
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.
Another approach will be to import openfirm.c also and redefine the OFW_*
macro to directly call the respective functions.
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> 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>> 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
> 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/20200513/8ffc585e/attachment-0001.html>
More information about the devel
mailing list