Device Tree Blob for Beaglebone Black?

[Amar Takhar]

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.  We don't really have a choice here however I would 
suggest we do a mix of the two.


  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.

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.

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.

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.


Amar.