Beagle: FDT support in BSP as a GSoC project?

Fri Aug 16 07:26:40 UTC 2019

On 15/08/2019 23:01, Joel Sherrill wrote:
> 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

Hello Joel,

if we have an FDT based initialization it's not really possible to say
whether (for example) I2C or framebuffer is used during compile and link
time. That depends on the FDT passed from U-Boot to the application and
is only decided during boot.

We have three possibilities to solve that:

- Use dynamic loading (like Chris suggested) for driver modules. On the
beagle it would be necessary to load from a SD card or a similar storage
which already needs lots of initialization. So I don't think that's a
good solution.

- Add a module concept similar to the one used in libbsd. That would
mean that an application can use defines like the
SYSINIT_DRIVER_REFERENCE to tell the linker which drivers to add. Note
that for libbsd drivers (framebuffer, ethernet, USB, SD-Card) that's
already there. As far as I know there is no such concept for any BSP in
RTEMS core yet.

- Add all drivers from the RTEMS core and just be careful to make it
simple to remove them by overwriting only a single function.

Like I said although the second option might would be the cleaner one I
would prefer the last option. In the core system there are only the
basic peripherals like SPI or I2C. I don't think that they add that much
overhead for FDT based BSPs. But I think it's a huge advantage for a new
user if he doesn't have to add these (BSP specific) peripherals to a BSP
specific config.

By the way: I think it's good to discuss that. And it's a good point
that should be on the list for a project like this. It can be a big part
of the work depending on what solution we agree on.

Best regards

Christian

> 
> 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
> 