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=1ARKlYk/; spf=none, err=SPF record not found (domain: semihalf.com, ip: 209.85.222.175, mailfrom: mw@semihalf.com) Received: from mail-qk1-f175.google.com (mail-qk1-f175.google.com [209.85.222.175]) by groups.io with SMTP; Fri, 28 Jun 2019 01:57:47 -0700 Received: by mail-qk1-f175.google.com with SMTP id x18so4123695qkn.13 for ; Fri, 28 Jun 2019 01:57:47 -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=rwaz7Yb/m+FpyU+/owso/ngo7pq8yhPqu40aJI4GY3I=; b=1ARKlYk/DwnTXfm7w5vgtbiK0LfKAkahVYFi8QwnbT2q7Vx1XlfpqGFC3cMIzQFgUA 2iCyvGlboVOZHkRxkkb8tFzBTbCKSL1S1PKXEhM3JinYdo1WhHPCEfRw3+h1XKL4YXBu m6+9La73Fk1YR9UBSDhYmTAWOXxP3cVQ0Stqii9vA/vyteJGw1UXyjLHDDHkokoVAy/D 7AMBvmqrSRk6gE0SjDf4RaFddWusGe3JKrdHP3OXwsUAUs9/kqSun+utI84gg+r5SJGL RFZ7T8HVw0lrtGvvdF8WK+nWvjroNzrIZtSvyZKf1Lu9jgb9uCJGLAt0IQbq1MUqK9yY KOYw== 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=rwaz7Yb/m+FpyU+/owso/ngo7pq8yhPqu40aJI4GY3I=; b=gmzfQcyh5UX6nTUSJ2E7Cqvyl8HkstJyiTABXsLABHnug6K5EAYzhPmUxnB55QZQAb dYZrt74mx+SDJDv8JAWXwiYwZuuhI+oILuEW85Zc+rQdCs26m4KHp8dCymAscot9I53j UVKEG2jtOPS9bVgzKuDsVAA59aONLV4MTE+wKapuzCkF9SRD1TArVs9ugnL3JzqxG86l 8yq/rEa4ZMLZLOkULRr4axi+xcFNutQghMsEp3J9j0qsW0XiBUxYqkh4jQ2ZBBUVNgNG rdpfu7VD+vsFML5IugesqckYi0QQuPVWsoxvne/b/UVfNyFNu50dD59mck5Vcsr1hYfn dXtQ== X-Gm-Message-State: APjAAAV3BWUdSoGmIxizLFgtaBmsq9K9dloITM3Jci4lvyaTAKK/avzs EQs/722WFcXpGE1uF0y8wQ3Y/pq39c/Rr4nvA8aeAA== X-Google-Smtp-Source: APXvYqwmDVO/trD0pS6jrQG06GozjKrPhn9i5kMbMzuRtj2t/rzCJl824VIdJ9Mr8c5HwOpXBa98NM9/u76VY7KJ3v8= X-Received: by 2002:a37:56c5:: with SMTP id k188mr7398403qkb.109.1561712266497; Fri, 28 Jun 2019 01:57:46 -0700 (PDT) MIME-Version: 1.0 References: <20190626131003.3088-1-mateusz.albecki@intel.com> <92CF190FF2351747A47C1708F0E09C0875E76FFE@IRSMSX102.ger.corp.intel.com> In-Reply-To: <92CF190FF2351747A47C1708F0E09C0875E76FFE@IRSMSX102.ger.corp.intel.com> From: "Marcin Wojtas" Date: Fri, 28 Jun 2019 10:57:33 +0200 Message-ID: Subject: Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol To: "Albecki, Mateusz" Cc: "devel@edk2.groups.io" , "Wu, Hao A" , Sumit Garg , Ard Biesheuvel Content-Type: multipart/alternative; boundary="000000000000e2e6fc058c5e7861" --000000000000e2e6fc058c5e7861 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mateusz, pt., 28 cze 2019 o 10:12 Albecki, Mateusz napisa=C5=82(a): > Hi, > > > > Do you use override driver with this SD controller(if yes and it is open > source could you provide the link)? > [MW] Of course it's open source https://github.com/tianocore/edk2-platforms/tree/master/Silicon/Marvell/Dr= ivers/SdMmc/XenonDxe The platform is Armada70x0Db.dsc from the same edk2-platforms repo. > There is one change introduced in this patch that might require changes = in > the override driver. We have added enumeration for SdMmcSdDs and SdMmcSd= Hs > modes which were so far indicated to override drivers as SdMmcUhsSdr12 a= nd > SdMmcUhsSdr25 respectively so if there were any actions that were necess= ary > for high speed to work and those were done only for SdMmcUhsSdr25 then t= hat > might be the reason for regression. > > > [MW] Now, that was the reason. This interface required special handling fo= r high speed. This patch fixed it: https://pastebin.com/rdRe9wAh I will submit it after your patchset is merged. Best regards, Marcin > Thanks, > > Mateusz > > > > *From:* devel@edk2.groups.io [mailto:devel@edk2.groups.io] *On Behalf Of= *Marcin > Wojtas > *Sent:* Friday, June 28, 2019 9:42 AM > *To:* Wu, Hao A > *Cc:* Albecki, Mateusz ; Sumit Garg < > sumit.garg@linaro.org>; Ard Biesheuvel ; > edk2-devel-groups-io > *Subject:* Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: > Implement revision 3 of SdMmcOverrideProtocol > > > > Hi Hao, > > > > pt., 28 cze 2019 o 09:23 Wu, Hao A napisa=C5=82(a): > > Hello Marcin, > > > > Do you mean by only reverting as below: > > - SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF) | ((CommandSystem = & > 0xF) << 4) | \ > > - ((DriverStrength & 0xF) << 8) | (( > PowerLimit & 0xF) << 12) | \ > > + SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF) | ((PowerLimit & 0= xF) > << 4) | \^M > > + ((DriverStrength & 0xF) << 8) | > ((DriverStrength & 0xF) << 12) | \^M > > ModeValue; > > > > All your devices work fine? > > > > Since the origin code is clearly not correct (DriveStrength used 2 times= , > > the offset of PowerLimit is not 4, should be 12 according to SD spec). > > > > Ok, just rechecked. It doesn't help for my 1 problematic case. Anyway fo= r > the next time I think it may be worth to split some improvements out of > such big patches. > > > > I won't be able to debug my board until second week of July (at best), s= o > in order not to block you please go ahead with merging (the most importa= nt > board (MacchiatoBin) seems not suffer any regression). > > > > Best regards, > > Marcin > > > > > > Best Regards, > > Hao Wu > > > > *From:* Marcin Wojtas [mailto:mw@semihalf.com] > *Sent:* Friday, June 28, 2019 2:33 PM > *To:* Wu, Hao A; Albecki, Mateusz > *Cc:* Sumit Garg; Ard Biesheuvel; edk2-devel-groups-io > *Subject:* Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: > Implement revision 3 of SdMmcOverrideProtocol > > > > 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 DriverStrengt= h > 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, cl= ock > 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 & 0= xF) > << 4) | \^M > > + ((DriverStrength & 0xF) << 8) | > ((DriverStrength & 0xF) << 12) | \^M > > ModeValue; > > > > Above is restoring SdMmcCmdBlk.CommandArgument to the state from before > the 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 i= s > 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 > > --------------------------------------------------------------------- > > *Intel Technology Poland sp. z o.o.*ul. Słowackiego 173 | 80-298 > Gdańsk | Sąd Rejonowy Gdańsk Północ | VII Wydzia = 2 > Gospodarczy Krajowego Rejestru Sądowego - KRS 101882 | NIP > 957-07-52-316 | Kapitał zakładowy 200.000 PLN. > > Ta wiadomość wraz z załącznikami jest przeznaczona dla > określonego adresata i może zawierać informacje poufne. W ra= zie > przypadkowego otrzymania tej wiadomości, prosimy o powiadomienie > nadawcy oraz trwałe jej usunięcie; jakiekolwiek przeglądanie > lub rozpowszechnianie jest zabronione. > This e-mail and any attachments may contain confidential material for th= e > sole use of the intended recipient(s). If you are not the intended > recipient, please contact the sender and delete all copies; any review o= r > distribution by others is strictly prohibited. > > --000000000000e2e6fc058c5e7861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mateusz,


