Selection of ethernet peripheral by application

[Chris Johns]

On 7/6/21 10:05 pm, Kinsey Moore wrote:
> On 6/6/2021 17:42, Chris Johns wrote:
>> On 4/6/21 11:26 pm, Joel Sherrill wrote:
>>> On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore <kinsey.moore at oarcorp.com
>>> <mailto:kinsey.moore at oarcorp.com>> wrote:
>>>
>>>      On 6/4/2021 02:32, Christian MAUDERER wrote:
>>>      > Am 02.06.21 um 20:37 schrieb Kinsey Moore:
>>>      >> Hello,
>>>      >>
>>>      >>  From what I’ve seen of the various BSPs supported by LibBSD that
>>>      >> have multiple ethernet peripherals,
>>>      >>
>>>      >> only one tends to be chosen and supported. I’ve encountered a
>>>      >> situation where the majority of platform
>>>      >>
>>>      >> examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the
>>>      >> only/primary ethernet interface and I
>>>      >>
>>>      >> need to have the option of selecting a different peripheral as the
>>>      >> primary interface.
>>>      >>
>>>      >> Unfortunately, the current configuration of LibBSD/RTEMS does not
>>>      >> allow for easy switching among the
>>>      >>
>>>      >> available interfaces. The easy one-off option is to just create a BSP
>>>      >> variant with a little bit of extra logic
>>>      >>
>>>      >> to select the correct interface in LibBSD, but this problem seems
>>>      >> more generally applicable than just
>>>      >>
>>>      >> ethernet and just this one BSP. Is the best alternative to configure
>>>      >> all available devices in
>>>      >>
>>>      >> nexus-devices.h and let LibBSD figure it out?
>>>      >>
>>>      >> Thanks,
>>>      >> Kinsey
>>>      >>
>>>      >
>>>      > If the problem is with "nexus-devices.h": You can always just add
>>>      > further devices or a completely own set of devices in your
>>>      > application. For example it should be no problem to use
>>>      >
>>>      > ====
>>>      > SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);
>>>      > SYSINIT_MODULE_REFERENCE(wlan_sta);
>>>      > SYSINIT_MODULE_REFERENCE(wlan_amrr);
>>>      > SYSINIT_MODULE_REFERENCE(wlan_wep);
>>>      > SYSINIT_MODULE_REFERENCE(wlan_tkip);
>>>      > SYSINIT_MODULE_REFERENCE(wlan_ccmp);
>>>      > SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);
>>>      > SYSINIT_REFERENCE(rtwn_rtl8188eufw);
>>>      >
>>>      > #define RTEMS_BSD_CONFIG_BSP_CONFIG
>>>      > #define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
>>>      > #define RTEMS_BSD_CONFIG_INIT
>>>      >
>>>      > #include <machine/rtems-bsd-config.h>
>>>      > ====
>>>      >
>>>      > in your application to add WLAN support. You could also remove the
>>>      > RTEMS_BSD_CONFIG_BSP_CONFIG (which has the effect that nexus-devices.h
>>>      > is not included in the rtems-bsd-config.h) and define a different set
>>>      > of modules for your application.
>>>      >
>>>      > Best regards
>>>      >
>>>      > Christian
>>>
>>>      I guess this is a misunderstanding on my part. It might still be nice to
>>>      have something switchable for testing purposes, but I see that it can be
>>>      altered relatively easily on the application side of things.
>>>
>>>
>>> I think what you want is like what some of the BSPs do which have a
>>> second ifdef inside the LIBBSP conditional. This is an example from
>>> the QORIQ. Perhaps an option in the BSP?
>> Is the Ultrascale's interface different to the Zync, ie same driver?
> It's the same driver after some upgrades went in to LibBSD to pull in the
> changes from 13 with some additional modifications.

Excellent. The Versal has the same MAC in the hard IP as the Ultra. The Versal
also has a MRMAC and MCDMA glue for the PL but that is a different topic.

>>> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h#n212
>>> <https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h#n212>
>>>
>>>
>>> Would this qualify as a BSP variant?
>> If the hardware exists then I suggest adding both interfaces. This does not
>> effect how or why they are configured (see the config INI file). I would prefer
>> we do not add more variants for hardware that is present, ie 2 NICs.
> Every ultrascale+ chip has all 4 ethernet interfaces. What varies is where the
> PHY(s) are attached.

I suggest you add the MACs and some PHY drivers the eval boards use and let the
stack sort it out. The unknown PHY may work in some cases.

>>> If you can probe for each, you could configure both but I suspect that's
>>> likely undesirable for many applications. A configure option might be
>>> the cleanest thing. Probably not worth a BSP variant.
>> If this is for testing then I suggest you extend or look at the INI file
>> configure option. You should be able to select the interface to use for testing.
> 
> I'll add an option for testing purposes for use in config.ini.

Great and thanks.

Chris