GSoC 2020: Implementation of OFW functions

Wed May 6 09:31:16 UTC 2020

On Wed, May 6, 2020 at 2:20 PM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:

> Hello Niteesh,
>
> On 06/05/2020 10:42, Niteesh G. S. wrote:
> > On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee <vijay at rtems.org
> > <mailto:vijay at rtems.org>> wrote:
> >
> >
> >
> >     On Tue, May 5, 2020 at 10:40 PM Niteesh G. S. <niteesh.gs at gmail.com
> >     <mailto:niteesh.gs at gmail.com>> wrote:
> >
> >         This is thread is about implementing OFW functions in RTEMS as
> part
> >         of my GSoC project. I would like to start off with this part
> >         since the refactoring
> >         work will somewhat depend on this.
> >
> >         Implementing these functions into RTEMS will make porting
> >         drivers from
> >         FreeBSD to RTEMS easy. Currently, the drivers ported from
> >         freebsd implement
> >         the functions using libfdt variants but this causes a lot of
> >         code duplication.
> >         eg: bsps/arm/imx/start/imx_iomux.c
> >
> >         My initial thoughts were to implement these functions one by
> >         one. But then
> >         Christian and Vijay mentioned about porting them from libbsd. I
> went
> >         through the OFW code in libbsd and have described my porting
> >         process below.
> >         Please have a look at it and let me know if I have missed
> >         something or you
> >         would like to improve things.
> >
> >         The following files will be ported from libbsd
> >         prefix = freebsd/sys/dev/ofw
> >         <prefix>/openfirm.c
> >         <prefix>/openfirm.h
> >         <prefix>/ofw_fdt.c
> >         <prefix>/ofwvar.h
> >
> >         The main idea is to port openfirm.h but the other files
> >         are dependencies of openfirm.h
> >
> >     Hi Niteesh,
> >
> >     The initial plan of your project was to implement the whole FDT
> >     support on RTEMS,
> >     but there's already support through libbsd, so it might be a better
> >     solution to port any
> >     remaining drivers from freebsd through libbsd and adapt the BSP
> >     drivers to use the
> >     freebsd FDT stack. This needs some discussion and input from other
> >     people to form
> >     the right plan and work accordingly.
> >
> >
> > But this would require even the smallest example to link to rtems-libbsd.
> > Is it okay for this to happen?
>
> From my point of view: No. It would mean that none of the RTEMS tests
> could be build anymore. And I'm not sure whether it would be a good idea
> for applications. There are use cases where you don't need a network stack.
>
> But I'm not the only one with an opinion. So please wait for further
> comments on that.
>
> > During the proposal period, Hesham also mentioned about this. I think the
> > comments are still there in the google docs. And also won't this cause
> > the drivers
> > to initialized only after initialization of libbsd?
> >
>
> I think at least some basic drivers have to work before libbsd. For
> example the console.
>
> Please also take a look at Sebastians suggestion. He mentioned that it
> might could be an idea to import some FreeBSD stuff directly into RTEMS
> with the new build system.
>

I am going through the new build system docs and code to understand how
this importing works.
https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf
https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf

But some more guidance from Sebastian will be really helpful.

> >
> >         After going through some open firmware documentation. I guess as
> >         far as RTEMS is
> >         concerned we could avoid many functions like OF_init,
> >         OF_putchar, OF_test
> >         and only care about functions defined under openfirm.h:105-142
> >
> >         But these functions have dependency on the automatically
> >         generated ofw_if.h and KOBJS.
> >         But after a close inspection, I guess the KOBJSLOOKUP macro in
> >         ofw_if.h can be
> >         redefined or replaced for RTEMS. Since all it does is call the
> >         respective functions defined in ofw_fdt_methods(ofw_fdt.c).
> >
> >     The openfirm.h is already ported in libbsd and is being used by some
> >     driver ported
> >     through libbsd (like i2c).
> >
> > I understand this. Maybe I didn't explain this properly. The
> > implementation of the
> > functions in openfirm.c depends on functions in that automatically
> > generated file.
> > Then this generated file depends on KOBJS.
> >
> > The functions in ofw_in.h(generated file) basically lookup for a
> > particular function
> > associated with kobj(ofw_obj).
> > For eg: the OF_getprop in openfirm.c calls OFW_GETPROP(auto-generated)
> > which then looks up for the ofw_fdt_get_prop(ofw_fdt.c) function
> > associated with
> > the ofw_obj.
> > Based on this my initial intention was to redefine the KOBJSLOOKUP macro
> in
> > RTEMS(rtems.git) to directly call the associated functions using some
> > macro magic.
> > But I now realized that this could be break when linked to rtems-libbsd.
> >
>
> Note that a lot of stuff in libbsd is put in it's own namespace (with
> some preprocessor magic). So it should be quite possible to have a lot
> of stuff with the same names if this is necessary.
>
> Of course it would be better to have not too much overlap between the
> functionality in RTEMS and libbsd. So it could mean that adding stuff to
> RTEMS means that it should be removed from libbsd.
>
> >
> >
> >     To help you understand the structure of the libbsd:
> >     * The files in freebsd/ directory are already ported to RTEMS.
> >     * The freebsd-org/ is the git submodule that has the original source
> >     of the freebsd.
> >     * The rtemsbsd/ has the codes that we added to adapt the freebsd
> codes.
> >
> >     The *_if.h files are generally automatically generated from the
> >     *_if.m files.
> >     The ofw_if.h has already been ported, you can find the generated
> header
> >     file in rtemsbsd/include/rtems/bsd/local/ofw_if.h so there's no need
> >     to do it
> >     again. If future if there's a need to do it, we generally add a
> >     recipe to build
> >     the h files from the .m files in the Makefile.todo . You can have a
> >     look at it
> >     if you want, it's simple to follow.
> >
> >         I had just spent a few hours going through the code. If I had
> >         missed something
> >         please let me know.
> >
> >     You're in the right direction. We need to wait a bit to get some
> >     input from
> >     the community and progress accordingly.
> >
> >     Best regards,
> >     Vijay
> >
> >         Thanks,
> >         Niteesh.
> >
>
> --
> --------------------------------------------
> 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/20200506/6a26d47c/attachment-0001.html>