Re: [PATCH 1/2] arm64: dts: qcom: rubikpi3: Add qcs6490-rubikpi3 board dts

[Hongyang Zhao <hongyang.zhao@thundersoft.com>]

Hi, thank you for your review.

On 11/14/25 5:34 PM, Hongyang Zhao wrote:
> > Add DTS for Thundercomm qcs6490-rubikpi3 board which uses
> > QCS6490 SoC.
> > 
> > Works:
> > - Bluetooth (AP6256)
> > - Wi-Fi (AP6256)
> > - Ethernet (AX88179B connected to UPD720201)
> > - FAN
> > - Two USB Type-A 3.0 ports (UPD720201 connected to PCIe0)
> > - M.2 M-Key 2280 PCIe 3.0
> > - RTC
> > - USB Type-C
> > - USB Type-A 2.0 port
> > - 40PIN: I2C x1, UART x1
> > 
> > Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com>
> > Reviewed-by: Roger Shimizu <rosh@debian.org>
> > ---
> >   arch/arm64/boot/dts/qcom/Makefile                  |    1 +
> >   .../boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts | 1415 ++++++++++++++++++++
> >   2 files changed, 1416 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
> > index 6f34d5ed331c..2433b15754fe 100644
> > --- a/arch/arm64/boot/dts/qcom/Makefile
> > +++ b/arch/arm64/boot/dts/qcom/Makefile
> > @@ -138,6 +138,7 @@ qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2
> >   
> >   dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2-industrial-mezzanine.dtb
> >   dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-rb3gen2-vision-mezzanine.dtb
> > +dtb-$(CONFIG_ARCH_QCOM)	+= qcs6490-thundercomm-rubikpi3.dtb
> >   dtb-$(CONFIG_ARCH_QCOM)	+= qcs8300-ride.dtb
> >   dtb-$(CONFIG_ARCH_QCOM)	+= qcs8550-aim300-aiot.dtb
> >   dtb-$(CONFIG_ARCH_QCOM)	+= qcs9100-ride.dtb
> > diff --git a/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
> > new file mode 100644
> > index 000000000000..4c9016992de3
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts
> > @@ -0,0 +1,1415 @@
> 
> [snip]
> 
> > +
> > +&pcie0 {
> > +	perst-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
> > +	wake-gpios = <&tlmm 89 GPIO_ACTIVE_HIGH>;
> > +
> > +	pinctrl-0 = <&pcie0_clkreq_n>,
> > +		    <&pcie0_reset_n>,
> > +		    <&pcie0_wake_n>;
> > +	pinctrl-names = "default";
> > +
> > +	status = "okay";
> > +};
> > +
> > +&pcie0_phy {
> > +	vdda-phy-supply = <&vreg_l10c_0p88>;
> > +	vdda-pll-supply = <&vreg_l6b_1p2>;
> > +
> > +	status = "okay";
> > +};
> > +
> > +&pcie1 {
> > +	/* Using traditional address mapping */
> > +	reg = <0 0x01c08000 0 0x3000>,
> > +	      <0 0x40000000 0 0xf1d>,
> > +	      <0 0x40000f20 0 0xa8>,
> > +	      <0 0x40001000 0 0x1000>,
> > +	      <0 0x40100000 0 0x100000>;
> > +
> > +	ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>,
> > +		 <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x1fd00000>;
> 

This issue has been resolved (bba4562adc Revert "arm64: dts: qcom: sc7280: Increase config size to 256MB for ECAM feature").

And I will remove this part of the modification, like this:

&pcie1 {
	perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
	wake-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;

	pinctrl-0 = <&pcie1_clkreq_n>,
		    <&pcie1_reset_n>,
		    <&pcie1_wake_n>;
	pinctrl-names = "default";

	status = "okay";
};

> Thanks for attempting to fix the PCIe issues. With your patch series 
> applied on top of linux-next, I'm still seeing PCIe issues:
> 
> [    0.380693] Internal error: synchronous external abort: 
> 0000000096000010 [#1]  SMP
> [    0.406491] Modules linked in:
> [    0.406495] CPU: 5 UID: 0 PID: 106 Comm: kworker/u32:6 Tainted: G   M 
>                 6.18.0-rc5-next-20251113 #13 NONE
> [    0.406499] Tainted: [M]=MACHINE_CHECK
> [    0.406500] Hardware name: thundercomm Thundercomm RUBIK Pi 
> 3/Thundercomm RUBIK Pi 3, BIOS 2025.10-rc4 10/01/2025
> [    0.406502] Workqueue: async async_run_entry_fn
> [    0.406508] pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS 
> BTYPE=--)
> [    0.428362] pc : __pi_memset_generic+0x16c/0x188
> [    0.428366] lr : dma_direct_alloc+0x19c/0x3d0
> [    0.428370] sp : ffff8000810e3920
> [    0.428371] x29: ffff8000810e3920 x28: ffff000080d0f810 x27: 
> ffffba4c6196ec48
> [    0.428373] x26: ffff000080d0f810 x25: ffffba4c607b31cc x24: 
> 0000000000000000
> [    0.428375] x23: ffff000080d0f810 x22: ffff000000c00000 x21: 
> ffff000082858948
> [    0.428376] x20: 0000000000001000 x19: fffffdffc0030000 x18: 
> 000000000000000a
> [    0.428378] x17: ffff0000823dae00 x16: 0000000000000000 x15: 
> 0000000000000000
> [    0.428380] x14: 00000000ffffffff x13: 0000000000000068 x12: 
> 0000000000000100
> [    0.449344] x11: 0000000000000000 x10: ffff0001fef99500 x9 : 
> 0000000000000000
> [    0.449345] x8 : ffff000000c00000 x7 : 0000000000000000 x6 : 
> 000000000000003f
> [    0.449347] x5 : 0000000000000040 x4 : 0000000000000000 x3 : 
> 0000000000000004
> [    0.449349] x2 : 0000000000000fc0 x1 : 0000000000000000 x0 : 
> ffff000000c00000
> [    0.449350] Call trace:
> [    0.449351]  __pi_memset_generic+0x16c/0x188 (P)
> [    0.449354]  dma_alloc_attrs+0x94/0x210
> [    0.449357]  dmam_alloc_attrs+0x74/0xc0
> [    0.469967]  dw_pcie_msi_host_init+0x100/0x300
> [    0.469971]  dw_pcie_host_init+0x5e4/0x6d8
> [    0.491913]  qcom_pcie_probe+0x5a8/0x838
> [    0.491916]  platform_probe+0x64/0xc0
> [    0.491919]  really_probe+0xc8/0x3f0
> [    0.491921]  __driver_probe_device+0x88/0x170
> [    0.491922]  driver_probe_device+0x48/0x130
> [    0.491923]  __device_attach_driver+0xc4/0x190
> [    0.491925]  bus_for_each_drv+0x90/0x100
> [    0.491928]  __device_attach_async_helper+0xb8/0x120
> [    0.491929]  async_run_entry_fn+0x3c/0x1e0
> [    0.491931]  process_one_work+0x150/0x3a0
> [    0.491934]  worker_thread+0x288/0x480
> [    0.491936]  kthread+0x118/0x1e0
> [    0.491938]  ret_from_fork+0x10/0x20
> [    0.513092] Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)
> [    0.513094] ---[ end trace 0000000000000000 ]---
> 
> I can only get the device to boot by disabling both pcie0 and pcie1.
> 

