Device Tree Blob for Beaglebone Black?

[Chris Johns]

On 28/2/20 9:14 am, Gedare Bloom wrote:
> 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.

Thanks and yes what I raised was a small part of the problem space.

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

This is a good idea. I am not sure how much work is needed or how to define the
work. I think the RTEMS side of things should not be hard but I am not sure
about the interface to libbsd and what is required here. I would help mentor
this project if is suitable for GSoC.

If this goes ahead we can start to populate a dts tree in RTEMS and that would
mean a release could be made.

One issue this raises is the libbds master vs 5-freebsd-12 branch. I am not sure
what happens here and which dts is placed in the rtems.git repo. Maybe placing
5-freebsd-12 dts in rtems.git is done up to the release of RTEMS 5 then we
update rtems.git master to match libbsd's master?

Chris