After internal discussion, we agree default opcode can support ordered list
opcode, I will follow up to enable it.
For your proposal, item 2 I think it's not an acceptable proposal, take below
code for example:
orderedlist
varid = MyIfrNVData.BootOrder,
EDK2 builds with 'warning level 4' when using Microsoft tools. For the
most part, that enables desirable warnings similar to those provided by
gcc -Wall. There is one major difference though, Microsoft warning level
4 warns about the routine practice of assigning a larger size integer to
a smaller
Hi Baranee,
PhysicalPresenceData.h is based on TCG specification and used for TPM1.2.
TrEEPhysicalPresenceData.h is based on MSFT specification
(http://msdn.microsoft.com/en-us/library/windows/hardware/jj923067.aspx) and
used for TPM2.0.
So it is not necessary to put them together.
Thanks,
Guo
Again, these are EDK2 decisions. They are not limitations of the specification.
The UEFI specification does not indicate that the EFI_IFR_ONE_OF_OPTION default
flag cannot work for ordered list. The UEFI specification does not say that
there is any limitation to the default opcode. It does not s
For ordered list opcode, we not support set default flags in the option field.
It is useful for oneof opcode not for ordered list opcode. Also I think your
proposal of item 2) also not acceptable. We not support set default value
through option for ordered list opcode.
The value for ordered list
The patch is good. Reviewed-by: Gao, Liming
From: Chen, Hesheng
Sent: Wednesday, September 03, 2014 9:05 AM
To: edk2-devel@lists.sourceforge.net; Gao, Liming
Subject: [edk2] [BaseTools] [Patch] Add a step to convert ":\\" to ":\"
Hello Liming,
Could you help review this patch? Thank you
This p
Hello Liming,
Could you help review this patch? Thank you
This patch is going to:
1. Convert ":" to ":\\", because it doesn't work with
WINDOWS_EXTENSION_PATH.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hess Chen mailto:hesheng.c...@intel.com>>
Best Rega
On 09/03/14 00:43, Toto Lebolo wrote:
> I would like to write a device driver on Minnowboard to access hardware
> resources. Is there a sample code to start with? I've tried the BlankDrv
> for nt32 from Intel but it doesn't seems to work fine on the minnowboard.
> Any suggestion is welcome.
http:/
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
Calls to constructors of interdependent library instances are generated in
the correct order only if all library instances in question have
constructors. If some have no constructors, then the rest may see their
constructors called out of order.
Cycle detection also only works when all library ins
The PCD Inf files contain this section in the header, describing the format of
the FFS file that is integrated with the PcdPei and PcdDxe modules. But two
fields are left undocumented: SkuIdTable and SystemSkuId.
Is there any further documentation elsewhere about the format of these sections/
T
I would like to write a device driver on Minnowboard to access hardware
resources. Is there a sample code to start with? I've tried the BlankDrv for
nt32 from Intel but it doesn't seems to work fine on the minnowboard.
Any suggestion is welcome.
MiKL~--
On 09/02/14 22:31, Ard Biesheuvel wrote:
> The need for the false dependency seems to be caused by the fact that
> AutoGen.py does not consider constructor ordering dependencies to be
> transitive via a library that has no constructor itself. In
> particular, my SerialPortLib's indirect dependency
I have a crash but it was caused by bad GDT loaded by AsmPrepareThunk16.
This is for X64 arch.
And the reason is that _BackFromUserCode.Base has a wrong symbol address.
Thus all calculations related to are wrong too.
I messed up with NASM and my environments a bit. I was still using NASM 2.09
whil
Eric -
I believe that what you say is useful. But I don't think the specification
describes that behavior.
The next question, which was asked by someone else on the EDK2 list, is what to
do with "default" Both the flag for the "option" and the separate "default"
opcode. The "just the value for
On 2 September 2014 15:06, Laszlo Ersek wrote:
> Let's revive this old thread:
>
> On 09/11/13 03:38, Andrew Fish wrote:
>
>> A dependency tree is constructed so the library constructors get
>> called in the correct sequence. If it does not work it is likely a
>> bug in the libraries INF file not
SecurityPkg maintainers,
Can we have a common header file based on TCG PPI specification for both TPM1.2
and TPM2 instead of defining equates in PhysicalPresenceData.h and
TrEEPhysicalPresenceData.h?
-Baranee
CONFIDENTIALITY NOTICE: The information contained in this e-mail and any
accompanying
Reviewed-by: Jaben Carsey
Commit 16037
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Wednesday, August 27, 2014 3:40 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] ShellPkg: Cleanup UefiShellDebug1CommandsLib strings
Jaben,
Can you please review this
Reviewed-By: Jaben Carsey
mailto:jaben.car...@intel.com>>
Commit 16036
Note: One of the .c files has a copyright and nothing else changed. I did not
check this file in with the others.
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com]
Sent: Wednesday, August 27, 2014 3:35 PM
T
Reviewed-by: Jaben Carsey
Commit 16035
> -Original Message-
> From: Scott Duplichan [mailto:sc...@notabs.org]
> Sent: Tuesday, September 02, 2014 12:36 PM
> To: Carsey, Jaben
> Cc: edk2-devel@lists.sourceforge.net
> Subject: RE: [edk2] ShellPkg: Refactor string manipulation in commands (
Hello Jaben,
The patch is attached.
Thanks,
Scott
--
ShellPkg: Prevent StrnCpy from overwriting null terminator when source is
larger than destination.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Scott Duplichan
--
-Original Message-
From: Carsey, Jaben
I could not make this work. I am trying to create a simple driver.
Anybody can help?
MiKL~
--
Slashdot TV.
Video for Nerds. Stuff that matters.
http://tv.slashdot.org/___
edk2-
Ting,
Thanks for the feedback. I agree with your suggestions. I will resubmit the
patch with thie change to use protocol notification event instead of a single
check.
From: Ye, Ting [mailto:ting...@intel.com]
Sent: Monday, September 01, 2014 9:06 PM
To: edk2-devel@lists.sourceforge.net
Subjec
Jaben,
Any update on this?
From: El-Haj-Mahmoud, Samer
Sent: Wednesday, August 27, 2014 5:40 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [PATCH] ShellPkg: Cleanup UefiShellDebug1CommandsLib strings
Jaben,
Can you please review this one as well. We plan on submitting a few more
sim
Jaben,
Any update on this patch?
From: El-Haj-Mahmoud, Samer
Sent: Wednesday, August 27, 2014 5:35 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] ShellPkg: SmbiosView updates
Attached with the UNI file
From: El-Haj-Mahmoud, Samer
Sent: Wednesday, August 27, 2014 4:21 PM
To:
Reviewed-by: Jaben Carsey
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Tuesday, September 02, 2014 3:42 AM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [PATCH] ShellPkg: Add DXE_DRIVER class type to some libraries
Importance: High
Dear ShellPkg maintainer,
Pleas
Reviewed-by: Jaben Carsey
From: Olivier Martin [mailto:olivier.mar...@arm.com]
Sent: Tuesday, September 02, 2014 3:40 AM
To: Carsey, Jaben
Cc: edk2-devel@lists.sourceforge.net
Subject: [PATCH] ShellPkg: Fix dynamic command help
Importance: High
Dear ShellPkg maintainer,
Please find the attach
Good point.
Do you want to submit a patch?
> -Original Message-
> From: Scott Duplichan [mailto:sc...@notabs.org]
> Sent: Saturday, August 30, 2014 10:10 PM
> To: edk2-devel@lists.sourceforge.net; Carsey, Jaben
> Subject: RE: [edk2] ShellPkg: Refactor string manipulation in commands (#6)
Reviewed-by: Jaben Carsey
Thanks for the help!
From: Gao, Liming
Sent: Sunday, August 31, 2014 12:54 AM
To: Carsey, Jaben; Qiu, Shumin
Cc: edk2-devel@lists.sourceforge.net
Subject: [Patch] ShellPkg Build Failure
Importance: High
Jaben:
Could you help review this patch?
ShellPkg Build failu
On Sep 2, 2014, at 9:15 AM, Olivier Martin wrote:
> So there are two solutions. Either we do not support GCC 3.4.2 (and RHEL 5.8)
> or we add a build condition into the makefile to select the appropriate set
> of flags.
> I personally do not have any preference as soon as the message is clear.
On 09/02/14 17:48, Reza Jelveh wrote:
> On 02/09/14 17:38, Laszlo Ersek wrote:
>> Are you asking if this code would be acceptable in another *Pkg/
>> directory, distinct from OvmfPkg/?
>>
>> In that case, you'd still have to comply with *that* package's
>> "Contributions.txt" and "License.txt". And
So there are two solutions. Either we do not support GCC 3.4.2 (and RHEL
5.8) or we add a build condition into the makefile to select the appropriate
set of flags.
I personally do not have any preference as soon as the message is clear.
From: Andrew Fish [mailto:af...@apple.com]
Sent: 02 Sept
On Sep 2, 2014, at 3:45 AM, Olivier Martin wrote:
> Dear BaseTools maintainer,
>
> GCC 3.4.2 does not support this compiler flag.
> It prevents to build BaseTools on RHEL 5.8.
>
Olivier,
Clang will not compile the tools without -Wno-self-assign, so this change will
break clang.
gcc -c
Hi
Is that possible to use different package for difference FileSystem driver?
Different file system may have require licenses.
I am not clear about HFS, UDF, but it seems FAT and EXT2 are different.
Thank you
Yao, Jiewen
-Original Message-
From: Reza Jelveh [mailto:reza.jel...@tuhh.de]
On 02/09/14 17:38, Laszlo Ersek wrote:
> Are you asking if this code would be acceptable in another *Pkg/
> directory, distinct from OvmfPkg/?
>
> In that case, you'd still have to comply with *that* package's
> "Contributions.txt" and "License.txt". And they all look like OvmfPkg's.
>
> (Except
On 09/02/14 17:06, Reza Jelveh wrote:
> On 02/09/14 16:42, Laszlo Ersek wrote:
>> On 09/02/14 15:41, Reza Jelveh wrote:
>>> I just noticed that my email had an empty body.
>>>
>>> Can anyone comment on how we could get this into the codebase?
>>>
>>>
>>> 0011-OvmfPkg-add-a-HfsPlus-driver.patch
>>
>
On 02/09/14 16:42, Laszlo Ersek wrote:
> On 09/02/14 15:41, Reza Jelveh wrote:
> > I just noticed that my email had an empty body.
> >
> > Can anyone comment on how we could get this into the codebase?
> >
> >
> > 0011-OvmfPkg-add-a-HfsPlus-driver.patch
>
> This code is GPL / CDDL dual-licensed
On 09/02/14 15:41, Reza Jelveh wrote:
> I just noticed that my email had an empty body.
>
> Can anyone comment on how we could get this into the codebase?
>
>
> 0011-OvmfPkg-add-a-HfsPlus-driver.patch
This code is GPL / CDDL dual-licensed. You're trying to add it to OvmfPkg.
See OvmfPkg/Contri
Yeap, splitting FdtLib into FdtLib and FdtLoadLib is fine for me.
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 02 September 2014 13:53
> To: Laszlo Ersek
> Cc: edk2-devel@lists.sourceforge.net; Olivier Martin; Peter Maydell;
> Andrew Jones; Christo
Just checked this commit and resultant merge looks good.
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Friday, August 29, 2014 3:24 PM
To: Shah, Tapan; edk2-devel@lists.sourceforge.net
Cc: El-Haj-Mahmoud, Samer; Phillips, Chris J (Plano, TX); Carsey, Jaben
Subject: RE: ShellPkg: Add ne
On 09/01/2014 01:54 AM, Thomas Rognon wrote:
> If you just want debug output and you have the proper hardware/drivers
> to send/receive serial output through USB (like with Intel's
> Minnowboard), you can use any terminal, like PuTTY, and connect via serial.
>
> If you need breakpoints and stepping
Let's revive this old thread:
On 09/11/13 03:38, Andrew Fish wrote:
> A dependency tree is constructed so the library constructors get
> called in the correct sequence. If it does not work it is likely a
> bug in the libraries INF file not listing the LibraryClass it depends
> on. If the driver a
On 29 August 2014 12:58, Laszlo Ersek wrote:
> On 08/29/14 10:14, Ard Biesheuvel wrote:
>> On 29 August 2014 09:53, Ard Biesheuvel wrote:
>
>>> build.py...
>>> /home/ard/build/uefi-next/ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc(...):
>>> error 1001: Module type [SEC] is not su
On 02/09/14 05:21, Tian, Feng wrote:
> Hi, Sava
>
> From my side, I am ok with integrating these two cases into one.
>
> Please help review and verify if the attached patch is ok for Qemu and
> Marvel’s AHCI controller.
>
Looks good from my side. Agreed with the comment issue.
On 01/09/14 15:29, A. Sava wrote:
> As we add now Ahci support, we probably should also add Ahci support to Csm
> module (IntelFrameworkModulePkg/Csm/LegacyBiosDxe), otherwise Ahci devices
> won't appear as Legacy entries.
Can you elaborate on this please? Why is this needed?
On 08/30/14 02:34, Zir Blazer wrote:
> First of all, I want to say that I'm not developer and know very little
> about programming, so if you need more info that what I'm currently
> providing, please be as detailed as possible to tell me how to get you
> it. I usually achieve some success when I f
Dear BaseTools maintainer,
GCC 3.4.2 does not support this compiler flag.
It prevents to build BaseTools on RHEL 5.8.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Olivier Martin
Regards,
Olivier
BaseTools-Source-C-Removed-Wno-self-assign-from-Makefile.pat
Dear ShellPkg maintainer,
Please find the attached patch.
Shell Libraries can now be used from Platform Drivers with the introduction
of the Shell Dynamic Command Protocol.
Adding DXE_DRIVER class allows to use these libraries with this class of
driver.
Contributed-under: TianoCore Contri
Dear ShellPkg maintainer,
Please find the attached patch that:
- Uses Shell Help print function that understands Shell Man Page format.
- Moves Dynamic help print above the catchall case otherwise the help is
printed multiple times in case of man page format.
Contributed-under: TianoCo
Ok, let's give a bit more Timer context. We should get something like:
- ArmPkg/Library/ArmLib: Helper functions to access the generic timer registers
(including physical and virtual counters)
- ArmPkg/Include/Library/ArmGenericTimerCounterLib.h: Definition of the Generic
Timer Counter library
Andrew,
.align 3 cannot pass GCC 4.6 build. Why do you add it? Is it typo?
/DEBUG_GCC46/X64/UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib/OUTPUT/X64/ExceptionHandlerAsm.iii:30:
Error: alignment not a power of 2
Thanks!
Jeff
From: Andrew Fish [mailto:af...@apple.com]
Sent:
Thanks Feng, looks good. I tested with Qemu, it works fine (I do not have
Marvell hardware currently to test with that).
Perhaps the following comment should be reconsidered, as it doesn't
correspond to the new code:
// For PIO IN transfer, D2H means a device error. Therefore we only need to
check
After PartitionDxe driver enumerates all child partitions and install
BlockIo/BlockIo2, DiskIo driver's driver binding functions will run again at
those new child handles to produce DiskIo.
Thanks
Feng
From: tiger...@via-alliance.com [mailto:tiger...@via-alliance.com]
Sent: Tuesday, September 0
63 matches
Mail list logo
