On Thu, May 7, 2020 at 12:10 PM Christian Mauderer < christian.maude...@embedded-brains.de> wrote:
> Hello Niteesh, > > On 07/05/2020 06:58, Niteesh G. S. wrote: > [...] > > Is there any chance that we will be working with the new build system > > for this GSoC project? > > I think there is a good chance that the new build system will be added > soon. As far as I know, the current plan is to add it right after the > release. Especially Chris did an awesome work regarding the release and > there are only very few tickets left. Joel is also heavily involved in > testing. So I expect the release any day now. > > > > > I have a few doubts regarding the importing part. > > > > 1) Say we are importing the openfirm code to RTEMS(rtems.git) then we > will > > also have to bring in its dependencies like KOBJS which in turn has some > > other > > dependencies. And I am not really sure about this, but after looking at > > the libbsd > > code. This seems to bring in a huge amount of code into RTEMS. If this > > is what > > is going to happen then we could dump libbsd right? > > I don't think that dumping libbsd should be a short term goal and I'm > not sure whether it can be a long term one. There is a lot more in > libbsd than just the bus system. > > As a rough direction for now: libbsd was thought as a network and USB > stack. So you could say that simple and low-level peripherals (like GPIO > handling, serial ports, I2C, ...) are better in RTEMS and high-level > stuff and complex peripherals (like a firewall, VPN, TCP/IP, network > drivers, USB and SD drivers, ...) are better in libbsd. > > I'm also not sure whether importing KOBJS is the right way. The > alternative would be to do the cut right there: Import the openfirm > parts but replace the parts where KOBJS would be used. Maybe you can > think about importing the ofw_fdt.c stuff too but add shortcuts. > The KOBJS would just look up which ofw_fdt_... functions would be > called. We currently don't have any other sources for this kind of > information then the FDT. So you could just map for example OFW_GETPROP > to the ofw_fdt_getprop function. That would remove the KOBJS dependency > (which pulls in a lot of other stuff) but re-use a lot of the already > well tested FreeBSD code. > 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? > > > > 2) If we didn't dump libbsd, won't this cause double initialization of > > few things. > > That's a problem that should be addressed by your GSoC project. One > reason for the suggested FDT based initialization was the situation that > currently is there on the Beagle: Some pin functions are initialized by > the RTEMS drivers with a hard coded value and then they are > re-initialized by the libbsd pinmux driver based on the FDT. I think it > would be optimal if RTEMS would do the initialization based on the FDT > and libbsd would just skip that step. > > You maybe noted: Moving the pinmux stuff from libbsd to RTEMS could be > another use case for a FreeBSD code import. Although I don't want to > urge you into that direction if you don't want to do it (there are > always other solutions) it might has some benefits. > > > > You had already mentioned that libbsd uses some macro magic to avoid name > > collisions that's why I am ignoring that and only worried about double > > initialization. > > > > -- > -------------------------------------------- > 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