I noticed that the Zephyr RTOS (https://www.zephyrproject.org) uses a device tree based initialization for all of its BSPs. For example, here is the top level device tree source for the Adafruit Trinket M0, which is a very small Atmel Cortex M0 based board: https://github.com/zephyrproject-rtos/zephyr/blob/master/boards/arm/adafruit_trinket_m0/adafruit_trinket_m0.dts
The rest of the device tree source for common processors and devices are here: https://github.com/zephyrproject-rtos/zephyr/tree/master/dts To me, it looks like they have to develop (or port) and maintain device trees for each board and device that is supported. Does that look like a model that RTEMS could use? I'm not sure I understand everything that deploying such a model implies, or if it just makes more sense to use the existing FreeBSD or linux device trees. Just a thought.. I'm still catching up! Thanks, Alan On Thu, Feb 27, 2020 at 2:44 PM Amar Takhar <a...@rtems.org> wrote: > > On 2020-02-27 20:06 +0100, Christian Mauderer wrote: > > > > The only good way to handle this is to have it all in 1 giant repository > > > we work > > > with. Every other solution is a pain no matter how well thought out it > > > is. I > > > personally lean more on the service side of things that it should be *our* > > > problem to maintain this and for users it should just work.> > > > The easiest way to handle this is to have the minimum version required in > > > the > > > commit message. Eg, when pushing to libbsd have: > > > > > > Minimum RTEMS: <hash> > > > > > > After that it's up to the user to ensure to keep up-to-date. The first > > > thing > > > most developers do is check the log. > > > > Sounds like a nice suggestion. But it needs quite a lot of discipline > > for the developers. So most likely a lot of errors will happen. Beneath > > that it's not far from what we do now: Suggest to use commits from the > > same date. > > There are two ways to look at it -- requiring discipline or simply doing > something we should already be doing. Because right now there is no way to > tell > other than updating to the latest and if you are trying to bisect an issue > this > because huge because you could feasibly jump into a comment that skips a > version. How would a user know which version of the library *or* RTEMS to > use? > > > > But maybe we should move that discussion. It's not FDT related anymore > > so no one will find it in this toppic. And I think for Chris the > > pressing matter is FDT just now because it blocks the release. > > Yes that's true. > > > The BSP groups that use bsps/shared/start/bsp-fdt.c are: > > > > - riscv/riscv > > - arm/imx > > - arm/beagle > > - arm/raspberrypi > > - arm/altera-cyclone-v > > - powerpc/qoriq > > > > For beagle and raspberry it should be definitely the FreeBSD FDT. > > > > For imx: I'm currently working on imx6 support in the imx BSP and that > > one will use a FreeBSD derived one too. Not sure about the original imx7 > > support in that BSP. > > > > For the other BSPs I don't have any idea which FDT has been used during > > development. > > > Okay that list is already compelling enough to have the split model of having > source based files in-tree and binary outside. I think it makes sense to have > it 'just work' for opensource boards like the beagle and rpi even if that's > the > only two that require it. > > > Amar. > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
