GSoC: RTEMS directory for FreeBSD imports

Mon May 11 06:55:10 UTC 2020

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

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.

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

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

Best regards

Christian

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

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.