=

= pt., 28 cze 2019 o 10:12=C2=A0Albecki, Mateusz <mateusz.albecki@intel.com> napisa=C5=82(a):
=

Hi,

=C2=A0<= /p>

Do you use override driver w= ith this SD controller(if yes and it is open source could you provide the l= ink)?



The platform is Armada70x0Db.dsc from the = same edk2-platforms repo.

=C2=A0

There is one change introduced in this patch that might require changes in the override driver. We have added en= umeration for SdMmcSdDs and SdMmcSdHs modes which were so far indicated to = override drivers as SdMmcUhsSdr12 and SdMmcUhsSdr25 respectively so if ther= e were any actions that were necessary for high speed to work and those were done only for SdMmcUhsSdr25 then th= at might be the reason for regression.

=C2=A0


[MW] Now, that was the reason. Thi= s interface required special handling for high speed. This patch fixed it:<= /div>

I will submit it after your patch= set is merged.

Best regards,
Marcin=C2= =A0
=C2=A0

Thanks,=

Mateusz=

=C2=A0<= /p>

From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Marcin Wojtas
Sent: Friday, June 28, 2019 9:42 AM
To: Wu, Hao A <hao.a.wu@intel.com>
Cc: Albecki, Mateusz <mateusz.albecki@intel.com>; Sumit Garg <sumit.garg@linaro.or= g>; Ard Biesheuvel <ard.biesheuvel@linaro.org>; edk2-devel-groups-io &= lt;devel@edk2.gro= ups.io>
Subject: Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: I= mplement revision 3 of SdMmcOverrideProtocol

=C2=A0

Hi Hao,

=C2=A0

pt., 28 cze 2019 o 09:23=C2=A0Wu, Hao A <hao.a.wu@intel.com>= ; napisa=C5=82(a):

Hello Marcin,

=C2=A0

Do you mean by only revertin= g as below:

