[PATCH] mx6ul_14x14_evk: Fix SPL hang

Currently the following SPL hang is observed:
U-Boot SPL 2020.01-rc5-00079-g797eee36a1 (Jan 06 2020 - 11:24:09 -0300) Trying to boot from MMC1 Card did not respond to voltage select! spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Fix it by moving the eSDHC1 initialization to SPL.
While at it, since this board uses DM_MMC all the esdhc board code can be removed.
Signed-off-by: Fabio Estevam festevam@gmail.com --- Hi,
Still get the following "no card present" error in U-Boot proper:
MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... MMC: no card present *** Warning - No block device, using default environment
but this should be treated separately.
.../mx6ul_14x14_evk/mx6ul_14x14_evk.c | 175 ++---------------- 1 file changed, 20 insertions(+), 155 deletions(-)
diff --git a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c index 898da34729..086e0e6739 100644 --- a/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c +++ b/board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c @@ -36,14 +36,6 @@ DECLARE_GLOBAL_DATA_PTR; PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ PAD_CTL_DSE_40ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS)
-#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ - PAD_CTL_PUS_22K_UP | PAD_CTL_SPEED_LOW | \ - PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS) - -#define USDHC_DAT3_CD_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ - PAD_CTL_PUS_100K_DOWN | PAD_CTL_SPEED_LOW | \ - PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS) - #define I2C_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ PAD_CTL_PUS_100K_UP | PAD_CTL_SPEED_MED | \ PAD_CTL_DSE_40ohm | PAD_CTL_HYS | \ @@ -112,67 +104,6 @@ static iomux_v3_cfg_t const uart1_pads[] = { MX6_PAD_UART1_RX_DATA__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL), };
-static iomux_v3_cfg_t const usdhc1_pads[] = { - MX6_PAD_SD1_CLK__USDHC1_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_SD1_CMD__USDHC1_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_SD1_DATA0__USDHC1_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_SD1_DATA1__USDHC1_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_SD1_DATA2__USDHC1_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_SD1_DATA3__USDHC1_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - - /* VSELECT */ - MX6_PAD_GPIO1_IO05__USDHC1_VSELECT | MUX_PAD_CTRL(USDHC_PAD_CTRL), - /* CD */ - MX6_PAD_UART1_RTS_B__GPIO1_IO19 | MUX_PAD_CTRL(NO_PAD_CTRL), - /* RST_B */ - MX6_PAD_GPIO1_IO09__GPIO1_IO09 | MUX_PAD_CTRL(NO_PAD_CTRL), -}; - -/* - * mx6ul_14x14_evk board default supports sd card. If want to use - * EMMC, need to do board rework for sd2. - * Introduce CONFIG_MX6UL_14X14_EVK_EMMC_REWORK, if sd2 reworked to support - * emmc, need to define this macro. - */ -#if defined(CONFIG_MX6UL_14X14_EVK_EMMC_REWORK) -static iomux_v3_cfg_t const usdhc2_emmc_pads[] = { - MX6_PAD_NAND_RE_B__USDHC2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_WE_B__USDHC2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA00__USDHC2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA01__USDHC2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA02__USDHC2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA03__USDHC2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA04__USDHC2_DATA4 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA05__USDHC2_DATA5 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA06__USDHC2_DATA6 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA07__USDHC2_DATA7 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - - /* - * RST_B - */ - MX6_PAD_NAND_ALE__GPIO4_IO10 | MUX_PAD_CTRL(NO_PAD_CTRL), -}; -#else -static iomux_v3_cfg_t const usdhc2_pads[] = { - MX6_PAD_NAND_RE_B__USDHC2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_WE_B__USDHC2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA00__USDHC2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA01__USDHC2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA02__USDHC2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), - MX6_PAD_NAND_DATA03__USDHC2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), -}; - -/* - * The evk board uses DAT3 to detect CD card plugin, - * in u-boot we mux the pin to GPIO when doing board_mmc_getcd. - */ -static iomux_v3_cfg_t const usdhc2_cd_pad = - MX6_PAD_NAND_DATA03__GPIO4_IO05 | MUX_PAD_CTRL(USDHC_DAT3_CD_PAD_CTRL); - -static iomux_v3_cfg_t const usdhc2_dat3_pad = - MX6_PAD_NAND_DATA03__USDHC2_DATA3 | - MUX_PAD_CTRL(USDHC_DAT3_CD_PAD_CTRL); -#endif
static void setup_iomux_uart(void) { @@ -189,101 +120,35 @@ static int board_qspi_init(void) } #endif
-#ifdef CONFIG_FSL_ESDHC_IMX -static struct fsl_esdhc_cfg usdhc_cfg[2] = { - {USDHC1_BASE_ADDR, 0, 4}, -#if defined(CONFIG_MX6UL_14X14_EVK_EMMC_REWORK) - {USDHC2_BASE_ADDR, 0, 8}, -#else - {USDHC2_BASE_ADDR, 0, 4}, -#endif +#ifdef CONFIG_SPL_BUILD + +#define USDHC_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \ + PAD_CTL_PUS_22K_UP | PAD_CTL_SPEED_LOW | \ + PAD_CTL_DSE_80ohm | PAD_CTL_SRE_FAST | PAD_CTL_HYS) + +static iomux_v3_cfg_t const usdhc2_pads[] = { + MX6_PAD_NAND_RE_B__USDHC2_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_NAND_WE_B__USDHC2_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_NAND_DATA00__USDHC2_DATA0 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_NAND_DATA01__USDHC2_DATA1 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_NAND_DATA02__USDHC2_DATA2 | MUX_PAD_CTRL(USDHC_PAD_CTRL), + MX6_PAD_NAND_DATA03__USDHC2_DATA3 | MUX_PAD_CTRL(USDHC_PAD_CTRL), };
-#define USDHC1_CD_GPIO IMX_GPIO_NR(1, 19) -#define USDHC1_PWR_GPIO IMX_GPIO_NR(1, 9) -#define USDHC2_CD_GPIO IMX_GPIO_NR(4, 5) -#define USDHC2_PWR_GPIO IMX_GPIO_NR(4, 10) +static struct fsl_esdhc_cfg usdhc_cfg[1] = { + {USDHC2_BASE_ADDR, 0, 4}, +};
int board_mmc_getcd(struct mmc *mmc) { - struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv; - int ret = 0; - - switch (cfg->esdhc_base) { - case USDHC1_BASE_ADDR: - ret = !gpio_get_value(USDHC1_CD_GPIO); - break; - case USDHC2_BASE_ADDR: -#if defined(CONFIG_MX6UL_14X14_EVK_EMMC_REWORK) - ret = 1; -#else - imx_iomux_v3_setup_pad(usdhc2_cd_pad); - gpio_request(USDHC2_CD_GPIO, "usdhc2 cd"); - gpio_direction_input(USDHC2_CD_GPIO); - - /* - * Since it is the DAT3 pin, this pin is pulled to - * low voltage if no card - */ - ret = gpio_get_value(USDHC2_CD_GPIO); - - imx_iomux_v3_setup_pad(usdhc2_dat3_pad); -#endif - break; - } - - return ret; + return 1; }
int board_mmc_init(bd_t *bis) { - int i, ret; - - /* - * According to the board_mmc_init() the following map is done: - * (U-Boot device node) (Physical Port) - * mmc0 USDHC1 - * mmc1 USDHC2 - */ - for (i = 0; i < CONFIG_SYS_FSL_USDHC_NUM; i++) { - switch (i) { - case 0: - imx_iomux_v3_setup_multiple_pads( - usdhc1_pads, ARRAY_SIZE(usdhc1_pads)); - gpio_request(USDHC1_CD_GPIO, "usdhc1 cd"); - gpio_direction_input(USDHC1_CD_GPIO); - usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC_CLK); - - gpio_direction_output(USDHC1_PWR_GPIO, 0); - udelay(500); - gpio_direction_output(USDHC1_PWR_GPIO, 1); - break; - case 1: -#if defined(CONFIG_MX6UL_14X14_EVK_EMMC_REWORK) - imx_iomux_v3_setup_multiple_pads( - usdhc2_emmc_pads, ARRAY_SIZE(usdhc2_emmc_pads)); -#else - imx_iomux_v3_setup_multiple_pads( - usdhc2_pads, ARRAY_SIZE(usdhc2_pads)); -#endif - gpio_request(USDHC2_PWR_GPIO, "usdhc2 pwr"); - gpio_direction_output(USDHC2_PWR_GPIO, 0); - udelay(500); - gpio_direction_output(USDHC2_PWR_GPIO, 1); - usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK); - break; - default: - printf("Warning: you configured more USDHC controllers (%d) than supported by the board\n", i + 1); - return -EINVAL; - } - - ret = fsl_esdhc_initialize(bis, &usdhc_cfg[i]); - if (ret) { - printf("Warning: failed to initialize mmc dev %d\n", i); - return ret; - } - } - return 0; + imx_iomux_v3_setup_multiple_pads(usdhc2_pads, ARRAY_SIZE(usdhc2_pads)); + usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC2_CLK); + return fsl_esdhc_initialize(bis, &usdhc_cfg[0]); } #endif

On Mon, Jan 06, 2020 at 11:26:06AM -0300, Fabio Estevam wrote:
Currently the following SPL hang is observed:
U-Boot SPL 2020.01-rc5-00079-g797eee36a1 (Jan 06 2020 - 11:24:09 -0300) Trying to boot from MMC1 Card did not respond to voltage select! spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Fix it by moving the eSDHC1 initialization to SPL.
While at it, since this board uses DM_MMC all the esdhc board code can be removed.
Signed-off-by: Fabio Estevam festevam@gmail.com
Hi,
Still get the following "no card present" error in U-Boot proper:
MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... MMC: no card present *** Warning - No block device, using default environment
but this should be treated separately.
Should this come in for the 2020.01 release then? Thanks!

Hi Tom,
On Mon, Jan 6, 2020 at 12:06 PM Tom Rini trini@konsulko.com wrote:
Should this come in for the 2020.01 release then? Thanks!
I don't have the U-Boot proper fix yet, so I think this patch can wait and go into 2020.04.
Thanks

Hi Tom,
On Mon, Jan 6, 2020 at 12:20 PM Fabio Estevam festevam@gmail.com wrote:
I don't have the U-Boot proper fix yet, so I think this patch can wait and go into 2020.04.
I managed to fix the card detection problem in U-Boot proper and have just sent a patch series.
Thanks

Hi Fabio!
happy new year! Hope you are fine?
I just builded the newest mainline U-Boot code for the wandboard, and I get:
U-Boot SPL 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: pmic_get() ret -19 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... OK In: serial Out: serial Err: serial Model: Wandboard i.MX6 Dual Lite Board rev B1 Board: Wandboard rev B1 Net: Could not get PHY for FEC0: addr 1 Could not get PHY for FEC0: addr 1 No ethernet found.
Hit any key to stop autoboot: 0 =>
Ethernet does not work, also pmic setup seems buggy... Hmm pmic is not detected, and later board revision is B1 instead D1... I think thats the root cause of the problem...
Attached a bootlog from an older, working version [1].
Ok, I tried to bisect it, but bisecting does not work, as there are commits, which does not build for wandboard :-(
Looking into git history, there is a commit from you:
commit 5b858582512883b8a85d74e108873f9beed1e954 Author: Fabio Estevam festevam@gmail.com Date: Wed Jun 12 12:34:40 2019 -0300
wandboard: Add FIT image support
After the transition to DM, only the mx6dl/solo wandboard is supported.
Add FIT image support so that all the wandboard variants can be supported, like it was prior to the DM conversion.
Successfully booted Linux on mx6q/solo/qp wandboards.
So it worked for you? I flashed the u-boot-fit-dtb.bin instead of u-boot-dtb.bin, but this leads to:
resetting ...
U-Boot SPL 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:25:09 +0100) Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error spl: ext4fs_open failed spl_load_image_ext: error reading image u-boot-dtb.img, err - -1 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Same with u-boot-with-spl.imx flashed.
I am sure I make here something wrong... any ideas?
Attached also a working bootlog with an older version [1].
Thanks!
bye, Heiko
[1] working U-Boot bootlog: U-Boot SPL 2019.04-rc4-tbot-00111-gab8fc41 (Jan 08 2020 - 06:18:50 +0100) Trying to boot from MMC1
U-Boot 2019.04-rc4-tbot-00111-gab8fc41 (Jan 08 2020 - 06:18:50 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... OK No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Board: Wandboard rev D1 Net: FEC [PRIME] Hit any key to stop autoboot: 0 =>

Hi Heiko,
On Wed, Jan 8, 2020 at 2:41 AM Heiko Schocher hs@denx.de wrote:
Hi Fabio!
happy new year! Hope you are fine?
I just builded the newest mainline U-Boot code for the wandboard, and I get:
U-Boot SPL 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: pmic_get() ret -19
I have already fixed this PMIC issue. Please try this series: https://lists.denx.de/pipermail/u-boot/2019-December/393500.html
I thought it would reach 2020.01, but apparently it did not.
Regards,
Fabio Estevam

Hi Heiko,
On Wed, Jan 8, 2020 at 6:31 AM Fabio Estevam festevam@gmail.com wrote:
I have already fixed this PMIC issue. Please try this series: https://lists.denx.de/pipermail/u-boot/2019-December/393500.html
Actually the correct version is v3: https://lists.denx.de/pipermail/u-boot/2019-December/393517.html
Please test v3.
Thanks

Hi Fabio, Heiko,
On 08/01/20 10:31, Fabio Estevam wrote:
Hi Heiko,
On Wed, Jan 8, 2020 at 2:41 AM Heiko Schocher hs@denx.de wrote:
Hi Fabio!
happy new year! Hope you are fine?
I just builded the newest mainline U-Boot code for the wandboard, and I get:
U-Boot SPL 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: pmic_get() ret -19
I have already fixed this PMIC issue. Please try this series: https://lists.denx.de/pipermail/u-boot/2019-December/393500.html
I thought it would reach 2020.01, but apparently it did not.
Indeed, I am sure I have already worked and merged the series, but I cannot find them, no idea why. I can just apply them now and push on -master :-(
Regards, Stefano

Hello Stefano, Fabio,
Am 08.01.2020 um 10:54 schrieb Stefano Babic:
Hi Fabio, Heiko,
On 08/01/20 10:31, Fabio Estevam wrote:
Hi Heiko,
On Wed, Jan 8, 2020 at 2:41 AM Heiko Schocher hs@denx.de wrote:
Hi Fabio!
happy new year! Hope you are fine?
I just builded the newest mainline U-Boot code for the wandboard, and I get:
U-Boot SPL 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: pmic_get() ret -19
I have already fixed this PMIC issue. Please try this series: https://lists.denx.de/pipermail/u-boot/2019-December/393500.html
I thought it would reach 2020.01, but apparently it did not.
Indeed, I am sure I have already worked and merged the series, but I cannot find them, no idea why. I can just apply them now and push on -master :-(
With this patch I see the same issue:
U-Boot SPL 2020.01-tbot-00273-g877a689 (Jan 08 2020 - 11:05:27 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00273-g877a689 (Jan 08 2020 - 11:05:27 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: pmic_get() ret -19 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Model: Wandboard i.MX6 Dual Lite Board rev B1 Board: Wandboard rev B1 Net: Could not get PHY for FEC0: addr 1 No ethernet found.
Hit any key to stop autoboot: 0 =>
I try to dig into it ...
bye, Heiko

Hello Fabio,
Am 08.01.2020 um 11:11 schrieb Heiko Schocher:
Hello Stefano, Fabio,
Am 08.01.2020 um 10:54 schrieb Stefano Babic:
Hi Fabio, Heiko,
On 08/01/20 10:31, Fabio Estevam wrote:
Hi Heiko,
On Wed, Jan 8, 2020 at 2:41 AM Heiko Schocher hs@denx.de wrote:
Hi Fabio!
happy new year! Hope you are fine?
I just builded the newest mainline U-Boot code for the wandboard, and I get:
U-Boot SPL 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:33:42 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: pmic_get() ret -19
I have already fixed this PMIC issue. Please try this series: https://lists.denx.de/pipermail/u-boot/2019-December/393500.html
I thought it would reach 2020.01, but apparently it did not.
Indeed, I am sure I have already worked and merged the series, but I cannot find them, no idea why. I can just apply them now and push on -master :-(
With this patch I see the same issue:
U-Boot SPL 2020.01-tbot-00273-g877a689 (Jan 08 2020 - 11:05:27 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00273-g877a689 (Jan 08 2020 - 11:05:27 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: pmic_get() ret -19 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Model: Wandboard i.MX6 Dual Lite Board rev B1 Board: Wandboard rev B1 Net: Could not get PHY for FEC0: addr 1 No ethernet found.
Hit any key to stop autoboot: 0 =>
I try to dig into it ...
Hmm... current try (remove all other dts from image):
diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig index ca564c5..62b013c 100644 --- a/configs/wandboard_defconfig +++ b/configs/wandboard_defconfig @@ -42,8 +42,8 @@ CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_OF_CONTROL=y -CONFIG_DEFAULT_DEVICE_TREE="imx6dl-wandboard-revb1" -CONFIG_OF_LIST="imx6q-wandboard-revb1 imx6qp-wandboard-revd1 imx6dl-wandboard-revb1" +CONFIG_DEFAULT_DEVICE_TREE="imx6qp-wandboard-revd1" +CONFIG_OF_LIST="imx6qp-wandboard-revd1" CONFIG_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_MMC=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y
and with your patch applied, I see on the console:
resetting ...
U-Boot SPL 2020.01-tbot-00275-gae9089a (Jan 08 2020 - 11:53:10 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00275-gae9089a (Jan 08 2020 - 11:53:10 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: PMIC: PFUZE100 ID=0x10 MMC: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.20.3-jumpnow (oe-user@oe-host) (gcc version 8.2.0 (GCC)) #1 SMP Fri Jan 18 17:29:07 UTC 2019 [ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
So, PMIC gets now detected, but after "MMC" no output from console ... but it seems, U-Boot boots into linux!
Hmm... looking into board/wandboard/wandboard.c
#ifdef CONFIG_SPL_LOAD_FIT int board_fit_config_name_match(const char *name) { if (is_mx6dq()) { if (!strcmp(name, "imx6q-wandboard-revb1")) return 0; } else if (is_mx6dqp()) { if (!strcmp(name, "imx6qp-wandboard-revd1")) return 0; } else if (is_mx6dl() || is_mx6solo()) { if (!strcmp(name, "imx6dl-wandboard-revb1")) return 0; }
return -EINVAL; } #endif
On my board is_mx6dl() is true! but it is a revision D1 ... ? It has definitely a pmic@0x08
May I make something obvious wrong?
Is the content of board/wandboard/README correct?
Thanks in advance!
bye, Heiko

Hi Heiko,
On Wed, Jan 8, 2020 at 8:45 AM Heiko Schocher hs@denx.de wrote:
On my board is_mx6dl() is true! but it is a revision D1 ... ? It has definitely a pmic@0x08
I think we need to import the imx6dl-wandboard-d1.dts from kernel to U-Boot and fix the board_fit_config_name_match() logic to take the imx6dl-wandboard-d1 into account.
We will need to use is_revd1() inside board_fit_config_name_match() to fix the detection logic.
Could you try that?
Thanks

Hi Heiko,
On Wed, Jan 8, 2020 at 8:45 AM Heiko Schocher hs@denx.de wrote:
diff --git a/configs/wandboard_defconfig b/configs/wandboard_defconfig index ca564c5..62b013c 100644 --- a/configs/wandboard_defconfig +++ b/configs/wandboard_defconfig @@ -42,8 +42,8 @@ CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4_WRITE=y CONFIG_OF_CONTROL=y -CONFIG_DEFAULT_DEVICE_TREE="imx6dl-wandboard-revb1" -CONFIG_OF_LIST="imx6q-wandboard-revb1 imx6qp-wandboard-revd1 imx6dl-wandboard-revb1" +CONFIG_DEFAULT_DEVICE_TREE="imx6qp-wandboard-revd1" +CONFIG_OF_LIST="imx6qp-wandboard-revd1"
Here you mark only the imx6qp board, but yours is a imx6dl, so that's why the U-Boot console did not show up :-)

Hi Heiko,
On Wed, Jan 8, 2020 at 2:41 AM Heiko Schocher hs@denx.de wrote:
Looking into git history, there is a commit from you:
commit 5b858582512883b8a85d74e108873f9beed1e954 Author: Fabio Estevam festevam@gmail.com Date: Wed Jun 12 12:34:40 2019 -0300
wandboard: Add FIT image support After the transition to DM, only the mx6dl/solo wandboard is supported. Add FIT image support so that all the wandboard variants can be supported, like it was prior to the DM conversion. Successfully booted Linux on mx6q/solo/qp wandboards.
So it worked for you? I flashed the u-boot-fit-dtb.bin instead of u-boot-dtb.bin, but this leads to:
Just tested the latest u-boot-imx, which contains the PMIC fix and booting a imx6qp-wandboard-revd1 works fine: http://code.bulix.org/pncucj-1073321
This is the only revd1 wandboard I have access to.
I flashed the SD card as per the board/wandboard/README instructions.
Ethernet is also functional in U-Boot.
The support for imx6q-wandboard-revd1 and imx6dl-wandboard-revd1 still needs to be added (it used to work prior to the DM conversion as you noticed), but unfortunately I don't have access to these variants.
Regards,
Fabio Estevam
resetting ...
U-Boot SPL 2020.01-tbot-00271-gd8a3f52 (Jan 08 2020 - 06:25:09 +0100) Trying to boot from MMC1 mmc_load_image_raw_sector: mmc block read error spl: ext4fs_open failed spl_load_image_ext: error reading image u-boot-dtb.img, err - -1 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###
Same with u-boot-with-spl.imx flashed.
I am sure I make here something wrong... any ideas?
Attached also a working bootlog with an older version [1].
Thanks!
bye, Heiko
[1] working U-Boot bootlog: U-Boot SPL 2019.04-rc4-tbot-00111-gab8fc41 (Jan 08 2020 - 06:18:50 +0100) Trying to boot from MMC1
U-Boot 2019.04-rc4-tbot-00111-gab8fc41 (Jan 08 2020 - 06:18:50 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG I2C: ready DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... OK No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Board: Wandboard rev D1 Net: FEC [PRIME] Hit any key to stop autoboot: 0 =>
-- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs@denx.de

Hi Heiko,
On Wed, Jan 8, 2020 at 4:52 PM Fabio Estevam festevam@gmail.com wrote:
The support for imx6q-wandboard-revd1 and imx6dl-wandboard-revd1 still needs to be added (it used to work prior to the DM conversion as you noticed), but unfortunately I don't have access to these variants.
Could you please try the attached two patches?
I don't have access to a imx6dl-wandboard-revd1 board, but hopefully these two patches would make it to work.
It applies against the latest u-boot-imx tree.
Thanks

Hello Fabio,
Am 08.01.2020 um 21:26 schrieb Fabio Estevam:
Hi Heiko,
On Wed, Jan 8, 2020 at 4:52 PM Fabio Estevam festevam@gmail.com wrote:
The support for imx6q-wandboard-revd1 and imx6dl-wandboard-revd1 still needs to be added (it used to work prior to the DM conversion as you noticed), but unfortunately I don't have access to these variants.
Could you please try the attached two patches?
You were faster than I, thanks!
I don't have access to a imx6dl-wandboard-revd1 board, but hopefully these two patches would make it to work.
Unfortunately they don;t work.
It applies against the latest u-boot-imx tree.
Tried mainline also as u-boot-imx.
But! Additionally setting:
CONFIG_DEFAULT_DEVICE_TREE="imx6dl-wandboard-revd1" CONFIG_OF_LIST="imx6dl-wandboard-revd1"
and U-Boot works again, see [1]!
So we are on the correct direction...
Hmm.. I wonder ... if you want to detect the revd1, you must access the pmic in SPL, so you need a DTS in which it is configured, also DM PMIC support in SPL ... which introduces a lot of dependencies starting with enabling CONFIG_SPL_DM and blows up SPL ... :-(
2 problems I see:
- reorder board_fit_config_name_match
see attached patch: 0001-wandboard-reorder-board_fit_config_name_match.patch
With this patch (based on your patches) and hack [2] U-Boot works also again.
- detect rev D1 board (remaining problem)
board_fit_config_name_match() is called from board_fit_config_name_match, so from SPL where you have no access (yet?) to pmic_get(), and so is_revd1() is always 0 -> which leads to wrong DTB selection.
First question: other possibility to detect revision D1 ?
may only probing the chip is enough ?
Should we use instead CONFIG_DTB_RESELECT ?
This is the way to go I think, added patches: 0002-wandboard-enable-CONFIG_DTB_RESELECT.patch 0003-wandboard-use-imx6dl-wandboard-revd1-as-default-DTB.patch 0004-wandboard-add-u-boot-specific-wandboard-revd1-u-boot.patch 0005-wandboard-in-SPL-use-only-D1-DTB.patch
with them, after a soft reset all works fine, see [3] but on power on I see [4] :-(
Any idea, why after a power on, pmic does not work?
Uff... sorry for the long email ... and may dummy questions.
bye, Heiko [1] U-Boot SPL 2020.01-tbot-00002-g6cd56d3 (Jan 09 2020 - 06:21:00 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00002-g6cd56d3 (Jan 09 2020 - 06:21:00 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Model: Wandboard i.MX6 Dual Lite Board revD1 Board: Wandboard rev D1 Net: Warning: ethernet@2188000 using MAC address from ROM eth0: ethernet@2188000 Hit any key to stop autoboot: 0 =>
[2] hack for is_revd1()
diff --git a/board/wandboard/wandboard.c b/board/wandboard/wandboard.c index 4cb9bf6..5c64ab5 100644 --- a/board/wandboard/wandboard.c +++ b/board/wandboard/wandboard.c @@ -414,6 +414,7 @@ static bool is_revc1(void)
static bool is_revd1(void) { + with_pmic = 1; if (with_pmic) return true; else
[3] softreset with patches 1-5 U-Boot SPL 2020.01-tbot-00007-g44f7a02 (Jan 09 2020 - 09:00:27 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00007-g44f7a02 (Jan 09 2020 - 09:00:27 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: WDOG PMIC: PFUZE100 ID=0x10 DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 MMC: FSL_SDHC: 2, FSL_SDHC: 1, FSL_SDHC: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial Model: Wandboard i.MX6 Dual Lite Board revD1 Board: Wandboard rev D1 Net: Warning: ethernet@2188000 using MAC address from ROM eth0: ethernet@2188000 Hit any key to stop autoboot: 0 =>
[4] hard power on U-Boot SPL 2020.01-tbot-00007-g44f7a02 (Jan 09 2020 - 09:00:27 +0100) Trying to boot from MMC1
U-Boot 2020.01-tbot-00007-g44f7a02 (Jan 09 2020 - 09:00:27 +0100)
CPU: Freescale i.MX6DL rev1.3 at 792 MHz Reset cause: POR wait_for_sr_state: failed sr=81 cr=a0 state=2020 i2c_init_transfer: failed for chip 0x8 retry=0 wait_for_sr_state: failed sr=81 cr=a0 state=2020 i2c_init_transfer: failed for chip 0x8 retry=1 wait_for_sr_state: failed sr=81 cr=a0 state=2020 i2c_init_transfer: failed for chip 0x8 retry=2 i2c_init_transfer: give up i2c_regs=0x21a8000 read error from device: 0093e358 register: 0x0! pmic_reg_read() ret -5 DRAM: 1 GiB PMIC: PFUZE100 ID=0x10 [...]

Hi Heiko,
On Thu, Jan 9, 2020 at 5:26 AM Heiko Schocher hs@denx.de wrote:
Hmm.. I wonder ... if you want to detect the revd1, you must access the pmic in SPL, so you need a DTS in which it is configured, also DM PMIC support in SPL ... which introduces a lot of dependencies starting with enabling CONFIG_SPL_DM and blows up SPL ... :-(
Yes, as we are very memory limited in SPL, so what about just probing the I2C bus directly at 0x8 via I2C API to detect the presence of the PMIC?
This way we do not need DM PMIC support in SPL.
Do we need to mark I2C with 'u-boot,dm-pre-reloc;' too and create a arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi ?
2 problems I see:
reorder board_fit_config_name_match
see attached patch: 0001-wandboard-reorder-board_fit_config_name_match.patch
With this patch (based on your patches) and hack [2] U-Boot works also again.
detect rev D1 board (remaining problem)
board_fit_config_name_match() is called from board_fit_config_name_match, so from SPL where you have no access (yet?) to pmic_get(), and so is_revd1() is always 0 -> which leads to wrong DTB selection.
First question: other possibility to detect revision D1 ?
may only probing the chip is enough ?
As far as I know probing the PMIC chip is the only way to detect D1.
Should we use instead CONFIG_DTB_RESELECT ?
Not familiar with CONFIG_DTB_RESELECT, sorry.
This is the way to go I think, added patches: 0002-wandboard-enable-CONFIG_DTB_RESELECT.patch 0003-wandboard-use-imx6dl-wandboard-revd1-as-default-DTB.patch 0004-wandboard-add-u-boot-specific-wandboard-revd1-u-boot.patch 0005-wandboard-in-SPL-use-only-D1-DTB.patch
with them, after a soft reset all works fine, see [3] but on power on I see [4] :-(
Any idea, why after a power on, pmic does not work?
Interesting, I do not see this behavior with a imx6qp wandboard revd1.
I have seen I2C errors when booting with an HDMI cable connected: https://lists.denx.de/pipermail/u-boot/2019-December/393503.html
,but haven't had a chance to debug this yet.
Regards,
Fabio Estevam

Hello Fabio,
Am 09.01.2020 um 12:14 schrieb Fabio Estevam:
Hi Heiko,
On Thu, Jan 9, 2020 at 5:26 AM Heiko Schocher hs@denx.de wrote:
Hmm.. I wonder ... if you want to detect the revd1, you must access the pmic in SPL, so you need a DTS in which it is configured, also DM PMIC support in SPL ... which introduces a lot of dependencies starting with enabling CONFIG_SPL_DM and blows up SPL ... :-(
Yes, as we are very memory limited in SPL, so what about just probing the I2C bus directly at 0x8 via I2C API to detect the presence of the PMIC?
This way we do not need DM PMIC support in SPL.
Yes, i had such a hack also ...
Do we need to mark I2C with 'u-boot,dm-pre-reloc;' too and create a arch/arm/dts/imx6qdl-wandboard-u-boot.dtsi ?
see my patches, I added there such u-boot files. Unfortunately a imx6qdl-wandboard-u-boot.dtsi did not worked, I needed 2 files.
2 problems I see:
reorder board_fit_config_name_match
see attached patch: 0001-wandboard-reorder-board_fit_config_name_match.patch
With this patch (based on your patches) and hack [2] U-Boot works also again.
detect rev D1 board (remaining problem)
board_fit_config_name_match() is called from board_fit_config_name_match, so from SPL where you have no access (yet?) to pmic_get(), and so is_revd1() is always 0 -> which leads to wrong DTB selection.
First question: other possibility to detect revision D1 ?
may only probing the chip is enough ?
As far as I know probing the PMIC chip is the only way to detect D1.
Ok, so we must find a way for it ...
Should we use instead CONFIG_DTB_RESELECT ?
Not familiar with CONFIG_DTB_RESELECT, sorry.
This is the way to go I think, added patches: 0002-wandboard-enable-CONFIG_DTB_RESELECT.patch 0003-wandboard-use-imx6dl-wandboard-revd1-as-default-DTB.patch 0004-wandboard-add-u-boot-specific-wandboard-revd1-u-boot.patch 0005-wandboard-in-SPL-use-only-D1-DTB.patch with them, after a soft reset all works fine, see [3] but on power on I see [4] :-( Any idea, why after a power on, pmic does not work?
Interesting, I do not see this behavior with a imx6qp wandboard revd1.
I have seen I2C errors when booting with an HDMI cable connected: https://lists.denx.de/pipermail/u-boot/2019-December/393503.html
,but haven't had a chance to debug this yet.
Ok, may I find more time for it...
If you have time, may I can ask, if you can test my patches, if they do not break other board revisions?
Many thanks!
bye, Heiko

Hi Heiko,
On Thu, Jan 9, 2020 at 8:33 AM Heiko Schocher hs@denx.de wrote:
If you have time, may I can ask, if you can test my patches, if they do not break other board revisions?
I haven't had a chance to look at your patches yet, but could you please submit the whole series to the list?
I will try to review and test them next week.
Thanks
participants (4)
-
Fabio Estevam
-
Heiko Schocher
-
Stefano Babic
-
Tom Rini