On Wed, May 6, 2020 at 1:22 AM Gedare Bloom <ged...@rtems.org> wrote:
> Just to pile on, I have a small port of OFW underneath sparc64, it > would be great to replace it. It might also provide some useful code, > maybe.. Anyway, look at what it is using. Thanks for letting me know about this. It somewhat gives me a direction to head in. While going through the code, I came across ofw_call. I couldn't figure out how it works :(. I tried going through the assembly of the ofw function in ofwasm.S but the ABI of SPARC wasn't easy for me to go through. I am intrigued by how this function works. I also have the following doubts. What is ofw_cif used for? It is some kind of function pointer table? Does ofw_init initialize ofw_cif? Thanks, Niteesh. > > On Tue, May 5, 2020 at 12:20 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. > > > > > > > > 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. > > > > > 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. > > > > > > > > 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. > > > > 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
