Re: [edk2] [PATCH] IntelFsp2Pkg: Remove CarBase and CarSize from FSP_GLOBAL_DATA

[Yao, Jiewen]

Agree to remove car calculation from MSR.
Reviewed-by: jiewen@intel.com


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Satya Yarlagadda
> Sent: Wednesday, July 20, 2016 2:49 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [edk2] [PATCH] IntelFsp2Pkg: Remove CarBase and CarSize from
> FSP_GLOBAL_DATA
> 
> CarBase and CarSize in Fsp Global data strcture are no longer needed as
> Boot loader doesn't pass them to FSP even incase BL chooses to skip calling
> the FspTempRamInit API. Incase of FspTempramInit is called we can use the
> PCDs to identify the CarBase and Size. Hence removeing the relevent code.
> 
> Cc: Giri P Mudusuru 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Satya Yarlagadda 
> ---
>  IntelFsp2Pkg/FspSecCore/SecFsp.c   |  4 +--
>  IntelFsp2Pkg/Include/FspGlobalData.h   |  2 --
>  IntelFsp2Pkg/Include/Library/FspCommonLib.h| 20 ---
>  .../Library/BaseFspCommonLib/FspCommonLib.c| 42
> --
>  4 files changed, 1 insertion(+), 67 deletions(-)
> 
> diff --git a/IntelFsp2Pkg/FspSecCore/SecFsp.c
> b/IntelFsp2Pkg/FspSecCore/SecFsp.c
> index 7259a55..96f8fb7 100644
> --- a/IntelFsp2Pkg/FspSecCore/SecFsp.c
> +++ b/IntelFsp2Pkg/FspSecCore/SecFsp.c
> @@ -76,7 +76,7 @@ SecGetPlatformData (
>//
>// Pointer to the size field
>//
> -  TopOfCar = FspPlatformData->CarBase + FspPlatformData->CarSize;
> +  TopOfCar = PcdGet32(PcdTemporaryRamBase) +
> PcdGet32(PcdTemporaryRamSize);
>StackPtr = (UINT32 *)(TopOfCar - sizeof (UINT32));
> 
>if (*(StackPtr - 1) == FSP_MCUD_SIGNATURE) {
> @@ -140,8 +140,6 @@ FspGlobalDataInit (
>PeiFspData->CoreStack= BootLoaderStack;
>PeiFspData->PerfIdx  = 2;
>PeiFspData->PerfSig  =
> FSP_PERFORMANCE_DATA_SIGNATURE;
> -  PeiFspData->PlatformData.CarBase = AsmReadMsr32 (0x200) & ~(0x6);
> -  PeiFspData->PlatformData.CarSize = ~(AsmReadMsr32(0x201) & ~(0x800))
> + 1;
> 
>SetFspMeasurePoint (FSP_PERF_ID_API_FSP_MEMORY_INIT_ENTRY);
> 
> diff --git a/IntelFsp2Pkg/Include/FspGlobalData.h
> b/IntelFsp2Pkg/Include/FspGlobalData.h
> index a484d16..8ac3199 100644
> --- a/IntelFsp2Pkg/Include/FspGlobalData.h
> +++ b/IntelFsp2Pkg/Include/FspGlobalData.h
> @@ -34,8 +34,6 @@ typedef struct  {
> UINT32 MicrocodeRegionSize;
> UINT32 CodeRegionBase;
> UINT32 CodeRegionSize;
> -   UINT32 CarBase;
> -   UINT32 CarSize;
>  } FSP_PLAT_DATA;
> 
>  #define FSP_GLOBAL_DATA_SIGNATURE  SIGNATURE_32 ('F', 'S', 'P', 'D')
> diff --git a/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> b/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> index 231f1e4..5f7a14b 100644
> --- a/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> +++ b/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> @@ -290,26 +290,6 @@ SetPhaseStatusCode (
>);
> 
>  /**
> -  This function gets FSP CAR base.
> -
> -**/
> -UINT32
> -EFIAPI
> -GetFspCarBase (
> -  VOID
> -  );
> -
> -/**
> -  This function gets FSP CAR size.
> -
> -**/
> -UINT32
> -EFIAPI
> -GetFspCarSize (
> -  VOID
> -  );
> -
> -/**
>This function updates the return status of the FSP API with requested
> reset type and returns to Boot Loader.
> 
>@param[in] FspResetType Reset type that needs to returned as API
> return status
> diff --git a/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> b/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> index 0c5f0b3..660e9fc 100644
> --- a/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> +++ b/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> @@ -505,48 +505,6 @@ SetPhaseStatusCode (
>  }
> 
>  /**
> -  This function gets FSP CAR base.
> -
> -**/
> -UINT32
> -EFIAPI
> -GetFspCarBase (
> -  VOID
> -  )
> -{
> -  FSP_GLOBAL_DATA  *FspData;
> -  UINT32   CarBase;
> -
> -  FspData  = GetFspGlobalDataPointer ();
> -  CarBase = FspData->PlatformData.CarBase;
> -  if (CarBase == 0) {
> -CarBase = PcdGet32(PcdTemporaryRamBase);
> -  }
> -  return CarBase;
> -}
> -
> -/**
> -  This function gets FSP CAR size.
> -
> -**/
> -UINT32
> -EFIAPI
> -GetFspCarSize (
> -  VOID
> -  )
> -{
> -  FSP_GLOBAL_DATA  *FspData;
> -  UINT32   CarSize;
> -
> -  FspData  = GetFspGlobalDataPointer ();
> -  CarSize = FspData->PlatformData.CarSize;
> -  if (FspData->PlatformData.CarBase == 0) {
> -CarSize = PcdGet32(PcdTemporaryRamSize);
> -  }
> -  return CarSize;
> -}
> -
> -/**
>This function updates the return status of the FSP API with requested
> reset type and returns to Boot Loader.
> 
>@param[in] FspResetType Reset type that needs to returned as API
> return status
> --
> 2.9.2.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___

Re: [edk2] [PATCH] IntelFsp2Pkg: Remove CarBase and CarSize from FSP_GLOBAL_DATA

[Mudusuru, Giri P]

Please fix typos in the comments.
Reviewed-by: Giri P Mudusuru  

> -Original Message-
> From: Yarlagadda, Satya P
> Sent: Tuesday, July 19, 2016 11:49 PM
> To: edk2-devel@lists.01.org
> Cc: Mudusuru, Giri P ; Yao, Jiewen
> 
> Subject: [PATCH] IntelFsp2Pkg: Remove CarBase and CarSize from
> FSP_GLOBAL_DATA
> 
> CarBase and CarSize in Fsp Global data strcture are no longer needed as
> Boot loader doesn't pass them to FSP even incase BL chooses to skip calling 
> the
> FspTempRamInit API. Incase of FspTempramInit is called we can use the PCDs to
> identify the CarBase and Size. Hence removeing the relevent code.
> 
> Cc: Giri P Mudusuru 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Satya Yarlagadda 
> ---
>  IntelFsp2Pkg/FspSecCore/SecFsp.c   |  4 +--
>  IntelFsp2Pkg/Include/FspGlobalData.h   |  2 --
>  IntelFsp2Pkg/Include/Library/FspCommonLib.h| 20 ---
>  .../Library/BaseFspCommonLib/FspCommonLib.c| 42 
> --
>  4 files changed, 1 insertion(+), 67 deletions(-)
> 
> diff --git a/IntelFsp2Pkg/FspSecCore/SecFsp.c
> b/IntelFsp2Pkg/FspSecCore/SecFsp.c
> index 7259a55..96f8fb7 100644
> --- a/IntelFsp2Pkg/FspSecCore/SecFsp.c
> +++ b/IntelFsp2Pkg/FspSecCore/SecFsp.c
> @@ -76,7 +76,7 @@ SecGetPlatformData (
>//
>// Pointer to the size field
>//
> -  TopOfCar = FspPlatformData->CarBase + FspPlatformData->CarSize;
> +  TopOfCar = PcdGet32(PcdTemporaryRamBase) +
> PcdGet32(PcdTemporaryRamSize);
>StackPtr = (UINT32 *)(TopOfCar - sizeof (UINT32));
> 
>if (*(StackPtr - 1) == FSP_MCUD_SIGNATURE) {
> @@ -140,8 +140,6 @@ FspGlobalDataInit (
>PeiFspData->CoreStack= BootLoaderStack;
>PeiFspData->PerfIdx  = 2;
>PeiFspData->PerfSig  = FSP_PERFORMANCE_DATA_SIGNATURE;
> -  PeiFspData->PlatformData.CarBase = AsmReadMsr32 (0x200) & ~(0x6);
> -  PeiFspData->PlatformData.CarSize = ~(AsmReadMsr32(0x201) & ~(0x800)) + 1;
> 
>SetFspMeasurePoint (FSP_PERF_ID_API_FSP_MEMORY_INIT_ENTRY);
> 
> diff --git a/IntelFsp2Pkg/Include/FspGlobalData.h
> b/IntelFsp2Pkg/Include/FspGlobalData.h
> index a484d16..8ac3199 100644
> --- a/IntelFsp2Pkg/Include/FspGlobalData.h
> +++ b/IntelFsp2Pkg/Include/FspGlobalData.h
> @@ -34,8 +34,6 @@ typedef struct  {
> UINT32 MicrocodeRegionSize;
> UINT32 CodeRegionBase;
> UINT32 CodeRegionSize;
> -   UINT32 CarBase;
> -   UINT32 CarSize;
>  } FSP_PLAT_DATA;
> 
>  #define FSP_GLOBAL_DATA_SIGNATURE  SIGNATURE_32 ('F', 'S', 'P', 'D')
> diff --git a/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> b/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> index 231f1e4..5f7a14b 100644
> --- a/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> +++ b/IntelFsp2Pkg/Include/Library/FspCommonLib.h
> @@ -290,26 +290,6 @@ SetPhaseStatusCode (
>);
> 
>  /**
> -  This function gets FSP CAR base.
> -
> -**/
> -UINT32
> -EFIAPI
> -GetFspCarBase (
> -  VOID
> -  );
> -
> -/**
> -  This function gets FSP CAR size.
> -
> -**/
> -UINT32
> -EFIAPI
> -GetFspCarSize (
> -  VOID
> -  );
> -
> -/**
>This function updates the return status of the FSP API with requested 
> reset type
> and returns to Boot Loader.
> 
>@param[in] FspResetType Reset type that needs to returned as API return
> status
> diff --git a/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> b/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> index 0c5f0b3..660e9fc 100644
> --- a/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> +++ b/IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c
> @@ -505,48 +505,6 @@ SetPhaseStatusCode (
>  }
> 
>  /**
> -  This function gets FSP CAR base.
> -
> -**/
> -UINT32
> -EFIAPI
> -GetFspCarBase (
> -  VOID
> -  )
> -{
> -  FSP_GLOBAL_DATA  *FspData;
> -  UINT32   CarBase;
> -
> -  FspData  = GetFspGlobalDataPointer ();
> -  CarBase = FspData->PlatformData.CarBase;
> -  if (CarBase == 0) {
> -CarBase = PcdGet32(PcdTemporaryRamBase);
> -  }
> -  return CarBase;
> -}
> -
> -/**
> -  This function gets FSP CAR size.
> -
> -**/
> -UINT32
> -EFIAPI
> -GetFspCarSize (
> -  VOID
> -  )
> -{
> -  FSP_GLOBAL_DATA  *FspData;
> -  UINT32   CarSize;
> -
> -  FspData  = GetFspGlobalDataPointer ();
> -  CarSize = FspData->PlatformData.CarSize;
> -  if (FspData->PlatformData.CarBase == 0) {
> -CarSize = PcdGet32(PcdTemporaryRamSize);
> -  }
> -  return CarSize;
> -}
> -
> -/**
>This function updates the return status of the FSP API with requested 
> reset type
> and returns to Boot Loader.
> 
>@param[in] FspResetType Reset type that needs to returned as API return
> status
> --
> 2.9.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question on eMMC and SD driver

[Haojian Zhuang]

在 07/21/2016 11:23 AM, Tian, Feng 写道:

Hi, Haojian

If there is no PCI bus, you could implement a fake one. Just like what we did 
at edk2\Omap35xxPkg\PciEmulation. Through this way, you can reuse SdMmcPciHc 
driver.



Oh, your eMMC/SD IP is compatible SDHC. But Designware eMMC/SD IP isn't 
compatible to SDHC. So I can't reuse SdMmcPciHc driver in my platform.


Best Regards
Haojian
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v1 1/1] BaseTools/toolsetup: Do not set CONF_PATH when already set.

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu  

Best Regards,
Zhu Yonghong


-Original Message-
From: Marvin Häuser [mailto:marvin.haeu...@outlook.com] 
Sent: Wednesday, July 20, 2016 11:02 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming ; Zhu, Yonghong 
Subject: [PATCH v1 1/1] BaseTools/toolsetup: Do not set CONF_PATH when already 
set.

When CONF_PATH is already set, toolsetup.bat overwrites its value.
This is not the case on Linux platforms (BuildEnv) and contra-productive when 
using the same Workspace across multiple Operating Systems.
With this patch, a check is performed prior to setting the variable.
Furthermore, it will not be scanned for Conf directories in PACKAGES_PATH 
directories to respect the user's choice.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 BaseTools/toolsetup.bat | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/BaseTools/toolsetup.bat b/BaseTools/toolsetup.bat index 
76fd8bb6ef9e..c1ab9bcc8d33 100755
--- a/BaseTools/toolsetup.bat
+++ b/BaseTools/toolsetup.bat
@@ -160,13 +160,16 @@ if not defined WORKSPACE (
goto skip_reconfig
 )
 
-set CONF_PATH=%WORKSPACE%\Conf
-if NOT exist %CONF_PATH% (
-  if defined PACKAGES_PATH (
-for %%i IN (%PACKAGES_PATH%) DO (
-  if exist %%~fi\Conf (
-set CONF_PATH=%%i\Conf
-goto CopyConf
+if not defined CONF_PATH (
+  set CONF_PATH=%WORKSPACE%\Conf
+
+  if NOT exist %CONF_PATH% (
+if defined PACKAGES_PATH (
+  for %%i IN (%PACKAGES_PATH%) DO (
+if exist %%~fi\Conf (
+  set CONF_PATH=%%i\Conf
+  goto CopyConf
+)
   )
 )
   )
--
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question on eMMC and SD driver

[Andrew Fish]

> On Jul 20, 2016, at 8:59 PM, Haojian Zhuang  wrote:
> 
> 
> 
> 在 07/21/2016 11:41 AM, Andrew Fish 写道:
>> 
>>> On Jul 20, 2016, at 8:23 PM, Tian, Feng  wrote:
>>> 
>>> Hi, Haojian
>>> 
>>> If there is no PCI bus, you could implement a fake one. Just like what we 
>>> did at edk2\Omap35xxPkg\PciEmulation. Through this way, you can reuse 
>>> SdMmcPciHc driver.
>>> 
>>> For your questions:
>>> 1. The EDKII SD/MMC stack (SdMmcPciHc plus SdDxe and EmmcDxe) is used to 
>>> manage all SD & MMC host controllers & cards. Each SD & MMC host controller 
>>> would be installed a EFI_SD_MMC_PASS_THRU_PROTOCOL instance. We distinguish 
>>> the card types by identification process defined in SD & EMMC spec. after 
>>> that, we will install different device paths through which upper layer 
>>> could distinguish them.
>>> 
>>> For SD host controller, the device path is Pci(x, x)\Sd(x). for EMMC host 
>>> controller, the device path is Pci(x, x)\EMMC(x)\Ctrl(x). why we appended a 
>>> Ctrl(x) device node to EMMC device path is because EMMC device has many 
>>> partitions (User Data Area, BOOT1&2, GP1&2&3&4, RPMB). We use Ctrl(x) to 
>>> distinguish the partitions. But SD is different story, it has no 
>>> partitions, so we just produce Pci(x, x)\Sd(x) to distinguish different SD 
>>> HCs if they exist.
>>> 
>>> 2. Just like I said above, EmmcDxe driver only runs on EMMC HCs/devices. 
>>> That's the way how SdMmcPciHc works.
>>> 
>>> 3. I don't quite understand your question. The EmmcDxe driver produces 
>>> BlockIo on its partitions. Then DiskIo driver will be connected. (see UEFI 
>>> spec driver model chapter)
>>> As for remaining device path, it must to be a EMMC device path otherwise 
>>> DriverBindingSupported() will not succeed. It means EMMC driver binding 
>>> start() would not run at all for such device path.
>>> 
>>> 4. I don't know your use case. But in the first glance, it doesn't make 
>>> sense. How could you SD driver depends on a variable service? Could you 
>>> clarify more?
>>> 
>> 
>> I would also point out that a UEFI_DRIVER by definition will only be loaded 
>> when all the EFI services are available. So no Depex does not mean run right 
>> away it means you depend on all the architectural protocols
>> 
>> This is the list of architectural protocols:
>> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c#L27
>> 
>> EFI_CORE_PROTOCOL_NOTIFY_ENTRY  mArchProtocols[] = {
>>  { &gEfiSecurityArchProtocolGuid, (VOID **)&gSecurity,  NULL, 
>> NULL, FALSE },
>>  { &gEfiCpuArchProtocolGuid,  (VOID **)&gCpu,   NULL, 
>> NULL, FALSE },
>>  { &gEfiMetronomeArchProtocolGuid,(VOID **)&gMetronome, NULL, 
>> NULL, FALSE },
>>  { &gEfiTimerArchProtocolGuid,(VOID **)&gTimer, NULL, 
>> NULL, FALSE },
>>  { &gEfiBdsArchProtocolGuid,  (VOID **)&gBds,   NULL, 
>> NULL, FALSE },
>>  { &gEfiWatchdogTimerArchProtocolGuid,(VOID **)&gWatchdogTimer, NULL, 
>> NULL, FALSE },
>>  { &gEfiRuntimeArchProtocolGuid,  (VOID **)&gRuntime,   NULL, 
>> NULL, FALSE },
>>  { &gEfiVariableArchProtocolGuid, (VOID **)NULL,NULL, 
>> NULL, FALSE },
>>  { &gEfiVariableWriteArchProtocolGuid,(VOID **)NULL,NULL, 
>> NULL, FALSE },
>>  { &gEfiCapsuleArchProtocolGuid,  (VOID **)NULL,NULL, 
>> NULL, FALSE },
>>  { &gEfiMonotonicCounterArchProtocolGuid, (VOID **)NULL,NULL, 
>> NULL, FALSE },
>>  { &gEfiResetArchProtocolGuid,(VOID **)NULL,NULL, 
>> NULL, FALSE },
>>  { &gEfiRealTimeClockArchProtocolGuid,(VOID **)NULL,NULL, 
>> NULL, FALSE },
>>  { NULL,  (VOID **)NULL,NULL, 
>> NULL, FALSE }
>> };
>> 
>> This is the code that handles the NO Depex case.
>> 
>> https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dispatcher/Dependency.c#L236
>> 
>>  if (DriverEntry->Depex == NULL) {
>>//
>>// A NULL Depex means treat the driver like an UEFI 2.0 thing.
>>//
>>Status = CoreAllEfiServicesAvailable ();
>>DEBUG ((DEBUG_DISPATCH, "  All UEFI Services Available
>>  = "));
>>if (EFI_ERROR (Status)) {
>>  DEBUG ((DEBUG_DISPATCH, "FALSE\n  RESULT = FALSE\n"));
>>  return FALSE;
>>}
>>DEBUG ((DEBUG_DISPATCH, "TRUE\n  RESULT = TRUE\n"));
>>return TRUE;
>>  }
>> 
>> 
>> Trying to store the EFI Variables on the EMMC card is probably not going to 
>> really work.
>> 
> 
> Yes, I have to hack it as DXE_DRIVER instead. But both EmmcDxe and PciBusDxe 
> are UEFI_DRIVER. If I submit a patch to only change EmmcDxe driver to 
> DXE_DRIVER, I doubt that it'll break other platforms.
> 
> What's the suggestion on this?
> 

The Variable stack should be a DXE_RUNTIME_DRIVER as it produces services used 
by the OS. I don't know how your driver and the OS EMMC driver can coexist. 
https://github.com/tianocore/edk2/bl

Re: [edk2] Question on eMMC and SD driver

[Haojian Zhuang]

在 07/21/2016 11:41 AM, Andrew Fish 写道:



On Jul 20, 2016, at 8:23 PM, Tian, Feng  wrote:

Hi, Haojian

If there is no PCI bus, you could implement a fake one. Just like what we did 
at edk2\Omap35xxPkg\PciEmulation. Through this way, you can reuse SdMmcPciHc 
driver.

For your questions:
1. The EDKII SD/MMC stack (SdMmcPciHc plus SdDxe and EmmcDxe) is used to manage all SD & 
MMC host controllers & cards. Each SD & MMC host controller would be installed a 
EFI_SD_MMC_PASS_THRU_PROTOCOL instance. We distinguish the card types by identification process 
defined in SD & EMMC spec. after that, we will install different device paths through which 
upper layer could distinguish them.

For SD host controller, the device path is Pci(x, x)\Sd(x). for EMMC host controller, the 
device path is Pci(x, x)\EMMC(x)\Ctrl(x). why we appended a Ctrl(x) device node to EMMC device 
path is because EMMC device has many partitions (User Data Area, BOOT1&2, 
GP1&2&3&4, RPMB). We use Ctrl(x) to distinguish the partitions. But SD is different 
story, it has no partitions, so we just produce Pci(x, x)\Sd(x) to distinguish different SD HCs 
if they exist.

2. Just like I said above, EmmcDxe driver only runs on EMMC HCs/devices. That's 
the way how SdMmcPciHc works.

3. I don't quite understand your question. The EmmcDxe driver produces BlockIo 
on its partitions. Then DiskIo driver will be connected. (see UEFI spec driver 
model chapter)
As for remaining device path, it must to be a EMMC device path otherwise 
DriverBindingSupported() will not succeed. It means EMMC driver binding start() 
would not run at all for such device path.

4. I don't know your use case. But in the first glance, it doesn't make sense. 
How could you SD driver depends on a variable service? Could you clarify more?



I would also point out that a UEFI_DRIVER by definition will only be loaded 
when all the EFI services are available. So no Depex does not mean run right 
away it means you depend on all the architectural protocols

This is the list of architectural protocols:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c#L27

EFI_CORE_PROTOCOL_NOTIFY_ENTRY  mArchProtocols[] = {
  { &gEfiSecurityArchProtocolGuid, (VOID **)&gSecurity,  NULL, 
NULL, FALSE },
  { &gEfiCpuArchProtocolGuid,  (VOID **)&gCpu,   NULL, 
NULL, FALSE },
  { &gEfiMetronomeArchProtocolGuid,(VOID **)&gMetronome, NULL, 
NULL, FALSE },
  { &gEfiTimerArchProtocolGuid,(VOID **)&gTimer, NULL, 
NULL, FALSE },
  { &gEfiBdsArchProtocolGuid,  (VOID **)&gBds,   NULL, 
NULL, FALSE },
  { &gEfiWatchdogTimerArchProtocolGuid,(VOID **)&gWatchdogTimer, NULL, 
NULL, FALSE },
  { &gEfiRuntimeArchProtocolGuid,  (VOID **)&gRuntime,   NULL, 
NULL, FALSE },
  { &gEfiVariableArchProtocolGuid, (VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiVariableWriteArchProtocolGuid,(VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiCapsuleArchProtocolGuid,  (VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiMonotonicCounterArchProtocolGuid, (VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiResetArchProtocolGuid,(VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiRealTimeClockArchProtocolGuid,(VOID **)NULL,NULL, 
NULL, FALSE },
  { NULL,  (VOID **)NULL,NULL, 
NULL, FALSE }
};

This is the code that handles the NO Depex case.

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dispatcher/Dependency.c#L236

  if (DriverEntry->Depex == NULL) {
//
// A NULL Depex means treat the driver like an UEFI 2.0 thing.
//
Status = CoreAllEfiServicesAvailable ();
DEBUG ((DEBUG_DISPATCH, "  All UEFI Services Available = 
"));
if (EFI_ERROR (Status)) {
  DEBUG ((DEBUG_DISPATCH, "FALSE\n  RESULT = FALSE\n"));
  return FALSE;
}
DEBUG ((DEBUG_DISPATCH, "TRUE\n  RESULT = TRUE\n"));
return TRUE;
  }


Trying to store the EFI Variables on the EMMC card is probably not going to 
really work.



Yes, I have to hack it as DXE_DRIVER instead. But both EmmcDxe and 
PciBusDxe are UEFI_DRIVER. If I submit a patch to only change EmmcDxe 
driver to DXE_DRIVER, I doubt that it'll break other platforms.


What's the suggestion on this?

Best Regards
Haojian
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Resolve IA32 ARCH VS2015 build error in NetworkPkg

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Hao Wu
> Sent: Thursday, July 21, 2016 11:51 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A 
> Subject: [edk2] [PATCH 0/2] Resolve IA32 ARCH VS2015 build error in
> NetworkPkg
> 
> When using the following version of compiler in VS2015:
> Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86
> 
> The IA32 ARCH build will meet "unresolved external symbol __allmul" build
> errors. They are caused by calls to the gBS->SetTimer() function.
> 
> Now, when the third parameter for gBS->SetTimer() is get by a
> multiplication, we need to explictly use the MultU64x32/MultU64x64
> functions.
> 
> Hao Wu (2):
>   NetworkPkg IScsiDxe: Fix build error for lastest VS2015 compiler
>   NetworkPkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler
> 
>  NetworkPkg/IScsiDxe/IScsiProto.c| 6 +-
>  NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c | 4 ++--
>  2 files changed, 7 insertions(+), 3 deletions(-)
> 
> --
> 1.9.5.msysgit.0
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 1/2] NetworkPkg IScsiDxe: Fix build error for lastest VS2015 compiler

[Hao Wu]

The IScsiDxe module encounters a build error for IA32 arch using the
latest version of VS2015:

IScsiDxe.lib(IScsiProto.obj) : error LNK2001: unresolved external symbol
__allmul

The cause is line 141 in file NetworkPkg\IScsiDxe\IScsiProto.c. The third
parameter for gBS->SetTimer() function is of type UINT64, so the
multiplication should use the MultU64x32() function now.

Cc: Siyuan Fu 
Cc: Jiaxin Wu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 NetworkPkg/IScsiDxe/IScsiProto.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/NetworkPkg/IScsiDxe/IScsiProto.c b/NetworkPkg/IScsiDxe/IScsiProto.c
index c82290e..5092365 100644
--- a/NetworkPkg/IScsiDxe/IScsiProto.c
+++ b/NetworkPkg/IScsiDxe/IScsiProto.c
@@ -138,7 +138,11 @@ IScsiConnLogin (
   //
   // Start the timer, and wait Timeout seconds to establish the TCP connection.
   //
-  Status = gBS->SetTimer (Conn->TimeoutEvent, TimerRelative, Timeout * 
TICKS_PER_MS);
+  Status = gBS->SetTimer (
+  Conn->TimeoutEvent,
+  TimerRelative,
+  MultU64x32 (Timeout, TICKS_PER_MS)
+  );
   if (EFI_ERROR (Status)) {
 return Status;
   }
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 0/2] Resolve IA32 ARCH VS2015 build error in NetworkPkg

[Hao Wu]

When using the following version of compiler in VS2015:
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24210 for x86

The IA32 ARCH build will meet "unresolved external symbol __allmul" build
errors. They are caused by calls to the gBS->SetTimer() function.

Now, when the third parameter for gBS->SetTimer() is get by a
multiplication, we need to explictly use the MultU64x32/MultU64x64
functions.

Hao Wu (2):
  NetworkPkg IScsiDxe: Fix build error for lastest VS2015 compiler
  NetworkPkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler

 NetworkPkg/IScsiDxe/IScsiProto.c| 6 +-
 NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c | 4 ++--
 2 files changed, 7 insertions(+), 3 deletions(-)

-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH 2/2] NetworkPkg UefiPxeBcDxe: Fix build error for lastest VS2015 compiler

[Hao Wu]

The UefiPxeBcDxe module encounters a build error for IA32 arch using the
latest version of VS2015:

UefiPxeBcDxe.lib(PxeBcBoot.obj) : error LNK2001: unresolved external
symbol __allmul

The cause is line 148 in file NetworkPkg\UefiPxeBcDxe\PxeBcBoot.c. The
third parameter for gBS->SetTimer() function is of type UINT64, so the
multiplication should use the MultU64x32() function now.

Cc: Siyuan Fu 
Cc: Jiaxin Wu 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c 
b/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
index 5be82dc..8eff13c 100644
--- a/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
+++ b/NetworkPkg/UefiPxeBcDxe/PxeBcBoot.c
@@ -1,7 +1,7 @@
 /** @file
   Boot functions implementation for UefiPxeBc Driver.
 
-  Copyright (c) 2009 - 2014, Intel Corporation. All rights reserved.
+  Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved.
   (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 
   This program and the accompanying materials
@@ -145,7 +145,7 @@ PxeBcSelectBootPrompt (
   Status = gBS->SetTimer (
   TimeoutEvent,
   TimerRelative,
-  Timeout * TICKS_PER_SECOND
+  MultU64x32 (Timeout, TICKS_PER_SECOND)
   );
   if (EFI_ERROR (Status)) {
 goto ON_EXIT;
-- 
1.9.5.msysgit.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question on eMMC and SD driver

[Haojian Zhuang]

Hi Feng,

I appended my comments in below.

Best Regards
Haojian

在 07/21/2016 11:23 AM, Tian, Feng 写道:

Hi, Haojian

If there is no PCI bus, you could implement a fake one. Just like what we did 
at edk2\Omap35xxPkg\PciEmulation. Through this way, you can reuse SdMmcPciHc 
driver.

For your questions:
1. The EDKII SD/MMC stack (SdMmcPciHc plus SdDxe and EmmcDxe) is used to manage all SD & 
MMC host controllers & cards. Each SD & MMC host controller would be installed a 
EFI_SD_MMC_PASS_THRU_PROTOCOL instance. We distinguish the card types by identification process 
defined in SD & EMMC spec. after that, we will install different device paths through which 
upper layer could distinguish them.

For SD host controller, the device path is Pci(x, x)\Sd(x). for EMMC host controller, the 
device path is Pci(x, x)\EMMC(x)\Ctrl(x). why we appended a Ctrl(x) device node to EMMC device 
path is because EMMC device has many partitions (User Data Area, BOOT1&2, 
GP1&2&3&4, RPMB). We use Ctrl(x) to distinguish the partitions. But SD is different 
story, it has no partitions, so we just produce Pci(x, x)\Sd(x) to distinguish different SD HCs 
if they exist.


I think that there's also partition in SD card. 
(http://forum.xda-developers.com/wiki/SD_card_partitioning)




2. Just like I said above, EmmcDxe driver only runs on EMMC HCs/devices. That's 
the way how SdMmcPciHc works.

3. I don't quite understand your question. The EmmcDxe driver produces BlockIo 
on its partitions. Then DiskIo driver will be connected. (see UEFI spec driver 
model chapter)
As for remaining device path, it must to be a EMMC device path otherwise 
DriverBindingSupported() will not succeed. It means EMMC driver binding start() 
would not run at all for such device path.


I think so. But it didn't run as my expected.



4. I don't know your use case. But in the first glance, it doesn't make sense. 
How could you SD driver depends on a variable service? Could you clarify more?


In the HiKey platform, there's no NOR flash. I store all system 
variables into eMMC partition. So BlockVariableDxe is created to access 
variables on block devices.




Thanks
Feng

-Original Message-
From: Haojian Zhuang [mailto:haojian.zhu...@linaro.org]
Sent: Thursday, July 21, 2016 10:34 AM
To: Tian, Feng 
Cc: Leif Lindholm ; Ard Biesheuvel 
; edk2-devel@lists.01.org
Subject: [edk2] Question on eMMC and SD driver

Hi all,

I have a few questions on eMMC/SD driver when I'm working on my driver.

In my hikey platform, there's no PCI bus. So I create my own DwMmc driver to do 
the same thing as SdMmcPciHcDxe driver. There's one controller for eMMC and one 
controller for SD.

1. How to support both eMMC and SD driver in the same driver? The IP is 
designed for both eMMC/SD. If we could share the same driver, we could use 
common code.
I tried to follow SdMmcPciHcDxe driver. I use "Emmc(0)/Ctrl(0)" to indicate the device 
path of eMMC controller. And I should use "Sd(0)/Ctrl(1)" to indicate the device path of 
SD controller. Is it right?

When I tried to access one partition, I use this device path 
"Emmc(0)/Ctrl(0)/HD(5,GPT,00354BCD-BBCB-4CB3-B5AE-CDEFCB5DAC43)". Is it right?


2. When RemainingDevicePath variable is valid, GetSlotNumber() is called in 
both EmmcDxe and SdDxe. But how could DwMmc driver knows which stack is calling 
it? Does it mean that I need to implement two different 
EFI_SD_MMC_PASS_THRU_PROTOCOL interfaces? One is for eMMC, and the other one is 
for SD.


3. How to create the connection DiskIo and eMMC?
When RemainingDevicePath variable is valid, GetSlotNumber() is invoked in 
EmmcDxeDriverBindingStart(). But where RemainingDevicePath is set?
When I debug code, I got this debug message in below.
#EmmcDxeDriverBindingStart, 909, Remain
path:VenHw(CE660500-824D-11E0-AC72-0002A5D5C51B)

The CE660500 belongs to LcdGraphicsOutputDxe. And I didn't build it into the 
firmware at all. I don't know where it comes from.
If I check the eMMC device path in GetSlotNumber(), I'll skip it and DiskIo 
won't run successfully. So partition checking won't run in DiskIo. If I force 
the GetSlotNumber() empty to pass this RemainingDevicePath, partition checking 
could run in DiskIo.
I guess that something is missing between DiskIo and eMMC driver. Do you have 
any idea on this? This issue blocks me to enable multiple slots.


4. Driver dependency. EmmcDxe and SdDxe are both UEFI_DRIVER.
VariableRuntimeDxe Driver is DXE_RUNTIME_DRIVER. But the dependency is in below.

EmmcDxe --->  DwMmcDxe ---> BlockVariableDxe ---> VariableRuntimeDxe

Now I hack EmmcDxe from UEFI_DRIVER to DXE_RUNTIME to make this dependency 
working. Is there any other solution without hacking?

Best Regards
Haojian


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Question on eMMC and SD driver

[Andrew Fish]

> On Jul 20, 2016, at 8:23 PM, Tian, Feng  wrote:
> 
> Hi, Haojian
> 
> If there is no PCI bus, you could implement a fake one. Just like what we did 
> at edk2\Omap35xxPkg\PciEmulation. Through this way, you can reuse SdMmcPciHc 
> driver.
> 
> For your questions:
> 1. The EDKII SD/MMC stack (SdMmcPciHc plus SdDxe and EmmcDxe) is used to 
> manage all SD & MMC host controllers & cards. Each SD & MMC host controller 
> would be installed a EFI_SD_MMC_PASS_THRU_PROTOCOL instance. We distinguish 
> the card types by identification process defined in SD & EMMC spec. after 
> that, we will install different device paths through which upper layer could 
> distinguish them.
> 
> For SD host controller, the device path is Pci(x, x)\Sd(x). for EMMC host 
> controller, the device path is Pci(x, x)\EMMC(x)\Ctrl(x). why we appended a 
> Ctrl(x) device node to EMMC device path is because EMMC device has many 
> partitions (User Data Area, BOOT1&2, GP1&2&3&4, RPMB). We use Ctrl(x) to 
> distinguish the partitions. But SD is different story, it has no partitions, 
> so we just produce Pci(x, x)\Sd(x) to distinguish different SD HCs if they 
> exist.
> 
> 2. Just like I said above, EmmcDxe driver only runs on EMMC HCs/devices. 
> That's the way how SdMmcPciHc works.
> 
> 3. I don't quite understand your question. The EmmcDxe driver produces 
> BlockIo on its partitions. Then DiskIo driver will be connected. (see UEFI 
> spec driver model chapter)
> As for remaining device path, it must to be a EMMC device path otherwise 
> DriverBindingSupported() will not succeed. It means EMMC driver binding 
> start() would not run at all for such device path.
> 
> 4. I don't know your use case. But in the first glance, it doesn't make 
> sense. How could you SD driver depends on a variable service? Could you 
> clarify more?
> 

I would also point out that a UEFI_DRIVER by definition will only be loaded 
when all the EFI services are available. So no Depex does not mean run right 
away it means you depend on all the architectural protocols 

This is the list of architectural protocols:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/DxeMain/DxeProtocolNotify.c#L27

EFI_CORE_PROTOCOL_NOTIFY_ENTRY  mArchProtocols[] = {
  { &gEfiSecurityArchProtocolGuid, (VOID **)&gSecurity,  NULL, 
NULL, FALSE },
  { &gEfiCpuArchProtocolGuid,  (VOID **)&gCpu,   NULL, 
NULL, FALSE },
  { &gEfiMetronomeArchProtocolGuid,(VOID **)&gMetronome, NULL, 
NULL, FALSE },
  { &gEfiTimerArchProtocolGuid,(VOID **)&gTimer, NULL, 
NULL, FALSE },
  { &gEfiBdsArchProtocolGuid,  (VOID **)&gBds,   NULL, 
NULL, FALSE },
  { &gEfiWatchdogTimerArchProtocolGuid,(VOID **)&gWatchdogTimer, NULL, 
NULL, FALSE },
  { &gEfiRuntimeArchProtocolGuid,  (VOID **)&gRuntime,   NULL, 
NULL, FALSE },
  { &gEfiVariableArchProtocolGuid, (VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiVariableWriteArchProtocolGuid,(VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiCapsuleArchProtocolGuid,  (VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiMonotonicCounterArchProtocolGuid, (VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiResetArchProtocolGuid,(VOID **)NULL,NULL, 
NULL, FALSE },
  { &gEfiRealTimeClockArchProtocolGuid,(VOID **)NULL,NULL, 
NULL, FALSE },
  { NULL,  (VOID **)NULL,NULL, 
NULL, FALSE }
};

This is the code that handles the NO Depex case.

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Core/Dxe/Dispatcher/Dependency.c#L236

  if (DriverEntry->Depex == NULL) {
//
// A NULL Depex means treat the driver like an UEFI 2.0 thing.
//
Status = CoreAllEfiServicesAvailable ();
DEBUG ((DEBUG_DISPATCH, "  All UEFI Services Available 
= "));
if (EFI_ERROR (Status)) {
  DEBUG ((DEBUG_DISPATCH, "FALSE\n  RESULT = FALSE\n"));
  return FALSE;
}
DEBUG ((DEBUG_DISPATCH, "TRUE\n  RESULT = TRUE\n"));
return TRUE;
  }


Trying to store the EFI Variables on the EMMC card is probably not going to 
really work. 

Thanks,

Andrew Fish

> Thanks
> Feng
> 
> -Original Message-
> From: Haojian Zhuang [mailto:haojian.zhu...@linaro.org] 
> Sent: Thursday, July 21, 2016 10:34 AM
> To: Tian, Feng 
> Cc: Leif Lindholm ; Ard Biesheuvel 
> ; edk2-devel@lists.01.org
> Subject: [edk2] Question on eMMC and SD driver
> 
> Hi all,
> 
> I have a few questions on eMMC/SD driver when I'm working on my driver.
> 
> In my hikey platform, there's no PCI bus. So I create my own DwMmc driver to 
> do the same thing as SdMmcPciHcDxe driver. There's one controller for eMMC 
> and one controller for SD.
> 
> 1. How to support both eMMC and SD driver in the same driver? The IP is 
> designed for both eMMC/SD. If we could share the same driver, we could use 
> common code.
> I tried to follow SdMmcPciHcDx

Re: [edk2] Question on eMMC and SD driver

[Tian, Feng]

Hi, Haojian

If there is no PCI bus, you could implement a fake one. Just like what we did 
at edk2\Omap35xxPkg\PciEmulation. Through this way, you can reuse SdMmcPciHc 
driver.

For your questions:
1. The EDKII SD/MMC stack (SdMmcPciHc plus SdDxe and EmmcDxe) is used to manage 
all SD & MMC host controllers & cards. Each SD & MMC host controller would be 
installed a EFI_SD_MMC_PASS_THRU_PROTOCOL instance. We distinguish the card 
types by identification process defined in SD & EMMC spec. after that, we will 
install different device paths through which upper layer could distinguish them.

For SD host controller, the device path is Pci(x, x)\Sd(x). for EMMC host 
controller, the device path is Pci(x, x)\EMMC(x)\Ctrl(x). why we appended a 
Ctrl(x) device node to EMMC device path is because EMMC device has many 
partitions (User Data Area, BOOT1&2, GP1&2&3&4, RPMB). We use Ctrl(x) to 
distinguish the partitions. But SD is different story, it has no partitions, so 
we just produce Pci(x, x)\Sd(x) to distinguish different SD HCs if they exist.

2. Just like I said above, EmmcDxe driver only runs on EMMC HCs/devices. That's 
the way how SdMmcPciHc works.

3. I don't quite understand your question. The EmmcDxe driver produces BlockIo 
on its partitions. Then DiskIo driver will be connected. (see UEFI spec driver 
model chapter)
As for remaining device path, it must to be a EMMC device path otherwise 
DriverBindingSupported() will not succeed. It means EMMC driver binding start() 
would not run at all for such device path.

4. I don't know your use case. But in the first glance, it doesn't make sense. 
How could you SD driver depends on a variable service? Could you clarify more?

Thanks
Feng

-Original Message-
From: Haojian Zhuang [mailto:haojian.zhu...@linaro.org] 
Sent: Thursday, July 21, 2016 10:34 AM
To: Tian, Feng 
Cc: Leif Lindholm ; Ard Biesheuvel 
; edk2-devel@lists.01.org
Subject: [edk2] Question on eMMC and SD driver

Hi all,

I have a few questions on eMMC/SD driver when I'm working on my driver.

In my hikey platform, there's no PCI bus. So I create my own DwMmc driver to do 
the same thing as SdMmcPciHcDxe driver. There's one controller for eMMC and one 
controller for SD.

1. How to support both eMMC and SD driver in the same driver? The IP is 
designed for both eMMC/SD. If we could share the same driver, we could use 
common code.
I tried to follow SdMmcPciHcDxe driver. I use "Emmc(0)/Ctrl(0)" to indicate the 
device path of eMMC controller. And I should use "Sd(0)/Ctrl(1)" to indicate 
the device path of SD controller. Is it right?

When I tried to access one partition, I use this device path 
"Emmc(0)/Ctrl(0)/HD(5,GPT,00354BCD-BBCB-4CB3-B5AE-CDEFCB5DAC43)". Is it right?


2. When RemainingDevicePath variable is valid, GetSlotNumber() is called in 
both EmmcDxe and SdDxe. But how could DwMmc driver knows which stack is calling 
it? Does it mean that I need to implement two different 
EFI_SD_MMC_PASS_THRU_PROTOCOL interfaces? One is for eMMC, and the other one is 
for SD.


3. How to create the connection DiskIo and eMMC?
When RemainingDevicePath variable is valid, GetSlotNumber() is invoked in 
EmmcDxeDriverBindingStart(). But where RemainingDevicePath is set?
When I debug code, I got this debug message in below.
#EmmcDxeDriverBindingStart, 909, Remain
path:VenHw(CE660500-824D-11E0-AC72-0002A5D5C51B)

The CE660500 belongs to LcdGraphicsOutputDxe. And I didn't build it into the 
firmware at all. I don't know where it comes from.
If I check the eMMC device path in GetSlotNumber(), I'll skip it and DiskIo 
won't run successfully. So partition checking won't run in DiskIo. If I force 
the GetSlotNumber() empty to pass this RemainingDevicePath, partition checking 
could run in DiskIo.
I guess that something is missing between DiskIo and eMMC driver. Do you have 
any idea on this? This issue blocks me to enable multiple slots.


4. Driver dependency. EmmcDxe and SdDxe are both UEFI_DRIVER. 
VariableRuntimeDxe Driver is DXE_RUNTIME_DRIVER. But the dependency is in below.

EmmcDxe --->  DwMmcDxe ---> BlockVariableDxe ---> VariableRuntimeDxe

Now I hack EmmcDxe from UEFI_DRIVER to DXE_RUNTIME to make this dependency 
working. Is there any other solution without hacking?

Best Regards
Haojian
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Fix IPv6 HTTPClient vendor class data

[Zhang, Lubo]

Yes,  the wrong length definition of the ClassIdentifier lead to a wrong 
location CopyMem for system architecture when we build the vendor class option. 
Thanks for your correction.
 Do you have access to check in the code?

Best Regards
Lubo

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Chang
Sent: Thursday, July 21, 2016 9:59 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH] Fix IPv6 HTTPClient vendor class data

The size of the ClassIdentifier is apparently wrong in the structure. In my 
testing it caused the vendor class data to be displayed as bogus 
"HTTPClient:Arch00016x:UNDI00300". After correcting the size the vendor class 
data is "HTTPClient:Arch00016:UNDI003000" which looks good to me.

---
 NetworkPkg/HttpBootDxe/HttpBootDhcp6.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.h 
b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.h
index f9eec9d..14d6db0 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.h
@@ -50,7 +50,7 @@ typedef struct {
 } HTTP_BOOT_DHCP6_OPTION_ARCH;
 
 typedef struct {
-  UINT8 ClassIdentifier[10];
+  UINT8 ClassIdentifier[11];
   UINT8 ArchitecturePrefix[5];
   UINT8 ArchitectureType[5];
   UINT8 Lit3[1];
--
2.6.6

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Question on eMMC and SD driver

[Haojian Zhuang]

Hi all,

I have a few questions on eMMC/SD driver when I'm working on my driver.

In my hikey platform, there's no PCI bus. So I create my own DwMmc 
driver to do the same thing as SdMmcPciHcDxe driver. There's one 
controller for eMMC and one controller for SD.


1. How to support both eMMC and SD driver in the same driver? The IP is 
designed for both

eMMC/SD. If we could share the same driver, we could use common code.
I tried to follow SdMmcPciHcDxe driver. I use "Emmc(0)/Ctrl(0)" to 
indicate the device path of eMMC controller. And I should use 
"Sd(0)/Ctrl(1)" to indicate the device path of SD controller. Is it right?


When I tried to access one partition, I use this device path 
"Emmc(0)/Ctrl(0)/HD(5,GPT,00354BCD-BBCB-4CB3-B5AE-CDEFCB5DAC43)". Is it 
right?



2. When RemainingDevicePath variable is valid, GetSlotNumber() is called 
in both EmmcDxe and SdDxe. But how could DwMmc driver knows which stack 
is calling it? Does it mean that I need to implement two different 
EFI_SD_MMC_PASS_THRU_PROTOCOL interfaces? One is for eMMC, and the other 
one is for SD.



3. How to create the connection DiskIo and eMMC?
When RemainingDevicePath variable is valid, GetSlotNumber() is invoked 
in EmmcDxeDriverBindingStart(). But where RemainingDevicePath is set?

When I debug code, I got this debug message in below.
#EmmcDxeDriverBindingStart, 909, Remain 
path:VenHw(CE660500-824D-11E0-AC72-0002A5D5C51B)


The CE660500 belongs to LcdGraphicsOutputDxe. And I didn't build it into 
the firmware at all. I don't know where it comes from.
If I check the eMMC device path in GetSlotNumber(), I'll skip it and 
DiskIo won't run successfully. So partition checking won't run in 
DiskIo. If I force the GetSlotNumber() empty to pass this 
RemainingDevicePath, partition checking could run in DiskIo.
I guess that something is missing between DiskIo and eMMC driver. Do you 
have any idea on this? This issue blocks me to enable multiple slots.



4. Driver dependency. EmmcDxe and SdDxe are both UEFI_DRIVER. 
VariableRuntimeDxe Driver is DXE_RUNTIME_DRIVER. But the dependency is 
in below.


EmmcDxe --->  DwMmcDxe ---> BlockVariableDxe ---> VariableRuntimeDxe

Now I hack EmmcDxe from UEFI_DRIVER to DXE_RUNTIME to make this 
dependency working. Is there any other solution without hacking?


Best Regards
Haojian
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] What's the status of Minnowboard MAX/Turbot gcc build?

[Gary Lin]

On Wed, Jul 20, 2016 at 01:10:47PM +, Alcantara, Paulo wrote:
> Hi Gary,
> 
> I usually set the TOOL_CHAIN_TAG to GCC49 when I want to build it with GCC5+. 
> AFAIC there's no tags for versions 5 and 6.
> 
Hi Paulo,

I actually modified the build script to use GCC49 instead of GCC46. The
problem is that there are too many compilation errors so I wonder if
anyone really uses gcc to compile the Minnowboard firmware or it only
can be compiled with gcc 4.6.

Thanks,

Gary Lin

> Paulo
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary 
> Lin
> Sent: quarta-feira, 20 de julho de 2016 07:24
> To: edk2-devel@lists.01.org
> Subject: [edk2] What's the status of Minnowboard MAX/Turbot gcc build?
> 
> Hi,
> 
> I recently got a Minnowboard Turbot and would like to build the firmware on 
> my own. I downloaded the 0.92 binary objects and tried to build the firmware 
> with Vlv2TbltDevicePkg/Build_IFWI.sh. However, the build script spitted tons 
> of errors like "set but not used variable" or "multiple definition". Some of 
> them are real while some of them are actually the false-positive of 
> ASSERT_EFI_ERROR. Besides, in the build script, it specifies the build target 
> as GCC46 which is old. My build machine runs openSUSE Tumbleweed which is 
> using gcc 6.1.1. Before I really dive into it, just want to know: Can the 
> firmware be compiled with gcc?
> 
> Thanks,
> 
> Gary Lin
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] [BaseTools/Scripts]: Preserve hii section in GCC binaries

[Thomas Palmer]

This change keeps the .hii sections in GCC built binaries.  Please
refer to email thread titled "[edk2] HII
gEfiHiiPackageListProtocolGuid problem with  GCC48 (VS2012x86 works)"

As this is the first time I've ever touched a GCC linker script,
please feel free to send feedback

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 BaseTools/Scripts/GccBase.lds | 5 +
 1 file changed, 5 insertions(+)

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 32310bc..7e4cdde 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -4,6 +4,7 @@
 
   Copyright (c) 2010 - 2015, Intel Corporation. All rights reserved.
   Copyright (c) 2015, Linaro Ltd. All rights reserved.
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 
   This program and the accompanying materials are licensed and made available 
under
   the terms and conditions of the BSD License that accompanies this 
distribution.
@@ -57,6 +58,10 @@ SECTIONS {
 *(.rela .rela.*)
   }
 
+  .hii : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+KEEP (*(.hii))
+  }
+
   /DISCARD/ : {
 *(.note.GNU-stack)
 *(.gnu_debuglink)
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] Fix IPv6 HTTPClient vendor class data

[Michael Chang]

The size of the ClassIdentifier is apparently wrong in the structure. In my
testing it caused the vendor class data to be displayed as bogus
"HTTPClient:Arch00016x:UNDI00300". After correcting the size the vendor class
data is "HTTPClient:Arch00016:UNDI003000" which looks good to me.

---
 NetworkPkg/HttpBootDxe/HttpBootDhcp6.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.h 
b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.h
index f9eec9d..14d6db0 100644
--- a/NetworkPkg/HttpBootDxe/HttpBootDhcp6.h
+++ b/NetworkPkg/HttpBootDxe/HttpBootDhcp6.h
@@ -50,7 +50,7 @@ typedef struct {
 } HTTP_BOOT_DHCP6_OPTION_ARCH;
 
 typedef struct {
-  UINT8 ClassIdentifier[10];
+  UINT8 ClassIdentifier[11];
   UINT8 ArchitecturePrefix[5];
   UINT8 ArchitectureType[5];
   UINT8 Lit3[1];
-- 
2.6.6

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

[Haojian Zhuang]

在 07/21/2016 09:51 AM, Haojian Zhuang 写道:

Hi Feng,

I think the main difference is who to handle the CRC bits. In the
designware emmc/sd controller, the whole 128-bit value is loaded into
the four response registers. There's no any shift on the 128-bit value
to remove CRC. (Refer to: drivers/mmc/host/dw_mmc.c).


I mean the implementation in linux. $Linux/drivers/mmc/host/dw_mmc.c



In the eMMC spec, it only mentions R2 response in table.

Bit position[127:1]
Width (bits)127
Value  x
DescriptionCID or CSD register incl.
internal CRC7
It also doesn't mention that we need to shift response value for CSD
register.

So I did this fixing patch. I think that shifting isn't common to
support all eMMC/SD controller IP. Without this patch, the eMMC stack
will only get shifted CSD register value.
It results in parse error.

Best Regards
Haojian

在 07/20/2016 04:14 PM, Tian, Feng 写道:

Correct my words,

According to SD host controller spec,  the CRC field is ignored by
h/c. user could only get the data between bit8 and bit127.

Kind of Response|   Meaning of Response  |
ResponseField|ResponseRegister
--

R2 (CID, CSD register)|   CID or CSD reg. incl.  |   R
[127:8]   |   REP [119:0]

So I don't think your fix is correct. Please correct me if I
misunderstand.

Thanks
Feng

-Original Message-
From: Tian, Feng
Sent: Wednesday, July 20, 2016 10:13 AM
To: Haojian Zhuang 
Cc: edk2-devel@lists.01.org; guodong...@linaro.org;
leif.lindh...@linaro.org; ard.biesheu...@linaro.org; Tian, Feng

Subject: RE: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

Hi, Haojian

Why I didn't get the lowest byte data is because it's CRC field. I
thought nobody will care about it. My assumption is incorrect for your
usage model?

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Haojian Zhuang
Sent: Tuesday, July 19, 2016 3:38 PM
To: Tian, Feng 
Cc: Haojian Zhuang ;
edk2-devel@lists.01.org; guodong...@linaro.org;
leif.lindh...@linaro.org; ard.biesheu...@linaro.org
Subject: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

The CSD structure is a 128-bit structure. But EmmcGetCsd() only loads
120 bits with 8-bit offset. Now fix it.

Signed-off-by: Haojian Zhuang 
---
 MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
index fc705e1..fe85627 100644
--- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
+++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
@@ -191,9 +191,9 @@ EmmcGetCsd (
   Status = PassThru->PassThru (PassThru, Device->Slot, &Packet, NULL);
   if (!EFI_ERROR (Status)) {
 //
-// For details, refer to SD Host Controller Simplified Spec 3.0
Table 2-12.
+// Copy 128bit data for CSD structure.
 //
-CopyMem (((UINT8*)Csd) + 1, &SdMmcStatusBlk.Resp0, sizeof
(EMMC_CSD) - 1);
+CopyMem ((VOID*)Csd, &SdMmcStatusBlk.Resp0, sizeof (EMMC_CSD));
   }

   return Status;


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Generated *.FV is bigger than it's contents

[Gao, Liming]

Michael:
 I have no comments on your patch. I am curious what build error when you 
specify BlockSize.

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Zimmermann
Sent: Wednesday, July 20, 2016 11:57 PM
To: Gao, Liming 
Cc: edk2-devel@lists.01.org ; Andrew Fish 

Subject: Re: [edk2] Generated *.FV is bigger than it's contents

> FV also supports BlockSize and NumBlocks. You can specify them to other
value, for example BlockSize = 0x8000. If NumBlocks is not specified, GenFv
will calculate the required FV size and divide BlockSize to get NumBlocks.
It does not, It gives me an build error. I didn't check the FDF spec, but
edk2's FDF parser doesn't support it from what I can see in the source code.
For me it doesn't matter though because I don't think I have to set the
size of the FV

> If your purpose is to generate FV image only, you can remove FD section.
The required Flash PCD can be set to its value in [Defines] section of FDF
file. For example:
Why didn't I see this solution? too simple :P thx.

so, I currently have this (working) patch to generate the small FV and
making the FD/FV drivers happy. Any suggestions on that or does it look
good to you?

Thanks
Michael

=

diff --git a/LittleKernelPkg.fdf b/LittleKernelPkg.fdf
index 4de69e1..0ad9756 100644
--- a/LittleKernelPkg.fdf
+++ b/LittleKernelPkg.fdf
@@ -26,35 +26,10 @@

[Defines]
!include $(WORKSPACE)/Build/EFIDROID/LittleKernelPkg.fdf.inc
-
-[FD.LittleKernelPkg_EFI]
-BaseAddress = $(FD_BASE)|gArmTokenSpaceGuid.PcdFdBaseAddress # The base
address of the Firmware in NOR Flash.
-Size = 0x0020|gArmTokenSpaceGuid.PcdFdSize # The size
in bytes of the FLASH Device
-ErasePolarity = 1
-
-# This one is tricky, it must be: BlockSize * NumBlocks = Size
-BlockSize = 0x1000
-NumBlocks = 0x200
-
-0x|0x0020
-gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
-FV = FVMAIN_COMPACT
+SET gArmTokenSpaceGuid.PcdFdBaseAddress = $(FD_BASE)
+SET gArmTokenSpaceGuid.PcdFdSize = 0x0040
+SET gArmTokenSpaceGuid.PcdFvBaseAddress = $(FD_BASE)
+SET gArmTokenSpaceGuid.PcdFvSize = 0x0040



@@ -189,6 +164,7 @@ FvNameGuid =
411ffc75-2138-44b9-874c-d2c91fa78e91
}

[FV.FVMAIN_COMPACT]
+FvBaseAddress = $(FD_BASE)
FvAlignment = 8
ERASE_POLARITY = 1
MEMORY_MAPPED = TRUE

On Wed, Jul 20, 2016 at 5:27 PM, Gao, Liming wrote:

> Michael:
> FV also supports BlockSize and NumBlocks. You can specify them to other
> value, for example BlockSize = 0x8000. If NumBlocks is not specified, GenFv
> will calculate the required FV size and divide BlockSize to get NumBlocks.
>
> If your purpose is to generate FV image only, you can remove FD
> section. The required Flash PCD can be set to its value in [Defines]
> section of FDF file. For example:
>
> [Defines]
> SET gArmTokenSpaceGuid.FvMainCompactBaseAddress = 0xFFF0
>
> [FV.FvMainCompact]
> BlockSize = 0x8000
> NumBlocks = 0x80
> FvBaseAddress = 0xFFC0
> ...
>
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Michael Zimmermann
> Sent: Tuesday, July 19, 2016 2:20 PM
> To: Andrew Fish
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] Generated *.FV is bigger than it's contents
>
> ok this is what's happening (in comparison to keeping FVMAIN_COMPACT in the
> FD):
> - the generated FVMAIN_COMPACT doesn't have the options EFI_BASE_ADDRESS
> and EFI_NUM_BLOCKS, EFI_BLOCK_SIZE is 0x1
> - this missing base causes FfsRebase to just return(I can actually see that
> in the binary, because there are WAY more differences than just the reset
> vector)
> - since FfsRebase returned without doing anything, mArm is still false.
> This line didn't get executed:
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L3380
> - since mArm is false, UpdateArmResetVectorIfNeeded is not getting called
>
> as you can see there are two problems:
> - no rebase
> - caused by that, all the ARM specific handling like the reset vector
> doesn't happen
>
> Now, FV's support the 'FvBaseAddress' flag, after setting that I indeed get
> a relocated binary, with a correct reset vector.
>
> so, what I did, apart from setting the base address in the Fv section is
> removing this line to not include the Fv in the FD:
> 'FV = FVMAIN_COMPACT'
> Is this the correct way or is there more to it? I guess I have to keep all
> the surrounding lines for generating the FD because it produces Pcd's
> like PcdFdBaseAddress which are needed right?
>
> Thanks for your help,
> Michael
>
> On Mon, Jul 18, 2016 at 11:54 PM, Andrew Fish wrote:
>
> >
> > On Jul 18, 2016, at 2:25 PM, Michael Zimmermann
> > wrote:
> >
> > If I do that the file is as small as possible(yay), but not bootable
> > anymore, i.e. the first 4 bytes are 0 instead of the instruction which
> > jumps past the DOS header.
> >

Re: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

[Haojian Zhuang]

Hi Feng,

I think the main difference is who to handle the CRC bits. In the 
designware emmc/sd controller, the whole 128-bit value is loaded into 
the four response registers. There's no any shift on the 128-bit value 
to remove CRC. (Refer to: drivers/mmc/host/dw_mmc.c).


In the eMMC spec, it only mentions R2 response in table.

Bit position[127:1]
Width (bits)127
Value  x
DescriptionCID or CSD register incl.
internal CRC7
It also doesn't mention that we need to shift response value for CSD 
register.


So I did this fixing patch. I think that shifting isn't common to 
support all eMMC/SD controller IP. Without this patch, the eMMC stack 
will only get shifted CSD register value.

It results in parse error.

Best Regards
Haojian

在 07/20/2016 04:14 PM, Tian, Feng 写道:

Correct my words,

According to SD host controller spec,  the CRC field is ignored by h/c. user 
could only get the data between bit8 and bit127.

Kind of Response|   Meaning of Response  |ResponseField
|ResponseRegister
--
R2 (CID, CSD register)|   CID or CSD reg. incl.  |   R [127:8]  
 |   REP [119:0]

So I don't think your fix is correct. Please correct me if I misunderstand.

Thanks
Feng

-Original Message-
From: Tian, Feng
Sent: Wednesday, July 20, 2016 10:13 AM
To: Haojian Zhuang 
Cc: edk2-devel@lists.01.org; guodong...@linaro.org; leif.lindh...@linaro.org; 
ard.biesheu...@linaro.org; Tian, Feng 
Subject: RE: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

Hi, Haojian

Why I didn't get the lowest byte data is because it's CRC field. I thought 
nobody will care about it. My assumption is incorrect for your usage model?

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Haojian 
Zhuang
Sent: Tuesday, July 19, 2016 3:38 PM
To: Tian, Feng 
Cc: Haojian Zhuang ; edk2-devel@lists.01.org; 
guodong...@linaro.org; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
Subject: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

The CSD structure is a 128-bit structure. But EmmcGetCsd() only loads
120 bits with 8-bit offset. Now fix it.

Signed-off-by: Haojian Zhuang 
---
 MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c 
b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
index fc705e1..fe85627 100644
--- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
+++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
@@ -191,9 +191,9 @@ EmmcGetCsd (
   Status = PassThru->PassThru (PassThru, Device->Slot, &Packet, NULL);
   if (!EFI_ERROR (Status)) {
 //
-// For details, refer to SD Host Controller Simplified Spec 3.0 Table 2-12.
+// Copy 128bit data for CSD structure.
 //
-CopyMem (((UINT8*)Csd) + 1, &SdMmcStatusBlk.Resp0, sizeof (EMMC_CSD) - 1);
+CopyMem ((VOID*)Csd, &SdMmcStatusBlk.Resp0, sizeof (EMMC_CSD));
   }

   return Status;


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Bugzilla Server is now live

[Kinney, Michael D]

Bruce,

Yes.  We have requested this...it is just taking some time 
to complete and I did not want to delay the use of Bugzilla 
for the new URL.

As soon as the new URL is up, I will let everyone know.

Mike

> -Original Message-
> From: Bruce Cran [mailto:br...@cran.org.uk]
> Sent: Wednesday, July 20, 2016 6:46 PM
> To: Kinney, Michael D ; edk2-devel@lists.01.org 
> (edk2-
> de...@ml01.01.org) 
> Subject: Re: [edk2] Tianocore Bugzilla Server is now live
> 
> On 7/20/16 4:47 PM, Kinney, Michael D wrote:
> 
> > I am pleased to announce that the Bugzilla server for Tianocore
> > is now live and ready to be used.  The server URL is:
> >
> >   https://tianocore.acgmultimedia.com
> 
> Great! Would it be possible to have a nicer URL though - something like
> "https://bugs.tianocore.org";?
> 
> --
> Bruce

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Tianocore Bugzilla Server is now live

[Bruce Cran]

On 7/20/16 4:47 PM, Kinney, Michael D wrote:


I am pleased to announce that the Bugzilla server for Tianocore
is now live and ready to be used.  The server URL is:

  https://tianocore.acgmultimedia.com


Great! Would it be possible to have a nicer URL though - something like 
"https://bugs.tianocore.org";?


--
Bruce

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] [BaseTools/Scripts]: Preserve hii section in GCC binaries

[Thomas Palmer]

This change keeps the .hii sections in GCC built binaries.  Please
refer to email thread titled "[edk2] HII
gEfiHiiPackageListProtocolGuid problem with  GCC48 (VS2012x86 works)"

As this is the first time I've ever touched a GCC linker script,
please feel free to send feedback

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 BaseTools/Scripts/GccBase.lds | 4 
 1 file changed, 4 insertions(+)

diff --git a/BaseTools/Scripts/GccBase.lds b/BaseTools/Scripts/GccBase.lds
index 32310bc..a761fa6 100644
--- a/BaseTools/Scripts/GccBase.lds
+++ b/BaseTools/Scripts/GccBase.lds
@@ -57,6 +57,10 @@ SECTIONS {
 *(.rela .rela.*)
   }
 
+  .hii : ALIGN(CONSTANT(COMMONPAGESIZE)) {
+KEEP (*(.hii))
+  }
+
   /DISCARD/ : {
 *(.note.GNU-stack)
 *(.gnu_debuglink)
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Tianocore Bugzilla Server is now live

[Kinney, Michael D]

Hello,

I am pleased to announce that the Bugzilla server for Tianocore 
is now live and ready to be used.  The server URL is: 

  https://tianocore.acgmultimedia.com

If you do not have a user account yet, please create one.

There is also a new mailing list called edk2-b...@lists.01.org.
Bugzilla has been configured so all new issues and all state 
changes to issues are sent to this mailing list.  If you want 
to see every state change on every issue, then you can sign 
up to this mailing list at:

https://lists.01.org/mailman/listinfo/edk2-bugs

There is one special Product type on the Bugzilla server called 
"Tianocore Security Issues".  If you believe you have discovered
a security issue, then you must enter the issue using the 
"Tianocore Security Issues" Product.  The issue will be evaluated
to determine if it really is a security issue or not.

  NOTE: Never any security issue details in email.

I am also updating the Tianocore web pages with the information
from this email along with additional details in how different
types of issues are processed.

I will transfer issues from GitHub issue tracker to Bugzilla over
the next day or two and the GitHub issue tracker for Tianocore
repositories will be disabled.

Best regards,

Mike


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] What's the status of Minnowboard MAX/Turbot gcc build?

[Laszlo Ersek]

On 07/20/16 22:57, David A. Van Arnem wrote:
> 
> 
> On 07/20/2016 07:10 AM, Alcantara, Paulo wrote:
>> Hi Gary,
>>
>> I usually set the TOOL_CHAIN_TAG to GCC49 when I want to build it with
>> GCC5+. AFAIC there's no tags for versions 5 and 6.
> 
> I am not sure, but I believe I read in another thread that GCC6 support
> is being worked on.  But in the meantime, like you I have not had any
> issues using TOOL_CHAIN_TAG = GCC49 with GCC5+.

You might be recalling

https://github.com/tianocore/edk2/issues/99

and

http://thread.gmane.org/gmane.comp.bios.edk2.devel/13918

Thanks
Laszlo

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [StdLib] Fails to compile with the latest version of Xcode/clang due to new compiler diagnostic.

[Andrew Fish]

It looks like clang has added a warning to detect infinite recursion and I'm 
seeing the failure here:

https://github.com/tianocore/edk2/blob/master/StdLib/LibC/StdLib/Environs.c#L123
void
_Exit(int status)
{
  gMD->ExitValue = status;  // Save our exit status.  Allows a status 
of 0.
  longjmp(gMD->MainExit, 0x55); // Get out of here.  longjmp can't return 
0. Use 0x55 for a non-zero value.

#ifdef __GNUC__
  _Exit(status);/* Keep GCC happy - never reached */
#endif
}

This is the compiler warning. 

error: all paths through this function will call itself 
[-Werror,-Winfinite-recursion]

I fixed by replacing the infinite recursion with UNREACHABLE() but I'm not sure 
what the rules are changing this chunk of code? 

Thanks,

Andrew Fish

https://github.com/tianocore/edk2/issues/109


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] What's the status of Minnowboard MAX/Turbot gcc build?

[David A. Van Arnem]

On 07/20/2016 07:10 AM, Alcantara, Paulo wrote:

Hi Gary,

I usually set the TOOL_CHAIN_TAG to GCC49 when I want to build it with GCC5+. 
AFAIC there's no tags for versions 5 and 6.


I am not sure, but I believe I read in another thread that GCC6 support 
is being worked on.  But in the meantime, like you I have not had any 
issues using TOOL_CHAIN_TAG = GCC49 with GCC5+.


David



Paulo

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary Lin
Sent: quarta-feira, 20 de julho de 2016 07:24
To: edk2-devel@lists.01.org
Subject: [edk2] What's the status of Minnowboard MAX/Turbot gcc build?

Hi,

I recently got a Minnowboard Turbot and would like to build the firmware on my own. I downloaded 
the 0.92 binary objects and tried to build the firmware with Vlv2TbltDevicePkg/Build_IFWI.sh. 
However, the build script spitted tons of errors like "set but not used variable" or 
"multiple definition". Some of them are real while some of them are actually the 
false-positive of ASSERT_EFI_ERROR. Besides, in the build script, it specifies the build target as 
GCC46 which is old. My build machine runs openSUSE Tumbleweed which is using gcc 6.1.1. Before I 
really dive into it, just want to know: Can the firmware be compiled with gcc?

Thanks,

Gary Lin
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel



--
Thanks,
David Van Arnem
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [staging/HTTPS-TLS][PATCH] CryptoPkg: Multiple bugs fix in TlsLib

[Palmer, Thomas]

Reviewed by Thomas Palmer 

Sorry, I still have your other patches to look at. Will find time this week 
hopefully

-Original Message-
From: Jiaxin Wu [mailto:jiaxin...@intel.com] 
Sent: Wednesday, July 20, 2016 12:01 AM
To: edk2-devel@lists.01.org
Cc: Long Qin ; Ye Ting ; Palmer, Thomas 

Subject: [staging/HTTPS-TLS][PATCH] CryptoPkg: Multiple bugs fix in TlsLib

This path made the following update:
* Fix X64 build error
* Correct and refine Set/Get compression method
* Fix GetHostPublicCert() failure

Cc: Long Qin 
Cc: Ye Ting 
Cc: Palmer Thomas 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 CryptoPkg/Include/Library/TlsLib.h |  2 +-  CryptoPkg/Library/TlsLib/TlsLib.c  
| 26 +++---
 2 files changed, 16 insertions(+), 12 deletions(-)

diff --git a/CryptoPkg/Include/Library/TlsLib.h 
b/CryptoPkg/Include/Library/TlsLib.h
index d62375b..e0c1b25 100644
--- a/CryptoPkg/Include/Library/TlsLib.h
+++ b/CryptoPkg/Include/Library/TlsLib.h
@@ -500,11 +500,11 @@ TlsGetCurrentCipher (
   @param[in,out]  CompressionIdThe current compression method used by
the TLS object.
 
   @retval  EFI_SUCCESS   The compression method was returned 
successfully.
   @retval  EFI_INVALID_PARAMETER The parameter is invalid.
-  @retval  EFI_UNSUPPORTED   Unsupported compression method.
+  @retval  EFI_ABORTED   Invalid Compression method.
 
 **/
 EFI_STATUS
 EFIAPI
 TlsGetCurrentCompressionId (
diff --git a/CryptoPkg/Library/TlsLib/TlsLib.c 
b/CryptoPkg/Library/TlsLib/TlsLib.c
index d9267f4..1f3554a 100644
--- a/CryptoPkg/Library/TlsLib/TlsLib.c
+++ b/CryptoPkg/Library/TlsLib/TlsLib.c
@@ -671,11 +671,11 @@ TlsDoHandshake (
   PendingBufferSize = (UINTN) BIO_ctrl_pending (TlsConn->OutBio);
 }
   }
 
   if (Ret < 1) {
-Ret = SSL_get_error (TlsConn->Ssl, Ret);
+Ret = SSL_get_error (TlsConn->Ssl, (int) Ret);
 if (Ret == SSL_ERROR_SSL ||
 Ret == SSL_ERROR_SYSCALL ||
 Ret == SSL_ERROR_ZERO_RETURN) {
   DEBUG ((
 DEBUG_ERROR,
@@ -1055,11 +1055,16 @@ TlsSetCompressionMethod (
 
   Cm  = NULL;
   Ret = 0;
 
   if (CompMethod == 0) {
-Cm = NULL;
+//
+// TLS defines one standard compression method, CompressionMethod.null 
(0), 
+// which specifies that data exchanged via the record protocol will not be 
compressed.  
+// So, return EFI_SUCCESS directly (RFC 3749).
+//
+return EFI_SUCCESS;
   } else if (CompMethod == 1) {
 Cm = COMP_zlib();
   } else {
 return EFI_UNSUPPORTED;
   }
@@ -1067,11 +1072,11 @@ TlsSetCompressionMethod (
   //
   // Adds the compression method to the list of available
   // compression methods.
   //
   Ret = SSL_COMP_add_compression_method (CompMethod, Cm);
-  if (Ret != 1) {
+  if (Ret != 0) {
 return EFI_UNSUPPORTED;
   }
 
   return EFI_SUCCESS;
 }
@@ -1252,11 +1257,11 @@ TlsGetCurrentCipher (
   @param[in,out]  CompressionIdThe current compression method used by
the TLS object.
 
   @retval  EFI_SUCCESS   The compression method was returned 
successfully.
   @retval  EFI_INVALID_PARAMETER The parameter is invalid.
-  @retval  EFI_UNSUPPORTED   Unsupported compression method.
+  @retval  EFI_ABORTED   Invalid Compression method.
 
 **/
 EFI_STATUS
 EFIAPI
 TlsGetCurrentCompressionId (
@@ -1279,17 +1284,16 @@ TlsGetCurrentCompressionId (
   if (TlsConn == NULL || TlsConn->Ssl == NULL || CompressionId == NULL) {
 return EFI_INVALID_PARAMETER;
   }
 
   StackSslComp = SSL_COMP_get_compression_methods ();
-  if (StackSslComp == NULL) {
-return EFI_UNSUPPORTED;
-  }
 
   CompMethod = SSL_get_current_compression (TlsConn->Ssl);
-  if (CompMethod == NULL) {
-return EFI_UNSUPPORTED;
+  
+  if (StackSslComp == NULL || CompMethod == NULL) {
+*CompressionId = 0;
+return EFI_SUCCESS;
   }
 
   for (Index = 0; Index < (UINTN) sk_SSL_COMP_num (StackSslComp); Index++) {
 SslComp = sk_SSL_COMP_value (StackSslComp, (int) Index);
 if (AsciiStrCmp (SSL_COMP_get_name (CompMethod), SslComp->name) == 0) { @@ 
-1298,11 +1302,11 @@ TlsGetCurrentCompressionId (
 
 SslComp = NULL;
   }
 
   if (SslComp == NULL) {
-return EFI_UNSUPPORTED;
+return EFI_ABORTED;
   }
 
   *CompressionId = (UINT8) (SslComp->id);
 
   return EFI_SUCCESS;
@@ -1792,11 +1796,11 @@ TlsGetHostPublicCert (
   if (*DataSize < (UINTN) i2d_X509 (Cert, NULL)) {
 *DataSize = (UINTN) i2d_X509 (Cert, NULL);
 return EFI_BUFFER_TOO_SMALL;
   }
 
-  i2d_X509 (Cert, Data);
+  *DataSize = (UINTN) i2d_X509 (Cert, (unsigned char **) &Data);
 
   return Status;
 }
 
 /**
--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Generated *.FV is bigger than it's contents

[Michael Zimmermann]

> FV also supports BlockSize and NumBlocks. You can specify them to other
value, for example BlockSize = 0x8000. If NumBlocks is not specified, GenFv
will calculate the required FV size and divide BlockSize to get NumBlocks.
It does not, It gives me an build error. I didn't check the FDF spec, but
edk2's FDF parser doesn't support it from what I can see in the source code.
For me it doesn't matter though because I don't think I have to set the
size of the FV

> If your purpose is to generate FV image only, you can remove FD section.
The required Flash PCD can be set to its value in [Defines] section of FDF
file. For example:
Why didn't I see this solution? too simple :P thx.

so, I currently have this (working) patch to generate the small FV and
making the FD/FV drivers happy. Any suggestions on that or does it look
good to you?

Thanks
Michael

=

diff --git a/LittleKernelPkg.fdf b/LittleKernelPkg.fdf
index 4de69e1..0ad9756 100644
--- a/LittleKernelPkg.fdf
+++ b/LittleKernelPkg.fdf
@@ -26,35 +26,10 @@

 [Defines]
 !include $(WORKSPACE)/Build/EFIDROID/LittleKernelPkg.fdf.inc
-
-[FD.LittleKernelPkg_EFI]
-BaseAddress   = $(FD_BASE)|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base
address of the Firmware in NOR Flash.
-Size  = 0x0020|gArmTokenSpaceGuid.PcdFdSize # The size
in bytes of the FLASH Device
-ErasePolarity = 1
-
-# This one is tricky, it must be: BlockSize * NumBlocks = Size
-BlockSize = 0x1000
-NumBlocks = 0x200
-
-0x|0x0020
-gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
-FV = FVMAIN_COMPACT
+SET gArmTokenSpaceGuid.PcdFdBaseAddress = $(FD_BASE)
+SET gArmTokenSpaceGuid.PcdFdSize= 0x0040
+SET gArmTokenSpaceGuid.PcdFvBaseAddress = $(FD_BASE)
+SET gArmTokenSpaceGuid.PcdFvSize= 0x0040


 

@@ -189,6 +164,7 @@ FvNameGuid =
411ffc75-2138-44b9-874c-d2c91fa78e91
   }

 [FV.FVMAIN_COMPACT]
+FvBaseAddress  = $(FD_BASE)
 FvAlignment= 8
 ERASE_POLARITY = 1
 MEMORY_MAPPED  = TRUE

On Wed, Jul 20, 2016 at 5:27 PM, Gao, Liming  wrote:

> Michael:
>FV also supports BlockSize and NumBlocks. You can specify them to other
> value, for example BlockSize = 0x8000. If NumBlocks is not specified, GenFv
> will calculate the required FV size and divide BlockSize to get NumBlocks.
>
>If your purpose is to generate FV image only, you can remove FD
> section. The required Flash PCD can be set to its value in [Defines]
> section of FDF file. For example:
>
> [Defines]
> SET gArmTokenSpaceGuid.FvMainCompactBaseAddress = 0xFFF0
>
> [FV.FvMainCompact]
> BlockSize  = 0x8000
> NumBlocks  = 0x80
> FvBaseAddress  = 0xFFC0
> ...
>
> Thanks
> Liming
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Michael Zimmermann
> Sent: Tuesday, July 19, 2016 2:20 PM
> To: Andrew Fish 
> Cc: edk2-devel@lists.01.org 
> Subject: Re: [edk2] Generated *.FV is bigger than it's contents
>
> ok this is what's happening (in comparison to keeping FVMAIN_COMPACT in the
> FD):
> - the generated FVMAIN_COMPACT doesn't have the options EFI_BASE_ADDRESS
> and EFI_NUM_BLOCKS, EFI_BLOCK_SIZE is 0x1
> - this missing base causes FfsRebase to just return(I can actually see that
> in the binary, because there are WAY more differences than just the reset
> vector)
> - since FfsRebase returned without doing anything, mArm is still false.
> This line didn't get executed:
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L3380
> - since mArm is false, UpdateArmResetVectorIfNeeded is not getting called
>
> as you can see there are two problems:
> - no rebase
> - caused by that, all the ARM specific handling like the reset vector
> doesn't happen
>
> Now, FV's support the 'FvBaseAddress' flag, after setting that I indeed get
> a relocated binary, with a correct reset vector.
>
> so, what I did, apart from setting the base address in the Fv section is
> removing this line to not include the Fv in the FD:
> 'FV = FVMAIN_COMPACT'
> Is this the correct way or is there more to it? I guess I have to keep all
> the surrounding lines for generating the FD because it produces Pcd's
> like PcdFdBaseAddress which are needed right?
>
> Thanks for your help,
> Michael
>
> On Mon, Jul 18, 2016 at 11:54 PM, Andrew Fish wrote:
>
> >
> > On Jul 18, 2016, at 2:25 PM, Michael Zimmermann
> > wrote:
> >
> > If I do that the file is as small as possible(yay), but not bootable
> > anymore, i.e. the first 4 bytes are 0 instead of the instruction which
> > jumps past the DOS header.
> >
> >
> > The 1st 16-bytes of the FV header are defined to be a zero vector. This
> > allows space for code that resets low, and is patched by the build tools.
> >
> >
> >
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L2050
> >
> > It looks like Ge

Re: [edk2] Generated *.FV is bigger than it's contents

[Gao, Liming]

Michael:
   FV also supports BlockSize and NumBlocks. You can specify them to other 
value, for example BlockSize = 0x8000. If NumBlocks is not specified, GenFv 
will calculate the required FV size and divide BlockSize to get NumBlocks.

   If your purpose is to generate FV image only, you can remove FD section. The 
required Flash PCD can be set to its value in [Defines] section of FDF file. 
For example:

[Defines]
SET gArmTokenSpaceGuid.FvMainCompactBaseAddress = 0xFFF0

[FV.FvMainCompact]
BlockSize  = 0x8000
NumBlocks  = 0x80
FvBaseAddress  = 0xFFC0
...

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Michael 
Zimmermann
Sent: Tuesday, July 19, 2016 2:20 PM
To: Andrew Fish 
Cc: edk2-devel@lists.01.org 
Subject: Re: [edk2] Generated *.FV is bigger than it's contents

ok this is what's happening (in comparison to keeping FVMAIN_COMPACT in the
FD):
- the generated FVMAIN_COMPACT doesn't have the options EFI_BASE_ADDRESS
and EFI_NUM_BLOCKS, EFI_BLOCK_SIZE is 0x1
- this missing base causes FfsRebase to just return(I can actually see that
in the binary, because there are WAY more differences than just the reset
vector)
- since FfsRebase returned without doing anything, mArm is still false.
This line didn't get executed:
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L3380
- since mArm is false, UpdateArmResetVectorIfNeeded is not getting called

as you can see there are two problems:
- no rebase
- caused by that, all the ARM specific handling like the reset vector
doesn't happen

Now, FV's support the 'FvBaseAddress' flag, after setting that I indeed get
a relocated binary, with a correct reset vector.

so, what I did, apart from setting the base address in the Fv section is
removing this line to not include the Fv in the FD:
'FV = FVMAIN_COMPACT'
Is this the correct way or is there more to it? I guess I have to keep all
the surrounding lines for generating the FD because it produces Pcd's
like PcdFdBaseAddress which are needed right?

Thanks for your help,
Michael

On Mon, Jul 18, 2016 at 11:54 PM, Andrew Fish wrote:

>
> On Jul 18, 2016, at 2:25 PM, Michael Zimmermann
> wrote:
>
> If I do that the file is as small as possible(yay), but not bootable
> anymore, i.e. the first 4 bytes are 0 instead of the instruction which
> jumps past the DOS header.
>
>
> The 1st 16-bytes of the FV header are defined to be a zero vector. This
> allows space for code that resets low, and is patched by the build tools.
>
>
> https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L2050
>
> It looks like GenFv will patch the start of the FV with a jmp to the
> _ModuleEntryPoint (The entry point in the PE/COFF header) of the SEC or
> PeiCore if they exist in the FV?
>
> You can poke around in that area to figure out why the patch did not
> happen.
>
> Thanks,
>
> Andrew Fish
>
> Thanks
> Michael
>
> On Mon, Jul 18, 2016 at 11:00 PM, Andrew Fish wrote:
>
>>
>> > On Jul 18, 2016, at 1:42 PM, Michael Zimmermann <
>> sigmaepsilo...@gmail.com> wrote:
>> >
>> > > For example This statement in the [FD.MEMFD] section will cause this
>> region of the FLASH to get padded out if the FV is smaller than 0xA0
>> >
>> > that seems to be the problem because the Size in the FV header is set
>> to that value and the file FVMAIN_COMPACT.Fv always has that size.
>> >
>> > of course I could just make it smaller, but in this case I'd have to
>> adjust it to the current size and increase it every time I need more space
>> to fix the build error.
>> > It would be easier to just be able to remove the 0xFF padding for the
>> FV, or at least have a clean way to remove it afterwards by external tools.
>> >
>> > to make things easier I'll link my source here:
>> >
>> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf
>> <
>> https://github.com/efidroid/uefi_edk2packages_LittleKernelPkg/blob/master/LittleKernelPkg.fdf
>> >
>> >
>>
>> What is the size of the FVMAIN_COMPACT if you don't place it in the FD?
>>
>> Thanks,
>>
>> Andrew Fish
>>
>> > Thanks
>> > Michael
>> >
>> >
>> > On Mon, Jul 18, 2016 at 10:03 PM, Andrew Fish mailto:%0b>>> af...@apple.com>> wrote:
>> >
>> > > On Jul 18, 2016, at 9:07 AM, Michael Zimmermann <
>> sigmaepsilo...@gmail.com > wrote:
>> > >
>> > >
>> > > I don't need/use XIP or relocation(would the latter make a difference
>> > > anyway?).
>> > >
>> > > Also the difference between FD and FV seems to be terminology only,
>> because
>> > > YOURPLATFORM.fd has the same checksum as FVMAIN_COMPACT.Fv.
>> > >
>> > > What I successfully tested as a workaround is reading
>> > > EFI_FV_TAKEN_SIZE from FVMAIN_COMPACT.Fv.map and strip the file to
>> that
>> > > size.
>> > > That seems to work, but I'm not sure if it's exact, because there are
>> still
>> > > a few 0xff 

Re: [edk2] [PATCH v3 0/9] MdePkg BaseTools: GCC optimization for X64

[Gao, Liming]

After fix one platform issue, this patches can work in our X64 real hardware 
platform. So, I add Tested-By: Liming Gao 
mailto:liming@intel.com>>

For the patch 6, I have given my comments. Other patches are good to me. 
Reviewed-by: Liming Gao

Thanks
Liming
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Monday, July 18, 2016 9:27 AM
To: Justen, Jordan L ; Ard Biesheuvel 
; edk2-devel@lists.01.org; ler...@redhat.com; 
af...@apple.com; Shi, Steven ; Zhu, Yonghong 
; Kinney, Michael D ; 
Bjorge, Erik C 
Cc: br...@cran.org.uk; pbonz...@redhat.com; Long, Qin ; Ye, 
Ting ; Ard Biesheuvel 
Subject: Re: [edk2] [PATCH v3 0/9] MdePkg BaseTools: GCC optimization for X64

Jordan:
Thanks for your reminder. Yes. I will verify this patch on another real 
hardware platform.

Thanks
Liming
> -Original Message-
> From: Justen, Jordan L
> Sent: Monday, July 18, 2016 6:45 AM
> To: Ard Biesheuvel ; edk2-devel@lists.01.org;
> ler...@redhat.com; 
> af...@apple.com; Gao, Liming ;
> Shi, Steven ; Zhu, Yonghong
> ; Kinney, Michael D
> ; Gao, Liming ; Bjorge,
> Erik C
> Cc: br...@cran.org.uk; 
> pbonz...@redhat.com; Ard Biesheuvel
> ; Ye, Ting ; Long, Qin
>
> Subject: Re: [edk2] [PATCH v3 0/9] MdePkg BaseTools: GCC optimization for
> X64
>
> I tested a bit with OVMF on GCC44 and GCC49. For the series:
> Reviewed-by: Jordan Justen
>
> I wonder if Liming or Erik might want to test GCC49 on another
> (non-OVMF) platform. Possibly with some windows boot testing.
>
> On 2016-07-17 03:34:37, Ard Biesheuvel wrote:
> > This is v3 of the series to enable compiler optimization under GCC for 
> > builds
> > targetting X64. It includes a patch from Steven Shi, taken from his series 
> > to
> > introduce support for GCC 5.x and Clang 3.8/X64 to EDK2.
> >
> > The first patch fixes the issue that __builtin_unreachable() is not
> > implemented by GCC 4.4 or earlier.
> >
> > Patch #2 sets a new define for OpensslLib that we will test in patches #3
> > and #4 to inhibit the use of the MS varargs ABI when building OpenSSL,
> which
> > lacks the ms_abi attributes on its variadic functions.
> >
> > Patch #3 is Steven's patch to switch to the flavor of VA_LIST that is
> > explicitly modeled after the MS implementation. This by itself is an
> > improvement, since the open coded implementation that performs
> arithmetic
> > on the address of explicit arguments to obtain the variadic arguments is
> > fragile and difficult to maintain, and should be best avoided.
> >
> > Patch #4 ports patch #3 to EdkCompatibilityPkg
> >
> > Patch #5 enables -Os optimization for X64/RELEASE and X86/DEBUG all the
> way
> > back to GCC44. This aligns X64 with IA32, which is already built using -Os
> > for both DEBUG and RELEASE.
> >
> > Note that the reported breakage regarding the use of -Os [0] is likely
> caused
> > by the poor man's __builtin_ms_va_list (NO_BUILTIN_VA_FUNCS) that we
> used for
> > GCC/X64 before Steven's patch above switches us to a properly defined
> builtin
> > type. (The poor man's implementation uses pointer arithmetic involving
> the
> > address of the last named argument to calculate pointers to the variadic
> > arguments and dereferences them to obtain the argument values. I'm
> quite
> > surprised it works as well as it does at -O0, to be honest)
> >
> > I tested this change with both Ovmf and EmulatorPkg built in various ways
> > and with various versions, with the caveat that I did not always use a
> matching
> > binutils (i.e., of the same era). Since the issues this series deal with are
> > all code generation issues, I think this is reasonable, but more testing 
> > would
> > be appreciated. (v2: this still applies, I have tested DEBUG and RELEASE
> builds
> > using GCC44, GCC46, GCC47 and GCC48, but all on the same Ubuntu 14.04
> system,
> > which means they all use the same ld version 2.24.90)
> >
> > [0] http://thread.gmane.org/gmane.comp.bios.tianocore.devel/10963
> >
> > Patch #6 explicitly forbids the poor man's MS ABI varargs implementation
> when
> > using GCC with optimization enabled.
> >
> > Patch #7 drops checks for the NO_BUILTIN_VA_FUNCS macro, which is
> never defined
> > anymore.
> >
> > Patch #8 applies the visibility 'protected' GCC pragma globally. Please 
> > refer
> to
> > the commit log for the motivation.
> >
> > Patch #9 switches GCC/X64 to the PIE small code model, which results in
> smaller
> > code.
> >
> > Changes in v3:
> > - Ensure OpensslLib does not switch to the MS varargs ABI inadvertently
> > - Switch to -fpie code generation rather than -fpic, which is more suitable
> for
> > executables. Note that this is *not* the -pie linker switch which generates
> > a RELA section and a _DYNAMIC entrypoint.
> > - Use 'protected' rather than 'hidden' visibility, which is equally 
> > suitable for
> > our purposes (inhibiting gener

[edk2] [PATCH v1 1/1] BaseTools/toolsetup: Do not set CONF_PATH when already set.

[Marvin Häuser]

When CONF_PATH is already set, toolsetup.bat overwrites its value.
This is not the case on Linux platforms (BuildEnv) and
contra-productive when using the same Workspace across multiple
Operating Systems.
With this patch, a check is performed prior to setting the variable.
Furthermore, it will not be scanned for Conf directories in
PACKAGES_PATH directories to respect the user's choice.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser 
---
 BaseTools/toolsetup.bat | 17 ++---
 1 file changed, 10 insertions(+), 7 deletions(-)

diff --git a/BaseTools/toolsetup.bat b/BaseTools/toolsetup.bat
index 76fd8bb6ef9e..c1ab9bcc8d33 100755
--- a/BaseTools/toolsetup.bat
+++ b/BaseTools/toolsetup.bat
@@ -160,13 +160,16 @@ if not defined WORKSPACE (
goto skip_reconfig
 )
 
-set CONF_PATH=%WORKSPACE%\Conf
-if NOT exist %CONF_PATH% (
-  if defined PACKAGES_PATH (
-for %%i IN (%PACKAGES_PATH%) DO (
-  if exist %%~fi\Conf (
-set CONF_PATH=%%i\Conf
-goto CopyConf
+if not defined CONF_PATH (
+  set CONF_PATH=%WORKSPACE%\Conf
+
+  if NOT exist %CONF_PATH% (
+if defined PACKAGES_PATH (
+  for %%i IN (%PACKAGES_PATH%) DO (
+if exist %%~fi\Conf (
+  set CONF_PATH=%%i\Conf
+  goto CopyConf
+)
   )
 )
   )
-- 
2.9.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] What's the status of Minnowboard MAX/Turbot gcc build?

[Alcantara, Paulo]

Hi Gary,

I usually set the TOOL_CHAIN_TAG to GCC49 when I want to build it with GCC5+. 
AFAIC there's no tags for versions 5 and 6.

Paulo

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary Lin
Sent: quarta-feira, 20 de julho de 2016 07:24
To: edk2-devel@lists.01.org
Subject: [edk2] What's the status of Minnowboard MAX/Turbot gcc build?

Hi,

I recently got a Minnowboard Turbot and would like to build the firmware on my 
own. I downloaded the 0.92 binary objects and tried to build the firmware with 
Vlv2TbltDevicePkg/Build_IFWI.sh. However, the build script spitted tons of 
errors like "set but not used variable" or "multiple definition". Some of them 
are real while some of them are actually the false-positive of 
ASSERT_EFI_ERROR. Besides, in the build script, it specifies the build target 
as GCC46 which is old. My build machine runs openSUSE Tumbleweed which is using 
gcc 6.1.1. Before I really dive into it, just want to know: Can the firmware be 
compiled with gcc?

Thanks,

Gary Lin
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] What's the status of Minnowboard MAX/Turbot gcc build?

[Gary Lin]

Hi,

I recently got a Minnowboard Turbot and would like to build the firmware
on my own. I downloaded the 0.92 binary objects and tried to build the
firmware with Vlv2TbltDevicePkg/Build_IFWI.sh. However, the build script
spitted tons of errors like "set but not used variable" or "multiple
definition". Some of them are real while some of them are actually the
false-positive of ASSERT_EFI_ERROR. Besides, in the build script, it
specifies the build target as GCC46 which is old. My build machine runs
openSUSE Tumbleweed which is using gcc 6.1.1. Before I really dive into
it, just want to know: Can the firmware be compiled with gcc?

Thanks,

Gary Lin
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2] UefiCpuPkg/PiSmmCpuDxeSmm: SMM_CPU_DATA_BLOCK is not cleared

[Laszlo Ersek]

On 07/20/16 01:38, Michael Kinney wrote:
> From: Jeff Fan 
> 
> The commit 8b9311 changed the zeroing of mSmmMpSyncData of type
> SMM_DISPATCHER_MP_SYNC_DATA by the following patch.
>  -ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
>  +mSmmMpSyncData->SwitchBsp = FALSE;
> 
> mSmmMpSyncDataSize not only includes SMM_DISPATCHER_MP_SYNC_DATA, but
> also includes the SMM_CPU_DATA_BLOCK array and one BOOLEAN variable
> array as shown here:
> 
>   mSmmMpSyncDataSize = sizeof (SMM_DISPATCHER_MP_SYNC_DATA) +
>(sizeof (SMM_CPU_DATA_BLOCK) + sizeof (BOOLEAN)) *
>gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus;
> 
> This patch restores the original ZeroMem() to clear all CPU Sync data.
> The commit 8b9311 may cause unexpected behavior.
> 
> v2:
>   Mentioned CandidateBsp array in comments to make it more accurate.
> 
> Cc: Laszlo Ersek 
> Cc: Feng Tian 
> Cc: Michael Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Fan 
> Reviewed-by: Feng Tian 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> index 5ba0514..12466ef 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
> @@ -1276,7 +1276,11 @@ InitializeMpSyncData (
>UINTN  CpuIndex;
>  
>if (mSmmMpSyncData != NULL) {
> -mSmmMpSyncData->SwitchBsp = FALSE;
> +//
> +// mSmmMpSyncDataSize includes one structure of 
> SMM_DISPATCHER_MP_SYNC_DATA, one
> +// CpuData array of SMM_CPU_DATA_BLOCK and one CandidateBsp array of 
> BOOLEAN.
> +//
> +ZeroMem (mSmmMpSyncData, mSmmMpSyncDataSize);
>  mSmmMpSyncData->CpuData = (SMM_CPU_DATA_BLOCK *)((UINT8 *)mSmmMpSyncData 
> + sizeof (SMM_DISPATCHER_MP_SYNC_DATA));
>  mSmmMpSyncData->CandidateBsp = (BOOLEAN *)(mSmmMpSyncData->CpuData + 
> gSmmCpuPrivate->SmmCoreEntryContext.NumberOfCpus);
>  if (FeaturePcdGet (PcdCpuSmmEnableBspElection)) {
> 

Reviewed-by: Laszlo Ersek 

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Email tags for Bugzilla and administrative events

[Laszlo Ersek]

On 07/19/16 21:57, Kinney, Michael D wrote:

> We have edk2-devel mailing list today for patch submissions/review and
> design/implementation discussions.
> 
> The commit messages in the future should include a link to the Bugzilla
> issue(s) the patch addresses.

I agree.

> If there are lively discussion on edk2-devel on root causing a bug
> or discussions on where and how the bug should be fixed in code, then
> the Bugzilla entry can include gmane links to those edk2-devel
> threads.

I agree.

Furthermore, I suggest:

- whenever a patch series is posted to edk2-devel, for (partly or
completely) fixing a bug, the cover letter of that series be linked in
the BZ,
- when patches are committed, the commit range also be noted on the BZ.

When someone tries to look over the bug from the distance of a month or
so, they can easily find all versions of the patch series, with the
review comments, and the commits too.

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] Email tags for Bugzilla and administrative events

[Laszlo Ersek]

On 07/19/16 19:59, Michael Zimmermann wrote:
> how will this work side-by-side with the mailing list?
> It kinda sounds like a mailing list replacement, and you probably don't
> want to have separate mailing list topics and bugzilla reports about the
> same thing.

Bugzilla and mailing list work very well together.

A bugzilla entry is (should be) focused on a specific bug or feature,
for a specific product, component, package. Some discussion can and
should occur in it, attachments can be uploaded, etc., but all comments
have to pertain to the bug or feature in question. The BZ entry also
carries a whole lot of metadata, which is great for queries (the
simplest query is likely "what am I responsible for at the moment").

The mailing list is much more free-form. It frequently happens that the
discussion initially takes place on the list, and when a bug clearly
emerges, a BZ entry is opened. The mailing list supports multi-party
discussion much better than Bugzilla, through the threading of emails.

As Mike mentions, patches are submitted to the list. While Bugzilla can
accept patch attachments, display them as colorized diffs, and even
track some level of review for them, it's vastly inferior to reviews
done on the mailing list.

... I can't produce more (or any) "formal" guidelines for choosing
between Bugzilla and the mailing list, but in my experience they become
clear with use.

Thanks
Laszlo

> On Tue, Jul 19, 2016 at 7:24 PM, Kinney, Michael D
> mailto:michael.d.kin...@intel.com>> wrote:
> 
> Laszlo,
> 
> Thanks for the feedback.  A few responses embedded below.
> 
> I agree there are many ways to organize this content inside Bugzilla
> and that we can refine the products/components/fields as we use it.
> 
> Mike
> 
> > -Original Message-
> > From: Laszlo Ersek [mailto:ler...@redhat.com ]
> > Sent: Wednesday, July 6, 2016 12:53 PM
> > To: Kinney, Michael D  >
> > Cc: edk2-devel@lists.01.org 
> mailto:edk2-de...@ml01.01.org>>
> > Subject: Re: [edk2] [RFC] Email tags for Bugzilla and administrative 
> events
> >
> > On 07/06/16 20:52, Kinney, Michael D wrote:
> > > Laszlo,
> > >
> > > Good timing.  I was going to send a status update today.
> > >
> > > We are working diligently to get Bugzilla online for all bugs.  There
> > > are a few logistics that are still being worked this week related to
> > > an email list for bug state changes that Jordan is helping with and
> > > setting up tianocore domain name for the Bugzilla server.
> > >
> > > I see many developers have created accounts on the Bugzilla server
> > > that is in a test mode right now.  Thank you to everyone who has done
> > > that already!  If you have not done so, please go to the following
> > > link and create an account.
> > >
> > > https://tianocore.acgmultimedia.com
> > >
> > > Also, please enter some sample bugs and feature requests and review
> > > the fields.  Please send feedback if you would like to see any changes
> > > to the fields.
> > >
> > > I will send updates as tasks are completed as I also want to see us
> > > move to Bugzilla ASAP.  This is my highest priority task right now.
> >
> > I skimmed the "new bug page" (with the advanced fields shown) for
> > TestProduct -- from a cursory look, it's fine.
> >
> > Other than that, why is "Feature Requests" a separate product from "EDK2
> > - Main Trunk"? Same for "UEFI Security Issues". I think feature requests
> > and security issues should not be separate products. They should be
> > orthogonal to any product. In the RH Bugzilla at least, these "traits"
> > are represented by Keywords.
> 
> Security issues are in a separate product so we can associate then with
> the "infosec" group for evaluation in the UNCONFIRMED state and support
> the filtering of email contents if a security issue is embargoed for a
> period of time.  I am working on the detailed process that will be used
> for these types of issues and will update tianocore web pages with the
> details for both normal bugs and security issues.
> 
> I am working through a few details today to reduce the number of
> products.
> 
> * "Test Product" will be removed.  This was just to evaluate before
> going live.
> * I have renamed to "Tianocore Feature Requests".  This is to cover
> feature
>   requests not only for EDK II code/tools/docs, but also for things like
>   the web site, wiki pages, dev process, testing process, release
> process,
>   etc.
> * I am going to remove "UDK" and update "EDK2" to add a field to
> identify
>   both where the issue was observed (EDK2 trunk, UDK 2015, UDK 2014,
> etc).
>   and where the issue need to be fixed (EDK2 trunk, U

Re: [edk2] [RFC] Email tags for Bugzilla and administrative events

[Laszlo Ersek]

On 07/19/16 19:24, Kinney, Michael D wrote:
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, July 6, 2016 12:53 PM
>> To: Kinney, Michael D 
>> Cc: edk2-devel@lists.01.org 
>> Subject: Re: [edk2] [RFC] Email tags for Bugzilla and administrative events

>> Also, the multi-selection is not flexible enough to express dependencies
>> between packages (BZ cloning is).
> 
> Not sure I understand what you mean here.  Can you provide an example?

For example, assume that the UEFI spec defines a new protocol, and we'd
like to build something upon it in OvmfPkg. The protocol definition will
go into MdePkg, so on the new bug, the package will have to be ticked.
The reference implementation (a new DXE_DRIVER module) might go into
MdeModulePkg -- the second package to be ticked. The client code belongs
to OvmfPkg, which would be the third package to be ticked for the same
Bugzilla entry.

Instead, these could be three separate BZs, each filed for a separate
component (MdePkg, MdeModulePkg, OvmfPkg), and their dependencies would
be expressed through the "Blocks" BZ fields (each such relationship sets
the "Depends" field of the other BZ as well). Hence, the OvmfPkg BZ
would depend on both the MdePkg and the MdeModulePkg BZs, and the
MdeModulePkg BZ would depend on the MdePkg BZ.

BZ cloning is not a requirement, it just saves some typing, and it adds
another "hint" hat the BZs are related to the same larger bug or feature
group.

(Because, "Blocks" and "Depends" can stand for other kinds of dependency
as well. For example, FooPkg has two maintainers, and one of them is on
vacation, but it is known that he plans to refactor a good chunk of a
driver in FooPkg. The other maintainer of FooPkg would like to implement
a small addition to that driver, but it's just not right (although
perhaps possible) to implement that small addition before the larger
refactoring happens. In this case, Blocks / Depends are also fully
appropriate, but what they express is a different kind of dependency
(i.e., not "same feature group"), so cloning doesn't apply.)

In the MdePkg -> MdeModulePkg -> OvmfPkg example, the MdePkg bug would
be cloned for MdeModulePkg, then either the MdePkg or the MdeModulePkg
bug could be cloned for OvmfPkg. Cloning creates a new bug, sets
Blocks/Depends automatically, sets the "Clone Of" field on the new bug,
and appends the number of the new bug to the "Clones" field of the
original bug. (A bug may have several clones.) Finally, the last missing
link could be added manually (with Blocks / Depends) between (MdePkg or
MdeModulePkg) and OvmfPkg.

The best part is that Bugzilla can display BZs that are linked together
through dependencies in a graph-like view.

... I do understand that practically the same can be done if we express
packages as entries in a multi-selection box, not as components. The
three BZs can be opened the same way, their dependencies / clone
relationships can be set up the same way, we'd just tick exactly one
package line in the multi-selection box in each BZ.

My point was that if we simply tick all three of MdePkg, MdeModulePkg,
OvmfPkg on the same BZ, then "what depends on what" is not expressed in
Bugzilla.

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

[Tian, Feng]

Correct my words,

According to SD host controller spec,  the CRC field is ignored by h/c. user 
could only get the data between bit8 and bit127. 

Kind of Response|   Meaning of Response  |ResponseField
|ResponseRegister
--
R2 (CID, CSD register)|   CID or CSD reg. incl.  |   R [127:8]  
 |   REP [119:0]

So I don't think your fix is correct. Please correct me if I misunderstand.

Thanks
Feng

-Original Message-
From: Tian, Feng 
Sent: Wednesday, July 20, 2016 10:13 AM
To: Haojian Zhuang 
Cc: edk2-devel@lists.01.org; guodong...@linaro.org; leif.lindh...@linaro.org; 
ard.biesheu...@linaro.org; Tian, Feng 
Subject: RE: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

Hi, Haojian

Why I didn't get the lowest byte data is because it's CRC field. I thought 
nobody will care about it. My assumption is incorrect for your usage model?

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Haojian 
Zhuang
Sent: Tuesday, July 19, 2016 3:38 PM
To: Tian, Feng 
Cc: Haojian Zhuang ; edk2-devel@lists.01.org; 
guodong...@linaro.org; leif.lindh...@linaro.org; ard.biesheu...@linaro.org
Subject: [edk2] [PATCH] EmmcBlockIo: fix to get CSD data

The CSD structure is a 128-bit structure. But EmmcGetCsd() only loads
120 bits with 8-bit offset. Now fix it.

Signed-off-by: Haojian Zhuang 
---
 MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c 
b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
index fc705e1..fe85627 100644
--- a/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
+++ b/MdeModulePkg/Bus/Sd/EmmcDxe/EmmcBlockIo.c
@@ -191,9 +191,9 @@ EmmcGetCsd (
   Status = PassThru->PassThru (PassThru, Device->Slot, &Packet, NULL);
   if (!EFI_ERROR (Status)) {
 //
-// For details, refer to SD Host Controller Simplified Spec 3.0 Table 2-12.
+// Copy 128bit data for CSD structure.
 //
-CopyMem (((UINT8*)Csd) + 1, &SdMmcStatusBlk.Resp0, sizeof (EMMC_CSD) - 1);
+CopyMem ((VOID*)Csd, &SdMmcStatusBlk.Resp0, sizeof (EMMC_CSD));
   }
 
   return Status;
-- 
1.9.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel