GSoC 2020: Implementation of OFW functions
Niteesh G. S.
niteesh.gs at gmail.com
Sat May 9 09:28:25 UTC 2020
On Sat, May 9, 2020 at 11:56 AM Christian Mauderer <oss at c-mauderer.de>
wrote:
>
>
> On 08/05/2020 23:05, Gedare Bloom wrote:
> > On Fri, May 8, 2020 at 9:34 AM Christian Mauderer <oss at c-mauderer.de>
> wrote:
> >>
> >>
> >> On 08/05/2020 17:26, Niteesh G. S. wrote:
> >>> On Fri, May 8, 2020 at 11:43 AM Christian Mauderer
> >>> <christian.mauderer at embedded-brains.de
> >>> <mailto:christian.mauderer at embedded-brains.de>> wrote:
> >>>
> >>>
> >>> On 07/05/2020 17:19, Niteesh G. S. wrote:
> >>> > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber
> >>> > <sebastian.huber at embedded-brains.de
> >>> <mailto:sebastian.huber at embedded-brains.de>
> >>> > <mailto:sebastian.huber at embedded-brains.de
> >>> <mailto:sebastian.huber at embedded-brains.de>>> wrote:
> >>> >
> >>> > On 07/05/2020 12:28, Niteesh G. S. wrote:
> >>> >
> >>> > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber
> >>> > > <sebastian.huber at embedded-brains.de
> >>> <mailto:sebastian.huber at embedded-brains.de>
> >>> > <mailto:sebastian.huber at embedded-brains.de
> >>> <mailto:sebastian.huber at embedded-brains.de>>
> >>> > > <mailto:sebastian.huber at embedded-brains.de
> >>> <mailto:sebastian.huber at embedded-brains.de>
> >>> > <mailto:sebastian.huber at embedded-brains.de
> >>> <mailto:sebastian.huber at embedded-brains.de>>>> wrote:
> >>> > >
> >>> > > On 07/05/2020 09:35, Niteesh G. S. wrote:
> >>> > >
> >>> > > > This is what I was trying to convey in one of the
> previous
> >>> > mails.
> >>> > > >
> >>> https://lists.rtems.org/pipermail/devel/2020-May/059717.html
> >>> > > > But in that mail, I was planning to replace
> KOBJLOOKUP.
> >>> > > > Should I start working on it? From the top of my
> mind, the
> >>> > > following has
> >>> > > > to be done.
> >>> > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c
> >>> > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt
> >>> are static.
> >>> > > > Should we also import ofw_if.h? Because that is where
> >>> OFW_*
> >>> > > functions
> >>> > > > are defined or just add a ofw_rtems_map.h which
> >>> redefines them,
> >>> > > instead
> >>> > > > of importing ofw_if.h?
> >>> > >
> >>> > > The KOBJ stuff in the OFW support enables FreeBSD to
> >>> have three
> >>> > > different implementations of the OFW API which can be
> >>> selected at
> >>> > > runtime:
> >>> > >
> >>> > > sys/powerpc/ofw/ofw_real.c
> >>> > > sys/dev/ofw/ofw_standard.c
> >>> > > sys/dev/ofw/ofw_fdt.c
> >>> > >
> >>> > > In libbsd this is already short cut to the FDT
> >>> implementation:
> >>> > >
> >>> > > #ifndef __rtems__
> >>> > > static ofw_def_t *ofw_def_impl = NULL;
> >>> > > #else /* __rtems__ */
> >>> > > #define ofw_def_impl (&ofw_fdt)
> >>> > > #endif /* __rtems__ */
> >>> > >
> >>> > > To me this looks like the KOBJ stuff was just used to
> >>> enable some
> >>> > > sort
> >>> > > of object oriented programming. Do we need this
> >>> flexibility at
> >>> > > runtime
> >>> > > in RTEMS? I would say no. I would hard wire this to
> the FDT
> >>> > > implementation. If someone has a problem with it in the
> >>> > future, this
> >>> > > decision can be readdressed.
> >>> > >
> >>> > >
> >>> > > Ok. But what is the neatest way to hardwire this to the FDT
> >>> > > implementation?
> >>> > > One way as Christian mentioned would be to redefine OFW_*
> >>> functions to
> >>> > > call the functions in ofw_fdt.c directly. Is there any
> other
> >>> way?
> >>> >
> >>> > I would try to replace the function declarations in
> openfirm.h
> >>> with
> >>> > inline functions which call the ofw_fdt.c functions.
> >>> >
> >>> >
> >>> > Should I proceed with the above method? or should I wait for
> others
> >>> > to comment?
> >>> > If I can proceed, the following is what I will be doing.
> >>> > 1) import openfirm.h and ofw_fdt.c into RTEMS.
> >>> > 2) Add ofw_fdt.h with functions declarations for functions in
> >>> ofw_fdt.c
> >>> > 3) Add necessary compile-time guards. This would include using
> >>> __rtems__
> >>> > preprocessor directive to avoid FreeBSD stuff and change the
> function
> >>> > definitions in ofw_fdt.c from static to non-static.
> >>> > Am I missing something? or is there any other way to do this?
> >>>
> >>> Maybe wait one or two more days for others to comment. For me the
> >>> direction sounds OK.
> >>>
> >>> You maybe can start thinking about where you want to import the
> >>> files to.
> >>>
> >>>
> >>> Since this has scope for future development. I think we should put it
> in a
> >>> separate directory under cpukit/include/ofw for header files and
> cpukit/ofw
> >>> for the source files. What do you think?
> >>>
> >>>
> >>
> >> If you plan to prepare a FreeBSD sync (regardless whether you implement
> >> it or someone else) another possibility could be to create a similar
> >> directory structure like in libbsd.
> >>
> >> Another directory could be ./cpukit/libmisc/rtems-fdt.
> >>
> >> But your suggestion is also possible.
> >>
> >> Maybe wait for some further input.
> >>
>
> First: I think it would be good to discuss a location as a _preparation_
> for a FreeBSD import. Implementing that would be a massive change of the
> target for Niteeshs project. If he want to do that, I don't have a
> problem with the change of direction. But I don't have a problem with
> the original target too.
>
> Niteesh: Are you interested in the FreeBSD import more then in your
> original target? I think that would mean that a big part of your project
> would target the new build system. I really don't want to urge you into
> any direction here. So please choose whatever you want.
>
I would like to continue with the original project rather than the FreeBSD
sync. This is mainly due to the complexity involved with the project and
my lack of knowledge.
> >
> > This thread got a bit massive. It might be nice to refactor to a clean
> > mail thread :) I'd be agreeable to the idea of a sync to freebsd for
> > external sources that we import to rtems.git, but the management of
> > that sync has to be done carefully and we must keep in mind the needs
> > of low-end targets. I wouldn't like to see too much feature creep from
> > freebsd into rtems in order to support some things meant for only a
> > few relatively resource-rich boards.
>
> Agreed. From my view it would be only for the low level stuff that we
> currently do in RTEMS too. Pin initialization, serial drivers, I2C, SPI.
> Everything more complex like USB, Ethernet should continue to live in
> libbsd.
>
> >
> > If we do this sync, I think it should be handled as a single
> > subdirectory that syncs all imports simultaneously. I don't want to be
> > managing several different imports from various versions of upstream
> > freebsd sources. This would mean something more like cpukit/libfreebsd
> > maybe. Avoid using libbsd, and I think calling it by the upstream name
> > is a good way to proceed. The design and planned implementation of
> > this process needs to be fleshed out and discussed on the ml, and
> > maybe a simple preliminary example/use case (fdt is ok) would be good
> > to sketch, as well as possible future additions and how they would be
> > incorporated.
>
> I'm not entirely sure about that. It could be an advantage to have
> arbitrary locations (also that makes the sync more difficult). Use case:
> BSP drivers. One example that we already have is the imx iomux driver:
>
> https://git.rtems.org/rtems/tree/bsps/arm/imx/start/imx_iomux.c
>
> If that would be in a common directory it might makes it a bit more
> difficult to find which files belong to which BSP.
>
> But of course having a common directory makes it more clear which files
> are imported. So that's a big advantage too. So I'm not really sure
> about which would be the better direction.
> >
> > I also need to be convinced that this code must be pulled into
> > rtems.git and can't be compiled/linked separately.
>
> Example: A pinmux driver. The RAM doesn't work without correct pin muxing.
>
> Best regards
>
> Christian
>
> >
> > Gedare
> >
> >> Best regards
> >>
> >> Christian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200509/5c95c86d/attachment-0001.html>
More information about the devel
mailing list