On Tue, May 5, 2020 at 11:44 PM Christian Mauderer <o...@c-mauderer.de> wrote:
> Hello Niteesh, > > On 05/05/2020 19:10, Niteesh G. S. 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. > > I'm not sure whether everyone on the list is already fully aware of what > your project is. For some of us the GSoC preparation phase is more of a > background noise. So maybe you want to give a short (only a few > sentences) overview of your target and what is the gain for the RTEMS > project. > I am sorry. I'll make sure that I do that from the next mail onwards. > > > > 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. > > Yes, there has been an offlist discussion whether the approach of a > reimplementing them is a good idea. > Can you forward those mails if possible? Maybe I could gather some ideas from it. > > > I went > > through the OFW code in libbsd and have described my porting process > below. > > If that can be ported, it would be a better approach then reimplementing. > > > 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 > > > > 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 > > OK. Note that these functions often have a "node". Think about what that > is and from where you would get it in an RTEMS driver. I think a lot of > FreeBSD drivers get it from their (logical) bus system like ofwbus. > Yes, the FreeBSD drivers do get their node handles from the buses. One way(hackish) to accomplish this would be to create a dummy dev structure which will be initialized during driver initialization. And then the drivers could query the node handles from it. But as mentioned this would be hackish and I don't think will scale well. Another approach will be to import ofwbus itself, but then it would be a huge diversion from my current project. I don't mind working on this if this is the cleanest way to do it. But then we should also consider re-working on the objectives. > > > 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). > > Note that the automatically generated interface is used for the FreeBSD > device driver structure (or rather the bus interface). If you port the > stuff to RTEMS you should think about whether > a) it should replace the libbsd stuff. In that case: What changes would > be necessary to libbsd. I don't get this point. By RTEMS do you mean rtems.git and not rtems-libbsd.git right? Because it is already there in rtems-libbsd. > > b) or whether it should live side by side. > > > > > I had just spent a few hours going through the code. If I had missed > > something > > please let me know. > > > > Thanks, > > Niteesh. > > Best regards > > Christian >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
