On 12/8/19 3:51 pm, Christian Mauderer wrote: > > On 12/08/2019 03:33, Chris Johns wrote: >> On 12/8/19 9:22 am, Joel Sherrill wrote: >>> >>> >>> On Sun, Aug 11, 2019, 5:47 PM Chris Johns <chr...@rtems.org >>> <mailto:chr...@rtems.org>> wrote: >>> >>> On 12/8/19 3:28 am, Joel Sherrill wrote: >>> > On Sun, Aug 11, 2019, 10:59 AM Christian Mauderer <l...@c-mauderer.de >>> <mailto:l...@c-mauderer.de> >>> > <mailto:l...@c-mauderer.de <mailto:l...@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. > > OK. I'll create one in the next days. > >>> >>> > 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? > > Most likely that's true for a lot of other FDT based BSPs too. Most of > the time FDT is used together with Linux systems. > >>> >>> 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? > > I think there would be two possibilities: > > 1. Introduce a module system similar to FreeBSD / libbsd. You > explicitely have to create a module reference if you want a driver. > > 2. Do it the other way round: Take care that device drivers are only > referenced via one init function. If a user wants a small config, he can > overwrite the function in his application which removes the driver. > > I would prefer 2 because: > > - Most likely it's simpler for the average user to just have everything > available without a special configuration.
I agree. > - It's simpler to implement. > > - A user that really needs the last few bytes on a system like Beagle is > unlikely. > > - If someone really needs the bytes, most likely he knew that when > creating the draft of the system. I would expect that this is a more > experienced user who either knows of the tricks or asks on the mailing list. > This is reasonable. Thanks Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
