GSoC: RTEMS directory for FreeBSD imports
Christian Mauderer
christian.mauderer at embedded-brains.de
Mon May 11 07:18:33 UTC 2020
On 11/05/2020 09:11, Chris Johns wrote:
> 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 <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.
>
> Thanks. I think I understand. The scope seems to be the low level SoC
> type initialisation. This makes sense.
And maybe some low level drivers like serial or I2C. I don't think that
we should go much further in complexity. Basically everything that is
beyond getting the board up and running is more of a libbsd topic.
>
>>>> 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.
>
That's fine and necessary. It's good if we find critical points before
Niteesh starts to add stuff.
For the OF and ofw parts I'm a bit worried about the node parameter. But
I'm sure we find a solution.
>>>> > 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
Best regards
Christian
--
--------------------------------------------
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.
More information about the devel
mailing list