Device Tree Blob for Beaglebone Black?

[Chris Johns]

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

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