Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol
Hello Marcin, Thanks for the verification. The series has been pushed via commits a37e18f6fc..adec1f5deb. Please help to raise if there is any help needed. Best Regards, Hao Wu From: Marcin Wojtas [mailto:m...@semihalf.com] Sent: Friday, June 28, 2019 4:58 PM To: Albecki, Mateusz Cc: devel@edk2.groups.io; Wu, Hao A; Sumit Garg; Ard Biesheuvel Subject: Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol Hi Mateusz, pt., 28 cze 2019 o 10:12 Albecki, Mateusz mailto:mateusz.albe...@intel.com>> napisał(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/Drivers/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 SdMmcSdHs modes which were so far indicated to override drivers as SdMmcUhsSdr12 and SdMmcUhsSdr25 respectively so if there were any actions that were necessary for high speed to work and those were done only for SdMmcUhsSdr25 then that might be the reason for regression. [MW] Now, that was the reason. This interface required special handling for 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> [mailto: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 mailto:hao.a...@intel.com>> Cc: Albecki, Mateusz mailto:mateusz.albe...@intel.com>>; Sumit Garg mailto:sumit.g...@linaro.org>>; Ard Biesheuvel mailto:ard.biesheu...@linaro.org>>; edk2-devel-groups-io mailto:devel@edk2.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 mailto:hao.a...@intel.com>> napisał(a): Hello Marcin, Do you mean by only reverting as below: - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & 0xF) << 4) | \ -((DriverStrength & 0xF) << 8) | ((PowerLimit & 0xF) << 12) | \ + SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((PowerLimit & 0xF) << 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 for 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), so in order not to block you please go ahead with merging (the most important board (MacchiatoBin) seems not suffer any regression). Best regards, Marcin Best Regards, Hao Wu From: Marcin Wojtas [mailto:m...@semihalf.com<mailto:m...@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 DriverStrength is set to EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE. SdCardIdentification: Found a SD device at slot [0] SdCardSetBusMode: Target bus mode: bus timing = 1, bus width = 4, clock freq[MHz] = 50, driver strength = 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 = 0xF; } - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & 0xF) << 4) | \ -
Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol
Hi Mateusz, pt., 28 cze 2019 o 10:12 Albecki, Mateusz napisał(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/Drivers/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 SdMmcSdHs > modes which were so far indicated to override drivers as SdMmcUhsSdr12 and > SdMmcUhsSdr25 respectively so if there were any actions that were necessary > for high speed to work and those were done only for SdMmcUhsSdr25 then that > might be the reason for regression. > > > [MW] Now, that was the reason. This interface required special handling for 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.g...@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ł(a): > > Hello Marcin, > > > > Do you mean by only reverting as below: > > - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & > 0xF) << 4) | \ > > -((DriverStrength & 0xF) << 8) | (( > PowerLimit & 0xF) << 12) | \ > > + SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((PowerLimit & 0xF) > << 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 for > 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), so > in order not to block you please go ahead with merging (the most important > board (MacchiatoBin) seems not suffer any regression). > > > > Best regards, > > Marcin > > > > > > Best Regards, > > Hao Wu > > > > *From:* Marcin Wojtas [mailto:m...@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 DriverStrength > is set to EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE. > > SdCardIdentification: Found a SD device at slot [0] > > SdCardSetBusMode: Target bus mode: bus timing = 1, bus width = 4, clock > freq[MHz] = 50, driver strength = 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 = 0xF; > >} > > > > - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & > 0xF) << 4) | \ >
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ł(a): > Hello Marcin, > > > > Do you mean by only reverting as below: > > - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & > 0xF) << 4) | \ > > -((DriverStrength & 0xF) << 8) | (( > PowerLimit & 0xF) << 12) | \ > > + SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((PowerLimit & 0xF) > << 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 for 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), so in order not to block you please go ahead with merging (the most important board (MacchiatoBin) seems not suffer any regression). Best regards, Marcin > > > Best Regards, > > Hao Wu > > > > *From:* Marcin Wojtas [mailto:m...@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 DriverStrength > is set to EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE. > > SdCardIdentification: Found a SD device at slot [0] > > SdCardSetBusMode: Target bus mode: bus timing = 1, bus width = 4, clock > freq[MHz] = 50, driver strength = 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 = 0xF; > >} > > > > - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & > 0xF) << 4) | \ > > -((DriverStrength & 0xF) << 8) | (( > PowerLimit & 0xF) << 12) | \ > > + SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((PowerLimit & 0xF) > << 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 is > the justification? > > > > Best regards, > > Marcin > > > > > > pt., 28 cze 2019 o 02:57 Wu, Hao A napisał(a): > > > -Original Message- > > From: Sumit Garg [mailto:sumit.g...@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:m...@semihalf.com] > > > > > Sent: Thursday,
Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol
Hello Marcin, Do you mean by only reverting as below: - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & 0xF) << 4) | \ -((DriverStrength & 0xF) << 8) | ((PowerLimit & 0xF) << 12) | \ + SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((PowerLimit & 0xF) << 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). Best Regards, Hao Wu From: Marcin Wojtas [mailto:m...@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 DriverStrength is set to EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE. SdCardIdentification: Found a SD device at slot [0] SdCardSetBusMode: Target bus mode: bus timing = 1, bus width = 4, clock freq[MHz] = 50, driver strength = 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 = 0xF; } - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & 0xF) << 4) | \ -((DriverStrength & 0xF) << 8) | ((PowerLimit & 0xF) << 12) | \ + SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((PowerLimit & 0xF) << 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 is the justification? Best regards, Marcin pt., 28 cze 2019 o 02:57 Wu, Hao A mailto:hao.a...@intel.com>> napisał(a): > -Original Message- > From: Sumit Garg [mailto:sumit.g...@linaro.org<mailto:sumit.g...@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 > mailto:ard.biesheu...@linaro.org>> > wrote: > > > > (+ Sumit) > > > > On Thu, 27 Jun 2019 at 08:29, Wu, Hao A > > mailto:hao.a...@intel.com>> wrote: > > > > > > > -Original Message----- > > > > From: Marcin Wojtas [mailto:m...@semihalf.com<mailto:m...@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 > > overr
Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol
pt., 28 cze 2019 o 08:32 Marcin Wojtas napisał(a): > > 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 = 1, bus width = 4, clock > freq[MHz] = 50, driver strength = 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: vanilla edk2 of course :) > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c > @@ -536,8 +536,8 @@ SdCardSwitch ( >AccessMode = 0xF; >} > > - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & 0xF) > << 4) | \ > -((DriverStrength & 0xF) << 8) | ((PowerLimit > & 0xF) << 12) | \ > + SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((PowerLimit & 0xF) << > 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 is the justification? > > Best regards, > Marcin > > > pt., 28 cze 2019 o 02:57 Wu, Hao A napisał(a): >> >> > -----Original Message- >> > From: Sumit Garg [mailto:sumit.g...@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:m...@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,
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 DriverStrength is set to EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE. SdCardIdentification: Found a SD device at slot [0] SdCardSetBusMode: Target bus mode: bus timing = 1, bus width = 4, clock freq[MHz] = 50, driver strength = 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 = 0xF; } - SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((CommandSystem & 0xF) << 4) | \ -((DriverStrength & 0xF) << 8) | ((PowerLimit & 0xF) << 12) | \ + SdMmcCmdBlk.CommandArgument = (AccessMode & 0xF) | ((PowerLimit & 0xF) << 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 is the justification? Best regards, Marcin pt., 28 cze 2019 o 02:57 Wu, Hao A napisał(a): > > -Original Message- > > From: Sumit Garg [mailto:sumit.g...@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:m...@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,305200)/eMMC(0x > > 0)/Ctrl(0x0) > > BLK5: Alias(s): > > VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,305200)/eMMC(0x > > 0)/Ctrl(0x1) > > BLK6: Alias(s): > > VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,305200)/eMMC(0x > > 0)/Ctrl(0x2) > > > > Shell> devices > > > > E9 D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,3052 > > 00)/eMMC(0x0)/Ctrl(0x0) > > EA D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,3052 > > 00)/eMMC(0x0)/Ctrl(0x1) > > EB D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > > ECA0CC8D514A,3052 > > 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 > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42974): https://edk2.groups.io/g/devel/message/42974 Mute This Topic: https://groups.io/mt/32214570/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol
> -Original Message- > From: Sumit Garg [mailto:sumit.g...@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:m...@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,305200)/eMMC(0x > 0)/Ctrl(0x0) > BLK5: Alias(s): > VenHw(0D51905B-B77E-452A-A2C0- > ECA0CC8D514A,305200)/eMMC(0x > 0)/Ctrl(0x1) > BLK6: Alias(s): > VenHw(0D51905B-B77E-452A-A2C0- > ECA0CC8D514A,305200)/eMMC(0x > 0)/Ctrl(0x2) > > Shell> devices > > E9 D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > ECA0CC8D514A,3052 > 00)/eMMC(0x0)/Ctrl(0x0) > EA D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > ECA0CC8D514A,3052 > 00)/eMMC(0x0)/Ctrl(0x1) > EB D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0- > ECA0CC8D514A,3052 > 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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42951): https://edk2.groups.io/g/devel/message/42951 Mute This Topic: https://groups.io/mt/32214570/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
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:m...@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,305200)/eMMC(0x 0)/Ctrl(0x0) BLK5: Alias(s): VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,305200)/eMMC(0x 0)/Ctrl(0x1) BLK6: Alias(s): VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,305200)/eMMC(0x 0)/Ctrl(0x2) Shell> devices E9 D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,3052 00)/eMMC(0x0)/Ctrl(0x0) EA D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,3052 00)/eMMC(0x0)/Ctrl(0x1) EB D - - 1 1 0 VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,3052 00)/eMMC(0x0)/Ctrl(0x2) So you can add following: Regression-tested-by: Sumit Garg -Sumit -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42937): https://edk2.groups.io/g/devel/message/42937 Mute This Topic: https://groups.io/mt/32214570/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol
(+ Sumit) On Thu, 27 Jun 2019 at 08:29, Wu, Hao A wrote: > > > -Original Message- > > From: Marcin Wojtas [mailto:m...@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! -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42924): https://edk2.groups.io/g/devel/message/42924 Mute This Topic: https://groups.io/mt/32214570/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v4 0/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol
> -Original Message- > From: Marcin Wojtas [mailto:m...@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. Best Regards, Hao Wu > > śr., 26 cze 2019 o 15:10 Albecki, Mateusz > napisał(a): > > > > To allow platform greater control over the bus settings for SD card and > eMMC card we have added a new notify phase to SdMmcOverrideProtocol > called GetOperatingParam. > > This phase is signaled before SD card/eMMC initialization and allows > platform to tweak the values in new structure called > EDKII_SD_MMC_OPERATING_PARAMETERS which allows to configure bus > width, clock frequency and driver strength. > > Other bus parameters can be configured by overriding host controller > capabilities. > > > > Changes in v2: > > - Fixed stylistic issues and documentation issues pointed out in v1 review > > - Changed bus width to be UINT8 > > - Reordered the SD_MMC_BUS_MODE to fix problem with driver never > choosing the DDR50 speed mode > > - Fixed the bug with driver not switching the controller into correct driver > strength for SD card slots > > - Fixed bug with the driver not considering driver strength support for SD > card slots > > - Fixed bug with driver choosing SdMmcMmcHsSdr if card doesn't support > frequencies above 26MHz > > - Fixed bug with driver choosing driver strength for legacy speed modes > > > > Changes in v3: > > - Changed BusWidth field of EDKII_SD_MMC_OPERATING_PARAMETERS to > UINT16 > > > > Changes in v4 > > - Fixed typos and ordering in SD_MMC_BUS_MODE(this time for real) > > - Fixed non boolean types usage in if statements > > - Fixed code that checks if there was an error in switch response for SD > > card. > The code has been updated to check if switch failed due to function being > busy > > > > Tests: > > - OS boot from eMMC without SdMmcOverride protocol installed > > - OS boot from eMMC with SdMmcOverride installed and clock frequency > lowered to 100MHz in HS200 > > - OS boot from eMMC with driver strength changed to Type1 > > - OS boot from eMMC in HS400 without override protocol installed > > - SD card enumeration in UEFI shell on default speed and high speed(non > UHS-I) with SdMmcOverride installed and UHS-I disabled in capability > > - SD card enumeration in UEFI shell on default speed and high speed(non > UHS-I) with no Override protocol(legacy card used) > > > > > > Cc: Hao A Wu > > > > > > Albecki, Mateusz (1): > > MdeModulePkg/SdMmcHcDxe: Implement revision 3 of > SdMmcOverrideProtocol > > > > Mateusz Albecki (1): > > MdeModulePkg/SdMmcOverride: Add GetOperatingParam notify phase > > > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c| 512 > +++-- > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c | 410 > ++--- > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 52 ++- > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 18 +- > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 34 ++ > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 19 + > > MdeModulePkg/Include/Protocol/SdMmcOverride.h | 60 ++- > > 7 files changed, 867 insertions(+), 238 deletions(-) > > > > -- > > 2.14.1.windows.1 > > > > > > > > Intel Technology Poland sp. z o.o. > > ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII > Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957- > 07-52-316 | Kapital zakladowy 200.000 PLN. > > > > Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego > adresata i moze zawierac informacje poufne. W razie przypadkowego > otrzymania tej wiadomosci, prosimy o powiadomienie nadawcy oraz trwale > jej usuniecie; jakiekolwiek > > przegladanie 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 > > others is strictly prohibited. > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42921): https://edk2.groups.io/g/devel/message/42921 Mute This Topic: https://groups.io/mt/32214570/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
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 śr., 26 cze 2019 o 15:10 Albecki, Mateusz napisał(a): > > To allow platform greater control over the bus settings for SD card and eMMC > card we have added a new notify phase to SdMmcOverrideProtocol called > GetOperatingParam. > This phase is signaled before SD card/eMMC initialization and allows platform > to tweak the values in new structure called EDKII_SD_MMC_OPERATING_PARAMETERS > which allows to configure bus width, clock frequency and driver strength. > Other bus parameters can be configured by overriding host controller > capabilities. > > Changes in v2: > - Fixed stylistic issues and documentation issues pointed out in v1 review > - Changed bus width to be UINT8 > - Reordered the SD_MMC_BUS_MODE to fix problem with driver never choosing the > DDR50 speed mode > - Fixed the bug with driver not switching the controller into correct driver > strength for SD card slots > - Fixed bug with the driver not considering driver strength support for SD > card slots > - Fixed bug with driver choosing SdMmcMmcHsSdr if card doesn't support > frequencies above 26MHz > - Fixed bug with driver choosing driver strength for legacy speed modes > > Changes in v3: > - Changed BusWidth field of EDKII_SD_MMC_OPERATING_PARAMETERS to UINT16 > > Changes in v4 > - Fixed typos and ordering in SD_MMC_BUS_MODE(this time for real) > - Fixed non boolean types usage in if statements > - Fixed code that checks if there was an error in switch response for SD > card. The code has been updated to check if switch failed due to function > being busy > > Tests: > - OS boot from eMMC without SdMmcOverride protocol installed > - OS boot from eMMC with SdMmcOverride installed and clock frequency lowered > to 100MHz in HS200 > - OS boot from eMMC with driver strength changed to Type1 > - OS boot from eMMC in HS400 without override protocol installed > - SD card enumeration in UEFI shell on default speed and high speed(non > UHS-I) with SdMmcOverride installed and UHS-I disabled in capability > - SD card enumeration in UEFI shell on default speed and high speed(non > UHS-I) with no Override protocol(legacy card used) > > > Cc: Hao A Wu > > > Albecki, Mateusz (1): > MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol > > Mateusz Albecki (1): > MdeModulePkg/SdMmcOverride: Add GetOperatingParam notify phase > > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c| 512 > +++-- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c | 410 ++--- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 52 ++- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 18 +- > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 34 ++ > MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 19 + > MdeModulePkg/Include/Protocol/SdMmcOverride.h | 60 ++- > 7 files changed, 867 insertions(+), 238 deletions(-) > > -- > 2.14.1.windows.1 > > > > Intel Technology Poland sp. z o.o. > ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII > Wydzial Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP > 957-07-52-316 | Kapital zakladowy 200.000 PLN. > > Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i > moze zawierac informacje poufne. W razie przypadkowego otrzymania tej > wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; > jakiekolwiek > przegladanie 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 > others is strictly prohibited. > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#42920): https://edk2.groups.io/g/devel/message/42920 Mute This Topic: https://groups.io/mt/32214570/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
