On 7/6/21 10:05 pm, Kinsey Moore wrote: > 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.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? > It's the same driver after some upgrades went in to LibBSD to pull in the > changes from 13 with some additional modifications.
Excellent. The Versal has the same MAC in the hard IP as the Ultra. The Versal also has a MRMAC and MCDMA glue for the PL but that is a different topic. >>> 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. I suggest you add the MACs and some PHY drivers the eval boards use and let the stack sort it out. The unknown PHY may work in some cases. >>> 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. Great and thanks. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
