GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

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.

> 
> 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.