GSoC: RTEMS directory for FreeBSD imports

[Chris Johns]

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?

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

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

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

Chris

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