GSoC 2020: Implementation of OFW functions

[Niteesh G. S.]

On Wed, May 6, 2020 at 1:22 AM Gedare Bloom <gedare at 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 <oss at 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 at rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200506/9e7f7ae4/attachment.html>