Re: Selection of ethernet peripheral by application

2021-06-07 Thread Chris Johns 


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

Re: Selection of ethernet peripheral by application

2021-06-07 Thread 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 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 
 > 
 >
 > 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 


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

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Selection of ethernet peripheral by application

2021-06-06 Thread Chris Johns 
On 4/6/21 11:26 pm, Joel Sherrill wrote:
> On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore  > 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 
> > 
> >
> > 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
>  
> 
> 
> 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

Re: Selection of ethernet peripheral by application

2021-06-04 Thread Joel Sherrill 
On Fri, Jun 4, 2021 at 7:59 AM Kinsey Moore 
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 
> > 
> >
> > 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

Re: Selection of ethernet peripheral by application

2021-06-04 Thread Kinsey Moore 

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 


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.



Thanks,

Kinsey

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Selection of ethernet peripheral by application

2021-06-04 Thread Christian MAUDERER 

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 


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

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Selection of ethernet peripheral by application

2021-06-02 Thread Chris Johns 
On 3/6/21 4:37 am, Kinsey Moore wrote:
> 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?

I am not sure what the issue is. I also do not know what is "the correct
interface" means.

How many interfaces do you need to support and what are they?

If a device like the Ultrascale as 2 hard IP GEM MACs maybe LibBSD for that BSP
should enable both by default. Maybe the Zynq and Versal (when added) should be
the same. If a user adds another MAC in the PL, for example a Tri-Core LogicCore
block (and adds a driver) then there may be 3 interfaces present but that would
not be enabled by default. The same goes for the PC with the ability to plug in
NIC boards.

What happens after probing and the drivers are present is for the application to
manage via the stack's various interfaces. The rc.conf support I added uses
commands such as ifconfig to access those interfaces and provide support for
initialisation and set up. There are other ways that could be done.

I wonder if there is a misunderstanding and it could be on my part. LibBSD does
not ship with THE defined set of interfaces. It has a minimal set to allow
testing and maybe that is wrong. A lot of the testing framework is just that a
testing framework and if you wish to leverage that support in applications then
all the best because that support can and may change to suite the testing needs
of LibBSD and there is no requirement to make it backwards compatible for
application that depend on it.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Selection of ethernet peripheral by application

2021-06-02 Thread Joel Sherrill 
On Wed, Jun 2, 2021 at 1:37 PM Kinsey Moore 
wrote:

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

Thinking out loud. The first order selection of the driver is the
LIBBSD_ABC header guard to
select a BSP. Some BSPs have a second ifdef. I think qoriq is an example.
But this would
require adding a BSP configure option or 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

Selection of ethernet peripheral by application

2021-06-02 Thread 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel