from:"Ramesh R ."

Re: [edk2] Question regarding CMOS regions.

2018-08-16 Thread Ramesh R .

1) To check the Extended RAM validity.



* Read the Offset 0 from Extended RTC Ram.

* If no 0 value, extended RTC Ram is present.

* If it's 0xFF, write some value to Offset 0

* Read it back. If you get the value that you wrote, extended RTC RAM 
is present and preserve the old value again.

* If you still get 0xFF, Extended RTC RAM is not present.



2) Extended RTC RAM is NOT duplicate of standard RTC RAM. It's up to BIOS 
vendor how they use it. May be BIOS uses the extended RTC RAM as duplicate copy 
of the standard RTC RAM.



Check the "Real Time Clock Registers" Section in the SB Spec.



Thanks,

Ramesh



-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
mohammadyounaskha...@dell.com
Sent: 16 August 2018 11:59
To: ruiyu...@intel.com; edk2-devel@lists.01.org
Subject: Re: [edk2] Question regarding CMOS regions.



Thanks Ruiyu.



I have some inconsistencies with CMOS regions. Even EDKII uses some CMOS 
regions.



I have attached the CMOS dump took using RW tool below:

Type:ISA   Port 0070,0071

Width:01

00=56 01=17 02=45 03=17 04=11 05=15 06=04 07=16

08=08 09=18 0A=26 0B=02 0C=50 0D=80 0E=00 0F=00

10=00 11=00 12=00 13=00 14=00 15=7B 16=02 17=FF 18=FF 19=00 1A=00 1B=00 1C=00 
1D=00 1E=00 1F=00

20=00 21=00 22=00 23=00 24=00 25=00 26=00 27=00

28=00 29=00 2A=00 2B=00 2C=00 2D=00 2E=02 2F=7B 30=FF 31=FF 32=20 33=00 34=00 
35=9D 36=0B 37=00

38=00 39=00 3A=00 3B=00 3C=00 3D=00 3E=00 3F=00

40=00 41=00 42=CA 43=B8 44=6C 45=58 46=00 47=00

48=00 49=00 4A=00 4B=00 4C=00 4D=00 4E=00 4F=00

50=00 51=00 52=00 53=00 54=03 55=00 56=00 57=00

58=00 59=00 5A=00 5B=00 5C=00 5D=00 5E=00 5F=00

60=00 61=00 62=00 63=00 64=00 65=00 66=00 67=00

68=00 69=00 6A=00 6B=00 6C=01 6D=00 6E=00 6F=A5

70=00 71=00 72=00 73=00 74=00 75=00 76=00 77=00

78=00 79=5F 7A=00 7B=00 7C=00 7D=00 7E=00 7F=00

80=56 81=17 82=45 83=17 84=11 85=15 86=04 87=16

88=08 89=18 8A=26 8B=02 8C=40 8D=80 8E=00 8F=00

90=00 91=00 92=00 93=00 94=00 95=7B 96=02 97=FF 98=FF 99=00 9A=00 9B=00 9C=00 
9D=00 9E=00 9F=00

A0=00 A1=00 A2=00 A3=00 A4=00 A5=00 A6=00 A7=00

A8=00 A9=00 AA=00 AB=00 AC=00 AD=00 AE=02 AF=7B B0=FF B1=FF B2=20 B3=00 B4=00 
B5=9D B6=0B B7=00

B8=00 B9=00 BA=00 BB=00 BC=00 BD=00 BE=00 BF=00

C0=00 C1=00 C2=CA C3=B8 C4=6C C5=58 C6=00 C7=00

C8=00 C9=00 CA=00 CB=00 CC=00 CD=00 CE=00 CF=00

D0=00 D1=00 D2=00 D3=00 D4=03 D5=00 D6=00 D7=00

D8=00 D9=00 DA=00 DB=00 DC=00 DD=00 DE=00 DF=00

E0=00 E1=00 E2=00 E3=00 E4=00 E5=00 E6=00 E7=00

E8=00 E9=00 EA=00 EB=00 EC=01 ED=00 EE=00 EF=A5

F0=00 F1=00 F2=00 F3=00 F4=00 F5=00 F6=00 F7=00

F8=00 F9=5F FA=00 FB=00 FC=00 FD=00 FE=00 FF=00



I have update my queries below.



Thank you,

Younas.

-Original Message-

From: Ni, Ruiyu [mailto:ruiyu...@intel.com]

