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. - 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. Best regards Christian > > Chris -- -------------------------------------------- embedded brains GmbH Herr Christian Mauderer Dornierstr. 4 D-82178 Puchheim Germany email: christian.maude...@embedded-brains.de Phone: +49-89-18 94 741 - 18 Fax: +49-89-18 94 741 - 08 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
