On 11/5/20 2:03 pm, Niteesh G. S. wrote:
On Mon, May 11, 2020 at 4:34 AM Chris Johns <chr...@rtems.org
<mailto:chr...@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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
