Hi Krzysztof,
> >>
> >> Which piece of actual hardware is represented in qcom-ride-common?
> >>
> >
> > All daughter cards like SOC-card, display, camera, ethernet, pcie, sensor, etc.
>
> No, I asked about the name of the hardware, datasheet, ID or picture.
> Common DTSI represents somoething, not just because you wanted to add
> something you had in downstream.
>
Currently we don't have any datasheet or document which is publicly
available, so I will try my best to describe our HW.
Ride is a modular hardware system with several smaller daughter cards
connected to single backplane board and each daughter card is stacked on
top of each other. I will try to explain each daughter card with HW
components and how it is connected to construct the ride-hw.
Backplane board:
- It contains an MCU (Aurix TC397), CAN/LIN transceiver,
Audio/GNSS/IMU-I2C signals, Fan header
- It holds & connects all the daughter cards.
SoC card:
- It contains:
- SoM:
- One of QCS9075M/QCS9100M/QAM8775p SoM.
- Each SoM is composed of either qcs9075/qcs9100/sa8775p SoC, along
with DDR & PMICs.
- Each SoM can be mounted to same SoC-daughter card of ride-hw.
- In addition to SoM, it also has
- 4x UART, 2x USB 3.1 & 1x USB 2.0
- Memory: 1x OSPI, 2x UFS-3.1
- Debug: JTAG/QDSS header
- PCIe0, PCIe1 & Display signals
- Reset button
- It is connected to backplain board via B2B connector.
Display card:
- It contains:
- 4 eDP ports & 2 DSI-DP bridge
- I2C GPIO expander & I2C switch
- It is connected to SoC-card via B2B connector.
Camera card:
- It contains:
- 4 Quad DE-serializer, each supporting 4 MIPI CSI inputs
- Total upto 16 Cameras ports are supported.
- It is connected to backplain board via B2B connector.
Ethernet card:
- There are two variants of ethernet card each with different
capabilities:
- [Ethernet-v1] card contains:
- 2x 1G RGMII phy, 2x 1G SGMII phy(enabled currently)
- Total 4 phy supported, only 2 phy are enabled and it is used in
ride.
- [Ethernet-v2] card contains:
- 2x 1G RGMII phy, 2x 2.5G HSGMII(enabled currently) & 10G PCIe based
MAC+PHY controller
- Total 5 phy supported, only 2 phy are enabled and it is used in
ride-r3.
- Either [Ethernet-v1] or [Ethernet-v2] is connected to backplain board
via B2B connector.
PCIe card:
- It contains:
- PCIe connections to SoC-card
- NVME, 2x WLBT module QCA6696/QCA6698 (Wi-Fi & bluetooth solution) &
GNSS module
- It is connected to backplain board via B2B connector & PCIe signals are
connected to SoC card via flyover cables.
Sensor Card:
- It contains 3-Axix compass & 6-Axis 3D IMU (accel/gyro) module which
are communicating via I2C
- It is connected to backplain board via B2B connector.
Front panel card:
- It does not contain any active circuitry, only ports are available
- Audio-in/out ports
- USB hub ports
- CAN/LIN ports
- 12V power off switch
- It is connected to backplain board via ribbon cable.
>
> >
> >> | | | +-------------------------+-----------------------+-----------------< sa8775p-ride-common.dtsi |
>
>
> There is no ride-common hardware. If there is, send us any proof of its
> existence. all your statements here show you want to create some
> structure because you like it. I don't think you get my questions. You
> painted diagram of DTS, not hardware.
>
> We talk about hardware. Not your DTS. Drop all DTSI, DTS, DTSO from here
> and show us the hardware.
>
Considering outlined h/w description, following are ride configuration
variation each platform supporting:
Between qcs9075, qcs9100 & sa8775p ride/ride-r3 boards, SoM is changing;
And between ride & ride-r3 ethernet is changing.
Excluding these differences all other cards i.e SoC, display, camera, PCIe,
sensor, front & backplain are same and are refactored in ride-common.
If any variant of these cards comes up in future we need to refactor
ride-common accordingly. I will try to outline this as clearly as possible
in next commit log.
Considering current outlines of all daughter cards, following defines
ride/ride-r3 variant boards:
- sa8775p ride : QAM8775p SoM + [Ethernet-v1] + other daughter cards
- sa8775p ride-r3 : QAM8775p SoM + [Ethernet-v2] + other daughter cards
- qcs9100 ride-r3 : QCS9100M SoM + [Ethernet-v2] + other daughter cards
- qcs9075 ride-r3 : QCS9075M SoM + [Ethernet-v2] + other daughter cards
Since we don't have a document yet which formally describes
qcs9075/qcs9100 ride board with [Ethernet-v1] card, I shall be dropping
this particular variant in next patch series and re-send after complete
documentation is available.
> > Actually we are not including dts here instead *.dtso file will be
> > overlayed to *-ride.dts to generate *-ride-r3.dts.
> >
> > Below is the correct arrow sequence.
>
> And the overlay represents what exactly? Different board? No, that's not
> how overlays should be used.
>
> You have different board, you have different DTS.
>
No the overlay is not a different ride board. This overlay represents
[Ethernet-v2] card which is different than [Ethernet-v1] card.
We thought of using overlay as otherwise we have to create separate board
DTS to support [Ethernet-v2] cards.
>
> >
> >> | +-------------------------+-----------------------+-------------------< sa8775p-ride-ethernet-aqr115c.dtso |
>
> How does "sa8775p-ride-ethernet-aqr115c" hardware look like?
>
Here sa8775p-ride-ethernet-aqr115c.dtso is representing [Ethernet-v2] card.
>
> Several companies solved it - most of NXP vendors, many Renesas etc. I
> really do not get why this needs so much talk and you cannot learn from
> their architecture how SoM should be represented.
>
Our SoM is separate HW which is reusable in ride-hw. Can you share more
details on what we can improve here?
Thanks & regards,
Wasim
