Selection of ethernet peripheral by application

[Joel Sherrill]

On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore <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?

https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/include/bsp/nexus-devices.h#n212

Would this qualify as a BSP variant?

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.

--joel

>
>
> Thanks,
>
> Kinsey
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210604/d4f12fba/attachment.html>