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