On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee <vi...@rtems.org> wrote:
> > > On Tue, May 5, 2020 at 10:40 PM Niteesh G. S. <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? 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? > 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. > 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. >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel