Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 27/02/2020 18:14, Amar Takhar wrote:
> On 2020-02-27 08:45 +0100, Christian Mauderer wrote:
>>
>> It's just another problem that I noted sometimes on the mailing list
>> with RTEMS and libbsd: Sometimes libbsd doesn't compile with some odd
>> error messages like unresolved symbols. Most of the time the problem is
>> that libbsd has been updated by the user but RTEMS hasn't. Having
>> defined versions in a master repository could help the average user to
>> see which version should be used together. On the other hand someone
>> would have to keep it up to date and I'm not sure whether all
>> maintainers would be happy about another necessary maintainance task.
>> Therefore it's not yet a well thought through idea.
> 
> 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.

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.



> 
> Regardless of what we choose none of it will work if the user is not updating 
> their repository or checking online for changes.  Having it in the commit 
> message also helps for build automation.  I've used git tags for this in the 
> past but hardly anyone uses or checks those which is too bad.
> >
>> If you are a new user and see "for this BSP use the FDT from X" but you
>> want to use some other BSP and someone tells you "for that BSP the FDT
>> isn't in X but at Y" it maybe isn't really that clear. Therefore - if we
>> introduce some handling - I would be in favor of only one location and
>> not a mix of two or three. Otherwise the situation is only slightly
>> better than now.
> 
> Having a section in the documentation to manage this is fine I think.  It's 
> either going to say:
> 
>   1. The FDT source is in rtems-fdt.git
>   2. The FDT source is already in RTEMS you don't need to do anything.
>   3. You need to purchase a board and place the files <here>
>   4. Covers all: If you want to roll your own place the files <here> -- same 
>      place as #3 maybe.
> 
> An easier way to make a decision would be to see what we're looking at right 
> now.  How many would be in-tree and how many external?
> 

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.

Best regards

Christian

> 
> Amar.