Sent: Thursday, August 16, 2018 11:38 AM

To: Pathan, MohammadYounasKhan; 
edk2-devel@lists.01.org

Subject: RE: Question regarding CMOS regions.



Younas,

Why are you still working on CMOS in now UEFI world?

Detailed answer is in below.



Thanks/Ray



> -Original Message-

> From: edk2-devel 
> mailto:edk2-devel-boun...@lists.01.org>> On 
> Behalf Of

> mohammadyounaskha...@dell.com

> Sent: Thursday, August 16, 2018 12:44 PM

> To: edk2-devel@lists.01.org

> Subject: Re: [edk2] Question regarding CMOS regions.

>

> Hi Guys,

>

> Please help to reply to my below queries.

>

> Thank you,

> Younas.

>

> -Original Message-

> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of

> Pathan, MohammadYounasKhan

> Sent: Tuesday, August 14, 2018 9:17 AM

> To: edk2-devel@lists.01.org

> Subject: [edk2] FW: Question regarding CMOS regions.

>

> Hi All,

>

> As we know CMOS data can be 128 or 256 bytes. CMOS lower 128 bytes are

> stored in IO ports 0x70-0x71 whereas CMOS upper 128 bytes are stored

> using IO ports 0x72-0x73.

>

>   1.  How to know that the system has 128bytes of CMOS or 256 bytes of

> CMOS region?

You could read the data to know whether high 128 bytes are valid or not.

[Younas]: How to check the validity of data?



>   2.  Is there any CMOS location which represents CMOS upper region is

> exists or valid or any other mechanism for it?

Refer to #1.

[Younas]: CMOS upper region means port 0x72-0x73. Each IO port can store 256 
bytes of data (0x00-0xFF). Default lower CMOS region has date and time and is 
valid always. But for upper CMOS region, I am not sure how to check whether it 
is valid or not?

>   3.  Are we replicating lower 128 bytes to upper 128 bytes in CMOS

> location

> 0x70-0x71 (or 0x72-0x73)? If yes, Why are we doing that?

It depends on BIOS implementation. I don't see any bios is duplicating the 
contents.

[Younas]: You can refer to my CMOS dump copied above which shows upper 128bytes 
have same information as lower 128bytes (of

[edk2] Partition Driver started multiple times.

2017-09-12 Thread Ramesh R .

Hi,

Is there any reason why are we starting the partition driver again for the same 
partition if it's already started. 

  if (Status == EFI_ALREADY_STARTED) {
return EFI_SUCCESS;
  }

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

[edk2] Lower Case Letters in the String definition.

2017-08-28 Thread Ramesh R .

Hi,



Is the lower case letters allowed in the string definition ?



STRING_TOKEN (STR_DATA_BITS)



Example if we define like below we are getting build error. Is it expected one ?



STRING_TOKEN (STR_DATA_xBITS)



Thanks,

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

Re: [edk2] UEFI shell vs UEFI BIOS version compatibility

2017-05-23 Thread Ramesh R .

Hi,

  Old Shell was installing EFI_SHELL_INTERFACE and new shell is installing the 
EFI_SHELL_PARAMETERS_PROTOCOL on the shell application. 

Thanks,
Ramesh

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of GN 
Keshava
Sent: 23 May 2017 17:01
To: edk2-devel@lists.01.org
Subject: [edk2] UEFI shell vs UEFI BIOS version compatibility

Hi all,

I was using older version of UEFI shell (older EFI shell inside 
EdkShellBinPkg). It was working fine with my testing PCs (Intel core i5 (Dell 
Optiplex 7020) (UEFI ver 2.31) as well as Intel Gigabit motherboard (UEFI ver 
2.4)). I'm able to load any driver efi and use it.

Now I'm trying newer UEFI shell (UEFI Interactive shell v 2.2, the newer one in 
ShellBinPkg).
I'm trying to load my driver (and default Fat.efi driver downloaded from github 
as well) It is working fine with Intel Gigabit motherboard (UEFI ver 2.4). I'm 
able to load the driver and use it.
But if I try to load the same efi driver on newer UEFI shell v2.2 on Intel core 
i5 (Dell Optiplex 7020) (UEFI ver 2.31), display is just turning black, and I'm 
not able to use the shell any further. (But I'm able to load my custom shell 
application!)

What could be the issue? Any help is much appreciated.

