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