Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

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.

On 26/02/2020 06:00, Amar Takhar wrote:
> 
> I've had to deal with this issue quite a lot in the past it can be really 
> annoying having to maintain separate repositories where we have to 'pin' a 
> version to the main repo. 

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

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

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

> 
> If they are not found print a notice to the user to get the 'rtems-fdt' 
> repository and point to it with a --rtems-fdt-path=  This is where it gets 
> annoying because there are several steps to get the right file.  Generally we 
> have to:
> 
>   1. Read a file stored within RTEMS that says what version of the FDT 
>      repository to checkout.
>   2. As part of configure this file needs to be loaded and the 'rtems-fdt'
>      repository checked to see if it's at the right revision.
>   3. If it as not at the right revision then the user will have to fix this 
>      manually and re-run configure.
>   4. Some BSPs may not even have the FDT files until you purchase a board.  Do 
>      we have any of these cases?  Now we have a situation where we have no 
>      revision *or* files and no way to test this code or ensure it even works.

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.

> 
> Regardless for case #4 it's going to be a user issue to get the FDT files and 
> our issue to suck these in.
> 
> It makes sense to do it this way for RTEMS as I don't see a reason to "punish" 
> the BSPs where everything is free and open it would be great to have these 'just 
> work' and it is less maintenance for us longterm.

Agreed: Open BSPs are first class citizens.

Best regards

Christian

> 
> 
> Amar.
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>