Hi,
First of all, please ignore this email if you are NOT a Marvell's MACCHIATOBin user.
If you are, I hope you can help me :)
I'm trying to install a NIC card into a PCIe slot on MACCHIATOBin DoubleSlot, but the kernel hangs up during the boot. What I found out so far is scanning a PCIe bus and initializing the controller or the device may have caused this error. When I trace the kernel execution by inserting debug messages, access to a control register on PCIe controller has caused a CPU to stall forever: === details === armada8k_pcie_probe() armada8k_add_pcie_port() dw_pcie_host_init() dw_pcie_host_init() dw_pcie_setup_rc() dw_pcie_dbi_ro_wr_en() -- inline reg = PCIE_MISC_CONTROL_1_OFF; val = dw_pcie_readl_dbi(pci, reg) <= here === ===
The same code, the same kernel, does work without any errors if a given NIC card (Intel i225) is not inserted in a slot.
My current environment is: TF-A: mainline v2.7 SCP_BL2: HEAD of https://github.com/MarvellEmbeddedProcessors/binaries-marvell.git mv-ddr: HEAD of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git U-Boot: u-boot-2020.10-release of https://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git OS: Debian 11 with the kernel v5.17 (from unstable release) (but the problem exists even with v5.10 of bullseye.)
So I would like to ask you, 1) Have you ever seen this sort of error in your experience? 2) If possible, please try to use a PCIe card on your board. 3) Then, please let me know your result along with your environment (software that you are using)
Will be much appreciated. -Takahiro Akashi
W dniu 16.06.2022 o 05:25, AKASHI Takahiro pisze:
The same code, the same kernel, does work without any errors if a given NIC card (Intel i225) is not inserted in a slot.
My current environment is: TF-A: mainline v2.7 SCP_BL2: HEAD ofhttps://github.com/MarvellEmbeddedProcessors/binaries-marvell.git mv-ddr: HEAD ofhttps://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git U-Boot: u-boot-2020.10-release ofhttps://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git
I asked on #solidrun channel at discord:
jnettlet — well if it is hanging reading the dbi registers, then that means a clock isn't running. I thought I saw a patch posted to fix that recently. Or maybe that patch caused the issue.
mwojtas — I haven’t used u-boot on it for years… In EDK2 + DT I switched to pcie-host-generic. Clock is most likely root cause.
OS: Debian 11 with the kernel v5.17 (from unstable release) (but the problem exists even with v5.10 of bullseye.)
So I would like to ask you,
- Have you ever seen this sort of error in your experience?
- If possible, please try to use a PCIe card on your board.
- Then, please let me know your result along with your environment (software that you are using)
So I would consider switching to UEFI firmware and then check.
Hi Marcin,
On Fri, 17 Jun 2022 at 14:47, Marcin Juszkiewicz marcin.juszkiewicz@linaro.org wrote:
W dniu 16.06.2022 o 05:25, AKASHI Takahiro pisze:
The same code, the same kernel, does work without any errors if a given NIC card (Intel i225) is not inserted in a slot.
My current environment is: TF-A: mainline v2.7 SCP_BL2: HEAD ofhttps://github.com/MarvellEmbeddedProcessors/binaries-marvell.git mv-ddr: HEAD ofhttps://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git U-Boot: u-boot-2020.10-release ofhttps://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git
I asked on #solidrun channel at discord:
jnettlet — well if it is hanging reading the dbi registers, then that means a clock isn't running. I thought I saw a patch posted to fix that recently. Or maybe that patch caused the issue.
Good hint. I will look for the patch.
mwojtas — I haven’t used u-boot on it for years… In EDK2 + DT I switched to pcie-host-generic. Clock is most likely root cause.
OS: Debian 11 with the kernel v5.17 (from unstable release) (but the problem exists even with v5.10 of bullseye.)
So I would like to ask you,
- Have you ever seen this sort of error in your experience?
- If possible, please try to use a PCIe card on your board.
- Then, please let me know your result along with your environment (software that you are using)
So I would consider switching to UEFI firmware and then check.
Yeah, it is the last resort as I hesitate to do so because OS must be reinstalled from the scratch.
Anyhow, thank you for your help, -Takahiro Akashi
linaro-dev mailing list -- linaro-dev@lists.linaro.org To unsubscribe send an email to linaro-dev-leave@lists.linaro.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
On Fri, 17 Jun 2022 at 15:17, Takahiro Akashi takahiro.akashi@linaro.org wrote:
Hi Marcin,
On Fri, 17 Jun 2022 at 14:47, Marcin Juszkiewicz marcin.juszkiewicz@linaro.org wrote:
W dniu 16.06.2022 o 05:25, AKASHI Takahiro pisze:
The same code, the same kernel, does work without any errors if a given NIC card (Intel i225) is not inserted in a slot.
My current environment is: TF-A: mainline v2.7 SCP_BL2: HEAD ofhttps://github.com/MarvellEmbeddedProcessors/binaries-marvell.git mv-ddr: HEAD ofhttps://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git U-Boot: u-boot-2020.10-release ofhttps://github.com/MarvellEmbeddedProcessors/u-boot-marvell.git
I asked on #solidrun channel at discord:
jnettlet — well if it is hanging reading the dbi registers, then that means a clock isn't running. I thought I saw a patch posted to fix that recently. Or maybe that patch caused the issue.
Good hint. I will look for the patch.
mwojtas — I haven’t used u-boot on it for years… In EDK2 + DT I switched to pcie-host-generic. Clock is most likely root cause.
OS: Debian 11 with the kernel v5.17 (from unstable release) (but the problem exists even with v5.10 of bullseye.)
So I would like to ask you,
- Have you ever seen this sort of error in your experience?
- If possible, please try to use a PCIe card on your board.
- Then, please let me know your result along with your environment (software that you are using)
So I would consider switching to UEFI firmware and then check.
Yeah, it is the last resort as I hesitate to do so because OS must be reinstalled from the scratch.
Update: Since I found, in linux-pci ML, that some guy had argued that U-Boot initialized pci bus in inconsistent way as the linux kernel did. So I tried U-Boot with pci driver disabled to boot the system, then the kernel started up without any error and the network interface has got working as expected.
-Takahiro Akashi
Anyhow, thank you for your help, -Takahiro Akashi
linaro-dev mailing list -- linaro-dev@lists.linaro.org To unsubscribe send an email to linaro-dev-leave@lists.linaro.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
W dniu 17.06.2022 o 08:17, Takahiro Akashi pisze:
So I would consider switching to UEFI firmware and then check.
Yeah, it is the last resort as I hesitate to do so because OS must be reinstalled from the scratch.
It does not. You just need to have small vfat partition and GPT partition table.
Conversion from U-Boot (or BIOS on x86) to UEFI is quite easy.
-
AKASHI Takahiro -
Marcin Juszkiewicz -
Takahiro Akashi