Beagle: FDT support in BSP as a GSoC project?

Joel Sherrill joel at
Sun Aug 11 17:28:05 UTC 2019

On Sun, Aug 11, 2019, 10:59 AM Christian Mauderer <list at>

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

There must be a good diagnostic if the device tree doesn't meet minimum
requirements. We don't want a failure to be hard to figure out. This is a
general statement for all device tree bsps.

> Best regards
> Christian
> _______________________________________________
> devel mailing list
> devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list