From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mx.groups.io; dkim=pass header.i=@semihalf-com.20150623.gappssmtp.com header.s=20150623 header.b=KdOo0Br4; spf=none, err=SPF record not found (domain: semihalf.com, ip: 209.85.160.193, mailfrom: mw@semihalf.com) Received: from mail-qt1-f193.google.com (mail-qt1-f193.google.com [209.85.160.193]) by groups.io with SMTP; Thu, 27 Jun 2019 23:33:03 -0700 Received: by mail-qt1-f193.google.com with SMTP id h24so2122203qto.0 for ; Thu, 27 Jun 2019 23:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Y3HENNRqgPBvxZ48tqokT/a1f20j0Hbasva1TW6McCs=; b=KdOo0Br4efx8KYWgHQNX6AH+0ree+SHYcEhNvQuYA4ENd4EtK0+Z3K8LwI1NS4BWWt iRkMv8hIei2v3NqdYNbp5llE6y1JAkymcCCz1NXtLQd1orfM49e9YPGTesnbYOqrWq/e kVG69Ol3SXqqG3d0psezVd409lc2uIToUERj5DogRLoljCWVH0ecVSe7nPSOcdJZzvVc cbbrl0XIYF56xwKYbNCx8W9EpdGz+OsLFx/qz+AVSNtkiTNlVGDu7jPSMiLwsBsQnkXS zM9Ju5C3eOyuBmKFY5fIWdjtATgBOyEsp3aDrmwXLhbT9rnao47A6BJ/vZggPw218oTJ 0KtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Y3HENNRqgPBvxZ48tqokT/a1f20j0Hbasva1TW6McCs=; b=GH8ki3X3ut8FwQMfaV529LYgqHPq7+B+j85+WsBh9Tbu2tCKH/uBC42jVNrIL4Q//K A/o3Y/fE1qdzgOCIFFtcwWqaiaJzsXcZfrn7dI4vUIs9+xAQRL5V5EMNImJlVG2Z3DQq CjxD5V4g0hc309zdb2E/Aaykq6CmmDb56MRWVSPWBXnUpGTiiixcAIA2KxfqcGso/4XU otR5ArLaadsSCAQnSUg6kp473IrndBK+YXW3J7BtOrqmSjapxBmCuK/OUcfjLNtfhX0X LvCfiKC+XqINMBoOPKQkAJdbhTsBlXO8zvwSbC+0A1IGmrlshAqx9dxvkZf0T3jRjW9E 5t1g== X-Gm-Message-State: APjAAAWD7CzAcxwUMURGwlRXtXsjReSrInLnS+Y7qdAKmPYbqQuq3bRl HjfzMd13EIU6Qe75SdGkvFui+d2fVt+8tRLjUq7g7g== X-Google-Smtp-Source: APXvYqzfPvQgWd/2O7iS4NiQShjCnD+iniGHpiBLj817/jQY3meNl2eqL1Edn5Ss+o7zwDtn5FDqsvNg8zhSl6acnh0= X-Received: by 2002:ac8:1c7b:: with SMTP id j56mr6530130qtk.247.1561703581827; Thu, 27 Jun 2019 23:33:01 -0700 (PDT) MIME-Version: 1.0 References: <20190626131003.3088-1-mateusz.albecki@intel.com> In-Reply-To: From: "Marcin Wojtas" Date: Fri, 28 Jun 2019 08:32:49 +0200 Message-ID: Subject: Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol To: "Wu, Hao A" , "Albecki, Mateusz" Cc: Sumit Garg , Ard Biesheuvel , edk2-devel-groups-io Content-Type: multipart/alternative; boundary="0000000000003d73dc058c5c7344" --0000000000003d73dc058c5c7344 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I was almost happily sending you email with 'tested-by' information, but I checked 3 boards: Board 1 (out of tree): SD - OK, MMC - OK Board 2: (Armada80x0McBin): SD - OK, MMC - OK Board 3: (Armada70x0Db): SD - problems, MMC - OK In the latter case I get stall and booting takes around 3 minutes. Without "MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol" patch it works as before. I enabled debugs, and in theory everything seems fine, the DriverStrength is set to EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE. SdCardIdentification: Found a SD device at slot [0] SdCardSetBusMode: Target bus mode: bus timing =3D 1, bus width =3D 4, cloc= k freq[MHz] =3D 50, driver strength =3D 255 However right after Csd register dump the booting stalls until printing following and continuing: FatOpenDevice: read of part_lba failed Time out This is absent from the prints I dumped from vanilla kernel. Despite I currently really have no time to additional debug, I checked and with following diff, everything works as before: --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c @@ -536,8 +536,8 @@ SdCardSwitch ( AccessMode =3D 0xF; } - SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF) | ((CommandSystem & 0xF) << 4) | \ - ((DriverStrength & 0xF) << 8) | ((PowerLimit & 0xF) << 12) | \ + SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF) | ((PowerLimit & 0xF= ) << 4) | \^M + ((DriverStrength & 0xF) << 8) | ((DriverStrength & 0xF) << 12) | \^M ModeValue; Above is restoring SdMmcCmdBlk.CommandArgument to the state from before th= e patch in question. Now the question - why the layout of the command changed? CommandSystem was unused before, and PowerLimit changed its position. Is this change really related to the rest of the patch? What is the justification? Best regards, Marcin pt., 28 cze 2019 o 02:57 Wu, Hao A napisa=C5=82(a): > > -----Original Message----- > > From: Sumit Garg [mailto:sumit.garg@linaro.org] > > Sent: Thursday, June 27, 2019 9:39 PM > > To: Ard Biesheuvel > > Cc: edk2-devel-groups-io; Wu, Hao A; Marcin Wojtas; Albecki, Mateusz > > Subject: Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: > > Implement revision 3 of SdMmcOverrideProtocol > > > > On Thu, 27 Jun 2019 at 13:40, Ard Biesheuvel > > wrote: > > > > > > (+ Sumit) > > > > > > On Thu, 27 Jun 2019 at 08:29, Wu, Hao A wrote: > > > > > > > > > -----Original Message----- > > > > > From: Marcin Wojtas [mailto:mw@semihalf.com] > > > > > Sent: Thursday, June 27, 2019 2:25 PM > > > > > To: Albecki, Mateusz > > > > > Cc: edk2-devel-groups-io; Wu, Hao A > > > > > Subject: Re: [edk2-devel] [PATCH v4 0/2] > > MdeModulePkg/SdMmcHcDxe: > > > > > Implement revision 3 of SdMmcOverrideProtocol > > > > > > > > > > Hi Mateusz, > > > > > > > > > > Can you please push those patches somewhere (github?) so that I = can > > > > > easily do a quick check for regression? > > > > > > > > > > Thanks, > > > > > Marcin > > > > > > > > > > > > Hello Marcin, > > > > > > > > I have just pushed the series at: > > > > https://github.com/hwu25/edk2/tree/sdmmc_override_extend_v4 > > > > > > > > Please help to check. > > > > > > > > > > I have cc'ed my colleague Sumit, who has kindly agreed to regression > > > test this branch on Socionext SynQuacer, which also uses the SD/MMC > > > override infrastructure. > > > > > > Sumit, please reply here with your results. And thanks again! > > > > I did picked this patch-set and applied on top of edk2 master branch. > > It works well on SynQuacer with eMMC device enumerated properly and > > all three eMMC partitions are visible: > > > > BLK4: Alias(s): > > VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,000030520000000000)/eMMC(0x > > 0)/Ctrl(0x0) > > BLK5: Alias(s): > > VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,000030520000000000)/eMMC(0x > > 0)/Ctrl(0x1) > > BLK6: Alias(s): > > VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,000030520000000000)/eMMC(0x > > 0)/Ctrl(0x2) > > > > Shell> devices > > > > E9 D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,0000305200000000 > > 00)/eMMC(0x0)/Ctrl(0x0) > > EA D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,0000305200000000 > > 00)/eMMC(0x0)/Ctrl(0x1) > > EB D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,0000305200000000 > > 00)/eMMC(0x0)/Ctrl(0x2) > > > > So you can add following: > > > > Regression-tested-by: Sumit Garg > > > Thanks a lot for the testing. > > Best Regards, > Hao Wu > > > > > > -Sumit > >=20 > > --0000000000003d73dc058c5c7344 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I was almost happily sending you email with '= tested-by' information, but I checked 3 boards:
Board 1 (out = of tree): SD - OK, MMC - OK
Board 2: (Armada80x0McBin): SD - OK, = MMC - OK
Board 3: (Armada70x0Db): SD - problems, MMC - OK

