Hello Niteesh, On 28/05/2020 17:08, Niteesh G. S. wrote: > Hello Christian, > > On Thu, May 28, 2020 at 8:12 PM Christian Mauderer > <christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de>> wrote: > > Hello Niteesh, > > On 28/05/2020 16:34, Niteesh G. S. wrote: > > > > > > On Wed, May 27, 2020 at 11:25 PM Christian Mauderer > <o...@c-mauderer.de <mailto:o...@c-mauderer.de> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote: > > > > On 27/05/2020 19:32, Niteesh G. S. wrote: > > > > > > > > > On Wed, May 27, 2020 at 12:04 AM Christian Mauderer > > <o...@c-mauderer.de <mailto:o...@c-mauderer.de> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>> > > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote: > > > > > > Hello Niteesh, > > > > > > On 26/05/2020 19:56, Christian Mauderer wrote: > > > > Hello Niteesh, > > > > > > > > On 25/05/2020 11:20, Niteesh G. S. wrote: > > > >> Hello, > > > >> > > > >> I have completed the porting of the OFW code from FreeBSD > > to RTEMS. > > > >> I do acknowledge the fact that we haven't decided on the > > > directory for files > > > >> to be placed in. The previous conversation had > stopped quite a > > > while ago. > > > >> Christian suggested I work on the patch since that > would also > > > start the > > > >> conversation again and also refactoring the patch to the > > correct > > > directory > > > >> will not be much of work. > > > >> > > > >> cpukit/libfreebsd was suggested as one of the > directories to > > > place the > > > >> ported > > > >> FreeBSD files. It is suggested to place all the > source files > > > under this > > > >> directory. > > > >> Since this will make the sync part easier. But this > causes > > issues > > > when > > > >> porting > > > >> BSP dependent files. Since RTEMS currently doesn't allow > > files in > > > cpukit to > > > >> reference bsp headers. I faced a similar issue during my > > porting > > > process > > > >> also. > > > >> The OFW init function require bsp_fdt_get function to > get a > > > reference to > > > >> the fdt > > > >> blob. But I can't include the bsp/fdt.h header file > from a > > source > > > file > > > >> under cpukit. > > > >> We must decide the directory quickly because my > project will > > > import other > > > >> FreeBSD sources like the pinmux driver for beaglebone > into > > RTEMS. > > > > > > > > Do you have a suggestion for another directory? > > > > > > > > If cpukit makes problems (which it clearly does due to > the BSP > > > > dependencies) maybe something in bsps/shared? > > > > > > > >> > > > >> https://github.com/gs-niteesh/rtems/commits/ofw_branch > > > > > > > > For small patches it would be better to send them to > the list > > > using "git > > > > send-email". That allows to comment directly on the > patches. But > > > in this > > > > case using a repo is OK because especially the import is > > quite big. > > > > > > > > I'll add comments for small stuff directly on github. > I hope > > that > > > works ;-) > > > > > > Finished adding comments for small stuff. Some bigger > questions: > > > > > > - How do you plan to include ofw_if.h in some driver > files? RTEMS > > > currently puts every file that can be included with <some.h> > > into a path > > > called "include". > > > > > > > > > Will ofw_if.h be included in driver files? As far as I have > > searched in the > > > FreeBSD sources, other than the OFW implementation none of > the driver > > > files include this header. So this could be placed in the same > > directory as > > > the OFW sources and need not be added to the global include > path. > > > If there is a case where it is included in some driver > please let > > me know. > > > > > > And also all the references to this header in the OFW > > implementations are > > > relative so in future, if we add other implementations, > having it > > in the > > > same > > > directory would be the right choice. > > > > > > > You are right. I didn't have a detailed enough look. The > functions like > > OFW_GETPROP (declared in ofw_if.h) are only used in > openfirm.c. So that > > location is OK. > > > > > > > > > > > - You created quite some commits. I would suggest to > merge all > > porting > > > commits so that you have one import commit, one port commit > > and maybe > > > one commit adding RTEMS specific files > > > > > > > > > I have squashed them into a single port commit. > > > > > > > > > > > > > > > - You have at least one completely hand written file > > (ofw_if.h). Maybe > > > we should think about whether that is located well in > the same > > directory > > > as the imported code or whether a similar structure like > used > > in libbsd > > > would be better. One tree for imported files and one for > RTEMS > > specific > > > hand written ones. > > > > > > > > > Do we need a separate directory for RTEMS specific handwritten > > ones depends > > > on what we will be importing in the future? Since we intend > only to > > > import mostly > > > driver related code I don't think there is a need for a separate > > > directory. I think > > > this way because I assuming we don't need any RTEMS specific > file for > > > the drivers. > > > But if we plan to include some simple subsystem then having > a separate > > > directory > > > will be nice. > > > > Things like that tend to grow. So even if we don't want to > import much > > for now, it's quite possible that it will be more in the future. > > Therefore I would use the future-proof approach even if it is > a bit > > overkill for now. > > > > OK. > > > > > > > > > > > > This also makes me think about if having all sources under a > single > > > directory under > > > cpukit a good idea. Since our main import targets are > drivers placing > > > them in the > > > cpukit directory or any other directory other than their > > respective BSP > > > directory is not > > > a good idea. This would make writing the sync script harder > but this > > > will decrease the > > > coupling and dependencies between various folders. The other way > > around > > > will be > > > to have all headers accessible in the global path i.e. files > under > > > cpukit should be > > > able to access bsp related headers. This would increase the > > coupling but > > > I guess > > > it will make writing the script easier since it has to track > only a > > > single directory. > > > I am not really sure which is a better tradeoff. If someone > could shed > > > some light on > > > the complexity of the script it'll help in coming up with a > conclusion > > > easier. > > > But from a logical perspective, Having the drivers in their > respective > > > directories > > > seems to be a better idea to me. > > > > That really depends. I agree that we only want to import low-level > > drivers. > > > > But also note that it's not always easy to say that driver A > belongs > > exactly to BSP B. For example take a look at some PowerPC > chips and some > > ARM chips. PowerPC has been used a lot by Freescale. Freescale now > > belongs to NXP. NXP started to use the Freescale peripherals > but with an > > ARM core. Therefore now there are quite some modules that use > the same > > driver in ARM chips and in Freescale chips. If you import that > driver to > > an PowerPC you maybe would have to move it later to some > shared section > > if you want to use it in an ARM BSP. > > > > > > I didn't know this I thought we only share across the same > > architectures. So I > > didn't take this into consideration. > > Yes, it's a bit unusual. But it gets more common with programmable > logic. I think we have at least two or three FPGA based cores too. The > peripherals for those can theoretically be the same for all cores. > > > OK. > > > > > So why not just put all the drivers imported from FreeBSD in a > shared > > section right from the start. Keep the directory structure but > move it > > to bsps. I think I suggested it earlier already: What about > > bsps/shared/freebsd or bsps/shared/bsdports? > > > > > > We place the shared drivers in the shared section that is okay. > But what > > about drivers which are unique something like the Beagle I2C or > something > > similar will they be in their respective folders? > > Does it hurt if a driver is placed in the shared folder even if it is > unique? You don't know whether the hardware vendor decides to use it in > some other chip too in the future. > > Advantage is that we could keep the FreeBSD structure beyond this one > folder. > > > OK. A shared folder seems to be the right option for the drivers. > > > > > > > > Why shouldn't we create a separate directory for the ports? > Something on > > a top-level. Which can reference headers from both cpukit and bsps. > > This way we can have all imported source files under a single > directory and > > can share them across bsps. Is there any disadvantage in using a new > > directory > > for this? > > This is possible too. But I would expect that it will cause a _long_ > discussion whether it is a good idea, what would be a good name, ... > > What's the big advantage? > > cpukit has mostly core specific stuff and hardware independant sub > systems. We don't plan to import bigger stuff like that (at least I hope > that) but just basic drivers. Drivers are most of the time located in > the bsps directory. > > > If it is just drivers and board dependent stuff then a shared folder > under bsps > seems to be a good option. Even if we want to import something that is bsps > independent it should work with the same directory structure but it > wouldn't be > the most correct thing. > > What if we stick with a shared folder under bsps currently and restructure > when we import something independent of bsps since this is more of a > rare case. How much work will it be?
I would suggest that way. Please start with it and create a compilable and ideally useable patch set and send it to the mailing list. That will involve others developers much better than this thread. Best regards Christian > > Best regards > > Christian > > > > > > > > > Best regards > > > > Christian > > > > > > > > > > > Please see all comments as advises. Feel free to argue > against > > any of > > > them if you think different ;-) > > > > > > Best regards > > > > > > Christian > > > > > > > > > > > Best regards > > > > > > > > Christian > > > > > > > >> Please have a look at the last 6 patches for the > ported work. > > > >> Below is a short summary of the patch. > > > >> * The openfirm.h is the OF interface that will > provided to > > the user. > > > >> * The openfirm.c contains the function definition for > > openfirm.h. The > > > >> functions > > > >> call the respective OFW_* functions which are > responsible for > > > choosing > > > >> the correct implementation for OF interface. > > > >> * ofw_if.h is the replacement for ofw_if.h in > FreeBSD. This > > is an > > > auto > > > >> generated > > > >> header in FreeBSD which choose the correct OF > > implementation(ofw_fdt, > > > >> ofw_std, > > > >> ofw_32bit, ofw_real). In RTEMS we directly map to the FDT > > > implementation as > > > >> suggested by Sebastian. > > > >> * ofw_fdt.c contains the fdt implementation of OF > interface. > > > >> > > > >> Thanks, > > > >> Niteesh. > > > >> > > > > _______________________________________________ > > > > devel mailing list > > > > devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>> > > <mailto:devel@rtems.org <mailto:devel@rtems.org> > <mailto:devel@rtems.org <mailto:devel@rtems.org>>> > > > > http://lists.rtems.org/mailman/listinfo/devel > > > > > > > > > > > -- > -------------------------------------------- > 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. > _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
