RE: [EXT] Re: [PATCH v6 3/3] arm64: dts: cn913x: add device trees for COM Express boards

[Elad Nachman]

> -----Original Message-----
> From: Andrew Lunn <andrew@xxxxxxx>
> Sent: Wednesday, November 29, 2023 3:12 PM
> To: Elad Nachman <enachman@xxxxxxxxxxx>
> Cc: robh+dt@xxxxxxxxxx; krzysztof.kozlowski+dt@xxxxxxxxxx;
> conor+dt@xxxxxxxxxx; gregory.clement@xxxxxxxxxxx;
> sebastian.hesselbarth@xxxxxxxxx; pali@xxxxxxxxxx; mrkiko.rs@xxxxxxxxx;
> chris.packham@xxxxxxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; Yuval Caduri
> <cyuval@xxxxxxxxxxx>
> Subject: Re: [EXT] Re: [PATCH v6 3/3] arm64: dts: cn913x: add device trees for
> COM Express boards
> 
> > > Now i'm confused. What does rd mean?
> > >
> > > I would expect RD mean Reference Design, and that is the complete
> > > device in its box.
> >
> > AC5X RD can either work as you would expect, as a complete standalone
> > box using the internal CPU, or you can move the switch on the back of the
> > box to "external" mode, and connect via an external cable a kit which would
> > allow it to use an external CPU COM Express module, mounted on top of an
> > interposer kit.
> >
> > >
> > > Yet, here you have RD for the carrier?
> > >
> > > The box itself is called cn9131-ac5x-carrier?
> > >
> > > This makes no sense to me.
> > >
> > > Maybe i'm understanding this all wrong, and its the carrier which
> > > you are producing a reference design for? The CPU module does not
> > > really matter? I
> >
> > So in this case, once the switch is set to external as explained above, the
> AC5X RD becomes part of the carrier solution.
> > This is a development/reference solution, not a full commercial solution,
>> hence it has the flexibility to be configured in different modes of operation.
> 
> O.K, now this make more sense. Please expand the documentation, in
> particularly the carrier, explaining how it can be used, and the .dts file about
> it giving a complete system, but again the carrier is the focus.

Will add comments on the dts and dtsi files on the next patch version.

> 
> Is the internal CPU open? Or is it a black box which only Marvell Firmware
> can use? I'm just wondering if we will need another .dtsi file describing the
> internal CPU, and a .dts file which includes both the carrier and the internal
> CPU .dtsi to give an image you can boot on the carrier?

When the board boots in the internal (standalone) CPU mode, the following dts, which is
Already upstreamed, is to be used to boot Linux on the internal, standalone CPU:

arch/arm64/boot/dts/marvell/ac5-98dx35xx-rd.dts

When the board boots in the external CPU mode, the internal CPU
is disabled, and only the switch portion of the SOC acts as a PCIe end-point,
Hence there is little use to describe a CPU which is disabled.

In this mode, the AC5X RD carrier portion only provides a non-CPU PCIe end-point to the
COM Express CPU module (in this case, containing the CN9131 CPU).
There is no CPU booting in this mode on the carrier, only on the COM Express
CPU module.
What runs the Linux is the CN9131 on the COM Express CPU module,
And it accesses the switch end-point on the AC5X RD portion of the carrier via PCIe.

This is briefly documented (will elaborate further in next patch version) in the following file covered in the patch:
arch/arm64/boot/dts/marvell/ac5x-rd-carrier.dtsi

> 
> 	Andrew

FYI,

Elad.