Re: [edk2] StdLib usage for drivers?

Breaking the Shell file-system dependency is very easy, if you don’t need file system support from StdLib. All you have to do is make sure that you don’t list DevMedia in your driver or application’s .inf file. That way no file system support is included. A similar thing can be done to

Re: [edk2] [PATCH 2/2] Revert "ShellPkg: Make the USB mouse behavior in 'edit' consistent with 'hexedit'."

Jaben, Sorry for using a wrong email address of you. Thanks, Ray > -Original Message- > From: Ni, Ruiyu > Sent: Thursday, July 7, 2016 12:37 PM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu ; Jaben Carsey > Subject: [PATCH 2/2] Revert

[edk2] [PATCH 2/2] Revert "ShellPkg: Make the USB mouse behavior in 'edit' consistent with 'hexedit'."

This reverts commit ee60bd2b6aa473fdff6af3bfc62203ed8ca5c52a. The above commit enhanced 'edit' to support text selection through mouse. But the code introduced some bugs resulting the text selection behavior is not very usable and potentially hang in certain platforms. So I'd like to revert this

[edk2] [PATCH 0/2] Revert some changes to make Shell edit stable

The two commits enhanced 'edit' to support text selection through mouse. But the code introduced some bugs resulting the text selection behavior is not very usable and potentially hang in certain platforms. Ruiyu Ni (2): Revert "ShellPkg/UefiShellDebug1CommandsLib: remove unused but set

Re: [edk2] [PATCH v2 0/2] MdeModulePkg/Ui: Remove the implicit dependency for libraries

Reviewed-by: Liming Gao > -Original Message- > From: Bi, Dandan > Sent: Thursday, July 07, 2016 11:41 AM > To: edk2-devel@lists.01.org > Cc: Gao, Liming ; Dong, Eric > Subject: [PATCH v2 0/2] MdeModulePkg/Ui: Remove the

[edk2] [PATCH v2 2/2] IntelFrameworkModulePkg/LegacyUi: Get legacy options when open legacy form

The LegacyBootMaintUiLib depends on the LegacyBootManagerLib to realize its functionality, the LegacyBootManagerLib may initialize after LegacyBootMaintUiLib, so the functionality of LegacyBootMaintUiLib may be incorrect. Now we fix this issue by executing the related codes when opening the legacy

[edk2] [PATCH v2 0/2] MdeModulePkg/Ui: Remove the implicit dependency for libraries

Patch 1 remove the implicit dependency between BootMaintenanceManagerUiLib and LeagcyBootMaintUiLib. Patch 2 remove the implicit dependency between LegacyBootMaintUiLib and LegacyBootManagerLib. Notes: v1->V2: -Patch 1:change the key value in vfr file and compare the question id when the form

[edk2] [PATCH v2 1/2] MdeModulePkg/BootMaintUiLib: Update menus when open BMM form

BootMaintenanceManagerUiLib depend on the LeagcyBootMaintUiLib to show the legacy menus. So we need to do the actions related to LegacyUi in BMM after the LeagcyBootMaintUiLib have been initialized. So now : 1). update menus (including legacy menus), 2) re-scan boot options (including legacy boot

Re: [edk2] UEFI driver for USB CDC ACM Serial device

Hi Feng, Thank you for your time. Yes, the PC is connected to board using USB cable. The board is running on Linux, and it is detected as CDC serial on PC. On Linux Host machine, the device works straightaway as ttyACM0: Would you suggest any reference driver in UEFI that I can refer for

Re: [edk2] multiprocessing in PEI?

Laszlo, On PEI phase, whatever it is normal boot or S3 boot, PEI memory allocation services should not allocate memory < 1 MB address. If any other PEIM module wants to allocate memory < 1 MB address, it has to scan Memory resource HOB to find the available memory range and build memory

Re: [edk2] UEFI driver for USB CDC ACM Serial device

Your info is insufficient. How is the usb2serial cable used to connect PC and the custom board? Usb port is connecting to PC and the opposite end, that is serial port, is connecting to the board? >From the dump of "devices" cmd, it looks like you are connecting them like >above way. And the

Re: [edk2] [patch 2/2] IntelFrameworkModulePkg/LegacyUi: Get legacy options when open legacy form

Open Action is also for question. So, please compare question ID in its call back function. > -Original Message- > From: Bi, Dandan > Sent: Tuesday, July 05, 2016 11:01 AM > To: edk2-devel@lists.01.org > Cc: Gao, Liming ; Dong, Eric > Subject:

Re: [edk2] [patch 1/2] MdeModulePkg/BootMaintUiLib: Update menus when open BMM form

Dandan: Please define KEY value like FORM_BOOT_ADD_ID, and check it in CallBack function. > -Original Message- > From: Bi, Dandan > Sent: Tuesday, July 05, 2016 11:01 AM > To: edk2-devel@lists.01.org > Cc: Gao, Liming ; Dong, Eric > Subject:

Re: [edk2] [patch] MdeModulePkg/HiiDB: Record fail info if fail to save data for EfiVarStore

Reviewed-by: Chao Zhang Thanks & Best regards Chao Zhang -Original Message- From: Bi, Dandan Sent: Tuesday, July 05, 2016 4:53 PM To: edk2-devel@lists.01.org Cc: Gao, Liming; Dong, Eric; Zhang, Chao B Subject: [patch] MdeModulePkg/HiiDB: Record fail info if

Re: [edk2] [patch] MdeModulePkg/HiiDB: Record fail info if fail to save data for EfiVarStore

Reviewed-by: Liming Gao > -Original Message- > From: Bi, Dandan > Sent: Tuesday, July 05, 2016 4:53 PM > To: edk2-devel@lists.01.org > Cc: Gao, Liming ; Dong, Eric ; > Zhang, Chao B > Subject:

Re: [edk2] StdLib usage for drivers?

Sounds good. So how about you contribute that coolness? :) > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Tim Lewis > Sent: Wednesday, July 06, 2016 2:21 PM > To: Carsey, Jaben ; af...@apple.com > Cc:

