GSoC 2020: Implementation of OFW functions

[Niteesh G. S.]

On Tue, May 5, 2020 at 11:46 PM Vijay Kumar Banerjee <vijay at rtems.org>
wrote:

>
>
> On Tue, May 5, 2020 at 10:40 PM Niteesh G. S. <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?
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?


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




> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200506/4788b61a/attachment-0001.html>