Selection of ethernet peripheral by application

[Kinsey Moore]

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


Thanks,

Kinsey