Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

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 <amar at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel