| Message ID | 1424753005-16490-8-git-send-email-yamada.m@jp.panasonic.com |
|---|---|
| State | Superseded |
| Delegated to: | Masahiro Yamada |
| Headers | show |
diff --git a/arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c b/arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c index 6c006f3..e18bf9c 100644 --- a/arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c +++ b/arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c @@ -5,6 +5,8 @@ * SPDX-License-Identifier: GPL-2.0+ */ +#include <common.h> +#include <spl.h> #include <asm/io.h> #include <mach/sc-regs.h> @@ -14,7 +16,10 @@ void early_clkrst_init(void) /* deassert reset */ tmp = readl(SC_RSTCTRL); + tmp |= SC_RSTCTRL_NRST_UMC1 | SC_RSTCTRL_NRST_UMC0; + if (spl_boot_device() != BOOT_DEVICE_NAND) + tmp &= ~SC_RSTCTRL_NRST_NAND; writel(tmp, SC_RSTCTRL); readl(SC_RSTCTRL); /* dummy read */
For all the UniPhier SoCs so far, the reset signal of the NAND core is automatically deasserted after the PLL gets stabled. (The bit 2 of SC_RSTCTRL is default to one.) This causes a fatal problem on the NAND controller of PH1-LD4. For that SoC, the NAND I/O pins are not set up yet at the power-on reset except the NAND boot mode. As a result, the NAND controller begins automatic device scanning with wrong I/O pins and finally hangs up. Actually, U-Boot dies after printing "NAND:" on the console unless the boot mode latch detected the NAND boot mode. To work around this problem, reset the NAND core in SPL for non-NAND boot modes. If CONFIG_NAND_DENALI is enabled, the reset signal is deasserted again in U-Boot proper. At this time, I/O pins have been correctly set up, the device scanning should succeed. Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com> --- Changes in v4: None Changes in v3: None Changes in v2: - Added arch/arm/mach-uniphier/ph1-pro4/early_clkrst_init.c | 5 +++++ 1 file changed, 5 insertions(+)