GSoC 2020: Implementation of OFW functions

[Gedare Bloom]

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.

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