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
