GSoC 2020: Implementation of OFW functions

[Niteesh G. S.]

On Thu, May 7, 2020 at 12:10 PM Christian Mauderer <
christian.mauderer at embedded-brains.de> wrote:

> Hello Niteesh,
>
> On 07/05/2020 06:58, Niteesh G. S. wrote:
> [...]
> > Is there any chance that we will be working with the new build system
> > for this GSoC project?
>
> I think there is a good chance that the new build system will be added
> soon. As far as I know, the current plan is to add it right after the
> release. Especially Chris did an awesome work regarding the release and
> there are only very few tickets left. Joel is also heavily involved in
> testing. So I expect the release any day now.
>
> >
> > 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?
>
> I don't think that dumping libbsd should be a short term goal and I'm
> not sure whether it can be a long term one. There is a lot more in
> libbsd than just the bus system.
>
> As a rough direction for now: libbsd was thought as a network and USB
> stack. So you could say that simple and low-level peripherals (like GPIO
> handling, serial ports, I2C, ...) are better in RTEMS and high-level
> stuff and complex peripherals (like a firewall, VPN, TCP/IP, network
> drivers, USB and SD drivers, ...) are better in libbsd.
>
> I'm also not sure whether importing KOBJS is the right way. The
> alternative would be to do the cut right there: Import the openfirm
> parts but replace the parts where KOBJS would be used. Maybe you can
> think about importing the ofw_fdt.c stuff too but add shortcuts.



> The KOBJS would just look up which ofw_fdt_... functions would be
> called. We currently don't have any other sources for this kind of
> information then the FDT. So you could just map for example OFW_GETPROP
> to the ofw_fdt_getprop function. That would remove the KOBJS dependency
> (which pulls in a lot of other stuff) but re-use a lot of the already
> well tested FreeBSD code.
>

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?



> >
> > 2) If we didn't dump libbsd, won't this cause double initialization of
> > few things.
>
> That's a problem that should be addressed by your GSoC project. One
> reason for the suggested FDT based initialization was the situation that
> currently is there on the Beagle: Some pin functions are initialized by
> the RTEMS drivers with a hard coded value and then they are
> re-initialized by the libbsd pinmux driver based on the FDT. I think it
> would be optimal if RTEMS would do the initialization based on the FDT
> and libbsd would just skip that step.
>
> You maybe noted: Moving the pinmux stuff from libbsd to RTEMS could be
> another use case for a FreeBSD code import. Although I don't want to
> urge you into that direction if you don't want to do it (there are
> always other solutions) it might has some benefits.
>
>
> > 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.
> >
>
> --
> --------------------------------------------
> 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/20200507/33876072/attachment.html>