GSoC: RTEMS directory for FreeBSD imports

[Chris Johns]

On 11/5/20 2:03 pm, Niteesh G. S. wrote:
> On Mon, May 11, 2020 at 4:34 AM Chris Johns <chrisj at rtems.org 
> <mailto: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.
> 

Why not call libfdt functions? I am wondering what there is in FreeBSD 
that is calling these functions? I am not questioning the need, it is a 
case of not understanding the dependency.

>     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

You say below some drivers are being imported from FreeBSD, it is these 
I am asking about.

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

I am asking if the changes effect rtems-libbsd?

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

Sure.

Chris

> 
> 
> 
>     Chris
> 
>     [1] https://lists.rtems.org/pipermail/devel/2020-May/059807.html
>