GSoC 2020: Implementation of OFW functions
Christian Mauderer
christian.mauderer at embedded-brains.de
Wed May 6 08:50:01 UTC 2020
Hello Niteesh,
On 06/05/2020 10:42, Niteesh G. S. wrote:
> On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee <vijay at rtems.org
> <mailto:vijay at rtems.org>> wrote:
>
>
>
> On Tue, May 5, 2020 at 10:40 PM Niteesh G. S. <niteesh.gs at gmail.com
> <mailto:niteesh.gs at gmail.com>> 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
>
> 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
>
> Hi Niteesh,
>
> The initial plan of your project was to implement the whole FDT
> support on RTEMS,
> but there's already support through libbsd, so it might be a better
> solution to port any
> remaining drivers from freebsd through libbsd and adapt the BSP
> drivers to use the
> freebsd FDT stack. This needs some discussion and input from other
> people to form
> the right plan and work accordingly.
>
>
> But this would require even the smallest example to link to rtems-libbsd.
> Is it okay for this to happen?
>From my point of view: No. It would mean that none of the RTEMS tests
could be build anymore. And I'm not sure whether it would be a good idea
for applications. There are use cases where you don't need a network stack.
But I'm not the only one with an opinion. So please wait for further
comments on that.
> During the proposal period, Hesham also mentioned about this. I think the
> comments are still there in the google docs. And also won't this cause
> the drivers
> to initialized only after initialization of libbsd?
>
I think at least some basic drivers have to work before libbsd. For
example the console.
Please also take a look at Sebastians suggestion. He mentioned that it
might could be an idea to import some FreeBSD stuff directly into RTEMS
with the new build system.
>
> 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).
>
> The openfirm.h is already ported in libbsd and is being used by some
> driver ported
> through libbsd (like i2c).
>
> I understand this. Maybe I didn't explain this properly. The
> implementation of the
> functions in openfirm.c depends on functions in that automatically
> generated file.
> Then this generated file depends on KOBJS.
>
> The functions in ofw_in.h(generated file) basically lookup for a
> particular function
> associated with kobj(ofw_obj).
> For eg: the OF_getprop in openfirm.c calls OFW_GETPROP(auto-generated)
> which then looks up for the ofw_fdt_get_prop(ofw_fdt.c) function
> associated with
> the ofw_obj.
> Based on this my initial intention was to redefine the KOBJSLOOKUP macro in
> RTEMS(rtems.git) to directly call the associated functions using some
> macro magic.
> But I now realized that this could be break when linked to rtems-libbsd.
>
Note that a lot of stuff in libbsd is put in it's own namespace (with
some preprocessor magic). So it should be quite possible to have a lot
of stuff with the same names if this is necessary.
Of course it would be better to have not too much overlap between the
functionality in RTEMS and libbsd. So it could mean that adding stuff to
RTEMS means that it should be removed from libbsd.
>
>
> To help you understand the structure of the libbsd:
> * The files in freebsd/ directory are already ported to RTEMS.
> * The freebsd-org/ is the git submodule that has the original source
> of the freebsd.
> * The rtemsbsd/ has the codes that we added to adapt the freebsd codes.
>
> The *_if.h files are generally automatically generated from the
> *_if.m files.
> The ofw_if.h has already been ported, you can find the generated header
> file in rtemsbsd/include/rtems/bsd/local/ofw_if.h so there's no need
> to do it
> again. If future if there's a need to do it, we generally add a
> recipe to build
> the h files from the .m files in the Makefile.todo . You can have a
> look at it
> if you want, it's simple to follow.
>
> I had just spent a few hours going through the code. If I had
> missed something
> please let me know.
>
> You're in the right direction. We need to wait a bit to get some
> input from
> the community and progress accordingly.
>
> Best regards,
> Vijay
>
> Thanks,
> Niteesh.
>
--
--------------------------------------------
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.
More information about the devel
mailing list