[U-Boot] [PULL] Please pull u-boot-imx

Sun Nov 18 20:29:08 UTC 2018

Hi Ricardo,

Ricardo Salveti writes:
> On Sun, Nov 18, 2018 at 7:51 AM Baruch Siach <baruch at tkos.co.il> wrote:
>> Peter Robinson writes:
>> > On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti <rsalveti at rsalveti.net> wrote:
>> >> On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach <baruch at 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 at gmail.com> wrote:
>> >> > > > On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach <baruch at 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(&regs->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=3cdfa7f5a689789ea2f24da867d7c947ab78c002;hb=HEAD#l455
>
> 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

-- 
     http://baruch.siach.name/blog/                  ~. .~   Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
   - baruch at tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -