GSoC 2020: Implementation of OFW functions

[Niteesh G. S.]

On Tue, May 5, 2020 at 11:44 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.
>

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200506/60ce79b8/attachment-0001.html>