| Message ID | 20221003125444.12975-1-quic_ppareek@quicinc.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: dts: qcom: add dts for sa8540p-ride board | expand |
On Mon, Oct 03, 2022 at 06:24:40PM +0530, Parikshit Pareek wrote: > Parikshit Pareek (3): > dt-bindings: arm: qcom: Document additional sa8540p device > arm64: dts: qcom: sa8295p: move common nodes to dtsi > arm64: dts: qcom: introduce sa8540p-ride dts For the series: Reviewed-by: Brian Masney <bmasney@redhat.com> Tested-by: Brian Masney <bmasney@redhat.com> Just for documentation purposes, to get linux-next-20220930 booting on the QDrive3 with the upstream arm64 defconfig I had to apply the following patches: - arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size https://lore.kernel.org/linux-arm-msm/20220915141601.18435-1-johan+linaro@kernel.org/ Without this, the phy fails to probe due to the following error: qcom-qmp-ufs-phy 1d87000.phy: can't request region for resource [mem 0x01d87400-0x01d87507] qcom-qmp-ufs-phy 1d87000.phy: failed to create lane0 phy, -16 qcom-qmp-ufs-phy: probe of 1d87000.phy failed with error -16 - This hack patch is still needed: disable has_address_auth_metacap and has_generic_auth https://github.com/andersson/kernel/commit/d46a4d05d5a17ff4447af08471edd78e194d48e5 Without this, the boot hangs at: rcu: srcu_init: Setting srcu_struct sizes based on contention. arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns - My UFS clock patch is still needed: arm64: dts: qcom: sc8280xp: correct ref_aux clock for ufs_mem_phy https://lore.kernel.org/lkml/20220830180120.2082734-1-bmasney@redhat.com/T/#u - I didn't use an initrd for testing so I had to change the options CONFIG_SCSI_UFS_QCOM and CONFIG_PHY_QCOM_QMP from =m to =y. Brian
On Mon, Oct 03, 2022 at 01:31:52PM -0400, Brian Masney wrote: > On Mon, Oct 03, 2022 at 06:24:40PM +0530, Parikshit Pareek wrote: > > Parikshit Pareek (3): > > dt-bindings: arm: qcom: Document additional sa8540p device > > arm64: dts: qcom: sa8295p: move common nodes to dtsi > > arm64: dts: qcom: introduce sa8540p-ride dts > > For the series: > > Reviewed-by: Brian Masney <bmasney@redhat.com> > Tested-by: Brian Masney <bmasney@redhat.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> # QDrive3/sa8540p-adp-ride > > > Just for documentation purposes, to get linux-next-20220930 booting on > the QDrive3 with the upstream arm64 defconfig I had to apply the > following patches: > > - arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size > https://lore.kernel.org/linux-arm-msm/20220915141601.18435-1-johan+linaro@kernel.org/ > > Without this, the phy fails to probe due to the following error: > > qcom-qmp-ufs-phy 1d87000.phy: can't request region for resource [mem 0x01d87400-0x01d87507] > qcom-qmp-ufs-phy 1d87000.phy: failed to create lane0 phy, -16 > qcom-qmp-ufs-phy: probe of 1d87000.phy failed with error -16 > > - This hack patch is still needed: > disable has_address_auth_metacap and has_generic_auth > https://github.com/andersson/kernel/commit/d46a4d05d5a17ff4447af08471edd78e194d48e5 > > Without this, the boot hangs at: > > rcu: srcu_init: Setting srcu_struct sizes based on contention. > arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). > clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns > sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns > > - My UFS clock patch is still needed: > arm64: dts: qcom: sc8280xp: correct ref_aux clock for ufs_mem_phy > https://lore.kernel.org/lkml/20220830180120.2082734-1-bmasney@redhat.com/T/#u > > - I didn't use an initrd for testing so I had to change the options > CONFIG_SCSI_UFS_QCOM and CONFIG_PHY_QCOM_QMP from =m to =y. > > Brian >
On 03/10/2022 14:54, Parikshit Pareek wrote: > Change in v5: > - Moved the usb and ufs nodes from sa8540p-adp.dtsi file to respective > board specific dts files: sa8295p-adp.dts and sa8540p-adp-ride.dts. Is there any benefit in this? USB0/2 and UFS (not UFS card) nodes are identical in the 2 files. Konrad > Took inputs from Shazad Hussain in this regard(John) > - Added more description of the board differences(John) > - Not including Reviewed-by for Krzysztof, because of the new changes to > be reviewed. > - Removed Reported-by tag(John). > > Changes in v4: > - Removed the ufs_card_hc node, as it is not mounted on Qdrive-3 board. > - Removed usb_1 relared nodes, as usb1 doesn't have any port connected on > Qdrive3 board. > - Added Reported-by tag for Shazad(for ufs and usb_1 node removals) > > Changes in v3: > - Added Acked-by tag (Krzysztof) > - Renamed dtsi to sa8540p-adp.dtsi (John) > - Removed copyright from sa8295-adp.dts and sa8295-adp.dtsi(John) > - Added cover letter > > change in v2: > - Make dt-binding patch as the first one in the patch set > - Add , after year 2022, in the license header > > Initial version: > - Move the common nodes to sa8540p-adp.dtsi, and create qrive-3 board > specific file sa8540p-adp-ride.dts. > > > Parikshit Pareek (3): > dt-bindings: arm: qcom: Document additional sa8540p device > arm64: dts: qcom: sa8295p: move common nodes to dtsi > arm64: dts: qcom: introduce sa8540p-ride dts > > .../devicetree/bindings/arm/qcom.yaml | 1 + > arch/arm64/boot/dts/qcom/Makefile | 1 + > arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 528 +++++------------- > arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts | 71 +++ > .../{sa8295p-adp.dts => sa8540p-adp.dtsi} | 133 ----- > 5 files changed, 219 insertions(+), 515 deletions(-) > rewrite arch/arm64/boot/dts/qcom/sa8295p-adp.dts (70%) > create mode 100644 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts > copy arch/arm64/boot/dts/qcom/{sa8295p-adp.dts => sa8540p-adp.dtsi} (72%) >
On Mon, Oct 03, 2022 at 01:31:52PM -0400, Brian Masney wrote: > Just for documentation purposes, to get linux-next-20220930 booting on > the QDrive3 with the upstream arm64 defconfig I had to apply the > following patches: > > - arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size > https://lore.kernel.org/linux-arm-msm/20220915141601.18435-1-johan+linaro@kernel.org/ > > Without this, the phy fails to probe due to the following error: > > qcom-qmp-ufs-phy 1d87000.phy: can't request region for resource [mem 0x01d87400-0x01d87507] > qcom-qmp-ufs-phy 1d87000.phy: failed to create lane0 phy, -16 > qcom-qmp-ufs-phy: probe of 1d87000.phy failed with error -16 > > - This hack patch is still needed: > disable has_address_auth_metacap and has_generic_auth > https://github.com/andersson/kernel/commit/d46a4d05d5a17ff4447af08471edd78e194d48e5 > > Without this, the boot hangs at: > > rcu: srcu_init: Setting srcu_struct sizes based on contention. > arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). > clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns > sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns > > - My UFS clock patch is still needed: > arm64: dts: qcom: sc8280xp: correct ref_aux clock for ufs_mem_phy > https://lore.kernel.org/lkml/20220830180120.2082734-1-bmasney@redhat.com/T/#u > > - I didn't use an initrd for testing so I had to change the options > CONFIG_SCSI_UFS_QCOM and CONFIG_PHY_QCOM_QMP from =m to =y. I followed the instructions above and linux-next-20220930 booted on the QDrive3 to a prompt. It then hanged after a couple minutes and rebooted in Sahara mode: B - 1662280 - Sahara Init B - 1665422 - Sahara Open There seems to be no trace from the kernel, this happened consistently over 3 boots. I asked Brian, he mentioned he only booted to prompt so that may have happened unbeknownst to him as well.
On Tue, Oct 04, 2022 at 09:28:16AM -0400, Eric Chanudet wrote: > On Mon, Oct 03, 2022 at 01:31:52PM -0400, Brian Masney wrote: > > Just for documentation purposes, to get linux-next-20220930 booting on > > the QDrive3 with the upstream arm64 defconfig I had to apply the > > following patches: > > > > - arm64: dts: qcom: sc8280xp: fix UFS PHY serdes size > > https://lore.kernel.org/linux-arm-msm/20220915141601.18435-1-johan+linaro@kernel.org/ > > > > Without this, the phy fails to probe due to the following error: > > > > qcom-qmp-ufs-phy 1d87000.phy: can't request region for resource [mem 0x01d87400-0x01d87507] > > qcom-qmp-ufs-phy 1d87000.phy: failed to create lane0 phy, -16 > > qcom-qmp-ufs-phy: probe of 1d87000.phy failed with error -16 > > > > - This hack patch is still needed: > > disable has_address_auth_metacap and has_generic_auth > > https://github.com/andersson/kernel/commit/d46a4d05d5a17ff4447af08471edd78e194d48e5 > > > > Without this, the boot hangs at: > > > > rcu: srcu_init: Setting srcu_struct sizes based on contention. > > arch_timer: cp15 and mmio timer(s) running at 19.20MHz (virt/virt). > > clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x46d987e47, max_idle_ns: 440795202767 ns > > sched_clock: 56 bits at 19MHz, resolution 52ns, wraps every 4398046511078ns > > > > - My UFS clock patch is still needed: > > arm64: dts: qcom: sc8280xp: correct ref_aux clock for ufs_mem_phy > > https://lore.kernel.org/lkml/20220830180120.2082734-1-bmasney@redhat.com/T/#u > > > > - I didn't use an initrd for testing so I had to change the options > > CONFIG_SCSI_UFS_QCOM and CONFIG_PHY_QCOM_QMP from =m to =y. > > I followed the instructions above and linux-next-20220930 booted on the > QDrive3 to a prompt. It then hanged after a couple minutes and rebooted > in Sahara mode: > B - 1662280 - Sahara Init > B - 1665422 - Sahara Open > > There seems to be no trace from the kernel, this happened consistently > over 3 boots. > > I asked Brian, he mentioned he only booted to prompt so that may have > happened unbeknownst to him as well. I took the upstream defconfig for a spin and see similar. My T-B was for this defconfig (downstream one + make olddefconfig) which works ok for me: https://gitlab.com/ahalaney/linux/-/commit/40f1b241117716ef4b0e27cf50054e749b8ff608 Thanks, Andrew > > -- > Eric Chanudet >
On Mon, Oct 03, 2022 at 11:05:11PM +0200, Konrad Dybcio wrote: > > On 03/10/2022 14:54, Parikshit Pareek wrote: > > Change in v5: > > - Moved the usb and ufs nodes from sa8540p-adp.dtsi file to respective > > board specific dts files: sa8295p-adp.dts and sa8540p-adp-ride.dts. > > Is there any benefit in this? USB0/2 and UFS (not UFS card) nodes are > identical > > in the 2 files. Similar boards might come in future, anticipated to be differing mainly with respect to usb/ufs. Hence thought it better to put ufs/usb nodes in board specific dts. Regards, Parikshit Pareek > > > Konrad > > > Took inputs from Shazad Hussain in this regard(John) > > - Added more description of the board differences(John) > > - Not including Reviewed-by for Krzysztof, because of the new changes to > > be reviewed. > > - Removed Reported-by tag(John). > > > > Changes in v4: > > - Removed the ufs_card_hc node, as it is not mounted on Qdrive-3 board. > > - Removed usb_1 relared nodes, as usb1 doesn't have any port connected on > > Qdrive3 board. > > - Added Reported-by tag for Shazad(for ufs and usb_1 node removals) > > > > Changes in v3: > > - Added Acked-by tag (Krzysztof) > > - Renamed dtsi to sa8540p-adp.dtsi (John) > > - Removed copyright from sa8295-adp.dts and sa8295-adp.dtsi(John) > > - Added cover letter > > > > change in v2: > > - Make dt-binding patch as the first one in the patch set > > - Add , after year 2022, in the license header > > > > Initial version: > > - Move the common nodes to sa8540p-adp.dtsi, and create qrive-3 board > > specific file sa8540p-adp-ride.dts. > > > > > > Parikshit Pareek (3): > > dt-bindings: arm: qcom: Document additional sa8540p device > > arm64: dts: qcom: sa8295p: move common nodes to dtsi > > arm64: dts: qcom: introduce sa8540p-ride dts > > > > .../devicetree/bindings/arm/qcom.yaml | 1 + > > arch/arm64/boot/dts/qcom/Makefile | 1 + > > arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 528 +++++------------- > > arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts | 71 +++ > > .../{sa8295p-adp.dts => sa8540p-adp.dtsi} | 133 ----- > > 5 files changed, 219 insertions(+), 515 deletions(-) > > rewrite arch/arm64/boot/dts/qcom/sa8295p-adp.dts (70%) > > create mode 100644 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts > > copy arch/arm64/boot/dts/qcom/{sa8295p-adp.dts => sa8540p-adp.dtsi} (72%) > >
On Tue, Oct 04, 2022 at 09:28:16AM -0400, Eric Chanudet wrote: > I followed the instructions above and linux-next-20220930 booted on the > QDrive3 to a prompt. It then hanged after a couple minutes and rebooted > in Sahara mode: > B - 1662280 - Sahara Init > B - 1665422 - Sahara Open > > There seems to be no trace from the kernel, this happened consistently > over 3 boots. > > I asked Brian, he mentioned he only booted to prompt so that may have > happened unbeknownst to him as well. Good catch, Eric! Parikshit: I found a way to reproduce the crash and isolated the issue to the qcom_q6v5_pas driver. Here's how you can reproduce the crash that we're seeing: 1) Use my instructions at [1] to build an upstream kernel with the arm64 defconfg. Today I used linux-next-20221017. 2) Copy the modules to the root filesystem. Before you reboot, mv /lib/modules/6.0.0-next-20221017-xxx to /lib/modules/6.0.0-next-20221017-xxx-old so that the modules are not automatically loaded on startup. 3) Reboot, and run lsmod and verify that no modules are loaded. 4) cd /lib/modules/6.0.0-next-20221017-xxx-old 5) Now load the modules that work as expected that are loaded with the upstream arm64 defconfig: insmod ./kernel/net/rfkill/rfkill.ko insmod ./kernel/arch/arm64/crypto/crct10dif-ce.ko insmod ./kernel/net/qrtr/qrtr.ko insmod ./kernel/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.ko insmod ./kernel/drivers/soc/qcom/llcc-qcom.ko insmod ./kernel/drivers/soc/qcom/qmi_helpers.ko insmod ./kernel/drivers/remoteproc/qcom_sysmon.ko insmod ./kernel/drivers/remoteproc/qcom_q6v5.ko insmod ./kernel/drivers/rpmsg/qcom_glink_smem.ko insmod ./kernel/drivers/soc/qcom/socinfo.ko insmod ./kernel/drivers/remoteproc/qcom_pil_info.ko insmod ./kernel/drivers/remoteproc/qcom_common.ko insmod ./kernel/drivers/watchdog/qcom-wdt.ko insmod ./kernel/fs/fuse/fuse.ko insmod ./kernel/drivers/soc/qcom/mdt_loader.ko 6) Wait a few minutes to be sure that everything is working as expected on the board. 7) Make the board go BOOM: insmod ./kernel/drivers/remoteproc/qcom_q6v5_pas.ko We don't know how or have the tools to analyze the ramdumps from the Qualcomm firmware at Red Hat, so we're flying blind right now. [1] https://lore.kernel.org/lkml/YzsciFeYpvv%2F92CG@x1/ Brian
On Mon, Oct 17, 2022 at 03:23:25PM -0400, Brian Masney wrote: > Parikshit: I found a way to reproduce the crash and isolated the issue > to the qcom_q6v5_pas driver. Here's how you can reproduce the crash > that we're seeing: > > 1) Use my instructions at [1] to build an upstream kernel with the arm64 > defconfg. Today I used linux-next-20221017. > > 2) Copy the modules to the root filesystem. Before you reboot, mv > /lib/modules/6.0.0-next-20221017-xxx to > /lib/modules/6.0.0-next-20221017-xxx-old so that the modules are not > automatically loaded on startup. > > 3) Reboot, and run lsmod and verify that no modules are loaded. > > 4) cd /lib/modules/6.0.0-next-20221017-xxx-old > > 5) Now load the modules that work as expected that are loaded with the > upstream arm64 defconfig: > > insmod ./kernel/net/rfkill/rfkill.ko > insmod ./kernel/arch/arm64/crypto/crct10dif-ce.ko > insmod ./kernel/net/qrtr/qrtr.ko > insmod ./kernel/drivers/phy/qualcomm/phy-qcom-snps-femto-v2.ko > insmod ./kernel/drivers/soc/qcom/llcc-qcom.ko > insmod ./kernel/drivers/soc/qcom/qmi_helpers.ko > insmod ./kernel/drivers/remoteproc/qcom_sysmon.ko > insmod ./kernel/drivers/remoteproc/qcom_q6v5.ko > insmod ./kernel/drivers/rpmsg/qcom_glink_smem.ko > insmod ./kernel/drivers/soc/qcom/socinfo.ko > insmod ./kernel/drivers/remoteproc/qcom_pil_info.ko > insmod ./kernel/drivers/remoteproc/qcom_common.ko > insmod ./kernel/drivers/watchdog/qcom-wdt.ko > insmod ./kernel/fs/fuse/fuse.ko > insmod ./kernel/drivers/soc/qcom/mdt_loader.ko > > 6) Wait a few minutes to be sure that everything is working as expected > on the board. > > 7) Make the board go BOOM: > > insmod ./kernel/drivers/remoteproc/qcom_q6v5_pas.ko > > We don't know how or have the tools to analyze the ramdumps from the > Qualcomm firmware at Red Hat, so we're flying blind right now. > > [1] https://lore.kernel.org/lkml/YzsciFeYpvv%2F92CG@x1/ I isolated the hang issue above to a single Kconfig symbol. First, a quick background. We're not seeing the hang issue using the upstream kernel with Red Hat's automotive kernel config. We see the hang though with the upstream arm64 defconfig. There's thousands of symbol differences between the two defconfigs and none of the changes stuck out to me. I wrote some code that slowly morphed the Red Hat defconfig into the upstream arm64 defconfig and committed the symbol changes in stages along the way. This allowed me to do an automated 'git bisect'. The symbol CONFIG_NO_HZ_IDLE=y is what triggers the hang. When I remove that line from arch/arm64/configs/defconfig, then the board continues to function normally after the qcom_q6v5_pas.ko module is loaded. Any ideas what could be causing this? Could it be the safety island is monitoring for a kernel tick and if it doesn't sense one then it kills the kernel and goes into ramdump mode? Brian
Change in v5: - Moved the usb and ufs nodes from sa8540p-adp.dtsi file to respective board specific dts files: sa8295p-adp.dts and sa8540p-adp-ride.dts. Took inputs from Shazad Hussain in this regard(John) - Added more description of the board differences(John) - Not including Reviewed-by for Krzysztof, because of the new changes to be reviewed. - Removed Reported-by tag(John). Changes in v4: - Removed the ufs_card_hc node, as it is not mounted on Qdrive-3 board. - Removed usb_1 relared nodes, as usb1 doesn't have any port connected on Qdrive3 board. - Added Reported-by tag for Shazad(for ufs and usb_1 node removals) Changes in v3: - Added Acked-by tag (Krzysztof) - Renamed dtsi to sa8540p-adp.dtsi (John) - Removed copyright from sa8295-adp.dts and sa8295-adp.dtsi(John) - Added cover letter change in v2: - Make dt-binding patch as the first one in the patch set - Add , after year 2022, in the license header Initial version: - Move the common nodes to sa8540p-adp.dtsi, and create qrive-3 board specific file sa8540p-adp-ride.dts. Parikshit Pareek (3): dt-bindings: arm: qcom: Document additional sa8540p device arm64: dts: qcom: sa8295p: move common nodes to dtsi arm64: dts: qcom: introduce sa8540p-ride dts .../devicetree/bindings/arm/qcom.yaml | 1 + arch/arm64/boot/dts/qcom/Makefile | 1 + arch/arm64/boot/dts/qcom/sa8295p-adp.dts | 528 +++++------------- arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts | 71 +++ .../{sa8295p-adp.dts => sa8540p-adp.dtsi} | 133 ----- 5 files changed, 219 insertions(+), 515 deletions(-) rewrite arch/arm64/boot/dts/qcom/sa8295p-adp.dts (70%) create mode 100644 arch/arm64/boot/dts/qcom/sa8540p-adp-ride.dts copy arch/arm64/boot/dts/qcom/{sa8295p-adp.dts => sa8540p-adp.dtsi} (72%)