Re: [edk2] StdLib usage for drivers?

Jaben, thanks. I think we're on the same page as far as the pre-Shell limitations for paths. The downside of using this strategy is the code size overhead for UEFI drivers. BTW, we've extended the ShellLib to contain wrapper functions for nearly all Shell Protocol member functions. It makes

Re: [edk2] StdLib usage for drivers?

You are correct. Device paths always work fine. DevicePaths are what are in Boot and Driver variables. The missing piece is the conversion from FSX to the starting node. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Tim Lewis >

Re: [edk2] StdLib usage for drivers?

Sure, the FSx: names are created by the shell. So before the shell loads, there is no Shell protocol, so no mapping names. That means that the StdLib implementation statically linked with a UEFI driver will not find the Shell protocol and will not be able to match any volume names (FSx or

Re: [edk2] StdLib usage for drivers?

The daShell problem is easy to solve since it's just a StdLib internal "driver" that's registered among others like stdout,stderr,stdin. We can just stop it from registering to StdLib if we don't have the Shell available. If we disable PcdShellLibAutoInitialize, we'd have to be very careful to

Re: [edk2] StdLib usage for drivers?

Tim, Good catch. I did not consider HII stuff. If you use a UEFI Shell Spec defined "consistent map name", it works without the shell since that is a 1:1 conversion with DevicePath. If you use a Shell map name, then it can try, but there is no guarantee that enumerations are right. Using

Re: [edk2] StdLib usage for drivers?

Jaben -- I can certainly recall instances where drivers that publish HII setup pages load things from the disk (such as when checking for specific file names). I also seem to recall that the original EDK shell library was designed to that volume names were simply ignored if the shell protocol

Re: [edk2] StdLib usage for drivers?

The thing that I am trying to figure out is what LibC APIs is really needed by the driver? UEFI Drivers are not supposed to do things like FILE I/O, so who cares if they would fail if they were called… Sidenote: I think that daShell.c is only used when you ask LibC for things that come from

Re: [edk2] StdLib usage for drivers?

It works for libs. If you specify a specific LibraryClass implementation, it will not add a second of that library class. Side note: what if you turn off AutoInitialize PCD for the shell lib? That would get rid of your main issue (the constructor ASSERT)… then we can see what other issues

Re: [edk2] multiprocessing in PEI?

On 07/06/16 22:29, Andrew Fish wrote: > >> On Jul 6, 2016, at 1:27 PM, Laszlo Ersek wrote: >> >> On 07/06/16 22:07, Andrew Fish wrote: >>> On Jul 6, 2016, at 1:02 PM, Laszlo Ersek wrote: On 07/06/16 21:01, Kinney, Michael D wrote: >

Re: [edk2] StdLib usage for drivers?

> You can have different libs and different flags per driver. You use the {} syntax on the INF file in the components section. This is already done in the Shell.DSC to control PCDs separating the ShellLib when used for the shell compared to ShellLib used for shell applications. Thanks for

Re: [edk2] multiprocessing in PEI?

On 07/06/16 22:07, Andrew Fish wrote: > >> On Jul 6, 2016, at 1:02 PM, Laszlo Ersek wrote: >> >> On 07/06/16 21:01, Kinney, Michael D wrote: >>> Laszlo, >>> >>> Yes. It is possible to use CPU MP PPI on S3 resume. >>> >>> Jeff and I have been working on some proposed changes

Re: [edk2] multiprocessing in PEI?

> On Jul 6, 2016, at 1:27 PM, Laszlo Ersek wrote: > > On 07/06/16 22:07, Andrew Fish wrote: >> >>> On Jul 6, 2016, at 1:02 PM, Laszlo Ersek wrote: >>> >>> On 07/06/16 21:01, Kinney, Michael D wrote: Laszlo, Yes. It is possible to use CPU

Re: [edk2] StdLib usage for drivers?

> On Jul 6, 2016, at 1:13 PM, Michael Zimmermann > wrote: > > Andrew, > > the problem with multiple library instances is that this does only work > globally and it gets in your way if you need different versions of a > dependent library. > > In our case,

Re: [edk2] StdLib usage for drivers?

Andrew, Note: The ShellLib is not part of the shell spec. The ShellProtocol and ShellParametersProtocol are. The current ShellLib is designed to facilitate porting and writing of apps for the shell. The porting will become obsolete over time as we encounter fewer and fewer EDKShell apps.

Re: [edk2] StdLib usage for drivers?

Andrew, the problem with multiple library instances is that this does only work globally and it gets in your way if you need different versions of a dependent library. In our case, Applications/Drivers only depend on LibC, an LibC then depends on ShellLib which means we'd have to create another

Re: [edk2] multiprocessing in PEI?

> On Jul 6, 2016, at 1:02 PM, Laszlo Ersek wrote: > > On 07/06/16 21:01, Kinney, Michael D wrote: >> Laszlo, >> >> Yes. It is possible to use CPU MP PPI on S3 resume. >> >> Jeff and I have been working on some proposed changes to the >> CPU DXE and CPU PEIM modules to

Re: [edk2] multiprocessing in PEI?

On 07/06/16 21:01, Kinney, Michael D wrote: > Laszlo, > > Yes. It is possible to use CPU MP PPI on S3 resume. > > Jeff and I have been working on some proposed changes to the > CPU DXE and CPU PEIM modules to share the MP source code in an > MP library and eliminate the code duplication

Re: [edk2] StdLib usage for drivers?

> On Jul 6, 2016, at 12:44 PM, Michael Zimmermann > wrote: > > Andrew, > > sry for not reasing the Shell Spec but I think you can answer this faster. > Does the Spec prevent implementing such a 'pure-EFI' fallback by default so > we can use the same ShellLib

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

Re: [edk2] StdLib usage for drivers?

Andrew, sry for not reasing the Shell Spec but I think you can answer this faster. Does the Spec prevent implementing such a 'pure-EFI' fallback by default so we can use the same ShellLib globally? and follow-up question: Libraries are not compiled multiple times right? so If I would specify

Re: [edk2] StdLib usage for drivers?

> On Jul 4, 2016, at 11:17 AM, Marvin Häuser wrote: > > Daryl, Jaben, > > As you are the package maintainers of StdLib, could you please comment on the > situation? > If modifications to have StdLib working for drivers are welcome, I would > offer my help in

Re: [edk2] [RFC V2] Add more flexible PCD value formats in DEC/INF/DSC/FDF files

Jiewen, Yes. It would be possible to support an OFFSET() operator, but we would have to add checks for overlaps and break the build if there is an overlap of bytes in the buffer for the PCD. However, I want to emphasis that the purpose of this RFC is to initialize a VOID* PCD that cannot be

Re: [edk2] multiprocessing in PEI?

Laszlo, Yes. It is possible to use CPU MP PPI on S3 resume. Jeff and I have been working on some proposed changes to the CPU DXE and CPU PEIM modules to share the MP source code in an MP library and eliminate the code duplication between the current DXE driver and PEIM. We will review the

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

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

Re: [edk2] multiprocessing in PEI?

On 07/06/16 19:08, Laszlo Ersek wrote: > Hi Jeff, > > On 07/05/16 15:50, Fan, Jeff wrote: >> When CPU MP PPI installed, CPU MP PPI Services will be fully usable. > > I included CpuMpPei in OVMF, and it works fine on the normal boot path. > (I haven't done anything special with it thus far, just

Re: [edk2] multiprocessing in PEI?

Hi Jeff, On 07/05/16 15:50, Fan, Jeff wrote: > When CPU MP PPI installed, CPU MP PPI Services will be fully usable. I included CpuMpPei in OVMF, and it works fine on the normal boot path. (I haven't done anything special with it thus far, just built it into the firmware, and it starts up fine.)

Re: [edk2] [PATCH] OvmfPkg/build.sh: update gcc detection

On 2016-07-05 07:37:58, Laszlo Ersek wrote: > On 06/30/16 12:16, Laszlo Ersek wrote: > > On 06/30/16 07:00, Olaf Hering wrote: > >> On Wed, Jun 29, Jordan Justen wrote: > >> > >>> Missing Contributed-under. (See OvmfPkg/Contributions.txt) > >> > >> Looks like this project tries to avoid simple

Re: [edk2] [staging/HTTPS-TLS][PATCH] NetworkPkg: Centralize TlsCaCertificate name and guid

Reviewed-by: Thomas Palmer -Original Message- From: Jiaxin Wu [mailto:jiaxin...@intel.com] Sent: Monday, July 4, 2016 8:41 PM To: edk2-devel@lists.01.org Cc: Palmer, Thomas ; Ye Ting ; Fu Siyuan

Re: [edk2] [PATCH] [ShellPkg/UefiHandleParsingLib]: Fix GUID dereference

Reviewed-by: Jaben Carsey And push e06a4c0812cfac25a9eb1e8c851156fe19a29ab3. > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Thomas Palmer > Sent: Tuesday, June 28, 2016 11:22 AM > To: edk2-devel@lists.01.org > Cc:

Re: [edk2] [PATCH v2 0/4] ArmPkg: refactor MMU handling routines into separate ArmMmuLib

On 07/06/16 14:35, Ard Biesheuvel wrote: > On 4 July 2016 at 16:32, Leif Lindholm wrote: >> On Fri, Jul 01, 2016 at 05:43:52PM +0200, Ard Biesheuvel wrote: >>> The MMU routines are only used by a small subset of the users of ArmLib. >>> In order to prevent all those

Re: [edk2] [PATCH v2 0/4] ArmPkg: refactor MMU handling routines into separate ArmMmuLib

On Wed, Jul 06, 2016 at 02:35:30PM +0200, Ard Biesheuvel wrote: > On 4 July 2016 at 16:32, Leif Lindholm wrote: > > On Fri, Jul 01, 2016 at 05:43:52PM +0200, Ard Biesheuvel wrote: > >> The MMU routines are only used by a small subset of the users of ArmLib. > >> In order

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

(addressing Mike due to ) Mike, On 05/23/16 20:33, Mangefeste, Tony wrote: > Folks, > > I'm ramping up work on deploying the Bugzilla server for our > community. A few things you will begin to see, and your comments are > appreciated on

Re: [edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT 3079

> -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Ard Biesheuvel > Sent: Wednesday, July 06, 2016 3:57 PM > To: David Woodhouse > Cc: Ye, Ting; edk2-devel@lists.01.org; Cohen, Eugene; > leif.lindh...@linaro.org; Long, Qin > Subject: Re: [edk2]

Re: [edk2] [PATCH] EmbeddedPkg/AcpiLib: add GICC table init macro for ACPI 6.0

On 5 July 2016 at 22:15, Graeme Gregory wrote: > ACPI 6.0 added a processor efficiency field and 3 reserved bytes at the > end of the GICC structure so add a new macro to initialise the new > field. > > Contributed-under: TianoCore Contribution Agreement 1.0 >

Re: [edk2] [Patch] MdeModulePkg: Fix IPv4 stack potential disappeared issue

Reviewed-by: Fu Siyuan > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Jiaxin Wu > Sent: Thursday, June 30, 2016 3:59 PM > To: edk2-devel@lists.01.org > Cc: Ye, Ting ; Zhang, Lubo

Re: [edk2] [Patch] MdeModulePkg: Fix IPv4 stack potential disappeared issue

Reviewed-by: Ye Ting -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu Sent: Thursday, June 30, 2016 3:59 PM To: edk2-devel@lists.01.org Cc: Ye, Ting ; Zhang, Lubo ; Fu, Siyuan

Re: [edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT 3079

On 6 July 2016 at 09:30, David Woodhouse wrote: > On Tue, 2016-07-05 at 17:04 +, Long, Qin wrote: >> Yes, this unset issue was already fixed in OpenSSL HEAD. >> The patch is OK for me to ignore the warning for current 1.0.2 >> version. Or we can backport some cleanups

Re: [edk2] [PATCH] CryptoPkg: update openssl to ignore RVCT 3079

On Tue, 2016-07-05 at 17:04 +, Long, Qin wrote: > Yes, this unset issue was already fixed in OpenSSL HEAD. > The patch is OK for me to ignore the warning for current 1.0.2 > version. Or we can backport some cleanups into our 1.0.2xx patch.  My main concern is that we don't accumulate hacks

Re: [edk2] [patch] MdeModulePkg/BootMaintUi: Add error handling codes when AllocatePool fail

Reviewed-by: Hao Wu Best Regards, Hao Wu > -Original Message- > From: Bi, Dandan > Sent: Tuesday, July 05, 2016 4:53 PM > To: edk2-devel@lists.01.org > Cc: Dong, Eric; Wu, Hao A > Subject: [patch] MdeModulePkg/BootMaintUi: Add error handling codes when > AllocatePool