Device Tree Blob for Beaglebone Black?

[Chris Johns]

Sorry about delay in getting back to this. I have been focused on getting the
release into something close to what we want for RC1.

On 28/2/20 9:48 pm, Christian Mauderer wrote:
> Hello Gedare and Chris,
> 
> On 27/02/2020 23:14, 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.
> 
> I think for Boards that normally run a Linux it is a sane approach to
> just replace the Linux Kernel with a RTEMS binary and otherwise keep the
> boot process with for example U-Boot. Everything else is a lot of extra
> effort to implement and not necessary in a lot of situations.

Is there documentation about that shows this process for an existing board?

I get what you are saying and it make prefect sense and it would be no issue for
me to do this however there are a number of steps involved and there is a
certain amount of assumed knowledge here. How do we establish a framework or
template that lets are capture this so it is useful and usable to our users?

> 
>>>
>>> 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.
>>>
> 
> One BSP where it is a disadvantage to statically link is Raspberry Pi.
> With the recent work you currently can use the same binary for RPi2 and
> 3 with only a different FDT. Same for RPi1 and RPi Zero / Zero W.

Great example and a good point.

> I'm not against the possibility to link the FDT. But we should be open
> to use both methods.

OK

>>> 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.
> 
> Note the licensing issues if you use FreeBSD or Linux FDTs: They are
> GPL. If you statically link them you will infect other code too.

Ouch, that is a blocker to linking to the image. In light of this maybe any
effort to link it is not worth it. I wonder what you do with a board that needs
an FDT but has no media to hold one?

> Although for BSPs where no FDT exists it might is a good idea to write
> your own FDT and license it with a RTEMS compatible license. For BSPs
> like BBB it's not a good idea if you ask me. It's a lot of work.

Yes I agree.

>>> 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.
> 
> Again: It opens licensing issues for our users!
> 

Understood. I had not considered this before now.

>>>
>>> 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.
> 
> If Chris sees it as a blocker for the release, GSoC might is not the
> right frame. It would need too much time and the result is not
> guaranteed to be OK.

The concern I have is how you take an experienced user and given then just ....

https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2003/

... then ask them to run an exe on a BBB or RPi to run?

> Maybe we should add an intermediate solution and create a GSoC project
> for improvement?

It leaves RTEMS 5 with a gap.

Chris