GSoC 2020: Implementation of OFW functions
Christian Mauderer
oss at c-mauderer.de
Wed May 6 15:49:12 UTC 2020
On 06/05/2020 11:31, Niteesh G. S. wrote:
> On Wed, May 6, 2020 at 2:20 PM Christian Mauderer
> <christian.mauderer at embedded-brains.de
> <mailto: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>
> > <mailto: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>
> > <mailto: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.
Hello Niteesh,
do you have some more specific questions? Do you search for a more
general quick start guide? Or some specific topics?
By the way: I'm new to the new build system too. But I have to learn it
anyway so I'm happy to try to answer questions too.
Best regards
Christian
>
>
> >
> > 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
> <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.
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
More information about the devel
mailing list