-=C2=A0 SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF)= | ((CommandSystem & 0xF) << 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 ((DriverStrength & 0xF) << 8) | ((PowerLimit & 0xF) << 12) | \

+=C2=A0 SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF)= | ((PowerLimit & 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 &= ; 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;

=C2=A0

All your devices work fine?<= /span>

=C2=A0

Since the origin code is cle= arly not correct (DriveStrength used 2 times,

the offset of PowerLimit is not 4, should be 12 according to SD spec).<= span lang=3D"EN-US">

=C2=A0

Ok, just rechecked. It doesn&#= 39;t help for my 1 problematic case. Anyway for the next time I think it ma= y be worth to split some improvements out of such big patches.

=C2=A0

I won't be able to debug m= y board until second week of July (at best), so in order not to block you p= lease go ahead with merging (the most important board (MacchiatoBin) seems = not suffer any regression).

=C2=A0

Best regards,

Marcin

=C2=A0

=C2=A0

Best Regards,

Hao Wu

=C2=A0

From: Marcin Wojtas [mailto:mw@semihalf.com]
Sent: Friday, June 28, 2019 2:33 PM
To: Wu, Hao A; Albecki, Mateusz
Cc: Sumit Garg; Ard Biesheuvel; edk2-devel-groups-io
Subject: Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHc= Dxe: Implement revision 3 of SdMmcOverrideProtocol<= /span>

=C2=A0

Hi,

=C2=A0

I was almost happily sending y= ou 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

=C2=A0

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.<= /u>

=C2=A0

I enabled debugs, and in theor= y everything seems fine, the DriverStrength is set to=C2=A0EDKII_SD_MMC_DRI= VER_STRENGTH_IGNORE.

SdCardIdentification= : Found a SD device at slot [0]

SdCardSetBusMode: Target bus mode: bus timing =3D 1, bus width =3D = 4, clock freq[MHz] =3D 50, driver strength =3D 255

=C2=A0

However right after Csd register dump the booting stalls until printing following an= d continuing:

FatOpenDevice= : read of part_lba failed Time out

=C2=A0

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

=C2=A0

--- a/MdeModulePkg/Bus/Pci<= /span>/SdMmcPciHcDxe/SdDevice.c

+++ b/MdeModulePkg/Bus/Pci<= /span>/SdMmcPciHcDxe/SdDevice.c

@@ -536,8 +536,8 @@ SdCardSwitch (

=C2=A0 =C2=A0 =C2=A0 =C2=A0= AccessMode =3D 0xF;

=C2=A0 =C2=A0}

=C2=A0

-=C2=A0 SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF)= | ((CommandSystem & 0xF) << 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 ((DriverStrength & 0xF) << 8) | ((PowerLimit & 0xF) << 12) | \

+=C2=A0 SdMmcCmdBlk.CommandArgument =3D (AccessMode & 0xF)= | ((PowerLimit & 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 &= ; 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;

=C2=A0

Above is restoring SdMmcCmdBlk.CommandArgument to the state from before the patch i= n 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 t= o the rest of the patch? What is the justification?

=C2=A0

Best regards,

Marcin

=C2=A0

=C2=A0

pt., 28 cze 2019 o 02:57=C2=A0Wu, Hao A <hao.a.wu@intel.com<= /span>> napisa=C5=82(a):

&= gt; -----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@in= tel.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.c= om/hwu25/edk2/tree/sdmmc_override_extend_v4=
> > >
> > > Please help to check.
> > >
> >
> > I have cc'ed my colleague Sumit, who has kindly ag= reed 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 prop= erly 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(0D= 51905B-B77E-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(0D= 51905B-B77E-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(0D= 51905B-B77E-452A-A2C0-
> ECA0CC8D514A,0000305200000000
> 00)/eMMC(0x0)/Ctrl(0x2)
>
> So you can add following:
>
> Regression-tested-by: Sumit Garg <sumit.garg@linaro.or= g>


Thanks a lot for the testing.

Best Regards,
Hao Wu


>
> -Sumit

--------------------------------------------------------------------- Intel Technology Poland sp. z o.o.
ul. S&#322owackiego 173 | 80-298 Gda&#324sk= | S&#261d Rejonowy Gda&#324sk P&#243&#322noc | VII Wydzia&#322 Gospodarczy Krajowego Rejestru S&#261dowego - KR= S 101882 | NIP 957-07-52-316 | Kapita&#322 zak&#322adowy 200.000 PLN.

<= p> Ta wiadomo&#347&#263 wraz z za&#322&#261cznikami jes= t przeznaczona dla okre&#347lonego adresata i mo&#380e zawiera&#263 informacje poufne. W razie przypa= dkowego otrzymania tej wiadomo&#347ci, prosimy o powiadomienie nadawcy oraz trwa&#322= e jej usuni&#281cie; jakiekolwiek przegl&#261danie lub rozpowszechnianie jest zabronione. This e-mail and any attachments may contain confidential material for the = sole use of the intended recipient(s). If you are not the intended recipient, please contact the sender and delete all copies; any review or distribution by ot= hers is strictly prohibited.

--000000000000e2e6fc058c5e7861--