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