In the latter case I get stall and booting takes around 3= minutes.
Without "MdeModulePkg/SdMmcHcDxe: Implement revisi= on 3 of SdMmcOverrideProtocol" patch it works as before.
I enabled debugs, and in theory everything seems fine, the Driv= erStrength is set to=C2=A0EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE.
SdCardIdentification: Found a SD device at slot [0]
SdCardSetB= usMode: Target bus mode: bus timing =3D 1, bus width =3D 4, clock freq[MHz]= =3D 50, driver strength =3D 255

However rig= ht after Csd register dump the booting stalls until printing following and = continuing:
FatOpenDevice: read of part_lba failed Time out

This is absent from the prints I dumped from vanill= a kernel. Despite I currently really have no time to additional debug, I ch= ecked and with following diff, everything works as before:

--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c
@@ -536,8 +5= 36,8 @@ SdCardSwitch (
=C2=A0 =C2=A0 =C2=A0 =C2=A0AccessMode =3D = 0xF;
=C2=A0 =C2=A0}
=C2=A0
-=C2=A0 SdMmcCmdBl= k.CommandArgument =3D (AccessMode & 0xF) | ((CommandSystem & 0xF) &= lt;< 4) | \
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ((DriverStr= ength & 0xF) << 8) | ((PowerLimit & 0xF) << 12) | \
+=C2=A0 SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF) | ((P= owerLimit & 0xF) << 4) | \^M
+=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = = =C2=A0 =C2=A0 ((DriverStrength & 0xF) << 8) | ((DriverStrength &= amp; 0xF) << 12) | \^M
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0ModeValue;

