GSoC 2020: Implementation of OFW functions
Niteesh G. S.
niteesh.gs at gmail.com
Thu May 7 04:58:00 UTC 2020
On Wed, May 6, 2020 at 9:18 PM Christian Mauderer <contact at c-mauderer.de>
wrote:
> 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?
>
I couldn't go through it yesterday. Today I started off with building rtems6
toolchain for arm using RSB but failed. I used the following command
../source-builder/sb-set-builder --prefix=/home/niteesh/development/rtems/6
6/rtems-arm --jobs=8
The problem seems to happen when trying to download the sources for GCC. I
have
attached the complete log file to this mail. I have also pasted the last
few lines below.
-------------------------------------------------------------------------
download: (full)
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz ->
sources/gcc-1dae549.tar.gz
download:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz ->
sources/gcc-1dae549.tar.gz
download: no ssl context
download:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz:
error: HTTP Error 403: Forbidden
error: downloading
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz:
all paths have failed, giving up
-------------------------------------------------------------------------
I will build RTEMS using the new build system as soon as the above issue
gets resolved.
I also went through the user manual and skimmed through the soft. eng.
guide to understand
the new build system.
Is there any chance that we will be working with the new build system for
this GSoC project?
I have a few doubts regarding the importing part.
1) Say we are importing the openfirm code to RTEMS(rtems.git) then we will
also have to bring in its dependencies like KOBJS which in turn has some
other
dependencies. And I am not really sure about this, but after looking at the
libbsd
code. This seems to bring in a huge amount of code into RTEMS. If this is
what
is going to happen then we could dump libbsd right?
2) If we didn't dump libbsd, won't this cause double initialization of few
things.
You had already mentioned that libbsd uses some macro magic to avoid name
collisions that's why I am ignoring that and only worried about double
initialization.
> 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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200507/18f29c85/attachment-0001.html>
More information about the devel
mailing list