GSoC: RTEMS directory for FreeBSD imports

[Niteesh G. S.]

On Mon, May 11, 2020 at 4:34 AM Chris Johns <chrisj at rtems.org> wrote:

> On 10/5/20 6:17 pm, Niteesh G. S. wrote:
> > This thread is a continuation of "GSoC 2020: Implementation of OFW
> > functions".
> >
> > A summary of points discussed in that thread is given below.
> >
> > Below is a short description of my GSoC project. For more information
> please
> > refer to the wiki.
> > https://devel.rtems.org/wiki/GSoC/2020/Beagle_FDT_initialization
> > My GSoC project deals with refactoring the Beagle BSP to add support for
> FDT
> > based initialization. As part of this process, I will have to import the
> > pin mux driver
> > into RTEMS which currently is present in libBSD.
> > This would require having support for OFW functions which are currently
> > not implemented
> > in RTEMS. Some drivers(eg: imx_iomux.c) which require these functions
> > provide
> > a local implementation using libFDT.
>
> I hope you do not mind if I wind back a couple of steps...
>
> OFW? Is this http://wiki.laptop.org/go/Open_Firmware?

How does OFW related to FDT?
>

We are only interested in the device tree interface provided by the OF.
Functions like OF_getprop, OF_parent, etc.



>
> You discuss importing drivers from FreeBSD? Do you know which core
> FreeBSD pieces would need to also come over for the drivers listed below?
>

We had discussed this in the previous thread.
https://lists.rtems.org/pipermail/devel/2020-May/059765.html
For OF_* functions we will only have to import the following files.
1) openfirm.h
2) ofw_fdt.c


> Is seamless integration with rtems-libbsd required or does it also
> include copies of the same code?
>

I am sorry. I don't really understand what you are asking :(.


>
> > In the previous thread, it has been decided to import the OFW functions
> from
> > FreeBSD but the directory where it has to be imported into RTEMS is not
> yet
> > decided. This thread has been created to discuss it.
> > It should also be noted that some drivers for example I2C, SPI are being
> > imported
> > into RTEMS from FreeBSD for some BSPs.
> > Now, since a large amount of code being imported from FreeBSD it is
> > planned to
> > add to a synchronization script(Yet to discussed in detail) to stay in
> > sync with
> > FreeBSD.
> >
> > So now is it necessary to choose a directory that is future compatible
> > with the
> > synchronization script. We should also discuss if we want to have all
> > imports
> > under a single directory or have the imports in their respective
> > directories for eg
> > a device driver could be placed in its BSP directories than in a common
> > folder
> > along with other imports. But it should also be noted that the latter
> > makes it
> > difficult to sync and the former.
>
> Gedare covered these issues in the other thread in an excellent post [1]
> and I would like to reference that as I agree with it.
>
> When importing from such a large and complex code base like FreeBSD we
> need to be careful we do not pull on a thread and pull in large pieces
> of FreeBSD.
>
> Gedare's point about making sure all imported pieces are from the same
> version is important and I think a base requirement.
>
> I am OK with some code being in rtems.git if there is a clear use
> outside of rtems-libbsd. FDT support is one use, another is the NFS
> client code in FreeBSD being used with the legacy stack (there are BSPs
> with only legacy driver support still in use) and the existing client is
> only NFSv2.
>
> We need a place to collect the common base parts of FreeBSD that are
> shared by the various imported pieces. Isolated pieces could lead to
> repeated imports common pieces if we do not do this.
>
> I believe Sebastian said the new build system should handle the
> synchronisation? This is a good idea. Could it manage separated pieces?
> Could the build system read in all the sync pieces and logically join
> them based on the upstream source and operate on them as a group? This
> way we can have drivers in a BSP, NFS in libnfs (or where ever).
>

I am not really familiar with the new build system. So can we please wait
until Sebastian answers this.





> Chris
>
> [1] https://lists.rtems.org/pipermail/devel/2020-May/059807.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200511/0d80c77c/attachment.html>