GSoC: Porting OFW to RTEMS

[Niteesh G. S.]

On Tue, May 26, 2020 at 11:26 PM Christian Mauderer <oss at c-mauderer.de>
wrote:

> Hello Niteesh,
>
> On 25/05/2020 11:20, Niteesh G. S. wrote:
> > Hello,
> >
> > I have completed the porting of the OFW code from FreeBSD to RTEMS.
> > I do acknowledge the fact that we haven't decided on the directory for
> files
> > to be placed in. The previous conversation had stopped quite a while ago.
> > Christian suggested I work on the patch since that would also start the
> > conversation again and also refactoring the patch to the correct
> directory
> > will not be much of work.
> >
> > cpukit/libfreebsd was suggested as one of the directories to place the
> > ported
> > FreeBSD files. It is suggested to place all the source files under this
> > directory.
> > Since this will make the sync part easier. But this causes issues when
> > porting
> > BSP dependent files. Since RTEMS currently doesn't allow files in cpukit
> to
> > reference bsp headers. I faced a similar issue during my porting process
> > also.
> > The OFW init function require bsp_fdt_get function to get a reference to
> > the fdt
> > blob. But I can't include the bsp/fdt.h header file from a source file
> > under cpukit.
> > We must decide the directory quickly because my project will import other
> > FreeBSD sources like the pinmux driver for beaglebone into RTEMS.
>
> Do you have a suggestion for another directory?
>
> If cpukit makes problems (which it clearly does due to the BSP
> dependencies) maybe something in bsps/shared?
>

The more organized way, in my opinion, will be to have the source files
in their respective directories. This is would make more sense than having
all source files under a single directory. But as discussed in the previous
mailing list using this approach will make it harder for the person writing
the sync script. I also have no idea of what complexity goes behind such
a script. So points from the person who's most probably going to write the
script will be really important.


> >
> > https://github.com/gs-niteesh/rtems/commits/ofw_branch
>
> For small patches it would be better to send them to the list using "git
> send-email". That allows to comment directly on the patches. But in this
> case using a repo is OK because especially the import is quite big.
>

Once we have a decent enough patch I'll send it to the mailing list.


> I'll add comments for small stuff directly on github. I hope that works ;-)
>
> Best regards
>
> Christian
>
> > Please have a look at the last 6 patches for the ported work.
> > Below is a short summary of the patch.
> > * The openfirm.h is the OF interface that will provided to the user.
> > * The openfirm.c contains the function definition for openfirm.h. The
> > functions
> > call the respective OFW_* functions which are responsible for choosing
> > the correct implementation for OF interface.
> > * ofw_if.h is the replacement for ofw_if.h in FreeBSD. This is an auto
> > generated
> > header in FreeBSD which choose the correct OF implementation(ofw_fdt,
> > ofw_std,
> > ofw_32bit, ofw_real). In RTEMS we directly map to the FDT implementation
> as
> > suggested by Sebastian.
> > * ofw_fdt.c contains the fdt implementation of OF interface.
> >
> > Thanks,
> > Niteesh.
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200527/b8d6d7ee/attachment.html>