GSoC 2020: Implementation of OFW functions

[Christian Mauderer]

On 06/05/2020 06:58, Sebastian Huber 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.
>>
>> 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.

That could be a really nice functionality. Especially seeing that we
already have quite some imported files. For example

   https://git.rtems.org/rtems/tree/bsps/arm/imx/start/imx_iomux.c


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