Thanks.
With regards,
Keshava
___
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

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

2016-09-07 Thread Ramesh R .

Hi Eric,

   Memory Page size Minimum (MPSMIN) is not exposed in the  UEFI Scope. 

Any schedule when this issue would be address in the SCT tool ? 

Thanks,
Ramesh

-Original Message-
From: Jin, Eric [mailto:eric@intel.com] 
Sent: 05 September 2016 10:54
To: Tian, Feng; Ramesh R.; edk2-devel
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

"Memory Page size Minimum (MPSMIN)" is Controller Capability and impl-spec.
Is it possible for high level driver to get this attribute in UEFI scope?
To detect the  LIST LENGTH with (>8) buffer size and then get the whole list 
sounds like a reasonable method.

For SCT to handle this case, change the code to if(Status == EFI_SUCCESS) 
||(Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){


Thanks
Eric

-Original Message-
From: Tian, Feng 
Sent: Monday, September 5, 2016 11:18 AM
To: Ramesh R. <rame...@ami.com>; edk2-devel <edk2-devel@lists.01.org>; Jin, 
Eric <eric@intel.com>
Cc: Tian, Feng <feng.t...@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Ramesh,

I suspect even if you send the buffer size as 512 all the devices should return 
EFI_SUCCESS as well.

As for different NVMe device behavior for length 10, it may be different 
understanding on spec.

Eric, 

Do you know how to handle such case in SCT?

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Saturday, September 3, 2016 2:06 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel <edk2-devel@lists.01.org>; 
Jin, Eric <eric@intel.com>
Subject: Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng,

Some Nvme devices returns EFI_DEVICE_ERROR for the SCT test code ( when the 
buffer passed with 10 bytes) and that creates failure in the SCT report. 
Some Nvme devices returns EFI_SUCCESS also. 

All the devices return EFI_SUCCESS if the we send the buffer size as "Memory 
Page size Minimum (MPSMIN)"
   
Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 01 September 2016 8:12
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

I checked the ATA spec, it says the transfer length of "Trust-Send" ATA cmd 
should be 512.

But for NVMe and other SCSI device, I didn't see any length limitation on 
"Security Protocol In" cmd with security protocol field 0 and security protocol 
specific field 0.

It seems user could pass in any length value to get security protocol 
information. And last, user could get the whole one by passing down "supported 
security protocol list length" + 8.

Ramesh, do you meet real failure case?

Eric, what's your opinion on this?

Thanks
Feng

-Original Message-
From: Ramesh R. [mailto:rame...@ami.com] 
Sent: Wednesday, August 31, 2016 1:20 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel <edk2-devel@lists.01.org>; 
Jin, Eric <eric@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng,

  Any update or suggestion on this? Can we consider this as SCT tool issue and 
would be fixed in next version ?

Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 26 August 2016 12:54
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Yes, I agree it's weird. 

We are looking at this and will get back to you if we have findings.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Thursday, August 25, 2016 4:44 PM
To: edk2-devel <edk2-devel@lists.01.org>
Subject: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi,

   When the we run the 
"BootableImageSupportTest\StorageSecurityCommandProtocolTest" test on the NVME 
devices we are getting into error because of the below testing code.

//
// According to TCG definition, when the Security Protocol field is set to 
00h, and SP
// Specific is set to h in a TRUSTED RECEIVE command, return security 
protocol
// information. This Command is not associated with a security send command
//
Status = StorageSecurityCommand->ReceiveData (
   StorageSecurityCommand,
   BlockIo->Media->MediaId,
   1,// Timeout 
10-sec
   0,// 
SecurityProtocol
   0,// 
SecurityProtocolSpecifcData
   1

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

2016-09-07 Thread Ramesh R .

Hi Feng,

   With the device we have , we tried 512 as size and all the devices returns 
EFI_SUCCESS.

Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 05 September 2016 08:48
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Ramesh,

I suspect even if you send the buffer size as 512 all the devices should return 
EFI_SUCCESS as well.

As for different NVMe device behavior for length 10, it may be different 
understanding on spec.

Eric, 

Do you know how to handle such case in SCT?

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Saturday, September 3, 2016 2:06 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel <edk2-devel@lists.01.org>; 
Jin, Eric <eric@intel.com>
Subject: Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng,

Some Nvme devices returns EFI_DEVICE_ERROR for the SCT test code ( when the 
buffer passed with 10 bytes) and that creates failure in the SCT report. 
Some Nvme devices returns EFI_SUCCESS also. 

All the devices return EFI_SUCCESS if the we send the buffer size as "Memory 
Page size Minimum (MPSMIN)"
   
Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 01 September 2016 8:12
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

I checked the ATA spec, it says the transfer length of "Trust-Send" ATA cmd 
should be 512.

But for NVMe and other SCSI device, I didn't see any length limitation on 
"Security Protocol In" cmd with security protocol field 0 and security protocol 
specific field 0.

It seems user could pass in any length value to get security protocol 
information. And last, user could get the whole one by passing down "supported 
security protocol list length" + 8.

Ramesh, do you meet real failure case?

Eric, what's your opinion on this?

Thanks
Feng

-Original Message-
From: Ramesh R. [mailto:rame...@ami.com] 
Sent: Wednesday, August 31, 2016 1:20 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel <edk2-devel@lists.01.org>; 
Jin, Eric <eric@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng,

  Any update or suggestion on this? Can we consider this as SCT tool issue and 
would be fixed in next version ?

Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 26 August 2016 12:54
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Yes, I agree it's weird. 

We are looking at this and will get back to you if we have findings.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Thursday, August 25, 2016 4:44 PM
To: edk2-devel <edk2-devel@lists.01.org>
Subject: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi,

   When the we run the 
"BootableImageSupportTest\StorageSecurityCommandProtocolTest" test on the NVME 
devices we are getting into error because of the below testing code.

//
// According to TCG definition, when the Security Protocol field is set to 
00h, and SP
// Specific is set to h in a TRUSTED RECEIVE command, return security 
protocol
// information. This Command is not associated with a security send command
//
Status = StorageSecurityCommand->ReceiveData (
   StorageSecurityCommand,
   BlockIo->Media->MediaId,
   1,// Timeout 
10-sec
   0,// 
SecurityProtocol
   0,// 
SecurityProtocolSpecifcData
   10,   // 
PayloadBufferSize,
   DataBuffer,   // 
PayloadBuffer
   
   );
//
// for ATA8-ACS SecurityProtocol, 512 byte is a request
//
if (IsAtaDevice) {
  if((Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
} else {
  if((!EFI_ERROR(Status)) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
}

For Ata devices, EFI_DEVICE_ERROR considered as valid error case and for the 
Nvme ( Non ATA

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

2016-09-02 Thread Ramesh R .

Hi Feng,

Some Nvme devices returns EFI_DEVICE_ERROR for the SCT test code ( when the 
buffer passed with 10 bytes) and that creates failure in the SCT report. 
Some Nvme devices returns EFI_SUCCESS also. 

All the devices return EFI_SUCCESS if the we send the buffer size as "Memory 
Page size Minimum (MPSMIN)"
   
Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 01 September 2016 8:12
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

I checked the ATA spec, it says the transfer length of "Trust-Send" ATA cmd 
should be 512.

But for NVMe and other SCSI device, I didn't see any length limitation on 
"Security Protocol In" cmd with security protocol field 0 and security protocol 
specific field 0.

It seems user could pass in any length value to get security protocol 
information. And last, user could get the whole one by passing down "supported 
security protocol list length" + 8.

Ramesh, do you meet real failure case?

Eric, what's your opinion on this?

Thanks
Feng

-Original Message-
From: Ramesh R. [mailto:rame...@ami.com] 
Sent: Wednesday, August 31, 2016 1:20 AM
To: Tian, Feng <feng.t...@intel.com>; edk2-devel <edk2-devel@lists.01.org>; 
Jin, Eric <eric@intel.com>
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng,

  Any update or suggestion on this? Can we consider this as SCT tool issue and 
would be fixed in next version ?

Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 26 August 2016 12:54
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Yes, I agree it's weird. 

We are looking at this and will get back to you if we have findings.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Thursday, August 25, 2016 4:44 PM
To: edk2-devel <edk2-devel@lists.01.org>
Subject: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi,

   When the we run the 
"BootableImageSupportTest\StorageSecurityCommandProtocolTest" test on the NVME 
devices we are getting into error because of the below testing code.

//
// According to TCG definition, when the Security Protocol field is set to 
00h, and SP
// Specific is set to h in a TRUSTED RECEIVE command, return security 
protocol
// information. This Command is not associated with a security send command
//
Status = StorageSecurityCommand->ReceiveData (
   StorageSecurityCommand,
   BlockIo->Media->MediaId,
   1,// Timeout 
10-sec
   0,// 
SecurityProtocol
   0,// 
SecurityProtocolSpecifcData
   10,   // 
PayloadBufferSize,
   DataBuffer,   // 
PayloadBuffer
   
   );
//
// for ATA8-ACS SecurityProtocol, 512 byte is a request
//
if (IsAtaDevice) {
  if((Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
} else {
  if((!EFI_ERROR(Status)) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
}

For Ata devices, EFI_DEVICE_ERROR considered as valid error case and for the 
Nvme ( Non ATA) device it's considered as error. Could you please let us know 
why there is difference in this case ?.

Thanks,
Ramesh


___
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

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

2016-08-30 Thread Ramesh R .

Hi Feng,

  Any update or suggestion on this? Can we consider this as SCT tool issue and 
would be fixed in next version ?

Thanks,
Ramesh

-Original Message-
From: Tian, Feng [mailto:feng.t...@intel.com] 
Sent: 26 August 2016 12:54
To: Ramesh R.; edk2-devel; Jin, Eric
Cc: Tian, Feng
Subject: RE: BootableImageSupportTest\StorageSecurityCommandProtocolTest

Yes, I agree it's weird. 

We are looking at this and will get back to you if we have findings.

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ramesh R.
Sent: Thursday, August 25, 2016 4:44 PM
To: edk2-devel <edk2-devel@lists.01.org>
Subject: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi,

   When the we run the 
"BootableImageSupportTest\StorageSecurityCommandProtocolTest" test on the NVME 
devices we are getting into error because of the below testing code.

//
// According to TCG definition, when the Security Protocol field is set to 
00h, and SP
// Specific is set to h in a TRUSTED RECEIVE command, return security 
protocol
// information. This Command is not associated with a security send command
//
Status = StorageSecurityCommand->ReceiveData (
   StorageSecurityCommand,
   BlockIo->Media->MediaId,
   1,// Timeout 
10-sec
   0,// 
SecurityProtocol
   0,// 
SecurityProtocolSpecifcData
   10,   // 
PayloadBufferSize,
   DataBuffer,   // 
PayloadBuffer
   
   );
//
// for ATA8-ACS SecurityProtocol, 512 byte is a request
//
if (IsAtaDevice) {
  if((Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
} else {
  if((!EFI_ERROR(Status)) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
}

For Ata devices, EFI_DEVICE_ERROR considered as valid error case and for the 
Nvme ( Non ATA) device it's considered as error. Could you please let us know 
why there is difference in this case ?.

Thanks,
Ramesh


___
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] BootableImageSupportTest\StorageSecurityCommandProtocolTest

2016-08-25 Thread Ramesh R .

Hi,

   When the we run the 
"BootableImageSupportTest\StorageSecurityCommandProtocolTest" test on the NVME 
devices we are getting into error because of the below testing code.

//
// According to TCG definition, when the Security Protocol field is set to 
00h, and SP
// Specific is set to h in a TRUSTED RECEIVE command, return security 
protocol
// information. This Command is not associated with a security send command
//
Status = StorageSecurityCommand->ReceiveData (
   StorageSecurityCommand,
   BlockIo->Media->MediaId,
   1,// Timeout 
10-sec
   0,// 
SecurityProtocol
   0,// 
SecurityProtocolSpecifcData
   10,   // 
PayloadBufferSize,
   DataBuffer,   // 
PayloadBuffer
   
   );
//
// for ATA8-ACS SecurityProtocol, 512 byte is a request
//
if (IsAtaDevice) {
  if((Status == EFI_DEVICE_ERROR) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
} else {
  if((!EFI_ERROR(Status)) || (Status == EFI_WARN_BUFFER_TOO_SMALL)){
AssertionType = EFI_TEST_ASSERTION_PASSED;
  } else {
AssertionType = EFI_TEST_ASSERTION_FAILED;
  }
}

For Ata devices, EFI_DEVICE_ERROR considered as valid error case and for the 
Nvme ( Non ATA) device it's considered as error. Could you please let us know 
why there is difference in this case ?.

Thanks,
Ramesh


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

Re: [edk2] Memory Profile question.

2016-07-04 Thread Ramesh R .

Is there any way we can track the FreePool also ? In the end is it possible to 
identify which are all the memory area allocated, but no freed by system BIOS ?

Thanks,
Ramesh

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Andrew 
Fish
Sent: 30 June 2016 19:47
To: Yao, Jiewen
Cc: edk2-devel
Subject: Re: [edk2] Memory Profile question.


> On Jun 30, 2016, at 12:05 AM, Yao, Jiewen  wrote:
> 
> Yes, Andrew. You are right.
> We encounter similar problem, but it seems MSVC _ReturnAddress() does not 
> take parameter.
>  #define RETURN_ADDRESS(L) ((L == 0) ? _ReturnAddress() : (VOID *) 0)
> 

For GCC family you can potentially get more info. 

#define RETURN_ADDRESS(L) __builtin_return_address (L)

> So we enhanced MemoryAllocationLib to support add record from 
> MemoryAllocationLib.
> 

Does that mean the logging gets moved to the library? Or does the library log 
just update the log in the DXE Core?

> The final log is like this:
> 
>  CountSize   RVA  Action
> ==  == == 
> ()
> 0x006B  0x0001D31F <== 0xAE7C 
> (gBS->AllocatePool) (InternalAllocatePool() - 
> c:\home\edk-ii\mdemodulepkg\library\smmmemoryallocationlibprofile\memo
> ryallocationlib.c:567)
> 0x0001  0x0020 <== 0xBCB8 
> (Lib:AllocatePool) (SmmMemLibConstructor() - 
> c:\home\edk-ii\mdepkg\library\smmmemlib\smmmemlib.c:309)
> 0x0001  0x0070 <== 0x7F2D 
> (Lib:AllocateZeroRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 055)
> 0x0001  0xC000 <== 0x715A 
> (Lib:AllocateZeroRuntimePool) (InitNonVolatileVariableStore() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:3
> 692)
> 0x0001  0x00010400 <== 0x8121 
> (Lib:AllocateRuntimePool) (VariableCommonInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:4
> 113)
> 0x0001  0x0404 <== 0x2957 
> (gBS->AllocatePool) (VariableServiceInitialize() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variablesmm.
> c:956)
> 0x0007  0x01CE <== 0xC42E 
> (Lib:AllocateZeroRuntimePool) (VarCheckLibVariablePropertySet() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:521)
> 0x0001  0x0020 <== 0xC071 
> (Lib:ReallocateRuntimePool) (VarCheckAddTableEntry() - 
> c:\home\edk-ii\mdemodulepkg\library\varchecklib\varchecklib.c:228)
> 0x0001  0x0030 <== 0x2E08 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 96)
> 0x0001  0x0044 <== 0x2E68 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 00) 0x002C  0x0840 <== 0x2F98 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 32) 0x002C  0x037C <== 0x2FF6 
> (Lib:AllocateZeroPool) (UpdateVariableInfo() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:2
> 36)
> 0x0001  0x000D <== 0x4DC9 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 960)
> 0x0001  0x0012 <== 0x4CC4 
> (Lib:AllocateCopyRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 930)
> 0x0001  0x0012 <== 0x4D28 
> (Lib:AllocateRuntimePool) (AutoUpdateLangVariable() - 
> c:\home\edk-ii\mdemodulepkg\universal\variable\runtimedxe\variable.c:1
> 940)
> 
> 

Are the address ranges allocated tracked? Is it possible to look up an address 
and figure out where it got allocated? 

Any plans to add logging for stalls? You can dump events with a debugger 
script, so that is not as important. 

Thanks,

Andrew Fish

> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
>> Of Andrew Fish
>> Sent: Thursday, June 30, 2016 2:38 PM
>> To: edk2-devel 
>> Subject: [edk2] Memory Profile question.
>> 
>> I've done some experimentation on the memory logging and if possible 
>> it is very useful to have 4 stack frames (non-LTO)  as it is common 
>> for the MemoryAllocationLib to to call a sequence of Internal 
>> functions, so to find the calling spot in the driver you need 4 entries.
>> For example:
>> FunctionThatAllocatePool()
>> AllocateZeroPool()
>> InternalAllocateZeroPool()
>> InternalAllocatePool()
>> 
>>

Re: [edk2] Question regarding CMOS regions.

[edk2] Partition Driver started multiple times.

[edk2] Lower Case Letters in the String definition.

Re: [edk2] UEFI shell vs UEFI BIOS version compatibility

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

[edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Re: [edk2] Memory Profile question.

10 matches

Site Navigation

Mail list logo

Footer information