[U-Boot] fsl_esdhc driver is broken with DM
Hi,
I noticed that fsl_esdhc is broken on 2017.09 for mx6slevk, when CONFIG_DM_MMC is selected:
U-Boot 2017.09 (Sep 30 2017 - 12:31:17 -0300)
CPU: Freescale i.MX6SL rev1.0 792 MHz (running at 396 MHz) CPU: Commercial temperature grade (0C to 95C) at 35C Reset cause: WDOG Model: Freescale i.MX6 SoloLite EVK Board Board: MX6SLEVK DRAM: 1 GiB PMIC: PFUZE100! DEV_ID=0x10 REV_ID=0x11 MMC: MMC Device 1 not found *** Warning - No MMC card found, using default environment
In: serial Out: serial Err: serial Net: FEC Hit any key to stop autoboot: 0 => mmc info No MMC device available =>
2017.07 works fine.
I ran a bisect which pointed to:
commit d6eb25e9878617f9a1d7f06ec21c9b981bb0a4e5 Author: Simon Glass sjg@chromium.org Date: Sat Jul 29 11:35:22 2017 -0600
dm: mmc: fsl_esdhc: Drop mmc_init() call from fsl_esdhc_init()
We want to use fsl_esdhc_init() with driver model. Move the mmc_init() out of this function so that we can use it for our common init.
Signed-off-by: Simon Glass sjg@chromium.org
If I remove CONFIG_DM_MMC:
--- a/configs/mx6slevk_defconfig +++ b/configs/mx6slevk_defconfig @@ -31,7 +31,6 @@ CONFIG_DM=y # CONFIG_BLK is not set CONFIG_DM_GPIO=y CONFIG_DM_I2C=y -CONFIG_DM_MMC=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y
Then the mmc can be used normally.
Any ideas on how to fix this properly so that fsl_esdhc can work with DM?
Thanks
On Sat, Sep 30, 2017 at 12:35 PM, Fabio Estevam festevam@gmail.com wrote:
Hi,
I noticed that fsl_esdhc is broken on 2017.09 for mx6slevk, when CONFIG_DM_MMC is selected:
U-Boot 2017.09 (Sep 30 2017 - 12:31:17 -0300)
CPU: Freescale i.MX6SL rev1.0 792 MHz (running at 396 MHz) CPU: Commercial temperature grade (0C to 95C) at 35C Reset cause: WDOG Model: Freescale i.MX6 SoloLite EVK Board Board: MX6SLEVK DRAM: 1 GiB PMIC: PFUZE100! DEV_ID=0x10 REV_ID=0x11 MMC: MMC Device 1 not found *** Warning - No MMC card found, using default environment
Same regression is observed with mx7dsabresd board as well.
On Sun, Oct 01, 2017 at 11:29:58AM -0300, Fabio Estevam wrote:
On Sat, Sep 30, 2017 at 12:35 PM, Fabio Estevam festevam@gmail.com wrote:
Hi,
I noticed that fsl_esdhc is broken on 2017.09 for mx6slevk, when CONFIG_DM_MMC is selected:
U-Boot 2017.09 (Sep 30 2017 - 12:31:17 -0300)
CPU: Freescale i.MX6SL rev1.0 792 MHz (running at 396 MHz) CPU: Commercial temperature grade (0C to 95C) at 35C Reset cause: WDOG Model: Freescale i.MX6 SoloLite EVK Board Board: MX6SLEVK DRAM: 1 GiB PMIC: PFUZE100! DEV_ID=0x10 REV_ID=0x11 MMC: MMC Device 1 not found *** Warning - No MMC card found, using default environment
Same regression is observed with mx7dsabresd board as well.
It's likely to be all i.MX :(
Have all of the changes gone in such that an i.MX platform with SPL can be non-interactively booted via imx_usb? Not having my iMX platforms in automated testing means that I always end up not testing them nearly often enough.
Hi Tom,
On Sun, Oct 1, 2017 at 11:49 AM, Tom Rini trini@konsulko.com wrote:
Same regression is observed with mx7dsabresd board as well.
It's likely to be all i.MX :(
Only the i.MX configs with CONFIG_DM_MMC=y.
Have all of the changes gone in such that an i.MX platform with SPL can be non-interactively booted via imx_usb? Not having my iMX platforms in automated testing means that I always end up not testing them nearly often enough.
Yes, Stefan's patches have been been applied and are in mainline now.
doc/README.sdp contains all the details to get imx_usb to load SPL + u-boot.img.
However, the two platforms I saw the issue does not use SPL.
Jagan,
I noticed that some of your i.MX boards do select CONFIG_DM_MMC=y.
Is MMC functional in U-Boot mainline on these targets?
Thanks
Hi Fabio,
Hi Tom,
On Sun, Oct 1, 2017 at 11:49 AM, Tom Rini trini@konsulko.com wrote:
Same regression is observed with mx7dsabresd board as well.
It's likely to be all i.MX :(
Only the i.MX configs with CONFIG_DM_MMC=y.
Yes, I can confirm this.
I'm using SPL + imx_usb (and boot to eMMC) on my imx6q boards and both work.
However, I'm not using the DM for eMMC (# CONFIG_DM_MMC is not set).
Have all of the changes gone in such that an i.MX platform with SPL can be non-interactively booted via imx_usb? Not having my iMX platforms in automated testing means that I always end up not testing them nearly often enough.
Yes, Stefan's patches have been been applied and are in mainline now.
doc/README.sdp contains all the details to get imx_usb to load SPL + u-boot.img.
However, the two platforms I saw the issue does not use SPL.
Jagan,
I noticed that some of your i.MX boards do select CONFIG_DM_MMC=y.
Is MMC functional in U-Boot mainline on these targets?
Thanks _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Sun, Oct 1, 2017 at 12:50 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Tom,
On Sun, Oct 1, 2017 at 11:49 AM, Tom Rini trini@konsulko.com wrote:
Same regression is observed with mx7dsabresd board as well.
It's likely to be all i.MX :(
Only the i.MX configs with CONFIG_DM_MMC=y.
mx6slevk_spl_defconfig does not have CONFIG_DM_MMC selected and it is also broken since 2017.05 due to this commit:
commit 001cdbbb32ef1f62f5913f2913eab49e3270ee7b Author: Peng Fan peng.fan@nxp.com Date: Sat Mar 4 10:45:44 2017 +0800
imx: mx6slevk: enable more DM drivers
Enable more DM drivers. The imx I2C/MMC DM drivers needs DM_GPIO enabled. So needs to enable them together.
DM FEC and SPI are not enabled, but they use gpio in board code. So use gpio_request first to request the gpio, because DM_GPIO is enabled.
Signed-off-by: Peng Fan peng.fan@nxp.com Cc: Stefano Babic sbabic@denx.de
I managed to fix it and will submit a fix for it.
mx6slevk_defconfig which has CONFIG_DM_MMC=y is still broken though and not sure how to fix it.
On Sun, Oct 1, 2017 at 9:20 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Tom,
On Sun, Oct 1, 2017 at 11:49 AM, Tom Rini trini@konsulko.com wrote:
Same regression is observed with mx7dsabresd board as well.
It's likely to be all i.MX :(
Only the i.MX configs with CONFIG_DM_MMC=y.
Have all of the changes gone in such that an i.MX platform with SPL can be non-interactively booted via imx_usb? Not having my iMX platforms in automated testing means that I always end up not testing them nearly often enough.
Yes, Stefan's patches have been been applied and are in mainline now.
doc/README.sdp contains all the details to get imx_usb to load SPL + u-boot.img.
However, the two platforms I saw the issue does not use SPL.
Jagan,
I noticed that some of your i.MX boards do select CONFIG_DM_MMC=y.
Is MMC functional in U-Boot mainline on these targets?
Yes, currently I'm using DM_MMC for U-Boot proper and recently I've moved SPL as well [1]. But I've seen an issue with i.MX6UL while moving to OF_SPL
[1] https://patchwork.ozlabs.org/cover/815776/
thanks!
Hi Jagan,
On Mon, Oct 2, 2017 at 7:23 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Yes, currently I'm using DM_MMC for U-Boot proper and recently I've moved SPL as well [1]. But I've seen an issue with i.MX6UL while moving to OF_SPL
What exactly is the MX6UL issue you see?
Thanks
On Mon, Oct 2, 2017 at 4:36 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Jagan,
On Mon, Oct 2, 2017 at 7:23 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Yes, currently I'm using DM_MMC for U-Boot proper and recently I've moved SPL as well [1]. But I've seen an issue with i.MX6UL while moving to OF_SPL
What exactly is the MX6UL issue you see?
I didn't dig much, but the i.MX6UL case has rebooting with DM_MMC for both SPL and U-Boot proper.
Log: ----- U-Boot SPL 2017.09-00371-ga81bf43 (Oct 09 2017 - 22:55:26) Trying to boot from MMC1
U-Boot 2017.09-00371-ga81bf43 (Oct 09 2017 - 22:55:26 +0530)
CPU: Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz) CPU: Industrial temperature grade (-40C to 105C) at 33C Reset cause: POR Model: Engicam GEAM6UL DRAM: 128 MiB
U-Boot SPL 2017.09-00371-ga81bf43 (Oct 09 2017 - 22:55:26) Trying to boot from MMC1
U-Boot 2017.09-00371-ga81bf43 (Oct 09 2017 - 22:55:26 +0530)
CPU: Freescale i.MX6UL rev1.1 528 MHz (running at 396 MHz) CPU: Industrial temperature grade (-40C to 105C) at 36C Reset cause: unknown reset Model: Engicam GEAM6UL DRAM: 128 MiB
thanks!
Hi Jagan,
On Mon, Oct 9, 2017 at 3:05 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
I didn't dig much, but the i.MX6UL case has rebooting with DM_MMC for both SPL and U-Boot proper.
Looks like the same issue I saw with mx6q, which has been fixed by this commit: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=3ea0520512089cffbe02b7d6eb64...
On Tue, Oct 10, 2017 at 5:18 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Jagan,
On Mon, Oct 9, 2017 at 3:05 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
I didn't dig much, but the i.MX6UL case has rebooting with DM_MMC for both SPL and U-Boot proper.
Looks like the same issue I saw with mx6q, which has been fixed by this commit: http://git.denx.de/?p=u-boot.git;a=commitdiff;h=3ea0520512089cffbe02b7d6eb64...
Still looping for i.MX6UL.
thanks!
Hi Jagan,
On Wed, Oct 11, 2017 at 7:17 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Still looping for i.MX6UL.
Can you test it again removing CONFIG_DM_MMC support?
Hi Fabio,
On Wed, Oct 11, 2017 at 9:19 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Jagan,
On Wed, Oct 11, 2017 at 7:17 AM, Jagan Teki jagannadh.teki@gmail.com wrote:
Still looping for i.MX6UL.
Can you test it again removing CONFIG_DM_MMC support?
I've observed here, u-boot is unable to relocate. So when I build U-Boot with removing u-boot,dm-spl from dts it works fine, but idea here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I suppose.
thanks!
On Wed, Oct 11, 2017 at 1:06 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
I've observed here, u-boot is unable to relocate. So when I build U-Boot with removing u-boot,dm-spl from dts it works fine, but idea here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I suppose.
Ok, a different bug then.
I was wondering if we could have some automated boot tests in U-Boot mainline?
Something like https://kernelci.org/ for U-Boot?
+ Stefano
On Wed, Oct 11, 2017 at 9:39 PM, Fabio Estevam festevam@gmail.com wrote:
On Wed, Oct 11, 2017 at 1:06 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
I've observed here, u-boot is unable to relocate. So when I build U-Boot with removing u-boot,dm-spl from dts it works fine, but idea here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I suppose.
Ok, a different bug then.
Yes, this is one of the reason I always insists new boards to use full proper U-Boot rather than just supporting their respective hardware on Mainline.
I was wondering if we could have some automated boot tests in U-Boot mainline?
Something like https://kernelci.org/ for U-Boot?
Yes, it's time otherwise all goes odd. Better to start a new thread discuss how we can move this.
thanks!
On Wed, Oct 11, 2017 at 01:09:04PM -0300, Fabio Estevam wrote:
On Wed, Oct 11, 2017 at 1:06 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
I've observed here, u-boot is unable to relocate. So when I build U-Boot with removing u-boot,dm-spl from dts it works fine, but idea here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I suppose.
Ok, a different bug then.
I was wondering if we could have some automated boot tests in U-Boot mainline?
Something like https://kernelci.org/ for U-Boot?
The problem(s) there are related to lack of hardware support for testing firmware in a CI type environment. For example, I do test/py/test.py on real hardware before every push cycle. The problem for iMX in this case at least is that I haven't seen (nor had a chance to come up with) the scripting to update u-boot from within u-boot, to catch the kind of failures that we don't see when doing the USB recovery boot method. I can test sabrelite via u-boot.imx (and in theory I could test my hummingboard with SPL, but my quick pass at enabling USB gadget support there didn't seem to work).
I would very much welcome more labs running tests however. There's already a few, but I guess the gap we see right here and now is that there's none for iMX.
On Wed, 11 Oct 2017 14:41:38 -0400 Tom Rini trini@konsulko.com wrote:
On Wed, Oct 11, 2017 at 01:09:04PM -0300, Fabio Estevam wrote:
On Wed, Oct 11, 2017 at 1:06 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
I've observed here, u-boot is unable to relocate. So when I build U-Boot with removing u-boot,dm-spl from dts it works fine, but idea here I need to use SPL_OF_CONTROL and it is not related to DM_MMC I suppose.
Ok, a different bug then.
I was wondering if we could have some automated boot tests in U-Boot mainline?
Something like https://kernelci.org/ for U-Boot?
The problem(s) there are related to lack of hardware support for testing firmware in a CI type environment. For example, I do test/py/test.py on real hardware before every push cycle. The problem for iMX in this case at least is that I haven't seen (nor had a chance to come up with) the scripting to update u-boot from within u-boot, to catch the kind of failures that we don't see when doing the USB recovery boot method. I can test sabrelite via u-boot.imx (and in theory I could test my hummingboard with SPL, but my quick pass at enabling USB gadget support there didn't seem to work).
If possible you can update SPL and u-boot.img via TFTP....
I would very much welcome more labs running tests however. There's already a few, but I guess the gap we see right here and now is that there's none for iMX.
There is some ongoing work to provide such facility..... for imx6 boards. I will keep you informed.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Hi Lukasz,
On Fri, Oct 13, 2017 at 5:16 AM, Lukasz Majewski lukma@denx.de wrote:
There is some ongoing work to provide such facility..... for imx6 boards. I will keep you informed.
That's good news! Please keep me in the loop as well.
Thanks
On Fri, Oct 13, 2017 at 7:03 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Fri, Oct 13, 2017 at 5:16 AM, Lukasz Majewski lukma@denx.de wrote:
There is some ongoing work to provide such facility..... for imx6 boards. I will keep you informed.
That's good news! Please keep me in the loop as well.
Would be good if we have some kind of discussion together on this topic on next week, ELCE Prague. Any plan?
thanks!
On Mon, Oct 16, 2017 at 6:51 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Fri, Oct 13, 2017 at 7:03 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Fri, Oct 13, 2017 at 5:16 AM, Lukasz Majewski lukma@denx.de wrote:
There is some ongoing work to provide such facility..... for imx6 boards. I will keep you informed.
That's good news! Please keep me in the loop as well.
Would be good if we have some kind of discussion together on this topic on next week, ELCE Prague. Any plan?
Yes, that would be nice. I will attend ELCE next week.
Thanks
On Mon, Oct 16, 2017 at 4:52 PM, Fabio Estevam festevam@gmail.com wrote:
On Mon, Oct 16, 2017 at 6:51 PM, Jagan Teki jagannadh.teki@gmail.com wrote:
On Fri, Oct 13, 2017 at 7:03 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Fri, Oct 13, 2017 at 5:16 AM, Lukasz Majewski lukma@denx.de wrote:
There is some ongoing work to provide such facility..... for imx6 boards. I will keep you informed.
That's good news! Please keep me in the loop as well.
The Logic PD board is also broken as well. When I did a git bisect on mine, it shows:
6eb25e9878617f9a1d7f06ec21c9b981bb0a4e5 is the first bad commit commit d6eb25e9878617f9a1d7f06ec21c9b981bb0a4e5 Author: Simon Glass sjg@chromium.org Date: Sat Jul 29 11:35:22 2017 -0600
dm: mmc: fsl_esdhc: Drop mmc_init() call from fsl_esdhc_init()
We want to use fsl_esdhc_init() with driver model. Move the mmc_init() out of this function so that we can use it for our common init.
Signed-off-by: Simon Glass sjg@chromium.org
I will admit, I haven't been as quick on checking this, so I feel bad for not noticing issues sooner. It could have been fixed, then later broken again, but 2017.07 work and 2017.09 did not.
adam
Would be good if we have some kind of discussion together on this topic on next week, ELCE Prague. Any plan?
Yes, that would be nice. I will attend ELCE next week.
Thanks _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
On Thu, Oct 19, 2017 at 7:52 PM, Adam Ford aford173@gmail.com wrote:
The Logic PD board is also broken as well. When I did a git bisect on mine, it shows:
Does this help?
--- a/configs/imx6q_logic_defconfig +++ b/configs/imx6q_logic_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y
On Thu, Oct 19, 2017 at 5:44 PM, Fabio Estevam festevam@gmail.com wrote:
On Thu, Oct 19, 2017 at 7:52 PM, Adam Ford aford173@gmail.com wrote:
The Logic PD board is also broken as well. When I did a git bisect on mine, it shows:
Does this help?
Yes it did. Thank you
I'll submit a patch. Should I indicate it 'fixes' that commit I referenced, or is there some other commit that I should reference?
thanks
adam
--- a/configs/imx6q_logic_defconfig +++ b/configs/imx6q_logic_defconfig @@ -28,7 +28,6 @@ CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_MTDPARTS=y CONFIG_ENV_IS_IN_NAND=y -# CONFIG_BLK is not set CONFIG_SYS_I2C_MXC=y CONFIG_NAND=y CONFIG_NAND_MXS=y
On Fri, Oct 20, 2017 at 12:18 AM, Adam Ford aford173@gmail.com wrote:
Yes it did. Thank you
I'll submit a patch. Should I indicate it 'fixes' that commit I referenced, or is there some other commit that I should reference?
I have just sent a patch that fixes the issue for all imx boards.
To all guys @ELCE,
Can we setup a formal meeting to discuss about ' U-Boot regression and test suit setup'
Do you think?
On 16-Oct-2017 10:51 PM, "Jagan Teki" jagannadh.teki@gmail.com wrote:
On Fri, Oct 13, 2017 at 7:03 PM, Fabio Estevam festevam@gmail.com wrote:
Hi Lukasz,
On Fri, Oct 13, 2017 at 5:16 AM, Lukasz Majewski lukma@denx.de wrote:
There is some ongoing work to provide such facility..... for imx6 boards. I will keep you informed.
That's good news! Please keep me in the loop as well.
Would be good if we have some kind of discussion together on this topic on next week, ELCE Prague. Any plan?
thanks! -- Jagan Teki Free Software Engineer | www.openedev.com U-Boot, Linux | Upstream Maintainer Hyderabad, India.
participants (6)
-
Adam Ford -
Fabio Estevam -
Jagan Teki -
Lukasz Majewski -
Tom Rini -
Łukasz Majewski