Selection of ethernet peripheral by application

[Chris Johns]

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?

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

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

Chris