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