Hi Baruch,
On Sun, Nov 18, 2018 at 7:51 AM Baruch Siach <bar...@tkos.co.il> wrote:
>
> Hi Peter, Ricardo,
>
> Peter Robinson writes:
> > On Fri, Nov 16, 2018 at 1:06 AM Ricardo Salveti <rsalv...@rsalveti.net>
> > wrote:
> >> On Wed, Nov 14, 2018 at 5:07 AM Baruch Siach <bar...@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 <feste...@gmail.com>
> >> > > wrote:
> >> > > > On Thu, Sep 6, 2018 at 12:42 PM, Baruch Siach <bar...@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=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.
Cheers,
--
Ricardo Salveti de Araujo
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
