On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore <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? 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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
