On Fri, Sep 22, 2017 at 7:00 AM, David Müller (ELSOFT AG) <d.muel...@elsoft.ch> wrote: > Hello > > Does the code below really work?
Hi Dave, This patch does work to resolve the issue stated in the commit log which was to fix failing to boot on a 4.11+ kernel which stems from the fact that we have no reliable way to reset the PCIe host controller for IMX6SDL/DQ. This code used to be in the kernel [1] but was removed in 4.11 because it was seen as a workaround for the bootloader failing to put the PCIe host controller back in a sane state (something normally not needed to be done if these hardware blocks have a reset available). However, your right you do end up hanging on a 'soft reset' likely for the same reason the kernel used to - the PCIe host controller is not left in a sane state because this code isn't run in that case. > > On my custom MX6Q board, the code hangs on the read of the > "PCIE_PL_PFLR". Please note that this code sequence is not entered the > first time after a power up; I have to execute a U-Boot reset to > actually trigger the hang. Any ideas what is going wrong? > > > While debugging it, I also noticed the two problems below. > > Tim Harvey wrote: > >> + if (is_mx6dq()) { >> + u32 val, gpr1, gpr12; >> + >> + gpr1 = readl(&iomuxc_regs->gpr[1]); >> + gpr12 = readl(&iomuxc_regs->gpr[12]); >> + if ((gpr1 & IOMUXC_GPR1_PCIE_REF_CLK_EN) && >> + (gpr12 & IOMUXC_GPR12_PCIE_CTL_2)) { > > This could be (gpr12 & IOMUXC_GPR12_APPS_LTSSM_ENABLE)) { Currently IOMUXC_GPR12_PCIE_CTL_2 is defined as GPR12[10] likely because that's how it was defined in an early reference manual but I would agree it should be changed for readability - its not a bug. > >> + val = readl(MX6_DBI_ADDR + PCIE_PL_PFLR); >> + val &= ~PCIE_PL_PFLR_LINK_STATE_MASK; >> + val |= PCIE_PL_PFLR_FORCE_LINK; >> + >> + imx_pcie_fix_dabt_handler(true); >> + writel(val, MX6_DBI_ADDR + PCIE_PL_PFLR); >> + imx_pcie_fix_dabt_handler(false); >> + >> + gpr12 &= ~IOMUXC_GPR12_PCIE_CTL_2; >> + writel(val, &iomuxc_regs->gpr[12]); > > I think this should be > writel(gpr12, &iomuxc_regs->gpr[12]); > > or even better > clrbits_le32(&iomuxc_regs->gpr[12], > IOMUXC_GPR12_APPS_LTSSM_ENABLE); Yes this is a bug for sure, however it doesn't appear to resolve your issue. Lucas, does barebox suffer from a hang on PCI init on chip-level reset and if not do you know what could be causing the read of PCIE_PL_PFLR to hang here? Regards, Tim [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/host/pci-imx6.c?h=v4.10#n270 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot