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

[Chris Johns]

On 2/11/2022 1:48 pm, Kinsey Moore wrote:
> On Tue, Nov 1, 2022 at 9:22 PM Chris Johns <chrisj at rtems.org
> <mailto:chrisj at rtems.org>> wrote:
>     On 2/11/2022 1:18 pm, Kinsey Moore wrote:
>     > On Tue, Nov 1, 2022 at 5:49 PM Chris Johns <chrisj at rtems.org
>     <mailto:chrisj at rtems.org>
>     > <mailto:chrisj at rtems.org <mailto: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>
>     >     <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>>
>     >     > <mailto:chrisj at rtems.org <mailto:chrisj at rtems.org>
>     <mailto: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.
> 
>     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.

Maybe we meet up and discuss the options.

Chris