UEFI spec requires CapsuleTarget to be a device path associated
with FMP producer.
Cc: Feng Tian
Cc: Star Zeng
Cc: Chao Zhang
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
---
MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 15
+++
Ray,
Yes, it is a problem.
After discussion with you, we can eliminate the call to IsQueueEmpty() as
Dequeue() has included the logic of IsQueueEmpty() and return status
accordingly.
I will resend the V2 patch series.
Thanks again for the comments. :)
Star
From: Ni, Ruiyu
Sent: Friday, Decembe
Reviewed-by: Ye Ting
-Original Message-
From: Wu, Jiaxin
Sent: Thursday, December 08, 2016 8:55 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Zhang, Lubo
; Wu, Jiaxin
Subject: [Patch] NetworkPkg/DnsDxe: Fixed the assert issue in DnsDxe
Fix the DnsDxe assert issue when th
Star,
I checked all your patches.
My comments to Patch 1/5 also apply to your other patches.
Regards,
Ray
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star
>Zeng
>Sent: Thursday, December 22, 2016 9:45 PM
>To: edk2-devel@lists.01.org
>Cc: Ni
Star,
Another comment: I think we need to use TPL_NOTIFY to guard the call to
IsQueueEmpty().
To simplify the code, how about create a EFI_LOCK (TPL_NOTIFY) to guard the
access to EfiKeyQueueForNotify?
EfiAcquireLock() can be used to replace the RaiseTPL().
Regards,
Ray
From: Zeng, Star
Sent:
Ray,
Good comment, it can make the code more clear, I agree it.
Thanks,
Star
-Original Message-
From: Ni, Ruiyu
Sent: Friday, December 23, 2016 3:01 PM
To: Zeng, Star ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Tian, Feng
; Zeng, Star
Subject: RE: [edk2] [PATCH 1/5] MdeModulePkg
Star,
I have one comment:
When call Enque(), can we put comments above the call to say that the key
notification
function needs to run at TPL_CALLBACK while current TPL is TPL_NOTIFY. It will
be called
in KeyNotifyProcessHandler() which runs at TPL_CALLBACK?
Regards,
Ray
>-Original Message-
Looks good to me.
Reviewed-by: Zhang Lubo
> -Original Message-
> From: Wu, Jiaxin
> Sent: Thursday, December 08, 2016 8:55 AM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Fu, Siyuan ; Zhang,
> Lubo ; Wu, Jiaxin
> Subject: [Patch] NetworkPkg/DnsDxe: Fixed the assert issue in DnsDxe
>
Jaben,
The assertion is to check caller instead of check user's input.
It's to make sure future modification won't break the parameter assumption of
this function.
It's like the below assertion in StrCpy:
ASSERT (Destination != NULL);
ASSERT (((UINTN) Destination & BIT0) == 0);
Regards,
Ray
Fr
Andrew:
edk2 build output lists all generated binary files. Could you use the binary
file without section header?
Thanks
Liming
> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Friday, December 23, 2016 1:07 PM
> To: Gao, Liming
> Cc: edk2-devel
> Subject
Andrew:
Yes. Linux Makefile supports IA32 and X64 both. Windows Makefile supports
IA32. Low level Makefile does handle IA32 and X64. But, BaseTools C source
codes are not verified. So now, 64bit Windows BaseTools C tools are not enabled.
Thanks
Liming
From: af...@apple.com [mailto:af...@apple.
> On Dec 22, 2016, at 8:59 PM, Gao, Liming wrote:
>
> Andrew:
> I am not clear your usage. Could you use source section and compressed
> section for the data before and after compression? Here, section means PI
> EFI section format file. Take Lzma compression as the example, source data
>
Thanks Liming And FIsh,
I will try your suggestion.
在 2016-12-23 12:54:23，"Andrew Fish" 写道：
On Dec 22, 2016, at 8:39 PM, Gao, Liming wrote:
Xiaofeng:
BaseTools Windows Makefile (BaseTools\Source\C\Makefile) sets ARCH = IA32. It
means BaseTools C tool passes IA32 arch only in Window
Andrew:
I am not clear your usage. Could you use source section and compressed
section for the data before and after compression? Here, section means PI EFI
section format file. Take Lzma compression as the example, source data is the
section stream. It may be combined of more than one secti
> On Dec 22, 2016, at 8:39 PM, Gao, Liming wrote:
>
> Xiaofeng:
> BaseTools Windows Makefile (BaseTools\Source\C\Makefile) sets ARCH = IA32.
> It means BaseTools C tool passes IA32 arch only in Windows OS. I don't try
> building it with X64 arch. You can update ARCH=X64, and try building
> B
Xiaofeng:
BaseTools Windows Makefile (BaseTools\Source\C\Makefile) sets ARCH = IA32. It
means BaseTools C tool passes IA32 arch only in Windows OS. I don't try
building it with X64 arch. You can update ARCH=X64, and try building BaseTools
with 64bit VS compiler. If you meet with warning or err
HI Fish,
Thanks for your answer. Actually I am not trying to build base tools . I am
writing a windows console tool and want to reuse some code of base tools common
library, All the changes will be in my platform packages, Due to some history
reason , my own tool is treating UINTN as x64 mode
Hi Jaben,
Version is 2.31... Revision is 4.653
Thanks.
Regards,
Keshava
On Thu, 22 Dec 2016 at 22:26 Carsey, Jaben wrote:
> That function is not in the shell library.
>
>
>
> LocateHandle would be useful is you wanted to find the image handle for
> the shell binary whereas LocaetProtocol would
The base tools width could be OS Specific so you should not depend on it. In
other words it has nothing to do with your ROM. You should code tools to exact
sizes, and only use UINTN if you don't care about size.
Sent from my iPhone
> On Dec 22, 2016, at 7:35 PM, wang xiaofeng wrote:
>
> Hi Ba
Hi Base tool owners,
I tried to build commonlib in basetools . And use the library file in my
own application tool . I just found the commonlib is build in IA32 mode ,this
means UINTN is 4 byte in the output lib. I expect to build a X64 mode
Common.lib ,can you help me?
Or base tools can
Cc: Ye Ting
Cc: Fu Siyuan
Cc: Wu Hao A
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin
---
NetworkPkg/HttpDxe/HttpImpl.c | 4 ++-
NetworkPkg/HttpDxe/HttpProto.c| 6 +++-
NetworkPkg/HttpDxe/HttpsSupport.c | 74 +++
3
Reviewed-by: Jeff Fan
-Original Message-
From: Zeng, Star
Sent: Thursday, December 22, 2016 9:45 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star; Ni, Ruiyu; Kinney, Michael D; Tian, Feng; Fan, Jeff
Subject: [PATCH 5/5] IntelFrameworkModulePkg KbDxe: Execute key notify func at
TPL_CALLBACK
Reviewed-by: Jeff Fan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Thursday, December 22, 2016 9:45 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Kinney, Michael D; Tian, Feng; Fan, Jeff; Zeng, Star
Subject: [edk2] [PATCH 4/5] I
Reviewed-by: Star Zeng
-Original Message-
From: Yao, Jiewen
Sent: Thursday, December 22, 2016 11:45 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star
Subject: [PATCH] MdeModulePkg/CapsuleLib: remove ImageIndex check.
UEFI specification does not require ImageIndex check, it onl
Reviewed-by: Star Zeng
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen
Yao
Sent: Thursday, December 22, 2016 1:48 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 0/2] Handle NULL capsule name in record.
According to UEFI spec, capsu
HI Even
Thank you for the response.
*Mike Kinney* is managing staging tree – he may help answer the question on
staging. ☺
I am glad to co-work with you on that.
Merry Christmas!
Thank you
Yao Jiewen
From: Evan Lloyd [mailto:evan.ll...@arm.com]
Sent: Friday, December 23, 2016 2:26 AM
To: Yao
Reviewed-by: Feng Tian
Thanks
Feng
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen
Yao
Sent: Thursday, December 22, 2016 1:48 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH 0/2] Handle NULL capsule name in record.
According to UEF
Reviewed-by: Feng Tian
Thanks
Feng
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiewen
Yao
Sent: Thursday, December 22, 2016 11:45 PM
To: edk2-devel@lists.01.org
Cc: Tian, Feng ; Zeng, Star
Subject: [edk2] [PATCH] MdeModulePkg/CapsuleLib: re
Hi Jiewen.
I hope I have our forename there, not your surname - it can be difficult to
tell :-)
I've trimmed a lot out of the history below, for clarity.
>
>From: Yao, Jiewen [mailto:jiewen@intel.com]
>Sent: 20 December 2016 16:35
>To: Evan Lloyd; Ni, Ruiyu; Carsey, Jaben; Sami Mujawar
>Cc:
That function is not in the shell library.
LocateHandle would be useful is you wanted to find the image handle for the
shell binary whereas LocaetProtocol would be just getting a pointer to the
protocol.
Which version of the UEFI Shell are you using? (what does “ver” command say)
-Jaben
From
UEFI specification does not require ImageIndex check,
it only requires ImageTypeId check.
Cc: Feng Tian
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao
---
MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c | 3 +--
1 file changed, 1 insertion
Current implementation executes key notify function in TimerHandler
at TPL_NOTIFY. The code change is to make key notify function
executed at TPL_CALLBACK to reduce the time occupied at TPL_NOTIFY.
The code will signal KeyNotify process event if the key pressed
matches any key registered and inser
Current implementation executes key notify function in TimerHandler
at TPL_NOTIFY. The code change is to make key notify function
executed at TPL_CALLBACK to reduce the time occupied at TPL_NOTIFY.
The code will signal KeyNotify process event if the key pressed
matches any key registered and inser
Current implementation executes key notify function in TimerHandler
at TPL_NOTIFY. The code change is to make key notify function
executed at TPL_CALLBACK to reduce the time occupied at TPL_NOTIFY.
The code will signal KeyNotify process event if the key pressed
matches any key registered and inser
Current implementation executes key notify function in TimerHandler
at TPL_NOTIFY. The code change is to make key notify function
executed at TPL_CALLBACK to reduce the time occupied at TPL_NOTIFY.
The code will signal KeyNotify process event if the key pressed
matches any key registered and inser
Current implementation executes key notify function in TimerHandler
at TPL_NOTIFY. The code change is to make key notify function
executed at TPL_CALLBACK to reduce the time occupied at TPL_NOTIFY.
The code will signal KeyNotify process event if the key pressed
matches any key registered and inser
Current implementation of keyboard driver executes key notify
function in TimerHandler at TPL_NOTIFY. The code change is to
make key notify function executed at TPL_CALLBACK to reduce
the time occupied at TPL_NOTIFY.
The code will signal KeyNotify process event if the key pressed
matches any key r
Register key notify for toggle state (CapsLock, NumLock and ScrollLock)
sync between multiple keyboards.
The implementation for this feature requires keyboard driver supports
EFI_KEY_STATE_EXPOSED, and turns on physical TextInEx partial key
report for toggle state sync.
The virtual TextInEx will re
Hi everyone
I have a platform that has a I2C device connected directly to a processor's
I2C pins.
Now I'm researching the way to send and receive information to this device.
The first idea we had was to use the I2C Protocol Stack, but I'd like to
clarify one point.
After reading the documentatio
Hi everyone
I have a platform that has a I2C device connected directly to a processor's
I2C pins.
Now I'm researching the way to send and receive information to this device.
The first idea we had was to use the I2C Protocol Stack, but I'd like to
clarify one point.
After reading the documentatio
Hi Jaben and Andrew, Thanks for the replies. Here's a small update.
I tried using *LocateProtocol*, and I get "*Status Not Found*" (%r would
print "Status Not Found").
I'm getting the same error status for *LocateHandle *too. I'm using
*BufferSize=0* and *Buffer=NULL* for getting the BufferSize.
W
Hi Jaben,
*>> Is there a reason that you are not using ShellLib to facilitate your
app functionality? That library makes lots of things a lot easier.*
I want to use EFI_SHELL_PROTOCOL->GetMapFromDevicePath in my app. Is there
any way to use it using ShellLib ?
*>> Why do you use LocateHandle a
42 matches
Mail list logo
