On Sat, May 9, 2020 at 11:56 AM Christian Mauderer <o...@c-mauderer.de> wrote:
> > > On 08/05/2020 23:05, Gedare Bloom wrote: > > On Fri, May 8, 2020 at 9:34 AM Christian Mauderer <o...@c-mauderer.de> > wrote: > >> > >> > >> On 08/05/2020 17:26, Niteesh G. S. wrote: > >>> On Fri, May 8, 2020 at 11:43 AM Christian Mauderer > >>> <christian.maude...@embedded-brains.de > >>> <mailto:christian.maude...@embedded-brains.de>> wrote: > >>> > >>> > >>> On 07/05/2020 17:19, Niteesh G. S. wrote: > >>> > On Thu, May 7, 2020 at 4:07 PM Sebastian Huber > >>> > <sebastian.hu...@embedded-brains.de > >>> <mailto:sebastian.hu...@embedded-brains.de> > >>> > <mailto:sebastian.hu...@embedded-brains.de > >>> <mailto:sebastian.hu...@embedded-brains.de>>> wrote: > >>> > > >>> > On 07/05/2020 12:28, Niteesh G. S. wrote: > >>> > > >>> > > On Thu, May 7, 2020 at 1:21 PM Sebastian Huber > >>> > > <sebastian.hu...@embedded-brains.de > >>> <mailto:sebastian.hu...@embedded-brains.de> > >>> > <mailto:sebastian.hu...@embedded-brains.de > >>> <mailto:sebastian.hu...@embedded-brains.de>> > >>> > > <mailto:sebastian.hu...@embedded-brains.de > >>> <mailto:sebastian.hu...@embedded-brains.de> > >>> > <mailto:sebastian.hu...@embedded-brains.de > >>> <mailto:sebastian.hu...@embedded-brains.de>>>> wrote: > >>> > > > >>> > > On 07/05/2020 09:35, Niteesh G. S. wrote: > >>> > > > >>> > > > This is what I was trying to convey in one of the > previous > >>> > mails. > >>> > > > > >>> https://lists.rtems.org/pipermail/devel/2020-May/059717.html > >>> > > > But in that mail, I was planning to replace > KOBJLOOKUP. > >>> > > > Should I start working on it? From the top of my > mind, the > >>> > > following has > >>> > > > to be done. > >>> > > > 1) Import openfirm.c openfirm.h, ofw_fdt.c > >>> > > > 2) Add ofw_fdt.h since all the functions in ofw_fdt > >>> are static. > >>> > > > Should we also import ofw_if.h? Because that is where > >>> OFW_* > >>> > > functions > >>> > > > are defined or just add a ofw_rtems_map.h which > >>> redefines them, > >>> > > instead > >>> > > > of importing ofw_if.h? > >>> > > > >>> > > The KOBJ stuff in the OFW support enables FreeBSD to > >>> have three > >>> > > different implementations of the OFW API which can be > >>> selected at > >>> > > runtime: > >>> > > > >>> > > sys/powerpc/ofw/ofw_real.c > >>> > > sys/dev/ofw/ofw_standard.c > >>> > > sys/dev/ofw/ofw_fdt.c > >>> > > > >>> > > In libbsd this is already short cut to the FDT > >>> implementation: > >>> > > > >>> > > #ifndef __rtems__ > >>> > > static ofw_def_t *ofw_def_impl = NULL; > >>> > > #else /* __rtems__ */ > >>> > > #define ofw_def_impl (&ofw_fdt) > >>> > > #endif /* __rtems__ */ > >>> > > > >>> > > To me this looks like the KOBJ stuff was just used to > >>> enable some > >>> > > sort > >>> > > of object oriented programming. Do we need this > >>> flexibility at > >>> > > runtime > >>> > > in RTEMS? I would say no. I would hard wire this to > the FDT > >>> > > implementation. If someone has a problem with it in the > >>> > future, this > >>> > > decision can be readdressed. > >>> > > > >>> > > > >>> > > Ok. But what is the neatest way to hardwire this to the FDT > >>> > > implementation? > >>> > > One way as Christian mentioned would be to redefine OFW_* > >>> functions to > >>> > > call the functions in ofw_fdt.c directly. Is there any > other > >>> way? > >>> > > >>> > I would try to replace the function declarations in > openfirm.h > >>> with > >>> > inline functions which call the ofw_fdt.c functions. > >>> > > >>> > > >>> > Should I proceed with the above method? or should I wait for > others > >>> > to comment? > >>> > If I can proceed, the following is what I will be doing. > >>> > 1) import openfirm.h and ofw_fdt.c into RTEMS. > >>> > 2) Add ofw_fdt.h with functions declarations for functions in > >>> ofw_fdt.c > >>> > 3) Add necessary compile-time guards. This would include using > >>> __rtems__ > >>> > preprocessor directive to avoid FreeBSD stuff and change the > function > >>> > definitions in ofw_fdt.c from static to non-static. > >>> > Am I missing something? or is there any other way to do this? > >>> > >>> Maybe wait one or two more days for others to comment. For me the > >>> direction sounds OK. > >>> > >>> You maybe can start thinking about where you want to import the > >>> files to. > >>> > >>> > >>> Since this has scope for future development. I think we should put it > in a > >>> separate directory under cpukit/include/ofw for header files and > cpukit/ofw > >>> for the source files. What do you think? > >>> > >>> > >> > >> If you plan to prepare a FreeBSD sync (regardless whether you implement > >> it or someone else) another possibility could be to create a similar > >> directory structure like in libbsd. > >> > >> Another directory could be ./cpukit/libmisc/rtems-fdt. > >> > >> But your suggestion is also possible. > >> > >> Maybe wait for some further input. > >> > > First: I think it would be good to discuss a location as a _preparation_ > for a FreeBSD import. Implementing that would be a massive change of the > target for Niteeshs project. If he want to do that, I don't have a > problem with the change of direction. But I don't have a problem with > the original target too. > > Niteesh: Are you interested in the FreeBSD import more then in your > original target? I think that would mean that a big part of your project > would target the new build system. I really don't want to urge you into > any direction here. So please choose whatever you want. > I would like to continue with the original project rather than the FreeBSD sync. This is mainly due to the complexity involved with the project and my lack of knowledge. > > > > This thread got a bit massive. It might be nice to refactor to a clean > > mail thread :) I'd be agreeable to the idea of a sync to freebsd for > > external sources that we import to rtems.git, but the management of > > that sync has to be done carefully and we must keep in mind the needs > > of low-end targets. I wouldn't like to see too much feature creep from > > freebsd into rtems in order to support some things meant for only a > > few relatively resource-rich boards. > > Agreed. From my view it would be only for the low level stuff that we > currently do in RTEMS too. Pin initialization, serial drivers, I2C, SPI. > Everything more complex like USB, Ethernet should continue to live in > libbsd. > > > > > If we do this sync, I think it should be handled as a single > > subdirectory that syncs all imports simultaneously. I don't want to be > > managing several different imports from various versions of upstream > > freebsd sources. This would mean something more like cpukit/libfreebsd > > maybe. Avoid using libbsd, and I think calling it by the upstream name > > is a good way to proceed. The design and planned implementation of > > this process needs to be fleshed out and discussed on the ml, and > > maybe a simple preliminary example/use case (fdt is ok) would be good > > to sketch, as well as possible future additions and how they would be > > incorporated. > > I'm not entirely sure about that. It could be an advantage to have > arbitrary locations (also that makes the sync more difficult). Use case: > BSP drivers. One example that we already have is the imx iomux driver: > > https://git.rtems.org/rtems/tree/bsps/arm/imx/start/imx_iomux.c > > If that would be in a common directory it might makes it a bit more > difficult to find which files belong to which BSP. > > But of course having a common directory makes it more clear which files > are imported. So that's a big advantage too. So I'm not really sure > about which would be the better direction. > > > > I also need to be convinced that this code must be pulled into > > rtems.git and can't be compiled/linked separately. > > Example: A pinmux driver. The RAM doesn't work without correct pin muxing. > > Best regards > > Christian > > > > > Gedare > > > >> Best regards > >> > >> Christian > >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
