On Thu, May 14, 2020 at 4:30 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote:
> On 13/05/2020 20:15, Niteesh G. S. wrote: > > Hello, > > > > This mail is to regain attention for this topic and also to discuss a > > few details > > regarding the porting process. > > > > In the previous thread, Sebastian mentioned that we will be hard wiring > > the OF > > functions with the FDT implementation. For reasons please have a look at > > previous thread. > > https://lists.rtems.org/pipermail/devel/2020-May/059762.html > > This will be achieved by inlining the functions in openfirm.h with > functions > > defined in ofw_fdt.c. This approach is valid for most functions but not > all. > > Since not all functions have a one to one mapping. > > > > For example, > > The OF_peer can be directly mapped to ofw_fdt_peer. > > But for OF_getencprop it calls ofw_fdt_getprop after few > manipulations. > > Inlining these functions doesn't seem like a good practice for me. > > > > One way to approach this would be to add the implementation for these > > functions in > > ofw_fdt.c but this would cause code redundancy if we plan to import > > openfirm.c > > in future since these functions are already defined in openfirm.c. > > Are the functions exact clones of the the ones in openfirm.c? In that > case I would suggest to import openfirm.c and put #ifndef __rtems__ > around everything you don't need. Eveni if it means that you only use > 10% of the file. > Yes, implementation of the mentioned functions(OF_getencprop, OF_getencprop_alloc etc) will be a copy of the ones in openfirm.c. > > > > Another approach will be to import openfirm.c also and redefine the OFW_* > > macro to directly call the respective functions. > > That sounds like a better aproach. > We can also call the respective functions directly from the functions in openfirm.c instead of redefining the OFW_* macro. Which one do you prefer? I will wait for a couple for everyone to participate in the discussion and then start implementing it. > > > I don't really know if there is any other better way to approach this. > > Any suggestion on > > how to proceed. > > > > Once this is resolved I will proceed with the porting even if we haven't > > finalized the > > directory since it is just a matter of moving files once we are > finalized. > > > > If you think this is too early to start with coding for GSoC please > > understand that my > > university exams haven't been conducted yet. And due to the COVID > > pandemic, the > > dates are quite uncertain. But it is mostly expected to happen during > > the coding period (july/aug) > > and this would eat up quite a lot of time. So just to be one the safe > > side I started > > quite early. > > > > Thank, > > Niteesh. > > > > On Mon, May 11, 2020 at 12:48 PM Christian Mauderer > > <christian.maude...@embedded-brains.de > > <mailto:christian.maude...@embedded-brains.de>> wrote: > > > > 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> > > >>>> <mailto: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 > > <mailto: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. > > > > -- > -------------------------------------------- > 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