I've tried several approaches, but the same call trace has never appeared;
PCIe0 and PCIe1 work fine, and my boot parameters are as follows:

linux /boot/vmlinuz-mainline root=UUID=131450ff-95bc-4791-b611-70855201b0cd rw console=ttyMSM0,115200n8 earlycon ignore_loglevel quiet splash vt.handoff=7

> > +
> > +
> > +	perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
> > +	wake-gpios = <&tlmm 3 GPIO_ACTIVE_LOW>;
> > +
> > +	pinctrl-0 = <&pcie1_clkreq_n>,
> > +		    <&pcie1_reset_n>,
> > +		    <&pcie1_wake_n>;
> > +	pinctrl-names = "default";
> > +
> > +	status = "okay";
> > +};
> > +
> > +&pcie1_phy {
> > +	vdda-phy-supply = <&vreg_l10c_0p88>;
> > +	vdda-pll-supply = <&vreg_l6b_1p2>;
> > +
> > +	status = "okay";
> > +};
> > +
> 
> [snip]
> 
> > +
> > +&remoteproc_adsp {
> > +	firmware-name = "qcom/qcs6490/adsp.mbn";
> > +
> > +	status = "okay";
> > +};
> 
> I'm fairly sure that this is the wrong ADSP firmware. With the firmware 
> in linux-firmware, I'm seeing charger pd crashes and the ADSP constantly 
> restarting. Using the Radxa Dragon Q6A ADSP firmware which disables the 
> charging feature in the firmware works way better and does not result in 
> crashes.
> 

Sorry, I didn't use linux-firmware for verification before.
Using firmware customized for RUBIK Pi 3 has solved this problem,
and I will submit this firmware to the linux-firmware repository
with the following modifications:

&remoteproc_adsp {
	firmware-name = "qcom/qcs6490/thundercomm/rubikpi3/adsp.mbn";

	status = "okay";
};

> > +
> > +&remoteproc_cdsp {
> > +	firmware-name = "qcom/qcs6490/cdsp.mbn";
> > +
> > +	status = "okay";
> > +};
> > +

> > [snip]

---
Thank you for the review!
Hongyang