<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">On Wed, May 6, 2020 at 9:18 PM Christian Mauderer <<a href="mailto:contact@c-mauderer.de">contact@c-mauderer.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">On 06/05/2020 11:31, Niteesh G. S. wrote:<br>
> On Wed, May 6, 2020 at 2:20 PM Christian Mauderer<br>
> <<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a><br>
> <mailto:<a href="mailto:christian.mauderer@embedded-brains.de" target="_blank">christian.mauderer@embedded-brains.de</a>>> wrote:<br>
> <br>
> 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<br>
> <<a href="mailto:vijay@rtems.org" target="_blank">vijay@rtems.org</a> <mailto:<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> <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.<br>
> <<a href="mailto:niteesh.gs@gmail.com" target="_blank">niteesh.gs@gmail.com</a> <mailto:<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> <mailto:<a href="mailto:niteesh.gs@gmail.com" target="_blank">niteesh.gs@gmail.com</a>>>><br>
> wrote:<br>
> ><br>
> > This is thread is about implementing OFW functions in<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> 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>
> <br>
> <br>
> I am going through the new build system docs and code to understand how<br>
> this importing works.<br>
> <a href="https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf" rel="noreferrer" target="_blank">https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf</a><br>
> <a href="https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf" rel="noreferrer" target="_blank">https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf</a><br>
> <br>
> But some more guidance from Sebastian will be really helpful.<br>
<br>
Hello Niteesh,<br>
<br>
do you have some more specific questions? Do you search for a more<br>
general quick start guide? Or some specific topics?<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I couldn't go through it yesterday. Today I started off with building rtems6</div><div class="gmail_default" style="font-size:small">toolchain for arm using RSB but failed. I used the following command</div><div class="gmail_default" style="font-size:small">../source-builder/sb-set-builder --prefix=/home/niteesh/development/rtems/6 6/rtems-arm --jobs=8<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The problem seems to happen when trying to download the sources for GCC. I have</div><div class="gmail_default" style="font-size:small">attached the complete log file to this mail. I have also pasted the last few lines below.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">-------------------------------------------------------------------------</div><div class="gmail_default" style="font-size:small">download: (full) <a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz">https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz</a> -> sources/gcc-1dae549.tar.gz<br>download: <a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz">https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz</a> -> sources/gcc-1dae549.tar.gz<br>download: no ssl context<br>download: <a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz">https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz</a>: error: HTTP Error 403: Forbidden<br>error: downloading <a href="https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz">https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;a=snapshot;h=1dae549;sf=tgz</a>: all paths have failed, giving up<br></div><div class="gmail_default" style="font-size:small">-------------------------------------------------------------------------</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I will build RTEMS using the new build system as soon as the above issue gets resolved.</div><div class="gmail_default" style="font-size:small">I also went through the user manual and skimmed through the soft. eng. guide to understand</div><div class="gmail_default" style="font-size:small">the new build system. </div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_default" style="font-size:small">Is there any chance that we will be working with the new build system for this GSoC project?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have a few doubts regarding the importing part.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Say we are importing the openfirm code to RTEMS(rtems.git) then we will</div><div class="gmail_default" style="font-size:small">also have to bring in its dependencies like KOBJS which in turn has some other</div><div class="gmail_default" style="font-size:small">dependencies. And I am not really sure about this, but after looking at the libbsd</div><div class="gmail_default" style="font-size:small">code. This seems to bring in a huge amount of code into RTEMS. If this is what</div><div class="gmail_default" style="font-size:small">is going to happen then we could dump libbsd right?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">2) If we didn't dump libbsd, won't this cause double initialization of few things.</div><div class="gmail_default" style="font-size:small">You had already mentioned that libbsd uses some macro magic to avoid name</div><div class="gmail_default" style="font-size:small">collisions that's why I am ignoring that and only worried about double initialization.</div><div class="gmail_default" style="font-size:small"><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">
By the way: I'm new to the new build system too. But I have to learn it<br>
anyway so I'm happy to try to answer questions too.<br>
<br>
Best regards<br>
<br>
Christian<br>
<br>
> <br>
> <br>
> ><br>
> > After going through some open firmware documentation. I<br>
> 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<br>
> 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<br>
> 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<br>
> 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<br>
> source<br>
> > of the freebsd.<br>
> > * The rtemsbsd/ has the codes that we added to adapt the<br>
> 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<br>
> generated header<br>
> > file in rtemsbsd/include/rtems/bsd/local/ofw_if.h so there's<br>
> 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<br>
> 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>
> <mailto:<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>
> <br>
> <br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
> <br>
</blockquote></div></div>