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 <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.
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.maude...@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. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
