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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
