On Mon, May 11, 2020 at 4:34 AM Chris Johns <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. > > 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 > 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 :(. > > > 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. > Chris > > [1] https://lists.rtems.org/pipermail/devel/2020-May/059807.html >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
