On 4/6/21 11:26 pm, Joel Sherrill wrote: > On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore <kinsey.mo...@oarcorp.com > <mailto:kinsey.mo...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