Above is restoring SdM= mcCmdBlk.CommandArgument to the state from before the patch in question. No= w the question - why the layout of the command changed? CommandSystem was u= nused before, and PowerLimit changed its position. Is this change really re= lated to the rest of the patch? What is the justification?

Best regards,
Marcin


pt., 28 cze 2019 o 02:57=C2=A0Wu, Hao A &l= t;hao.a.wu@intel.com> napisa= =C5=82(a):
>= -----Original Message-----
> From: Sumit Garg [mailto:sumit.garg@linaro.org]
> Sent: Thursday, June 27, 2019 9:39 PM
> To: Ard Biesheuvel
> Cc: edk2-devel-groups-io; Wu, Hao A; Marcin Wojtas; Albecki, Mateusz<= br> > Subject: Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe:
> Implement revision 3 of SdMmcOverrideProtocol
>
> On Thu, 27 Jun 2019 at 13:40, Ard Biesheuvel <ard.biesheuvel@linaro.org>= ;
> wrote:
> >
> > (+ Sumit)
> >
> > On Thu, 27 Jun 2019 at 08:29, Wu, Hao A <hao.a.wu@intel.com> wrote:
> > >
> > > > -----Original Message-----
> > > > From: Marcin Wojtas [mailto:mw@semihalf.com]
> > > > Sent: Thursday, June 27, 2019 2:25 PM
> > > > To: Albecki, Mateusz
> > > > Cc: edk2-devel-groups-io; Wu, Hao A
> > > > Subject: Re: [edk2-devel] [PATCH v4 0/2]
> MdeModulePkg/SdMmcHcDxe:
> > > > Implement revision 3 of SdMmcOverrideProtocol
> > > >
> > > > Hi Mateusz,
> > > >
> > > > Can you please push those patches somewhere (github?) = so that I can
> > > > easily do a quick check for regression?
> > > >
> > > > Thanks,
> > > > Marcin
> > >
> > >
> > > Hello Marcin,
> > >
> > > I have just pushed the series at:
> > > https://github.com/hwu25/= edk2/tree/sdmmc_override_extend_v4
> > >
> > > Please help to check.
> > >
> >
> > I have cc'ed my colleague Sumit, who has kindly agreed to re= gression
> > test this branch on Socionext SynQuacer, which also uses the SD/= MMC
> > override infrastructure.
> >
> > Sumit, please reply here with your results. And thanks again! >
> I did picked this patch-set and applied on top of edk2 master branch.=
> It works well on SynQuacer with eMMC device enumerated properly and > all three eMMC partitions are visible:
>
>=C2=A0 =C2=A0 =C2=A0 BLK4: Alias(s):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VenHw(0D51905B-B77E-452A-A2C0= -
> ECA0CC8D514A,000030520000000000)/eMMC(0x
> 0)/Ctrl(0x0)
>=C2=A0 =C2=A0 =C2=A0 BLK5: Alias(s):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VenHw(0D51905B-B77E-452A-A2C0= -
> ECA0CC8D514A,000030520000000000)/eMMC(0x
> 0)/Ctrl(0x1)
>=C2=A0 =C2=A0 =C2=A0 BLK6: Alias(s):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VenHw(0D51905B-B77E-452A-A2C0= -
> ECA0CC8D514A,000030520000000000)/eMMC(0x
> 0)/Ctrl(0x2)
>
> Shell> devices
> <snip>
>=C2=A0 =C2=A0E9 D - -=C2=A0 1=C2=A0 1=C2=A0 =C2=A00 VenHw(0D51905B-B77= E-452A-A2C0-
> ECA0CC8D514A,0000305200000000
> 00)/eMMC(0x0)/Ctrl(0x0)
>=C2=A0 =C2=A0EA D - -=C2=A0 1=C2=A0 1=C2=A0 =C2=A00 VenHw(0D51905B-B77= E-452A-A2C0-
> ECA0CC8D514A,0000305200000000
> 00)/eMMC(0x0)/Ctrl(0x1)
>=C2=A0 =C2=A0EB D - -=C2=A0 1=C2=A0 1=C2=A0 =C2=A00 VenHw(0D51905B-B77= E-452A-A2C0-
> ECA0CC8D514A,0000305200000000
> 00)/eMMC(0x0)/Ctrl(0x2)
>
> So you can add following:
>
> Regression-tested-by: Sumit Garg <sumit.garg@linaro.org>


Thanks a lot for the testing.

Best Regards,
Hao Wu


>
> -Sumit



--0000000000003d73dc058c5c7344--