GSoC: RTEMS directory for FreeBSD imports

[Chris Johns]

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.

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