Device Tree Blob for Beaglebone Black?

Wed Mar 4 14:38:08 UTC 2020

Hello Chris,

On 04/03/2020 05:55, Chris Johns wrote:
> 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.

No problem. The release is relevant for all of us.

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

To be honest: I don't know. Basically the description for the raspberry,
for BBB, for imx results in this. I haven't looked at the other BSPs
yet. But it isn't documented with this words.

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

Basically the boot process should always be documented in the BSP
section of the manual. We maybe add some default cases:

1. Boards that normally run Linux: Suggestion: Use the same boot process
as Linux. For device trees: Use one delivered with the board (which only
maybe works) or use the one provided by the repository we are discussing
now (which should always work).

2. Boards that are not running Linux but want to use a FDT: I think we
currently don't have any. But if we would have ones, they most likely
have a small hand written FDT or one generated for example together with
a FPGA. Here it might would be a sane approach to link the FDT into the
application. Again: We don't have a BSP yet that is in that category so
not relevant for the release.

3. Boards that are not using an FDT. Most BSPs. The boot is very target
dependent. Not relevant for our current discussion.

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

For targets with an Linux as alternative system: Yes. The FDT and Kernel
for Linux has to be loaded from somewhere too.

For other targets: See above: We might add the option to link an
hand-written or generated FDT with a suitable license. But that are most
likely smaller targets. We currently don't have any. So that can be a
future feature.

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

Again: Let's find a solution for the release. In my opinion that could
be something like:

- Collect sources and binaries.
- Put them into a repository.
- Don't add a build system (for now).
- But use a folder structure that allows to add a build system in the
near future.

This would allow to have a sane state for the release (binaries from the
repo can be used). At the same time we have enough time to discuss a
well defined build system and maybe improve the structure after the
release. Part of that could be a GSoC Project.

Best regards

Christian

> 
> Chris
> 

-- 
--------------------------------------------
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.mauderer at embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.