On 11/5/20 4:55 pm, Christian Mauderer wrote:
On 11/05/2020 06:57, Chris Johns wrote:
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.
The use case for the OF_... and ofw_... functions is more or less a
simple import from FreeBSD drivers. Beneath that there are some quite
nice shortcuts in the OF_... and ofw_... functions that would have to be
re-implemented in each driver (like ofw_bus_node_status_okay()).
Some drivers already use hacked versions of the functions. For example:
bsps/sparc64/shared/clock/ckinit.c
bsps/arm/imx/start/imx_iomux.c
A use case where the OF_... stuff would have been handy:
For the imx pin initialization I would have loved to just use the
fdt_pinctrl_configure_tree() from FreeBSD. But that one had a lot of
OF_.. stuff. Therefore I had to reimplement that function in a
imx_pinctrl_configure_children(). My implementation basically does
exactly the same thing but uses fdt_... functions instead of the OF_...
functions.
Thanks. I think I understand. The scope seems to be the low level SoC
type initialisation. This makes sense.
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?
I think the first step will be copies. It depends a bit on how well the
functions can be integrated into RTEMS (the "node" parameter maybe is a
bit difficult) but I'm confident that the OF_... and ofw_... stuff can
be replaced sooner or later.
Sure, this is sensible. I am just mapping out in my head how this all
goes together.
> 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.
Although note that I suggested to see the discussion as a _preparation_
for that import. Doing the import right is quite a bit of work. It would
change the target of Niteeshs GSoC project quite a lot. So we should
make sure that a good location is selected and that the same rules like
in libbsd are used. But I don't think that the actual script will be
added in that project.
Again this is sensible. Thank you for clarifying things.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
