Device Tree Blob for Beaglebone Black?

Thu Feb 27 22:14:26 UTC 2020

On Thu, Feb 27, 2020 at 3:01 PM Chris Johns <chrisj at rtems.org> wrote:
>
> On 28/2/20 7:23 am, Alan Cudmore wrote:
> > 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.
>
> This is where I was heading in my thinking but I am not sure. I am settling on
> having a dts tree in rtems.git and we may just have to manually manage the
> files. I am not sure there are enough files to warrant a system like libbsd and
> FreeBSD at this point in time. That may change with the new build system and
> python being available however until then manual is fine. Let me explain ...
>
> I have been looking beyond the internal development aspects and to how we use
> FDT blobs and I am wondering if the approach we have with the shared FDT BSP
> support is the right fit for RTEMS and a statically linked executable.
>
> I believe currently we need a suitable bootloader, ie u-boot, to load a blob.
> This is the Linux way of doing things and this may be the right approach for
> Linux but I am not so sure it is for us. It means you need u-boot and a suitable
> file system plus you have a lot more items to configuration manage in production
> systems and a lot more complexity for self upgrading.
>
> Why do we have a bootloader load the FDT files when we statically link
> everything else?
>
> Why not link them into the executable and register them? It s easy to do.
>
> The flow on from doing this has some real advantages. FDT files that are linked
> into an executable can then live in the rtems.git repo. If you move branches
> when testing or in production you do not need to manage and match suitable FDT
> blobs.
>
> I am not advocating this is the only solution. I can see for some BSPs this will
> not work and u-boot loading is the only or best solution. I however believe for
> DTS that is open and available we should avoid the whole mess of needing to
> build and manage them on boot media separately to the executable.
>
> The issue of RTEMS version mismatch of blobs is a real issue waiting to hit our
> users and simply linking the blobs into the executable would solve this.
>
> I am confronted by this now. I have a BBB with FDT blobs for libbsd master and
> now I need to run libbsd 5-freebsd-12 to test a release. I have to open my test
> set up open, pop the SD card and then update it. This seems unnecessary and
> avoidable to me.
>
> This also looks like a blocker for CI testing.
>
> Chris
>
Hi Chris,

I'm 100% with you. I will also go a step further and advocate that
source-based DTS -> dtc -> FDT in static images seems beneficial to
users. I don't know if we could get any input from users to justify
that, but I can see advantages for pre-qual and license compliance
that go beyond the technical advantages that you discuss above.

Initial steps in this direction would make a good GSoC for the right
(strong) student.

Gedare

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