Device Tree Blob for Beaglebone Black?

[Chris Johns]

> On 24 Feb 2020, at 7:39 pm, Christian Mauderer <christian.mauderer at embedded-brains.de> wrote:
> 
> On 24/02/2020 07:01, Chris Johns wrote:
>> 
>> 
>>>> On 24 Feb 2020, at 5:32 am, Christian Mauderer <list at c-mauderer.de> wrote:
>>> 
>>> On 23/02/2020 17:07, Alan Cudmore wrote:
>>>> I have been trying to bring up RTEMS with rtems-libbsd on the
>>>> beaglebone black (latest master).
>>>> 
>>>> I can run the regular RTEMS samples on the board, and a couple of the
>>>> rtems-libbsd testsuite examples run as well.
>>>> 
>>>> The samples such as ping01 and usb01 get a fatal exception in the
>>>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>>>> using the correct device tree blob.
>>>> 
>>>> I'm using the instructions here:
>>>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>>> 
>>>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>>>> u-boot build. The instructions talk about getting the one from the
>>>> FreeBSD repository, but there are many other files included in that
>>>> dts source.
>>>> 
>>>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>>> 
>>>> Is the dtb needed for the non-libbsd BSP?
>>>> 
>>>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>>>> libbsd to get ethernet?
>>>> 
>>>> Thanks,
>>>> Alan
>>> 
>>> Hello Alan,
>>> 
>>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>>> therefore works best with them. Normally I would suggest to use the
>>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>>> the last commit that doesn't seem to work. Vijay had some problems with
>>> it and noted that the version from FreeBSD commit
>>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>> 
>> Is this with 5 branch in Libbsd?
>> 
>> I am a little confused about the branch to package in a release and also which FDT files we need for which branch. If different I feel a release will makes things more complicated. This flies into the BSP  vertical stack building in the RSB. 
>> 
>> I am working on releasing and I hope this does not block things. 
>> 
>> Chris
> 
> Hello Chris,
> 
> the non-working device tree is for the master branch from a few weeks
> back. I didn't tested it with the 5-freebsd-12 branch.

Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
12-release branch in the FreeBSD repo however this is a guess, unfriendly on our
part and time consuming to sort out. I am not sure how we improve this and how
we should manage FDT source but we need to address the issue.

There are long time RTEMS users including myself struggling with this so it is a
clear indication in my mind we have an issue we need to improve.

> > Again: In the normal case I would just suggest to use the FDT sources
> that match the FreeBSD commit we use for libbsd. That worked best for me
> in the past. But in the current referenced commit FreeBSD has updated
> the device tree sources to the ones from a recent Linux version and the
> drivers haven't been adapted yet (on master - I expect that it works
> better on 5-freebsd-12).
> 
> Regarding the release: I don't think you pack the FDT files (yet), do
> you? 

No I do not but then should I be the one doing this in a release. I would have
thought this is a core issue for the BSPs that depend on FDT blobs at runtime.

I am up to libbsd with the release packaging. I can build a beagleboneblack as a
vertical stack up to libbsd and then I hit the issue of using master and not the
5-freebsd-12 branch and after that is the rtems_waf submodule naming. I would
like to resolve this in the RSB however before I do this I would like to resolve
the FDT files so I make a single pass over this.

> So I don't see why there should be a reason for this topic to block
> the release.

I do. To not handle this is to create a release where the files in the release
package crash a beagleboneblack with libbsd unless you manually get the correct
set of FDT files. This is unhelpful for users in a release context.

Consider a release called rtems-libbsd-5.0.5.tar.xz that you build. Some of the
libbsd tests work and some do not. Is the RTEMS release broken? You have never
used RTEMS and you have never used libbsd. It is all new, untested and
unfamiliar and when you follow a simple example to start networking it crashes.
After a bit of digging or a post to the user list and you find out you are
suppose to find FDT files to match from deep in the FreeBSD source. This is not
user friendly and we have not packaged what is needed to run a board. FDT is
important to RTEMS so it is important we manage it.

I would like this resolved this and for the RTEMS 5 release. The more that help
and contribute the quicker it is done and sooner I can release RTEMS 5.

> Note that the exact FDT version used for different BSPs is still a
> bigger problem. 

I see it as the same problem, it is just bigger in size than a BBB.

> Some BSPs expect a version provided by a board
> manufacturer. Some use a random Linux DTB. And some work well with the
> ones from FreeBSD (which is just a snapshot of the Linux ones) - that's
> the method I prefer because it works well with libbsd most of the time.

This is a developer's point of view. We need to move beyond this and manage it
for our users. The user manual for imx and qoriq state FDT blobs are needed with
the statement ...

  "A boot loader with device tree support must be used to start the
   BSP, e.g. U-Boot."

And the only other reference is "loadfdt". As far as I know the hand over ABI
between u-boot and RTEMS is not some accepted standard so you need to use u-boot
and you need u-boot to load the FDT blobs. However there is nothing to say what
FDT blobs to use?

> I think currently the right device tree for the board is only documented
> in the User Manual (if it is documented).

It is good to document the FDT for a board but I think links such as the one in
the BBB section are fragile at best and dangerous at worst. Links like this
break down with branches. A user for RTEMS 5 would need to remember to reference
the branch's documentation and not master. This is simple to miss and an
incorrect FDT file is difficult to debug.

Chris