GSoC 2020: Implementation of OFW functions
Christian Mauderer
oss at c-mauderer.de
Sat May 9 06:26:36 UTC 2020
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.
>
> 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
More information about the devel
mailing list