Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 26/02/2020 22:12, Amar Takhar wrote:
> On 2020-02-26 18:46 +0100, Christian Mauderer wrote:
>> Hello Amar,
>>
>> somehow I missed your response this morning. My filter for the mailing
>> list normally keeps stuff with my name in the inbox but your answer
>> didn't contain it and therefore it was hidden in the mailing list folder.
> 
> No problem! :)
> 
> 
>> Full acknowledge. I'm not a fan of another repository like I already
>> said toward Chris. On the other hand: We already have that problem and
>> have to deal with it sometimes anyway. I added a note in the response
>> toward Chris that we maybe sometimes should think about a master
>> repository with sub-repos to make the version dependencies more clear.
>> In other words: One repository to rule them all ;-)
> 
> We can for sure create a sub repository to handle this.  That can be annoying 
> however if the sub repositories don't update often because git pull can take a 
> while.

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 other option here is to just document for the user how to do a 'git 
> submodule add' and do it themselves within the RTEMS tree or a separate 
> repository it would depend on just how much demand there would be for this.  
> It's not a huge deal though to detect if the FDT repository is in-tree otherwise 
> force a --with-fdt-repo.
> 
> 
> 
>>> We don't really have a choice here however I would 
>>> suggest we do a mix of the two.
>>>
>>
>> I'm not sure whether that is a very transparent approach.
> 
> Transparent or complicated?  :)  It will still all be documented and out in the 
> open.
> 

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.

> 
>>>   1. Any source/permissive files be kept within the RTEMS repository.
>>>   2. Binary blobs get ejected to a separate repository lets say 'rtems-fdt'.
>>>   3. Source files with strict licensing gets the boot, too -- though we can 
>>>      discuss how much we care about this.
>>
>> I think we will get big problems finding "permissive" licenses. Most
>> device trees are Linux based and therefore GPL. Even the ones in FreeBSD.
> 
> Okay well if they're all GPL then instead of permissive just say source-based 
> because that is still far better than binary blobs.  It will still be left up to 
> the user if they want to include it the license won't change whether it's in tree 
> our outside.
> 
>>>
>>> How it would work is simple.  During configure if the required FDT files exist 
>>> that's great we look for the two binaries we need and build them all as part of 
>>> the normal building process.
>>
>> That would add dtc to our mandatory set of tools for RTEMS. Otherwise
>> nothing against it.
> 
> It would for BSPs that have it and if users want it.  Otherwise if there is no 
> FDT then we wouldn't require those tools.
> 
> 
>> There is even a case 5: We have a FDT (for example for BBB) but the user
>> wants to use an adapted one because he has connected extra peripherals
>> or has a board that is only based on the evaluation board. Our build
>> system should be open enough to handle such a case.
>>
>> The FreeBSD FDT scripts work fine for that. You give them your file and
>> the path to the FreeBSD fdt sources and they do the rest.
> 
> Yes that adds yet another option letting users supply their own files.  I should 
> have added that one thank you.
> 
> 
>> Agreed: Open BSPs are first class citizens.
> 
> Awesome I'm glad we agree on that! :)
> 
> 
> Amar.
> _______________________________________________
> 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.