[PATCH] bsps/zynqmp: Allow any or all CGEMs to be enabled

[Chris Johns]

On 30/6/21 1:21 am, Gedare Bloom wrote:
> On Tue, Jun 29, 2021 at 7:50 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
>>
>> On 29/06/2021 15:48, Kinsey Moore wrote:
>>> On 6/9/2021 00:27, Sebastian Huber wrote:
>>>> On 08/06/2021 22:18, Kinsey Moore wrote:
>>>>> Provide the options necessary to enable any combination of CGEM ethernet
>>>>> interfaces in LibBSD. The default is still CGEM3, so this should
>>>>> continue to operate as expected on typical Zynq Ultrascale+ MPSoC
>>>>> development hardware.
>>>>
>>>> An alternative to this configuration approach would be to enable the
>>>> device tree support for this BSP.
>>>>
>>> Sorry, I missed this earlier due to travel. Device tree support in
>>> libbsd for if_cgem.c is currently #ifdef'd out and has been since it was
>>> introduced. I had assumed that was the case for other FDT support as
>>> well based on the comments in that initial commit.
>>
>> The device tree support is disabled since the original Zynq BSP was
>> added before RTEMS had support for device trees in general. Nobody had
>> the time/budget/need to change the BSP to support device trees so far.
>>
> I'm not sure anyone has the time/budget yet either. FDT support is
> challenging for RTEMS because it requires a closer interaction between
> a bootloader and RTEMS, which raises legal/license compliance
> concerns.

Or RTEMS itself if linked into a single executable.

> Although I agree that FDT is a great solution, I'm not
> certain about the scope (or creep) it implies in terms of the
> relationship between RTEMS and Bootloaders/firmware, or whether we
> need to produce our own "mini bootloader" that deals with FDT support
> early in the RTEMS startup sequence.

I agree. RTEMS use to be a single binary image that contained everything and as
a configuration controlled item it was simple to manage. FDT and then boot
loaders that support FDT brings into RTEMS a range of new issues. Some users
completely ban GPL and uboot is GPL and then some FDT is licensed GPL. Licenses
aside users need to manage and configuration control 3 separate pieces. These
pieces all need to line up and that presents challengers to our project.

> Right now, the design eludes me, but I'm certain that requiring users
> to U-Boot for FDT support is not the best solution for RTEMS.

Yeap, it should be "a" solution and users should be to select what they want.

And finally from a developer point of view I understand uboot and FDT is an easy
and attractive solution but we as developers do not have to live with the flow
on issues these additions crate. As an open source project we need to consider
both positions.

Chris