<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Thu, May 7, 2020 at 12:10 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Niteesh,<br>
<br>
On 07/05/2020 06:58, Niteesh G. S. wrote:<br>
[...]<br>
> Is there any chance that we will be working with the new build system<br>
> for this GSoC project?<br>
<br>
I think there is a good chance that the new build system will be added<br>
soon. As far as I know, the current plan is to add it right after the<br>
release. Especially Chris did an awesome work regarding the release and<br>
there are only very few tickets left. Joel is also heavily involved in<br>
testing. So I expect the release any day now.<br>
<br>
> <br>
> I have a few doubts regarding the importing part.<br>
> <br>
> 1) Say we are importing the openfirm code to RTEMS(rtems.git) then we will<br>
> also have to bring in its dependencies like KOBJS which in turn has some<br>
> other<br>
> dependencies. And I am not really sure about this, but after looking at<br>
> the libbsd<br>
> code. This seems to bring in a huge amount of code into RTEMS. If this<br>
> is what<br>
> is going to happen then we could dump libbsd right?<br>
<br>
I don't think that dumping libbsd should be a short term goal and I'm<br>
not sure whether it can be a long term one. There is a lot more in<br>
libbsd than just the bus system.<br>
<br>
As a rough direction for now: libbsd was thought as a network and USB<br>
stack. So you could say that simple and low-level peripherals (like GPIO<br>
handling, serial ports, I2C, ...) are better in RTEMS and high-level<br>
stuff and complex peripherals (like a firewall, VPN, TCP/IP, network<br>
drivers, USB and SD drivers, ...) are better in libbsd.<br>
<br>
I'm also not sure whether importing KOBJS is the right way. The<br>
alternative would be to do the cut right there: Import the openfirm<br>
parts but replace the parts where KOBJS would be used. Maybe you can<br>
think about importing the ofw_fdt.c stuff too but add shortcuts.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The KOBJS would just look up which ofw_fdt_... functions would be<br>
called. We currently don't have any other sources for this kind of<br>
information then the FDT. So you could just map for example OFW_GETPROP<br>
to the ofw_fdt_getprop function. That would remove the KOBJS dependency<br>
(which pulls in a lot of other stuff) but re-use a lot of the already<br>
well tested FreeBSD code.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small"><div><div class="gmail_default">This is what I was trying to convey in one of the previous mails.</div></div><div class="gmail_default"><a href="https://lists.rtems.org/pipermail/devel/2020-May/059717.html" target="_blank">https://lists.rtems.org/pipermail/devel/2020-May/059717.html</a></div><div class="gmail_default">But in that mail, I was planning to replace KOBJLOOKUP.</div><div class="gmail_default">Should I start working on it? From the top of my mind, the following has</div><div class="gmail_default">to be done.</div><div class="gmail_default">1) Import openfirm.c openfirm.h, ofw_fdt.c</div><div class="gmail_default">2) Add ofw_fdt.h since all the functions in ofw_fdt are static.</div></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">Should we also import ofw_if.h? Because that is where OFW_* functions</div><div class="gmail_default" style="font-size:small">are defined or just add a ofw_rtems_map.h which redefines them, instead</div><div class="gmail_default" style="font-size:small">of importing ofw_if.h?</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> 2) If we didn't dump libbsd, won't this cause double initialization of<br>
> few things.<br>
<br>
That's a problem that should be addressed by your GSoC project. One<br>
reason for the suggested FDT based initialization was the situation that<br>
currently is there on the Beagle: Some pin functions are initialized by<br>
the RTEMS drivers with a hard coded value and then they are<br>
re-initialized by the libbsd pinmux driver based on the FDT. I think it<br>
would be optimal if RTEMS would do the initialization based on the FDT<br>
and libbsd would just skip that step.<br>
<br>
You maybe noted: Moving the pinmux stuff from libbsd to RTEMS could be<br>
another use case for a FreeBSD code import. Although I don't want to<br>
urge you into that direction if you don't want to do it (there are<br>
always other solutions) it might has some benefits.<br>
<br>
<br>
> You had already mentioned that libbsd uses some macro magic to avoid name<br>
> collisions that's why I am ignoring that and only worried about double<br>
> initialization.<br>
> <br>
<br>
-- <br>
--------------------------------------------<br>
embedded brains GmbH<br>
Herr Christian Mauderer<br>
Dornierstr. 4<br>
D-82178 Puchheim<br>
Germany<br>
email: <a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
Phone: +49-89-18 94 741 - 18<br>
Fax:   +49-89-18 94 741 - 08<br>
PGP: Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div></div>