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. > > 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
