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