On Tue, Nov 1, 2022 at 9:22 PM Chris Johns <chr...@rtems.org> wrote: > > > On 2/11/2022 1:18 pm, Kinsey Moore wrote: > > On Tue, Nov 1, 2022 at 5:49 PM Chris Johns <chr...@rtems.org > > <mailto:chr...@rtems.org>> wrote: > > > > On 2/11/2022 8:56 am, Kinsey Moore wrote: > > > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns <chr...@rtems.org > > <mailto:chr...@rtems.org> > > > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote: > > > On 2/11/2022 5:51 am, Kinsey Moore wrote: > > > > Certain hardware configurations will always use SGMII > instead of RGMII. > > > > Apply the appropriate flags for the relevant BSPs. > > > > --- > > > > freebsd/sys/dev/cadence/if_cgem.c | 10 ++++++++++ > > > > 1 file changed, 10 insertions(+) > > > > > > > > diff --git a/freebsd/sys/dev/cadence/if_cgem.c > > > b/freebsd/sys/dev/cadence/if_cgem.c > > > > index 3eaaf6b2..9b4cf693 100644 > > > > --- a/freebsd/sys/dev/cadence/if_cgem.c > > > > +++ b/freebsd/sys/dev/cadence/if_cgem.c > > > > @@ -1296,6 +1296,16 @@ cgem_config(struct cgem_softc *sc) > > > > CGEM_NET_CFG_FULL_DUPLEX | > > > > CGEM_NET_CFG_SPEED100; > > > > > > > > +#ifdef __rtems__ > > > > +#define STRINGIFY(to_str) #to_str > > > > +#define BSP_STR(to_str) STRINGIFY(to_str) > > > > + /* Configure the PHYs to use SGMII for particular BSPs > */ > > > > + if ( 0 == strcmp( BSP_STR(RTEMS_BSP), > > "xilinx_zynqmp_lp64_cfc400x" ) ) { > > > > + net_cfg |= CGEM_NET_CFG_SGMII_EN; > > > > + net_cfg |= CGEM_NET_CFG_PCS_SEL; > > > > + } > > > > > > This makes it a precedent a cgem device has to be an RTEMS BSP > to > > support SGMII. > > > I do not think that is a good idea. > > > > > > I don't particularly like this solution either, but I evaluated a > few other > > > options (see below). > > > > I also do not like it. > > > > > Is the simplest solution adding a weak function call asks > which mode > > and the > > > default call returns RGMII? > > > > > > The downside to that is that none of the tests can operate as > expected on a > > > SGMII-attached-PHY system since the application would be > overriding the weak > > > symbol and the tests wouldn't do that. Another option would be to > have a > > generic > > > option in RTEMS that specifies the PHY attachment and can be set in > > config.ini, > > > but that would appear to be dead code since it's not used within > RTEMS. > > > > Would FDT solve this problem? Forcing FDT support onto the cgem > driver would > > break compatibility so it would have to handle a default state. If > FDT probes > > were tolerant of calls without a valid FDT being loaded it would be > better but > > our FDT support seems to have no middle ground from what I can see. > > > > > > FDT could technically solve the problem, current driver support and PHY > > transport option support notwithstanding. As you pointed out, there isn't > > currently a way to have both static configuration and FDT support at the > same > > time and multiple BSPs across multiple architectures use the CGEM > support - at > > least Zynq, ZynqMP, and Versal - all of which would need the appropriate > support > > added. I thought we had a RISC-V BSP that used it as well, but I don't > see it at > > the moment. > > > > > > > As far as I'm aware, the closest analog in LibBSD would be the > buildset > > > configuration, but that seems more like a place to define which > modules get > > > built than a location for configuring hardware. > > > > I think FDT is handling this stuff for other archs and the MRMAC > will also > > require FDT support. > > > > > > It is and the FDT support in this driver in FreeBSD 13 is a bit better. > > Does this mean existing Zynq etc BSPs would need to add FDT support? >
Yes, unless there's a solution that allows both to exist at the same time. I haven't investigated that option thoroughly. Kinsey
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
