GSoC 2020: Implementation of OFW functions

Wed May 6 07:28:47 UTC 2020

On 06/05/2020 09:16, Niteesh G. S. wrote:
> On Tue, May 5, 2020 at 11:44 PM Christian Mauderer <oss at c-mauderer.de
> <mailto: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.
> 

No reason to be sorry. As soon as you introduced your project once - now
that it officially starts - you can assume that everyone knows about it.
I'm just not sure whether everyone watched the whole GSoC preparation mails.

>  
> 
>     >
>     > 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.

No, because it hasn't been mails. And it have been only a few comments
about the direction without any relevant content. But you just did
everything necessary: Re-started a discussion whether that direction is OK.

> 
> 
>     > 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.

Let's just wait for some further comments on that. From my view
importing ofwbus isn't really the best idea because it most likely has a
lot of dependencies. And I'm really not sure whether we want all these
during system start.

> 
>     >
>     > 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.
> 

Sorry for not beeing clear. I see RTEMS as the core in the rtems.git
repository. rtems-libbsd is an add on library. Most BSPs can and should
offer at least some basic functions without libbsd. For example, I don't
think that it would be a good idea to depend on libbsd for console output.

You plan to add some functionality that is there in libbsd to the RTEMS
core repository. With that these functionality will be there two times.
If it is compatible the new stuff maybe should replace some parts from
libbsd. But I'm not sure whether that is possible (buses could be a
problem!).

>      
> 
>     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
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.