[U-Boot] [PULL] Please pull u-boot-imx
Hi Tom,
a new PR. I dropped the patches causing breakages on PowerPC boards, as well as the issue on GE boards. It ran on travis successfully.
The following changes since commit 11ed312896c5f5814064c5d45dcb2f53dc121437:
configs: am57xx: change default board name to beagle_x15 (2018-08-26 12:26:16 -0400)
are available in the Git repository at:
git://www.denx.de/git/u-boot-imx.git master
for you to fetch changes up to c1d1543ebc6e1fb026d0d7ac96d865faa7567555:
mx7dsabresd: Add the qspi target to the list of supported defconfigs (2018-09-04 08:47:23 +0200)
---------------------------------------------------------------- Alex Kiernan (1): Cleanup CONFIG_BOOTDELAY on cl-som-imx7
Anson Huang (3): imx: mx7: psci: improve cpu hotplug flow imx: mx7: add gpc initialization for low power mode imx: mx7: add system suspend/resume support
Fabio Estevam (1): mx7dsabresd: Add the qspi target to the list of supported defconfigs
Martin Kaiser (1): watchdog: mx25: use the imx_watchdog driver for mx25
Stefan Agner (2): board: toradex: common: fail gracefully on missing NAND chip colibri_imx7_emmc: add Colibri iMX7D 1GB (eMMC) module support
Stefano Babic (1): imx: missing CONFIG_MII in mx7dsabresd_qspi_defconfig
Ye Li (6): imx: imx6sx-sdb: Enable DM QSPI driver imx: imx6sx-sabreauto: convert to use DM QSPI driver imx: imx7d-sdb: Add DM QSPI support dts: imx6ul: Update alias to support DM dts: imx6ul_evk: Add DTS files for 14x14 EVK and 9x9 EVK boards imx: imx6ul_evk: Enable DM driver for iMX6UL EVK u-boot
arch/arm/dts/Makefile | 7 ++- arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi | 16 +++++ arch/arm/dts/imx6sx-sabreauto.dts | 40 +++++++++++++ arch/arm/dts/imx6sx-sdb-u-boot.dtsi | 16 +++++ arch/arm/dts/imx6sx.dtsi | 12 ++-- arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi | 10 ++++ arch/arm/dts/imx6ul-14x14-evk.dts | 427 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ arch/arm/dts/imx6ul-9x9-evk-u-boot.dtsi | 10 ++++ arch/arm/dts/imx6ul-9x9-evk.dts | 471 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ arch/arm/dts/imx6ul.dtsi | 13 ++-- arch/arm/dts/imx7d-sdb-qspi-u-boot.dtsi | 10 ++++ arch/arm/dts/imx7d-sdb-qspi.dts | 44 ++++++++++++++ arch/arm/dts/imx7d-sdb.dts | 6 +- arch/arm/dts/imx7d.dtsi | 12 ++++ arch/arm/dts/imx7s.dtsi | 22 +++++-- arch/arm/include/asm/arch-mx25/imx-regs.h | 1 + arch/arm/mach-imx/mx7/Makefile | 2 +- arch/arm/mach-imx/mx7/psci-mx7.c | 472 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- arch/arm/mach-imx/mx7/psci-suspend.S | 67 +++++++++++++++++++++ arch/arm/mach-imx/mx7/soc.c | 103 ++++++++++++++++++++++++++++++++ board/freescale/mx6sxsabreauto/mx6sxsabreauto.c | 24 -------- board/freescale/mx6sxsabresd/mx6sxsabresd.c | 25 -------- board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 208 +++++++++++++--------------------------------------------------- board/freescale/mx7dsabresd/MAINTAINERS | 1 + board/freescale/mx7dsabresd/mx7dsabresd.c | 16 ----- board/toradex/colibri_imx7/Kconfig | 42 ++++++++++++- board/toradex/colibri_imx7/MAINTAINERS | 4 ++ board/toradex/colibri_imx7/colibri_imx7.c | 41 +++++++++++-- board/toradex/common/tdx-cfg-block.c | 7 ++- configs/mx6sxsabreauto_defconfig | 2 + configs/mx6sxsabresd_defconfig | 7 +++ configs/mx6ul_14x14_evk_defconfig | 17 +++++- configs/mx6ul_9x9_evk_defconfig | 20 ++++++- configs/mx7dsabresd_qspi_defconfig | 84 ++++++++++++++++++++++++++ drivers/watchdog/Makefile | 2 +- include/configs/cl-som-imx7.h | 2 - include/configs/colibri_imx7.h | 90 ++++++++++++++++++++++------ include/configs/mx6sxsabresd.h | 4 ++ include/configs/mx6ul_14x14_evk.h | 13 ++-- include/configs/mx7dsabresd.h | 4 +- 40 files changed, 2079 insertions(+), 295 deletions(-) create mode 100644 arch/arm/dts/imx6sx-sabreauto-u-boot.dtsi create mode 100644 arch/arm/dts/imx6sx-sdb-u-boot.dtsi create mode 100644 arch/arm/dts/imx6ul-14x14-evk-u-boot.dtsi create mode 100644 arch/arm/dts/imx6ul-14x14-evk.dts create mode 100644 arch/arm/dts/imx6ul-9x9-evk-u-boot.dtsi create mode 100644 arch/arm/dts/imx6ul-9x9-evk.dts create mode 100644 arch/arm/dts/imx7d-sdb-qspi-u-boot.dtsi create mode 100644 arch/arm/dts/imx7d-sdb-qspi.dts create mode 100644 arch/arm/mach-imx/mx7/psci-suspend.S create mode 100644 configs/mx7dsabresd_qspi_defconfig
On Tue, Sep 04, 2018 at 09:11:50AM +0200, Stefano Babic wrote:
Hi Tom,
a new PR. I dropped the patches causing breakages on PowerPC boards, as well as the issue on GE boards. It ran on travis successfully.
The following changes since commit 11ed312896c5f5814064c5d45dcb2f53dc121437:
configs: am57xx: change default board name to beagle_x15 (2018-08-26 12:26:16 -0400)
are available in the Git repository at:
git://www.denx.de/git/u-boot-imx.git master
for you to fetch changes up to c1d1543ebc6e1fb026d0d7ac96d865faa7567555:
mx7dsabresd: Add the qspi target to the list of supported defconfigs (2018-09-04 08:47:23 +0200)
Applied to u-boot/master, thanks!
Hi Stefano,
a new PR. I dropped the patches causing breakages on PowerPC boards, as well as the issue on GE boards. It ran on travis successfully.
The following changes since commit 11ed312896c5f5814064c5d45dcb2f53dc121437:
configs: am57xx: change default board name to beagle_x15 (2018-08-26 12:26:16 -0400)
are available in the Git repository at:
git://www.denx.de/git/u-boot-imx.git master
for you to fetch changes up to c1d1543ebc6e1fb026d0d7ac96d865faa7567555:
mx7dsabresd: Add the qspi target to the list of supported defconfigs (2018-09-04 08:47:23 +0200)
Alex Kiernan (1): Cleanup CONFIG_BOOTDELAY on cl-som-imx7
Anson Huang (3): imx: mx7: psci: improve cpu hotplug flow imx: mx7: add gpc initialization for low power mode imx: mx7: add system suspend/resume support
Fabio Estevam (1): mx7dsabresd: Add the qspi target to the list of supported defconfigs
Martin Kaiser (1): watchdog: mx25: use the imx_watchdog driver for mx25
Stefan Agner (2): board: toradex: common: fail gracefully on missing NAND chip colibri_imx7_emmc: add Colibri iMX7D 1GB (eMMC) module support
Stefano Babic (1): imx: missing CONFIG_MII in mx7dsabresd_qspi_defconfig
Ye Li (6): imx: imx6sx-sdb: Enable DM QSPI driver imx: imx6sx-sabreauto: convert to use DM QSPI driver imx: imx7d-sdb: Add DM QSPI support dts: imx6ul: Update alias to support DM dts: imx6ul_evk: Add DTS files for 14x14 EVK and 9x9 EVK boards imx: imx6ul_evk: Enable DM driver for iMX6UL EVK u-boot
Are you aware of any issues on some imx6 devices in 2018.09? The hummingboard2 (imx6q) hangs for me just after the output below, even with the above PR, it works fine with a imx6sx device (udoo neo). I'm sure I've seen something on the list that might be related but I can't find it.
Sorry for picking this up so late in the cycle.
Peter
U-Boot SPL 2018.09-rc3 (Sep 05 2018 - 20:28:15 +0000) Trying to boot from MMC1
U-Boot 2018.09-rc3 (Sep 05 2018 - 20:28:15 +0000)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 25C Reset cause: POR Board: MX6 HummingBoard2 (som rev 1.5) DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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
Hi Peter,
On 06/09/2018 11:23, Peter Robinson wrote:
Hi Stefano,
a new PR. I dropped the patches causing breakages on PowerPC boards, as well as the issue on GE boards. It ran on travis successfully.
The following changes since commit 11ed312896c5f5814064c5d45dcb2f53dc121437:
configs: am57xx: change default board name to beagle_x15 (2018-08-26 12:26:16 -0400)
are available in the Git repository at:
git://www.denx.de/git/u-boot-imx.git master
for you to fetch changes up to c1d1543ebc6e1fb026d0d7ac96d865faa7567555:
mx7dsabresd: Add the qspi target to the list of supported defconfigs (2018-09-04 08:47:23 +0200)
Alex Kiernan (1): Cleanup CONFIG_BOOTDELAY on cl-som-imx7
Anson Huang (3): imx: mx7: psci: improve cpu hotplug flow imx: mx7: add gpc initialization for low power mode imx: mx7: add system suspend/resume support
Fabio Estevam (1): mx7dsabresd: Add the qspi target to the list of supported defconfigs
Martin Kaiser (1): watchdog: mx25: use the imx_watchdog driver for mx25
Stefan Agner (2): board: toradex: common: fail gracefully on missing NAND chip colibri_imx7_emmc: add Colibri iMX7D 1GB (eMMC) module support
Stefano Babic (1): imx: missing CONFIG_MII in mx7dsabresd_qspi_defconfig
Ye Li (6): imx: imx6sx-sdb: Enable DM QSPI driver imx: imx6sx-sabreauto: convert to use DM QSPI driver imx: imx7d-sdb: Add DM QSPI support dts: imx6ul: Update alias to support DM dts: imx6ul_evk: Add DTS files for 14x14 EVK and 9x9 EVK boards imx: imx6ul_evk: Enable DM driver for iMX6UL EVK u-boot
Are you aware of any issues on some imx6 devices in 2018.09?
No.
The hummingboard2 (imx6q) hangs for me just after the output below, even with the above PR, it works fine with a imx6sx device (udoo neo). I'm sure I've seen something on the list that might be related but I can't find it.
:-(
Sorry for picking this up so late in the cycle.
I can just try to test on another mx6q boar if I get enough time, but of course this is not a great test.
Regards, Stefano
Peter
U-Boot SPL 2018.09-rc3 (Sep 05 2018 - 20:28:15 +0000) Trying to boot from MMC1
U-Boot 2018.09-rc3 (Sep 05 2018 - 20:28:15 +0000)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 25C Reset cause: POR Board: MX6 HummingBoard2 (som rev 1.5) DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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
Hi Stefano,
a new PR. I dropped the patches causing breakages on PowerPC boards, as well as the issue on GE boards. It ran on travis successfully.
The following changes since commit 11ed312896c5f5814064c5d45dcb2f53dc121437:
configs: am57xx: change default board name to beagle_x15 (2018-08-26 12:26:16 -0400)
are available in the Git repository at:
git://www.denx.de/git/u-boot-imx.git master
for you to fetch changes up to c1d1543ebc6e1fb026d0d7ac96d865faa7567555:
mx7dsabresd: Add the qspi target to the list of supported defconfigs (2018-09-04 08:47:23 +0200)
Alex Kiernan (1): Cleanup CONFIG_BOOTDELAY on cl-som-imx7
Anson Huang (3): imx: mx7: psci: improve cpu hotplug flow imx: mx7: add gpc initialization for low power mode imx: mx7: add system suspend/resume support
Fabio Estevam (1): mx7dsabresd: Add the qspi target to the list of supported defconfigs
Martin Kaiser (1): watchdog: mx25: use the imx_watchdog driver for mx25
Stefan Agner (2): board: toradex: common: fail gracefully on missing NAND chip colibri_imx7_emmc: add Colibri iMX7D 1GB (eMMC) module support
Stefano Babic (1): imx: missing CONFIG_MII in mx7dsabresd_qspi_defconfig
Ye Li (6): imx: imx6sx-sdb: Enable DM QSPI driver imx: imx6sx-sabreauto: convert to use DM QSPI driver imx: imx7d-sdb: Add DM QSPI support dts: imx6ul: Update alias to support DM dts: imx6ul_evk: Add DTS files for 14x14 EVK and 9x9 EVK boards imx: imx6ul_evk: Enable DM driver for iMX6UL EVK u-boot
Are you aware of any issues on some imx6 devices in 2018.09?
No.
The hummingboard2 (imx6q) hangs for me just after the output below, even with the above PR, it works fine with a imx6sx device (udoo neo). I'm sure I've seen something on the list that might be related but I can't find it.
:-(
Sorry for picking this up so late in the cycle.
I can just try to test on another mx6q boar if I get enough time, but of course this is not a great test.
It seems like the Wandboard Quad revB I have also works fine so It might just be a regression in the mx6cuboxi target.
P
Hi Peter,
[Adding Jon and Baruch]
On Thu, Sep 6, 2018 at 9:37 AM, Peter Robinson pbrobinson@gmail.com wrote:
It seems like the Wandboard Quad revB I have also works fine so It might just be a regression in the mx6cuboxi target.
I don't have access to a hummingboard2 to investigate it.
Does this issue also happen on a mx6q cuboxi?
Are you able to run a bisect?
Thanks
Hi Fabio,
Fabio Estevam writes:
Hi Peter,
[Adding Jon and Baruch]
On Thu, Sep 6, 2018 at 9:37 AM, Peter Robinson pbrobinson@gmail.com wrote:
It seems like the Wandboard Quad revB I have also works fine so It might just be a regression in the mx6cuboxi target.
I don't have access to a hummingboard2 to investigate it.
Does this issue also happen on a mx6q cuboxi?
Are you able to run a bisect?
I tested current master successfully on Hummingboard2 with i.MX6 Solo (SOM rev 1.5):
U-Boot SPL 2018.09-rc3-00026-g4cdeda511f80 (Sep 06 2018 - 18:30:30 +0300) Trying to boot from MMC1
U-Boot 2018.09-rc3-00026-g4cdeda511f80 (Sep 06 2018 - 18:30:30 +0300)
CPU: Freescale i.MX6SOLO rev1.3 996 MHz (running at 792 MHz) CPU: Commercial temperature grade (0C to 95C) at 38C Reset cause: POR Board: MX6 HummingBoard2 (som rev 1.5) DRAM: 512 MiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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 Net: FEC Error: FEC address not set.
Hit any key to stop autoboot: 0 =>
... and with i.MX6Q (SOM rev 1.3):
U-Boot SPL 2018.09-rc3-00026-g4cdeda511f80 (Sep 06 2018 - 18:30:30 +0300) Trying to boot from MMC1
U-Boot 2018.09-rc3-00026-g4cdeda511f80 (Sep 06 2018 - 18:30:30 +0300)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 27C Reset cause: POR Board: MX6 HummingBoard2 DRAM: 2 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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 Card did not respond to voltage select! Net: FEC Hit any key to stop autoboot: 0 =>
I don't have handy at the moment the exact same combination of HB2 with i.MX6Q SOM rev 1.5.
I built mx6cuboxi_defconfig with no changes using Linaro GCC 7.3-2018.05.
baruch
-- http://baruch.siach.name/blog/ ~. .~ Tk Open Systems =}------------------------------------------------ooO--U--Ooo------------{= - baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
Hi Baruch,
On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote:
I tested current master successfully on Hummingboard2 with i.MX6 Solo (SOM rev 1.5):
Thanks for testing.
It seems we need more information from Peter about the regression he reported.
It would be helpful if Peter could run a bisect so that we could understand where the regression is coming from.
Thanks
I tested current master successfully on Hummingboard2 with i.MX6 Solo (SOM rev 1.5):
Thanks for testing.
It seems we need more information from Peter about the regression he reported.
It would be helpful if Peter could run a bisect so that we could understand where the regression is coming from.
We're using gcc 8.2 and binutils 2.31 and there have been a few interesting bits there on some other platforms, I wonder if something like that is coming along here with the latest toolchains. I'll try building with Fedora 27 (gcc 7.3.1 / binutils 2.29) to rule them out first.
P
On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam festevam@gmail.com wrote:
Hi Baruch,
On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote:
I tested current master successfully on Hummingboard2 with i.MX6 Solo (SOM rev 1.5):
Thanks for testing.
It seems we need more information from Peter about the regression he reported.
It would be helpful if Peter could run a bisect so that we could understand where the regression is coming from.
Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM i2eX iMX6D - rev 1.3).
The patch set that introduced this regression was part of another pull request, the one that introduces eMMC booting support (from Jon Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more testing it seems that the hang happens when trying to verify if the board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), which is not the case for this SOM in particular (and probably why it works fine on most rev 1.5-based SOMs, as eMMC is usually available there).
Tested with current u-boot master and the issue is still valid.
Jon, did you have any issue when testing that patch set on SOMs without eMMC support?
Cheers,
Hi Ricardo,
On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote:
On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote:
I tested current master successfully on Hummingboard2 with i.MX6 Solo (SOM rev 1.5):
Thanks for testing.
It seems we need more information from Peter about the regression he reported.
It would be helpful if Peter could run a bisect so that we could understand where the regression is coming from.
Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM i2eX iMX6D - rev 1.3).
The patch set that introduced this regression was part of another pull request, the one that introduces eMMC booting support (from Jon Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more testing it seems that the hang happens when trying to verify if the board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), which is not the case for this SOM in particular (and probably why it works fine on most rev 1.5-based SOMs, as eMMC is usually available there).
Tested with current u-boot master and the issue is still valid.
Jon, did you have any issue when testing that patch set on SOMs without eMMC support?
I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as shown in my previous message on this thread.
What toolchain are you using?
What do you see on the serial console?
baruch
Hi Baruch,
On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach baruch@tkos.co.il wrote:
Hi Ricardo,
On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote:
On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote:
I tested current master successfully on Hummingboard2 with i.MX6 Solo (SOM rev 1.5):
Thanks for testing.
It seems we need more information from Peter about the regression he reported.
It would be helpful if Peter could run a bisect so that we could understand where the regression is coming from.
Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM i2eX iMX6D - rev 1.3).
The patch set that introduced this regression was part of another pull request, the one that introduces eMMC booting support (from Jon Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more testing it seems that the hang happens when trying to verify if the board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), which is not the case for this SOM in particular (and probably why it works fine on most rev 1.5-based SOMs, as eMMC is usually available there).
Tested with current u-boot master and the issue is still valid.
Jon, did you have any issue when testing that patch set on SOMs without eMMC support?
I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as shown in my previous message on this thread.
Indeed, you tested with i.MX6Q, only difference is that mine is iMX6D, but both without eMMC.
What toolchain are you using?
Using GCC 8.2 from latest OpenEmbedded. Will try building with the version you used to see if I get any different behavior.
What do you see on the serial console?
It boots up to the point when it tries to find the emmc, and then it basically hangs completely (tested with current master):
U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000) Trying to boot from MMC1
U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000)
CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6 HummingBoard2 DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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 ---> hangs
Cheers,
On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti rsalveti@rsalveti.net wrote:
Hi Baruch,
On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach baruch@tkos.co.il wrote:
Hi Ricardo,
On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote:
On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote:
I tested current master successfully on Hummingboard2 with i.MX6 Solo (SOM rev 1.5):
Thanks for testing.
It seems we need more information from Peter about the regression he reported.
It would be helpful if Peter could run a bisect so that we could understand where the regression is coming from.
Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM i2eX iMX6D - rev 1.3).
The patch set that introduced this regression was part of another pull request, the one that introduces eMMC booting support (from Jon Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more testing it seems that the hang happens when trying to verify if the board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), which is not the case for this SOM in particular (and probably why it works fine on most rev 1.5-based SOMs, as eMMC is usually available there).
Tested with current u-boot master and the issue is still valid.
Jon, did you have any issue when testing that patch set on SOMs without eMMC support?
I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as shown in my previous message on this thread.
Indeed, you tested with i.MX6Q, only difference is that mine is iMX6D, but both without eMMC.
I see the issue with a .IMX6Q wirth SOM rev 1.5 (TI wifi, no EMMC) on a hummingboard2
What toolchain are you using?
Using GCC 8.2 from latest OpenEmbedded. Will try building with the version you used to see if I get any different behavior.
gcc 8.2.x from Fedora 29
What do you see on the serial console?
It boots up to the point when it tries to find the emmc, and then it basically hangs completely (tested with current master):
U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000) Trying to boot from MMC1
U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000)
CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6 HummingBoard2 DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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 ---> hangs
Exactly the same as I saw.
Hi Peter, Ricardo,
Peter Robinson writes:
On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti rsalveti@rsalveti.net wrote:
On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach baruch@tkos.co.il wrote:
On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote:
On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote:
I tested current master successfully on Hummingboard2 with i.MX6 Solo (SOM rev 1.5):
Thanks for testing.
It seems we need more information from Peter about the regression he reported.
It would be helpful if Peter could run a bisect so that we could understand where the regression is coming from.
Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM i2eX iMX6D - rev 1.3).
The patch set that introduced this regression was part of another pull request, the one that introduces eMMC booting support (from Jon Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more testing it seems that the hang happens when trying to verify if the board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), which is not the case for this SOM in particular (and probably why it works fine on most rev 1.5-based SOMs, as eMMC is usually available there).
Tested with current u-boot master and the issue is still valid.
Jon, did you have any issue when testing that patch set on SOMs without eMMC support?
I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as shown in my previous message on this thread.
Indeed, you tested with i.MX6Q, only difference is that mine is iMX6D, but both without eMMC.
I see the issue with a .IMX6Q wirth SOM rev 1.5 (TI wifi, no EMMC) on a hummingboard2
I could not reproduce with SOM rev 1.3 (no eMMC) on Hummingboard2.
What toolchain are you using?
Using GCC 8.2 from latest OpenEmbedded. Will try building with the version you used to see if I get any different behavior.
gcc 8.2.x from Fedora 29
I am using the ARM (Ltd) provided GNU toolchain version 8.2:
=> version U-Boot 2018.11 (Nov 18 2018 - 11:22:16 +0200)
arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 8.2.1 20180802 GNU ld (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 2.30.0.20180625
What do you see on the serial console?
It boots up to the point when it tries to find the emmc, and then it basically hangs completely (tested with current master):
U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000) Trying to boot from MMC1
U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000)
CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6 HummingBoard2 DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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 ---> hangs
Exactly the same as I saw.
Here is what I get at this point:
In: serial Out: serial Err: serial Card did not respond to voltage select! Net: FEC ...
The error message is from drivers/mmc/mmc.c:mmc_get_op_cond(). The code around this point might be the source of your issue. Can you add a few prints in mmc_get_op_cond() to pinpoint the call that hangs the code?
Thanks, baruch
Hi Baruch,
On Sun, Nov 18, 2018 at 7:51 AM Baruch Siach baruch@tkos.co.il wrote:
Hi Peter, Ricardo,
Peter Robinson writes:
On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti rsalveti@rsalveti.net wrote:
On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach baruch@tkos.co.il wrote:
On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote:
On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam festevam@gmail.com wrote:
On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote:
> I tested current master successfully on Hummingboard2 with i.MX6 Solo > (SOM rev 1.5):
Thanks for testing.
It seems we need more information from Peter about the regression he reported.
It would be helpful if Peter could run a bisect so that we could understand where the regression is coming from.
Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM i2eX iMX6D - rev 1.3).
The patch set that introduced this regression was part of another pull request, the one that introduces eMMC booting support (from Jon Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more testing it seems that the hang happens when trying to verify if the board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), which is not the case for this SOM in particular (and probably why it works fine on most rev 1.5-based SOMs, as eMMC is usually available there).
Tested with current u-boot master and the issue is still valid.
Jon, did you have any issue when testing that patch set on SOMs without eMMC support?
I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as shown in my previous message on this thread.
Indeed, you tested with i.MX6Q, only difference is that mine is iMX6D, but both without eMMC.
I see the issue with a .IMX6Q wirth SOM rev 1.5 (TI wifi, no EMMC) on a hummingboard2
I could not reproduce with SOM rev 1.3 (no eMMC) on Hummingboard2.
What toolchain are you using?
Using GCC 8.2 from latest OpenEmbedded. Will try building with the version you used to see if I get any different behavior.
gcc 8.2.x from Fedora 29
I am using the ARM (Ltd) provided GNU toolchain version 8.2:
=> version U-Boot 2018.11 (Nov 18 2018 - 11:22:16 +0200)
arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 8.2.1 20180802 GNU ld (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 2.30.0.20180625
What do you see on the serial console?
It boots up to the point when it tries to find the emmc, and then it basically hangs completely (tested with current master):
U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000) Trying to boot from MMC1
U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000)
CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6 HummingBoard2 DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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 ---> hangs
Exactly the same as I saw.
Here is what I get at this point:
In: serial Out: serial Err: serial Card did not respond to voltage select! Net: FEC ...
The error message is from drivers/mmc/mmc.c:mmc_get_op_cond(). The code around this point might be the source of your issue. Can you add a few prints in mmc_get_op_cond() to pinpoint the call that hangs the code?
Also tried with ARM's pre-built toolchain (same version), and got the same hang. Looking a bit further, it basically looks up while waiting the first mmc command to complete:
has_emmc -> mmc_get_op_cond -> mmc_send_if_cond (testing for SD version 2) -> mmc_send_cmd -> esdhc_send_cmd_common -> while (!(esdhc_read32(®s->irqstat) & flags))
And the boot log with MMC_TRACE:
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001AA
The line where it locks up waiting for the command to complete: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=3cdfa7f5...
Unclear why this only happens with this som/soc, maybe hardware/errata differences?
Let me know if you need any extra info.
Cheers,
Hi Ricardo,
Ricardo Salveti writes:
On Sun, Nov 18, 2018 at 7:51 AM Baruch Siach baruch@tkos.co.il wrote:
Peter Robinson writes:
On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti rsalveti@rsalveti.net wrote:
On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach baruch@tkos.co.il wrote:
On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote:
On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam festevam@gmail.com wrote: > On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote: > > > I tested current master successfully on Hummingboard2 with i.MX6 Solo > > (SOM rev 1.5): > > Thanks for testing. > > It seems we need more information from Peter about the regression he reported. > > It would be helpful if Peter could run a bisect so that we could > understand where the regression is coming from.
Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM i2eX iMX6D - rev 1.3).
The patch set that introduced this regression was part of another pull request, the one that introduces eMMC booting support (from Jon Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more testing it seems that the hang happens when trying to verify if the board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), which is not the case for this SOM in particular (and probably why it works fine on most rev 1.5-based SOMs, as eMMC is usually available there).
Tested with current u-boot master and the issue is still valid.
Jon, did you have any issue when testing that patch set on SOMs without eMMC support?
I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as shown in my previous message on this thread.
Indeed, you tested with i.MX6Q, only difference is that mine is iMX6D, but both without eMMC.
I see the issue with a .IMX6Q wirth SOM rev 1.5 (TI wifi, no EMMC) on a hummingboard2
I could not reproduce with SOM rev 1.3 (no eMMC) on Hummingboard2.
What toolchain are you using?
Using GCC 8.2 from latest OpenEmbedded. Will try building with the version you used to see if I get any different behavior.
gcc 8.2.x from Fedora 29
I am using the ARM (Ltd) provided GNU toolchain version 8.2:
=> version U-Boot 2018.11 (Nov 18 2018 - 11:22:16 +0200)
arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 8.2.1 20180802 GNU ld (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 2.30.0.20180625
What do you see on the serial console?
It boots up to the point when it tries to find the emmc, and then it basically hangs completely (tested with current master):
U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000) Trying to boot from MMC1
U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000)
CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6 HummingBoard2 DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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 ---> hangs
Exactly the same as I saw.
Here is what I get at this point:
In: serial Out: serial Err: serial Card did not respond to voltage select! Net: FEC ...
The error message is from drivers/mmc/mmc.c:mmc_get_op_cond(). The code around this point might be the source of your issue. Can you add a few prints in mmc_get_op_cond() to pinpoint the call that hangs the code?
Also tried with ARM's pre-built toolchain (same version), and got the same hang. Looking a bit further, it basically looks up while waiting the first mmc command to complete:
has_emmc -> mmc_get_op_cond -> mmc_send_if_cond (testing for SD version 2) -> mmc_send_cmd -> esdhc_send_cmd_common -> while (!(esdhc_read32(®s->irqstat) & flags))
And the boot log with MMC_TRACE:
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001AA
The line where it locks up waiting for the command to complete: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=3cdfa7f5...
Unclear why this only happens with this som/soc, maybe hardware/errata differences?
Let me know if you need any extra info.
I'll take a look tomorrow.
Can you reproduce this hang with these binary images:
https://images.solid-build.xyz/IMX6/U-Boot/spl-imx6-sdhc.bin https://images.solid-build.xyz/IMX6/U-Boot/u-boot-imx6-sdhc.img
baruch
Hi Baruch,
On Sun, Nov 18, 2018 at 6:29 PM Baruch Siach baruch@tkos.co.il wrote:
Hi Ricardo,
Ricardo Salveti writes:
The line where it locks up waiting for the command to complete: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=3cdfa7f5...
Unclear why this only happens with this som/soc, maybe hardware/errata differences?
Let me know if you need any extra info.
I'll take a look tomorrow.
Can you reproduce this hang with these binary images:
https://images.solid-build.xyz/IMX6/U-Boot/spl-imx6-sdhc.bin https://images.solid-build.xyz/IMX6/U-Boot/u-boot-imx6-sdhc.img
Yup, looks like it hangs at the same place:
U-Boot SPL 2018.01-02296-g457cdd60c3 (May 17 2018 - 22:59:22) Trying to boot from MMC1
U-Boot 2018.01-02296-g457cdd60c3 (May 17 2018 - 22:59:22 +0200), Build: jenkins-u-boot-imx6-variant=sdhc-2
CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 26C Reset cause: POR Board: MX6 HummingBoard2 Watchdog enabled DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial ---> hangs Cheers, -- Ricardo Salveti de Araujo
Hi Ricardo,
On Sun, Nov 18, 2018 at 5:44 PM Ricardo Salveti rsalveti@rsalveti.net wrote:
Also tried with ARM's pre-built toolchain (same version), and got the same hang. Looking a bit further, it basically looks up while waiting the first mmc command to complete:
has_emmc -> mmc_get_op_cond -> mmc_send_if_cond (testing for SD version 2) -> mmc_send_cmd -> esdhc_send_cmd_common -> while (!(esdhc_read32(®s->irqstat) & flags))
Does the change below help?
--- a/drivers/mmc/fsl_esdhc.c +++ b/drivers/mmc/fsl_esdhc.c @@ -396,6 +396,7 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv *priv, struct mmc *mmc, uint irqstat; u32 flags = IRQSTAT_CC | IRQSTAT_CTOE; struct fsl_esdhc *regs = priv->esdhc_regs; + unsigned long start;
#ifdef CONFIG_SYS_FSL_ERRATUM_ESDHC111 if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION) @@ -453,8 +454,11 @@ static int esdhc_send_cmd_common(struct fsl_esdhc_priv *priv, struct mmc *mmc, flags = IRQSTAT_BRR;
/* Wait for the command to complete */ - while (!(esdhc_read32(®s->irqstat) & flags)) - ; + start = get_timer(0); + while (!(esdhc_read32(®s->irqstat) & flags)) { + if (get_timer(start) > 1000) + return -ETIMEDOUT; + }
irqstat = esdhc_read32(®s->irqstat);
Hi Ricardo,
On Sun, Nov 18, 2018 at 05:43:02PM -0200, Ricardo Salveti wrote:
On Sun, Nov 18, 2018 at 7:51 AM Baruch Siach baruch@tkos.co.il wrote:
Peter Robinson writes:
On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti rsalveti@rsalveti.net wrote:
On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach baruch@tkos.co.il wrote:
On Tue, Nov 13, 2018 at 11:42:44AM -0200, Ricardo Salveti wrote:
On Thu, Sep 6, 2018 at 12:52 PM Fabio Estevam festevam@gmail.com wrote: > On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach baruch@tkos.co.il wrote: > > > I tested current master successfully on Hummingboard2 with i.MX6 Solo > > (SOM rev 1.5): > > Thanks for testing. > > It seems we need more information from Peter about the regression he reported. > > It would be helpful if Peter could run a bisect so that we could > understand where the regression is coming from.
Finally got the time to test u-boot 2018.09 on my hummingboard 2 and I can also confirm the boot issue with imx6q (Hummingboard 2 MicroSOM i2eX iMX6D - rev 1.3).
The patch set that introduced this regression was part of another pull request, the one that introduces eMMC booting support (from Jon Nettleton, e.g. 86e5a7fc13 and 19ed6063a5). After doing some more testing it seems that the hang happens when trying to verify if the board has eMMC during runtime (has_emmc -> mmc_get_op_cond(mmc)), which is not the case for this SOM in particular (and probably why it works fine on most rev 1.5-based SOMs, as eMMC is usually available there).
Tested with current u-boot master and the issue is still valid.
Jon, did you have any issue when testing that patch set on SOMs without eMMC support?
I tested U-Boot successfully with SOM rev 1.3 (no eMMC) on Hummingboard2, as shown in my previous message on this thread.
Indeed, you tested with i.MX6Q, only difference is that mine is iMX6D, but both without eMMC.
I see the issue with a .IMX6Q wirth SOM rev 1.5 (TI wifi, no EMMC) on a hummingboard2
I could not reproduce with SOM rev 1.3 (no eMMC) on Hummingboard2.
What toolchain are you using?
Using GCC 8.2 from latest OpenEmbedded. Will try building with the version you used to see if I get any different behavior.
gcc 8.2.x from Fedora 29
I am using the ARM (Ltd) provided GNU toolchain version 8.2:
=> version U-Boot 2018.11 (Nov 18 2018 - 11:22:16 +0200)
arm-linux-gnueabihf-gcc (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 8.2.1 20180802 GNU ld (GNU Toolchain for the A-profile Architecture 8.2-2018-08 (arm-rel-8.23)) 2.30.0.20180625
What do you see on the serial console?
It boots up to the point when it tries to find the emmc, and then it basically hangs completely (tested with current master):
U-Boot SPL 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000) Trying to boot from MMC1
U-Boot 2018.11+gf6206f8587 (Nov 16 2018 - 00:56:34 +0000)
CPU: Freescale i.MX6D rev1.5 996 MHz (running at 792 MHz) CPU: Extended Commercial temperature grade (-20C to 105C) at 33C Reset cause: POR Board: MX6 HummingBoard2 DRAM: 1 GiB MMC: FSL_SDHC: 0, FSL_SDHC: 1 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 ---> hangs
Exactly the same as I saw.
Here is what I get at this point:
In: serial Out: serial Err: serial Card did not respond to voltage select! Net: FEC ...
The error message is from drivers/mmc/mmc.c:mmc_get_op_cond(). The code around this point might be the source of your issue. Can you add a few prints in mmc_get_op_cond() to pinpoint the call that hangs the code?
Also tried with ARM's pre-built toolchain (same version), and got the same hang. Looking a bit further, it basically looks up while waiting the first mmc command to complete:
has_emmc -> mmc_get_op_cond -> mmc_send_if_cond (testing for SD version 2) -> mmc_send_cmd -> esdhc_send_cmd_common -> while (!(esdhc_read32(®s->irqstat) & flags))
And the boot log with MMC_TRACE:
No panel detected: default to HDMI Display: HDMI (1024x768) In: serial Out: serial Err: serial CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001AA
The line where it locks up waiting for the command to complete: http://git.denx.de/?p=u-boot.git;a=blob;f=drivers/mmc/fsl_esdhc.c;h=3cdfa7f5...
Unclear why this only happens with this som/soc, maybe hardware/errata differences?
Here's what I get after adding irqstat print:
CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001AA esdhc_send_cmd_common: irqstat: 10000 RET -110
The irqstat register has the DTOE (Data Timeout Error) bit enabled right after the irqstat wait loop that hangs in your setup.
I guess Fabio's patch would fix the issue for you. Indefinite loops are not a good idea in general, I think.
baruch
Ricardo/Peter,
On Mon, Nov 19, 2018 at 5:44 AM Baruch Siach baruch@tkos.co.il wrote:
I guess Fabio's patch would fix the issue for you. Indefinite loops are not a good idea in general, I think.
I have just sent a patch that avoids the infinite loop.
Please test it when you have a chance.
Thanks
On Mon, Nov 19, 2018 at 11:17 AM Fabio Estevam festevam@gmail.com wrote:
Ricardo/Peter,
On Mon, Nov 19, 2018 at 5:44 AM Baruch Siach baruch@tkos.co.il wrote:
I guess Fabio's patch would fix the issue for you. Indefinite loops are not a good idea in general, I think.
I have just sent a patch that avoids the infinite loop.
Please test it when you have a chance.
Replied with my tested by on the patch but 2018.11 with that patch boots fine for me on the HB2 imx6q rev 1.5 SOM.
Thanks, Peter
participants (6)
-
Baruch Siach -
Fabio Estevam -
Peter Robinson -
Ricardo Salveti -
Stefano Babic -
Tom Rini