It turned out that after a reset the boot process from the spi bootflash is
disturbed by other spi slave devices connected to DHCOM SPI1, which uses the
same spi interface with a different SS line.
Therefore the pad pull ups are enabled.
Signed-off-by: Ludwig Zenz <lz...@dh-electronics.com>
---
board/dhelectronics/dh_imx6/dh_imx6_spl.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
index 2939389de3..9494d2d6a3 100644
--- a/board/dhelectronics/dh_imx6/dh_imx6_spl.c
+++ b/board/dhelectronics/dh_imx6/dh_imx6_spl.c
@@ -440,8 +440,13 @@ static void setup_iomux_sd(void)
/* SPI */
static iomux_v3_cfg_t const ecspi1_pads[] = {
- /* SS0 */
- IOMUX_PADS(PAD_EIM_EB2__GPIO2_IO30 | MUX_PAD_CTRL(SPI_PAD_CTRL)),
+ /* SS0 - SS of boot flash */
+ IOMUX_PADS(PAD_EIM_EB2__GPIO2_IO30 |
+ MUX_PAD_CTRL(SPI_PAD_CTRL | PAD_CTL_PUS_100K_UP)),
+ /* SS2 - SS of DHCOM SPI1 */
+ IOMUX_PADS(PAD_KEY_ROW2__GPIO4_IO11 |
+ MUX_PAD_CTRL(SPI_PAD_CTRL | PAD_CTL_PUS_100K_UP)),
+
IOMUX_PADS(PAD_EIM_D17__ECSPI1_MISO | MUX_PAD_CTRL(SPI_PAD_CTRL)),
IOMUX_PADS(PAD_EIM_D18__ECSPI1_MOSI | MUX_PAD_CTRL(SPI_PAD_CTRL)),
IOMUX_PADS(PAD_EIM_D16__ECSPI1_SCLK | MUX_PAD_CTRL(SPI_PAD_CTRL)),
--
2.11.0
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
