Beagle: FDT support in BSP as a GSoC project?

[Chris Johns]

On 12/8/19 9:22 am, Joel Sherrill wrote:
> 
> 
> On Sun, Aug 11, 2019, 5:47 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
> 
>     On 12/8/19 3:28 am, Joel Sherrill wrote:
>     > On Sun, Aug 11, 2019, 10:59 AM Christian Mauderer <list at c-mauderer.de
>     <mailto:list at c-mauderer.de>
>     > <mailto:list at c-mauderer.de <mailto:list at c-mauderer.de>>> wrote:
>     >
>     >     Hello,
>     >
>     >     while mentoring Vijays GSoC project this year I noted that some drivers
>     >     in the Beagle BSPs have quite horrible hard coded values for things like
>     >     pinmux initialization. Maybe it would be a nice GSoC project for next
>     >     year to replace this stuff with a fdt based initialization. I would like
>     >     to ask for feedback before creating a ticket for it because it would
>     >     mean a quite big change for the BSP (maybe even the name - see below).
>     >
>     >     Basically such a project would include the following parts:
>     >
>     >     - Parse the pinmux settings from FDT and create a two part driver for a
>     >     'pinctrl-single' compatible FDT entry. One part generic, one device
>     >     specific (similar to FreeBSD or Linux).
>     >
>     >     - Remove pinmux initialization from all drivers.
>     >
>     >     - Initialize drivers based on the FDT (instead of functions like
>     >     bbb_register_i2c_1(...))
>     >
>     >     - Taking a more detailed look at the FDT what else could be initialized
>     >     from it (maybe clocks?)
>     >
>     >     It could be a quite nice project for a RTEMS beginner. Due to the
>     >     distributed initialization a lot of drivers have to be touched (at least
>     >     i2c, spi and pwm). So a potential student would get a nice overview over
>     >     the parts.
>     >
>     >     Note that this would be a big change for the BSP. Currently the BSP can
>     >     be used without an FDT (as far as I know). Only libbsd needs one. After
>     >     that a FDT would be mandatory. Despite that, I think that it would be an
>     >     improvement.
>     >
>     >     Maybe it would be possible to merge the four beagle* BSPs that we have
>     >     into only one "beagle" or "am33xx" BSP with that change. That would
>     >     allow to support new Beagle variants like the Pocket Beagle without much
>     >     effort (most likely only a change in the FDT).
>     >
>     >     What do you think? Should I create a ticket for it?
>     >
> 
>     I love it. Yes please create a ticket.
> 
>     > I think this is a good idea if we can still avoid bloating apps with all
>     > drivers. Make sure it has the right tags and shows up on the project page.
> 
>     The beagle has a lot of RAM. Is this as important for this BSP?
> 
> Not really but we don't want bad patterns starting. 
> 

How does a user then configure a build to get the minimal set for them?

Without dynamically loading does mean we need a bunch of build options? Is
building for dynamic loading something we should consider?

Chris