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.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
