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