Device Tree Blob for Beaglebone Black?

[Amar Takhar]

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.

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.


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