<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Wed, May 6, 2020 at 2:20 PM Christian Mauderer <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>> wrote:<br></div></div><div dir="ltr"><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 06/05/2020 10:42, Niteesh G. S. wrote:<br>
> On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a><br>
> <mailto:<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a>>> wrote:<br>
> <br>
> <br>
> <br>
> On Tue, May 5, 2020 at 10:40 PM Niteesh G. S. <<a href="mailto:niteesh.gs@gmail.com" target="_blank">niteesh.gs@gmail.com</a><br>
> <mailto:<a href="mailto:niteesh.gs@gmail.com" target="_blank">niteesh.gs@gmail.com</a>>> wrote:<br>
> <br>
> This is thread is about implementing OFW functions in RTEMS as part<br>
> of my GSoC project. I would like to start off with this part<br>
> since the refactoring<br>
> work will somewhat depend on this.<br>
> <br>
> Implementing these functions into RTEMS will make porting<br>
> drivers from<br>
> FreeBSD to RTEMS easy. Currently, the drivers ported from<br>
> freebsd implement<br>
> the functions using libfdt variants but this causes a lot of<br>
> code duplication.<br>
> eg: bsps/arm/imx/start/imx_iomux.c<br>
> <br>
> My initial thoughts were to implement these functions one by<br>
> one. But then<br>
> Christian and Vijay mentioned about porting them from libbsd. I went<br>
> through the OFW code in libbsd and have described my porting<br>
> process below.<br>
> Please have a look at it and let me know if I have missed<br>
> something or you<br>
> would like to improve things.<br>
> <br>
> The following files will be ported from libbsd<br>
> prefix = freebsd/sys/dev/ofw<br>
> <prefix>/openfirm.c<br>
> <prefix>/openfirm.h<br>
> <prefix>/ofw_fdt.c<br>
> <prefix>/ofwvar.h<br>
> <br>
> The main idea is to port openfirm.h but the other files<br>
> are dependencies of openfirm.h<br>
> <br>
> Hi Niteesh,<br>
> <br>
> The initial plan of your project was to implement the whole FDT<br>
> support on RTEMS,<br>
> but there's already support through libbsd, so it might be a better<br>
> solution to port any<br>
> remaining drivers from freebsd through libbsd and adapt the BSP<br>
> drivers to use the<br>
> freebsd FDT stack. This needs some discussion and input from other<br>
> people to form<br>
> the right plan and work accordingly.<br>
> <br>
> <br>
> But this would require even the smallest example to link to rtems-libbsd.<br>
> Is it okay for this to happen?<br>
<br>
>From my point of view: No. It would mean that none of the RTEMS tests<br>
could be build anymore. And I'm not sure whether it would be a good idea<br>
for applications. There are use cases where you don't need a network stack.<br>
<br>
But I'm not the only one with an opinion. So please wait for further<br>
comments on that.<br>
<br>
> During the proposal period, Hesham also mentioned about this. I think the<br>
> comments are still there in the google docs. And also won't this cause<br>
> the drivers<br>
> to initialized only after initialization of libbsd?<br>
> <br>
<br>
I think at least some basic drivers have to work before libbsd. For<br>
example the console.<br>
<br>
Please also take a look at Sebastians suggestion. He mentioned that it<br>
might could be an idea to import some FreeBSD stuff directly into RTEMS<br>
with the new build system.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I am going through the new build system docs and code to understand how</div><div class="gmail_default" style="font-size:small">this importing works.</div><div class="gmail_default" style="font-size:small"><a>https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf</a><br></div><div class="gmail_default" style="font-size:small"><a>https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf</a></div><br></div><div><div class="gmail_default" style="font-size:small">But some more guidance from Sebastian will be really helpful.</div></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>
> After going through some open firmware documentation. I guess as<br>
> far as RTEMS is <br>
> concerned we could avoid many functions like OF_init,<br>
> OF_putchar, OF_test<br>
> and only care about functions defined under openfirm.h:105-142<br>
> <br>
> But these functions have dependency on the automatically<br>
> generated ofw_if.h and KOBJS.<br>
> But after a close inspection, I guess the KOBJSLOOKUP macro in<br>
> ofw_if.h can be<br>
> redefined or replaced for RTEMS. Since all it does is call the<br>
> respective functions defined in ofw_fdt_methods(ofw_fdt.c).<br>
> <br>
> The openfirm.h is already ported in libbsd and is being used by some<br>
> driver ported<br>
> through libbsd (like i2c).<br>
> <br>
> I understand this. Maybe I didn't explain this properly. The<br>
> implementation of the<br>
> functions in openfirm.c depends on functions in that automatically<br>
> generated file.<br>
> Then this generated file depends on KOBJS.<br>
> <br>
> The functions in ofw_in.h(generated file) basically lookup for a<br>
> particular function<br>
> associated with kobj(ofw_obj).<br>
> For eg: the OF_getprop in openfirm.c calls OFW_GETPROP(auto-generated)<br>
> which then looks up for the ofw_fdt_get_prop(ofw_fdt.c) function<br>
> associated with<br>
> the ofw_obj.<br>
> Based on this my initial intention was to redefine the KOBJSLOOKUP macro in<br>
> RTEMS(rtems.git) to directly call the associated functions using some<br>
> macro magic.<br>
> But I now realized that this could be break when linked to rtems-libbsd.<br>
> <br>
<br>
Note that a lot of stuff in libbsd is put in it's own namespace (with<br>
some preprocessor magic). So it should be quite possible to have a lot<br>
of stuff with the same names if this is necessary.<br>
<br>
Of course it would be better to have not too much overlap between the<br>
functionality in RTEMS and libbsd. So it could mean that adding stuff to<br>
RTEMS means that it should be removed from libbsd.<br>
<br>
> <br>
> <br>
> To help you understand the structure of the libbsd:<br>
> * The files in freebsd/ directory are already ported to RTEMS.<br>
> * The freebsd-org/ is the git submodule that has the original source<br>
> of the freebsd.<br>
> * The rtemsbsd/ has the codes that we added to adapt the freebsd codes.<br>
> <br>
> The *_if.h files are generally automatically generated from the<br>
> *_if.m files.<br>
> The ofw_if.h has already been ported, you can find the generated header<br>
> file in rtemsbsd/include/rtems/bsd/local/ofw_if.h so there's no need<br>
> to do it<br>
> again. If future if there's a need to do it, we generally add a<br>
> recipe to build<br>
> the h files from the .m files in the Makefile.todo . You can have a<br>
> look at it<br>
> if you want, it's simple to follow.<br>
> <br>
> I had just spent a few hours going through the code. If I had<br>
> missed something<br>
> please let me know.<br>
> <br>
> You're in the right direction. We need to wait a bit to get some<br>
> input from<br>
> the community and progress accordingly.<br>
> <br>
> Best regards,<br>
> Vijay <br>
> <br>
> Thanks,<br>
> Niteesh.<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>
</div>