Beagle: FDT support in BSP as a GSoC project?

[Joel Sherrill]

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 <list at 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 <chrisj at rtems.org
> >>>> <mailto:chrisj at rtems.org>> wrote:
> >>>>
> >>>>     On 12/8/19 3:28 am, Joel Sherrill wrote:
> >>>>     > On Sun, Aug 11, 2019, 10:59 AM Christian Mauderer <list at c-mauderer.de
> >>>>     <mailto:list at c-mauderer.de>
> >>>>     > <mailto:list at c-mauderer.de <mailto:list at 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