All I meant by "not all drivers" and "small" is that we currently do not include code that the application doesn't have a need for. I don't want that to change. If the application doesn't use i2c or the frame buffer, then those drivers shouldn't' be there. I wasn't attempting to create a new requirement -- just emphasize what we already do shouldn't change.
--joel On Thu, Aug 15, 2019 at 1:49 PM Christian Mauderer <l...@c-mauderer.de> wrote: > > On 12/08/2019 08:18, Chris Johns wrote: > > 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 > > > > I created a ticket for it: https://devel.rtems.org/ticket/3784 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
