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
