<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore <<a href="mailto:kinsey.moore@oarcorp.com">kinsey.moore@oarcorp.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/4/2021 02:32, Christian MAUDERER wrote:<br>
> Am 02.06.21 um 20:37 schrieb Kinsey Moore:<br>
>> Hello,<br>
>><br>
>>  From what I’ve seen of the various BSPs supported by LibBSD that <br>
>> have multiple ethernet peripherals,<br>
>><br>
>> only one tends to be chosen and supported. I’ve encountered a <br>
>> situation where the majority of platform<br>
>><br>
>> examples (Zynq Ultrascale+ MPSoC dev boards) use CGEM3 as the <br>
>> only/primary ethernet interface and I<br>
>><br>
>> need to have the option of selecting a different peripheral as the <br>
>> primary interface.<br>
>><br>
>> Unfortunately, the current configuration of LibBSD/RTEMS does not <br>
>> allow for easy switching among the<br>
>><br>
>> available interfaces. The easy one-off option is to just create a BSP <br>
>> variant with a little bit of extra logic<br>
>><br>
>> to select the correct interface in LibBSD, but this problem seems <br>
>> more generally applicable than just<br>
>><br>
>> ethernet and just this one BSP. Is the best alternative to configure <br>
>> all available devices in<br>
>><br>
>> nexus-devices.h and let LibBSD figure it out?<br>
>><br>
>> Thanks,<br>
>> Kinsey<br>
>><br>
><br>
> If the problem is with "nexus-devices.h": You can always just add <br>
> further devices or a completely own set of devices in your <br>
> application. For example it should be no problem to use<br>
><br>
> ====<br>
> SYSINIT_MODULE_REFERENCE(wlan_ratectl_none);<br>
> SYSINIT_MODULE_REFERENCE(wlan_sta);<br>
> SYSINIT_MODULE_REFERENCE(wlan_amrr);<br>
> SYSINIT_MODULE_REFERENCE(wlan_wep);<br>
> SYSINIT_MODULE_REFERENCE(wlan_tkip);<br>
> SYSINIT_MODULE_REFERENCE(wlan_ccmp);<br>
> SYSINIT_DRIVER_REFERENCE(rtwn_usb, uhub);<br>
> SYSINIT_REFERENCE(rtwn_rtl8188eufw);<br>
><br>
> #define RTEMS_BSD_CONFIG_BSP_CONFIG<br>
> #define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL<br>
> #define RTEMS_BSD_CONFIG_INIT<br>
><br>
> #include <machine/rtems-bsd-config.h><br>
> ====<br>
><br>
> in your application to add WLAN support. You could also remove the <br>
> RTEMS_BSD_CONFIG_BSP_CONFIG (which has the effect that nexus-devices.h <br>
> is not included in the rtems-bsd-config.h) and define a different set <br>
> of modules for your application.<br>
><br>
> Best regards<br>
><br>
> Christian<br>
<br>
I guess this is a misunderstanding on my part. It might still be nice to <br>
have something switchable for testing purposes, but I see that it can be <br>
altered relatively easily on the application side of things.<br></blockquote><div><br></div><div>I think what you want is like what some of the BSPs do which have a </div><div>second ifdef inside the LIBBSP conditional. This is an example from</div><div>the QORIQ. Perhaps an option in the BSP?<br><br><a href="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</a><br><br>Would this qualify as a BSP variant? </div><div><br></div><div>If you can probe for each, you could configure both but I suspect that's</div><div>likely undesirable for many applications. A configure option might be</div><div>the cleanest thing. Probably not worth a BSP variant.</div><div><br></div><div>--joel </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
Thanks,<br>
<br>
Kinsey<br>
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div>