Device Tree Blob for Beaglebone Black?

Fri Feb 28 10:48:39 UTC 2020

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.

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

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

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

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.

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

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

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

Best regards

Christian

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

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