[PATCH rtems-libbsd] freebsd/cgem: Use SGMII when necessary

[Kinsey Moore]

On Tue, Nov 1, 2022 at 5:49 PM Chris Johns <chrisj at rtems.org> wrote:

> On 2/11/2022 8:56 am, Kinsey Moore wrote:
> > On Tue, Nov 1, 2022 at 4:14 PM Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at 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.

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20221101/165f1615/attachment.htm>