GSoC 2020: Implementation of OFW functions

[Sebastian Huber]

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.
>
> 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
yes, what we have currently is a series of hacks and I am glad that we 
have now the opportunity to fix this.
>
> My initial thoughts were to implement these functions one by one. But then
> Christian and Vijay mentioned about porting them from libbsd. I went
> through the OFW code in libbsd and have described my porting process 
> below.
> 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
>
> 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).
>
> I had just spent a few hours going through the code. If I had missed 
> something
> please let me know.

This is a good analysis.

I am not sure if it is a good idea to replace the KOBJS support. This 
mechanism may be used in device drivers. I would try to make it optional.

I am strongly opposed to reinvent the wheel in this area. If an existing 
library with the right license fits our needs, then we should use and 
improve it. FreeBSD has an active community and from my experience it is 
easy to integrate changes. With the libbsd we have the ability to stay 
in synchronization with the FreeBSD upstream. This is done through the 
import/export script freebsd-to-rtems.py and a Git rebase in the FreeBSD 
Git clone. If you want to include bigger chunks of code from FreeBSD in 
RTEMS, then we should add this ability also to RTEMS. With the new build 
system, this would be easy. We could add an attribute (for example 
"synchronize-with: freebsd") to the objects items, e.g.

https://git.rtems.org/sebh/rtems.git/tree/spec/build/cpukit/libjffs2.yml?h=build

A script could load the build items and pick up the ones with 
synchronize-with == freebsd and then perform the import/export job. This 
could be also used for other areas, e.g. JFFS2, the dtc, the libcrypto 
stuff, etc.