Device Tree Blob for Beaglebone Black?

Wed Feb 26 03:50:23 UTC 2020

On 25/2/20 5:30 pm, Christian Mauderer wrote:
> On 24/02/2020 23:26, Chris Johns wrote:
>>> 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.
> 
> Same problem here. The topic already popped up multiple times and I
> can't really answer it.

I know but we have too.

> Like I said multiple time: My approach is to use the fdt that matches
> the FreeBSD commit used in libbsd. So for the 5-freebsd-12 branch that
> is the one from FreeBSD commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.
> But it's not a rule that works for all BSPs. Some BSPs are adapted to
> use a board manufacturers DTB or some random Linux one.

This means users need a clone of the FreeBSD repo .... and that means a bigger
disk array and a larger net pipe ;)

> 
>>
>> 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.
> 
> Although I agree that it would be great to have that issue resolved, I'm
> not sure whether it is doable in the time frame. 

Yes I should have raised this sooner.

>I think we should
> consider whether we really want to block a release for it.

Releases need to capture the source we reference and the specific versions of
these files is important or the BSP is of no value to a user. It is a long
standing requirement releases capture sources to avoid references to servers
that could go away.

> Depending on
> the used approach it could mean moving the release for weeks or years.
> In the later case it might be better to add it as a target for the next
> release.

Yes this is true however I would like to establish how we resolve the issue so I
can figure out how to capture the FDT files in a release. If I do not start on
this it means I have more and more changes in the release scripts to sort out
down the road and no one is paying me to make a release so I am having to spend
my money cleaning these things up and this makes me a little grumpy. I do
apologize for this.

I also do not know how I am to test the build once it is done. I have been using
the master for libbsd and this needs to change. I cannot create a release when I
have not seen libbsd on a zynq or bbb run and for the bbb I need FDT files.
Asking me to clone FreeBSD and to find specific sources is not a good use of my
(unfunded) time.

>>> 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?
> 
> The standard is to use the Linux API. That's why some of the BSPs moved
> to a use mkimage with OS type Linux. I think RTEMS as OS type should be
> discouraged by now.

It would be good if someone can post a patch to uboot to remove the RTEMS type
or alias it to linux. :)

>>> 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.
> 
> I have to disagree here: For a release the only valid documentation is
> the release version. 

Yes and it is locked for all time and if you reference a site that goes away
your documentation and release is broken.

> We can't possibly keep the documentation in a state
> that documents all past versions of RTEMS. That's why there are versions
> of the documentation. Otherwise you wouldn't even have to pack the
> documentation into a release.

This is not what I am saying. The RSB uses RTEMS's servers for all files when in
release mode because the links it contains are frozen when the release is made.
This problem extends to any link we embedded that references a file or resource
needed to make a BSP work.

> Back to the FDT problem: I think there are multiple approaches. All of
> them need work and I'm not yet sure who could do it and in what time
> frame. 

I agree but we need to make a start and we need to start working on this. I
think some BSPS will be easier to sort out than others. I am not asking all BSPs
are sorted.

> Some ideas that I think could be possible:

Awesome list :)

> 1. Add a dts import and the build infrastructure to create dtb files to
> libbsd. This would allow to update and manage the device trees together
> with FreeBSD (which are in my view the best ones for libbsd). We could
> add custom dts files to rtemsbsd or some other directory.
> 
> Pro: Up to date FDTs that match libbsd and work well with it.
> 
> Con: Not all BSPs have to use libbsd in every case. Of course the build
> system can be used anyway but it maybe is a bit unexpected for users if
> the dtb has to be build using libbsd even if libbsd isn't used.

Agreed.

> 2. Create a own dts repository together with a build system.
> 
> Pro: Very well control over the FDTs. Very few problems adding foreign
> files. The files with different licenses (dts is often GPL because it is
> extracted from the Linux tree) is well isolated.
> 
> Con: Most likely it's a bit harder to keep it up to date. It adds
> another version dependency between different repos (you have to use the
> right RTEMS commit, the right libbsd commit, the right documentation
> commit and the right device tree commit).

Agreed.

> 3. Add dts to RTEMS core.
> 
> Pro: Same as 2 without the license isolation.
> 
> Con: Same as 2 without the repo dependency.

Agreed.

> 4. Add binaries to some repo.
> 
> Con: Binaries (Although "Binary" is a bit of a difficult term here. You
> can quite easily decompile them. But you loose names.)

Yeah not nice.

> 5. Some better approach?

An RSB type approach of fetching source from various locations is a solution but
I feel some BSPs will not work with this approach, ie in a chip vendor's SDK.

> Problem for 1. to 3.: What to do if there is no dts for some board
> because the manufacturer didn't deliver one?

Why would FDT support be needed if there is no DTS source available?

> Note: I have a slight preference for approach 1. But I'm not strongly
> convinced of it. So I'm open for discussions.

We have code in the kernel that uses FDT files so this is awkward.

> Note2: If we don't force it for the release maybe it could be a GSoC
> topic? At least 1 is quite a bit of work: Get familiar with libbsd build
> system. Add an importer. Add dtc to rtems source builder if it isn't
> already there. Import the scripts from FreeBSD to build dtb files. Find
> an approach to connect dts with BSPs or alternatively build all dtb at
> once. Test dtb with at least one BSP.

I am thinking 2 is the best solution.

I am happy to work on a repo for the BBB if we decide on a separate repo. I can
then make the RSB build the FDT files and this has the advantage of not having
to do anything special in the release scripts. I hope this helps you understand
where I am coming from with this problem and why I looking for a solution.

Thanks
Chris