Re: [PATCH 2/2] arm64: dts: rockchip: Add CM3588 NAS board

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello Sebastian,

On 2024-05-28 19:22, Sebastian Kropatsch wrote:
Am 27.05.2024 um 21:02 schrieb Jonas Karlman:
On 2024-05-26 23:48, Sebastian Kropatsch wrote:
The CM3588 NAS by FriendlyElec pairs the CM3588 compute module, based on
the Rockchip RK3588 SoC, with the CM3588 NAS Kit carrier board.

[...]

PCIe bifurcation is used to handle all four M.2 sockets at PCIe 3.0 x1
speed. Data lane mapping in the DT is done like described in commit
f8020dfb311d ("phy: rockchip-snps-pcie3: fix bifurcation on rk3588").

This device tree includes support for eMMC, SD card, ethernet, all USB2 and USB3 ports, all four M.2 slots, GPU, RTC, buzzer, UART debugging as
well as the buttons and LEDs.
The GPIOs are labeled according to the schematics.

Signed-off-by: Sebastian Kropatsch <seb-dev@xxxxxx>
---
  arch/arm64/boot/dts/rockchip/Makefile         |    1 +
.../boot/dts/rockchip/rk3588-cm3588-nas.dts | 1269 +++++++++++++++++
  2 files changed, 1270 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588-cm3588-nas.dts

Because the CM3588 is a SoM and the NAS is a carrier board this should
probably be split in two, cm3588.dtsi and cm3588-nas.dts.

I thought about this before submitting. My reason for not splitting this
into two files for now was that as far as I know this board is the only
combination for the CM, maybe no other daughter board will ever get
released. If another carrier board compatible with the CM3588 is
released, the splitting could be done at that point in time.

But since both you and Heiko prefer to have it split, I will figure out
a way how and which parts will have to split up to the CM so we can
have two files in the end. I guess most things will go into the NAS dts
anyway.

I'll have a look how other Rockchip compute modules with split device
trees were done in the past and orient myself by that.

I also support the DT split between the SoM and the carrier board,
even if there are currently no more carrier boards available for
the particular SoM.  That may seem redundant, but it reflects the
nature of the hardware setup, in which the SoM plugs into the carrier
board.  This follows the principle of the DT describing hardware.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux