@lists.sourceforge.net; ler...@redhat.com;
olivier.mar...@arm.com; af...@apple.com; Cohen, Eugene; jiewen@intel.com
Cc: yingke.d@intel.com; matt.flem...@intel.com; Ard Biesheuvel
Subject: [PATCH 2/2] ArmVirtPkg: build runtime drivers with 64 KB section
alignment
This adds the 64 KB
Reviewed-by: Eugene Cohen
Thanks.
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Monday, June 29, 2015 12:37 PM
To: edk2-devel@lists.sourceforge.net; ler...@redhat.com;
olivier.mar...@arm.com; af...@apple.com; Cohen, Eugene; jiewen@intel.com
Cc
> the Property Table support in UEFI 2.5 requires the use of an explicit linker
> script so that sections are 4 KB aligned, and .text and .data are guaranteed
> not to share a 4 KB page frame, again for allowing them to be mapped with
> different permissions. This maps poorly onto AArch64, ag
> + * Since some AArch64 code is aligned to 0x800 (i.e., the vector table), we
> + * need to use at least this alignment for .text.
>From what I can see the vector table code uses .align directives to increase
>the alignment size which is propagated into the resulting ELF. The PE-COFF
>conv
r sees global variables correctly
On 18 June 2015 at 00:01, Cohen, Eugene wrote:
> Thanks for the great feedback -- you made me do more homework than I was
> expecting which is not a bad thing.
>
> Since we understand the problem and the fix, I think it's time to get
> Oliv
Subject: Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the
correlation .text and .data is consistent between ELF and PE-COFF so the
debugger sees global variables correctly
> On Jun 17, 2015, at 3:01 PM, Cohen, Eugene wrote:
>
> Thanks for the great feedback -- you made m
variables correctly
On 16 June 2015 at 22:32, Cohen, Eugene wrote:
>> OK. so does that mean we are using a builtin linker script for
>> AArch64? That sounds fragile to me ...
>
> Apparently we are using the builtin script. I learned that this can be
> queried with the
June 16, 2015 9:21 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] BaseTools for AArch64 GCC: Ensure that the
correlation .text and .data is consistent between ELF and PE-COFF so the
debugger sees global variables correctly
On 16 June 2015 at 16:50, Cohen, Eugene wrote:
>>
seTools for AArch64 GCC: Ensure that the
correlation .text and .data is consistent between ELF and PE-COFF so the
debugger sees global variables correctly
On 4 June 2015 at 21:48, Cohen, Eugene wrote:
> Oops, left off the contribution agreement line, trying again
>
> Dear ArmPkg maintain
Dear ArmPkg maintainers,
As I've been working towards an ARM implementation of SMM, I ran into an issue
with the organization of exception handling code in edk2. Today we have
exception handlers in the CpuDxe driver and another set in
DebugAgentSymbolsBaseLib which is pulled in by SEC. Since
sage-
From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Thursday, June 04, 2015 5:36 PM
To: Cohen, Eugene; edk2-devel@lists.sourceforge.net
Subject: RE: PiSmmIpl SMRAM Reservation Logic
Hi Eugene
Thanks to catch this.
Yes, I fully agree with you that the hidden assumption should be removed here.
Oops, left off the contribution agreement line, trying again
Dear ArmPkg maintainers (and later BaseTools maintainer),
This is a fix for debugger correlation of global variables for AArch64 built on
GCC.
Before this change looking at global variables with a debugger showed bogus
memory locatio
e) or even go so far as
to split the descriptor into multiple ones. I'd like to hear what the module
maintainer prefers to do.
Eugene
-Original Message-----
From: Cohen, Eugene
Sent: Thursday, June 04, 2015 1:02 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] PiSmmIpl SMRAM R
I've been debugging an SMM IPL issue and have isolated it to an assumption in
the SMRAM range reservation logic in SmmIplEntry. The logic checks to see if
the reserved range resides within the SMRAM descriptor and if it does it
reduces the size of the SMRAM range by the start address of the res
Dear ArmPkg maintainers (and later BaseTools maintainer),
This is a fix for debugger correlation of global variables for AArch64 built on
GCC.
Before this change looking at global variables with a debugger showed bogus
memory locations. This is because the offset of the .data section in the ELF
Dear ArmPkg maintainers,
I'm trying to debug AArch64 code built with Linaro GCC and don't have proper
correlation for global variables.
I'm digging into how .data/.bss is correlated across ELF and PE-COFF and I see
different offsets (in ELF the data appears to be 64KB higher up than PE-COFF).
:af...@apple.com>> wrote:
On May 29, 2015, at 9:23 AM, Cohen, Eugene
mailto:eug...@hp.com>> wrote:
Dear edk2 tools experts,
We are trying to invoke Signtool to sign applications (module type
UEFI_APPLICATION) in the edk2 build with a development key. After reviewing
the FDF a
? Is all of the following functions have platform specific code, or they can
be re-used from any of the PCI code like ARmJunoPkg etc? Are all these
functions definitions mendatory?
You have to implement the host bridge and root bridge protocols. When you
implement a protocol you must implemen
ol to review patches because it is difficult to compare changes
between pull-request (or at least it was not last time I tried). But email code
review is not better on this point neither. And Gerrit do it pretty well.
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: 16 May 2015
Dear edk2 tools experts,
We are trying to invoke Signtool to sign applications (module type
UEFI_APPLICATION) in the edk2 build with a development key. After reviewing
the FDF and build specifications I've been unable to find a way to invoke this
correctly.
We were trying to create a build r
Olivier (or if you prefer "Dear ArmPkg and ArmPlatformPkg maintainer"),
Here are three patches (in addition to the one I sent earlier) to fix issues I
encountered booting the FVP Base platform using SEC from ArmPlatformPkg instead
of Trusted Firmware. This boot path is still one where SEC runs
Andy,
DXE drivers are not sufficient for this use case - this is what UEFI Driver
Binding is for. This has been an outstanding issue for ARM for a few years
now. We need to define a bus protocol like PCI_IO that handles memory-mapped
SoC peripherals like the two SDIO controllers. With a bus
This patch fixes a crash in PEI on the AArch64 FVP platform when using SEC for
EL3. The current SEC code is not performing initialization of the TZC-400
TrustZone controller such that DRAM is not usable by PEI in EL2. This is a
minimal fix - long term a library abstraction for the TZC-400 woul
to:sc...@notabs.org]
Sent: Monday, May 04, 2015 8:52 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] Windows GCC build issues with echo
Cohen, Eugene [mailto:eug...@hp.com] wrote:
]Sent: Monday, May 04, 2015 07:45 AM
]To: edk2-devel@lists.sourceforge.net
]Subject: [edk2] Windows GCC
I'm seeing this issue building edk2 with GCC on Windows - in this case Aarch64
but I think the issue may be common to all gcc-on-Windows situations.
tools_def has this stuff for bypassing the objcopy stage:
*_*_*_OBJCOPY_PATH = echo
*_*_*_OBJCOPY_FLAGS = objcopy not need
[mailto:jordan.l.jus...@intel.com]
Sent: Friday, November 14, 2014 2:37 PM
To: edk2-devel@lists.sourceforge.net; Cohen, Eugene
Cc: Felix Poludov
Subject: Re: [edk2] DXE Services: SetMemorySpaceCapabilities is missing
On 2014-11-14 12:48:10, Cohen, Eugene wrote:
> As discussed offline, here i
As discussed offline, here is a patch for review as provided by HP and then
updated by Intel (thanks!).
Please review.
Signed-off-by: Eugene Cohen
From: Zeng, Star [mailto:star.z...@intel.com]
Sent: Friday, October 31, 2014 5:59 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] DXE
Siyuan,
Thanks, this patch fixed the issue for us. Much appreciated.
Reviewed-by: Eugene Cohen
-Original Message-
From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Wednesday, October 29, 2014 7:58 PM
To: Cohen, Eugene
Cc: edk2-devel@lists.sourceforge.net; Tian, Feng
Subject: RE
Dear MdeModulePkg maintainer,
On September 14 SVN rev 16104 there was a change to SnpDxe to improve the
detection of BARs to replace the hardcoded MemoryBarIndex=0 and IoBarIndex=1
with some intelligent scanning using PCI_IO GetBarAttributes instead.
This change had the side effect of breaking
ound? We finally had to hack the
library constructors, but it was messy.
Tim
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, August 26, 2014 7:49 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] Circular Dependency Between DxePrin
Dear maintainers of DebugLib and PrintLib,
It looks like we have a circular dependency between the
DxePrintLibPrint2Protocol library (which uses ASSERT) and
BaseDebugLibSerialPort library (which uses AsciiSPrint):
1>.dsc(...) : error F002: Library
[c:\edk2\MdeModulePkg\Library\DxePrintLibPrint
ailto:qin.l...@intel.com]
Sent: Tuesday, August 05, 2014 9:05 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [PATCH] CryptoPkg: Fix OpenSslLib build for ARM
Copy that. Thanks, Eugene.
Best Regards & Thanks,
LONG, Qin
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, August 05, 2
; Mcdaniel, Daryl; Cohen, Eugene
Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben
Subject: ShellPkg: Add Dynamic commands into standard command searching
Erik, Lee, Eugene, or Daryl,
Can you verify this patch?
This searches for handles that produce the dynamic command protocol after
searching
uld help the maintainer to remove a warning id when it should have been
fixed into OpenSslLib source code.
Nothing to do with this patch, but it's interesting to see RVCT (ARM RealView
Toolchain) supporting IA32/X64/IPF architectures.
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent
The ARM toolchain definitions are configured to treat warnings as errors. The
openssl code has numerous warnings so this patch tells the ARM RVCT compiler to
ignore those warnings. This patch also fixes an issue where the openssl
compiler flags were not being provided for the RVCT toolchain.
Olivier, this is something HP implemented and added for inclusion in the shell
spec a long time ago. We have contributed the implementation of dynamic
command handling and Jaben is in the process of integrating it. Hopefully
Jaben will be able to integrate the implementation shortly so you can
To be more clear, I wouldn't call this "UEFI in EL3" since UEFI is really the
OS/driver interface, instead I would call it something like "SEC/PEI in EL3".
Note that SEC and PEI are described in the PI specification and don't existing
in the UEFI specification.
We too are looking at this same
Agreed -- making the area uncached outright is not the preferred solution. For
drivers that don't use a bus protocol like PCI_IO, you can use the edk2 DmaLib
(
https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmbeddedPkg/Include/Library/DmaLib.h
) which provides functions for mapping buffers whi
Like any mass storage device, a driver that products the Block IO protocols
should be all that is required.
edk2 has a driver from ARM for their proprietary MMC host controller. Many
other systems use the industry standard SD Host Controller (SDHC) but I am not
aware of an open source driver b
This is what we did -- would it be better to create a universal S3-with-no-SMM
set of modules? For us we also did not want PCI, SmBus, or PEI NVRAM
dependencies.
-Original Message-
From: Yao, Jiewen [mailto:jiewen@intel.com]
Sent: Friday, December 27, 2013 6:20 PM
To: Laszlo Ersek
Alok,
I agree -- there is value in the modular nature of the PI component approach
extending to the ARM trusted firmware environment.
For SMM this is supported in the PI spec's SMM core interface specification and
in edk2 by the PiSmmCore module and accompanying libraries. Unlike DXE and
PEI,
Ø I've noticed various seemingly "random" asserts like this before and suspect
it may be related. Of course, the assert output never helps track down the
culprit, but that's a different issue altogether.
A call stack dump, either with a debugger or some additional crash handling
code should do
Dear ArmPkg Maintainer,
The exception handling support code at
ArmPkg\Drivers\CpuDxe\ArmV6\ExceptionSupport.asm appears to adjust the stack
pointer in the wrong direction. It decrements the stack pointer by 0x60, but
this should be an increment (add) for the downward-growing stack.
NoAdjustNe
.
Eugene
From: Cohen, Eugene
Sent: Thursday, August 22, 2013 6:59 AM
To: Andrew Fish; edk2-devel@lists.sourceforge.net
Cc: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] MNP PaddingSize Question
Thanks for the responses Siyuan and Andrew.
I think I understand your explanation -- to get the
f the fast paths and goes to a ldrb/strb mode. I think what you're
describing (go slow, then fast) will only work if they share the same
misalignment (say, 0x2 and 0x2).
Eugene
From: Andrew Fish [mailto:af...@apple.com]
Sent: Thursday, August 22, 2013 7:55 AM
To: Cohen, Eugene
Cc:
It seems like the sync system is designed to provide stability by limiting
day-to-day tools turmoil to edk2 trunk. But without a way to validate all
toolchains (including ARM, XCode, etc) then I don' t think the process is
really all that helpful as Olivier describes.
I think this issue points
Cc: Cohen, Eugene; edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] MNP PaddingSize Question
Sent from my iPhone
On Aug 22, 2013, at 12:15 AM, "Fu, Siyuan"
mailto:siyuan...@intel.com>> wrote:
Hi, Eugene
The PaddingSize is in order to make the packet data (exclude the media
mance impact only over your machine?
Or generally all machine?
Thanks,
Ruth
From: Cohen, Eugene [mailto:eug...@hp.com]
Sent: Tuesday, August 20, 2013 3:56 AM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: [edk2] MNP PaddingSize Question
I've been
]
Sent: Wednesday, August 21, 2013 9:32 AM
To: edk2-devel@lists.sourceforge.net; Cohen, Eugene
Cc: 'Ye, Ting'
Subject: RE: [edk2] MNP PaddingSize Question
I was told Ting is the Network expert for EDK2 MdeModulepkg code.
> -Original Message-
> From: Laszlo Ersek [mailto:l
oper
that is responsible for all of these components.
From: Cohen, Eugene
Sent: Monday, August 19, 2013 1:56 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] MNP PaddingSize Question
I've been tracking down a performance issue and have isolated it to this piece
of MNP init
I've been tracking down a performance issue and have isolated it to this piece
of MNP initialization code:
//
// Make sure the protocol headers immediately following the media header
// 4-byte aligned, and also preserve additional space for VLAN tag
//
MnpDeviceData->PaddingSize = ((4 -
Dear ShellPkg Maintainer,
Some storage subsystems benefit by having shell file operation sizes (affecting
copy and type commands right now) larger than 2^16. This patch changes the
PcdShellFileOperationSize type to 32-bits.
This patch is based on an old edk2 revision, 13353.
Contributed-unde
Patrick,
This seems like it would be a good SCT enhancement, at least for those systems
that have IOMMU capability.
Great suggestion.
Eugene
From: Patrick Georgi [mailto:patr...@georgi-clan.de]
Sent: Friday, July 26, 2013 1:44 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] XHCI DM
. :)
Feng, can you share some details on the timing of your plan to include
Map/AllocateBuffer calls for XhciDxe?
Thanks,
Eugene
From: Andrew Fish [mailto:af...@apple.com]
Sent: Wednesday, July 24, 2013 7:04 PM
To: Tian, Feng
Cc: Cohen, Eugene; edk2-devel@lists.sourceforge.net
Subject: Re: [edk2
Dear XhciDxe Maintainer,
I'm currently reviewing the XhciDxe driver and I'm trying to figure out how DMA
buffers are allocated. I see a number of pool and page allocations but I do
not see any called to PCI_IO Map()/Unmap() or to AllocateBuffer()/FreeBuffer().
This appears to be violating the
Dear ArmPkg maintainer,
Way back in SVN rev 12024 (July 18 2011!) a change was made to the
UncachedMemoryAllocationLib to use DXE Services instead of the CPU AP driver to
change the cacheability of allocated pages. However the function to free these
pages was not updated and still called the C
Sure, it looks good to the best of my ability to understand how this newfangled
shell works. :)
Reviewed-by: Eugene Cohen mailto:eug...@hp.com>>
Thanks again.
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Friday, June 21, 2013 2:17 PM
To: edk2-devel@lists.sourceforge.net
Subject: [e
Jaben,
This patch looks good to us and fixes all of the failing cases for us.
Thanks for the quick turnaround!
Eugene
From: Carsey, Jaben [mailto:jaben.car...@intel.com]
Sent: Friday, June 21, 2013 10:33 AM
To: Cohen, Eugene; edk2-devel@lists.sourceforge.net
Cc: Dellaquila, Katie; Carsey
Dear ShellPkg maintainer,
We are seeing an ASSERT with recursive deletion with the 'rm' shell command.
The issue seems to manifest when we try to delete a non-empty directory (and
hence the contents within it) when the command is executed from another drive
(or no current working directory at
As you know, EDK2 depends on the linker stripping dead code to manage code
size, especially from libraries. This is particularly important when running
from a pre-DDR environment (memory-mapped flash or SRAM).
The ARM RVCT linker can only do dead code stripping by placing different
functions i
You should be able to squeeze down the GPT header and entry array to reside in
LBAs 1 to 16 and make the boot partition a real GPT partition as well. I
didn't see anything in the GPT spec that specifies a minimum entry array size
so 14 LBAs may be sufficient.
Is the hardcoded LBA 17 an eMMC sp
hard to use in an I/O driver.
Tim
From: Andrew Fish [mailto:af...@apple.com]
Sent: Tuesday, February 12, 2013 1:54 PM
To: edk2-devel@lists.sourceforge.net<mailto:edk2-devel@lists.sourceforge.net>
Subject: Re: [edk2] WaitForEvent Idle Race Condition
On Feb 12, 2013, at 12:45 PM, "Co
tick. We are boot firmware and not an RTOS after
all ,and we have a signal model, not threads.
Andrew Fish
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/MdeModulePkg/Core/Dxe/Event/Event.c
On Feb 12, 2013, at 11:05 AM, "Cohen, Eugene"
mailto:eug...@hp.com>> wrote:
It appears that there is a race condition in WaitForEvent... after all events
are checked the idle event is signaled. But if a timer tick interrupt comes in
and schedules work (SignalEvent) after the loop is done but before the event is
signaled, we will delay unnecessarily for an additional ti
iable instead. If someone
else know a way to conditionally extend the PATH variable that would be even
better but I am not aware of a way to do so.
Thanks,
Eugene
From: Gao, Liming [mailto:liming@intel.com]
Sent: Tuesday, January 22, 2013 10:43 PM
To: Cohen, Eugene; edk2-
In BaseTools/toolsetup.bat there is a series of checks for a python freezer.
When I run from a VS command prompt (tested on 2005 and 2012) I found that when
we fall through to this case:
if not defined PYTHON_FREEZER_PATH (
echo.
echo !!! WARNING !!! Will not be able to compile P
Dear MdeModulePkg Maintainer,
The attached patch adds a boolean PCD value to change the behavior of the
Dhcpv4 driver to enable it to select the first offer received. I found that
this can resolve issues in some network environments where there is an
expectation for clients to select the first
In theory this protocol should enable performance improvements by doing IO in
the background. Unfortunately only the EFI_BLOCK_IO2_PROTOCOL allows for
asynchronous access while the protocols for higher layers (EFI_DISK_IO_PROTOCOL
and EFI_FILE_PROTOCOL) do not offer asynchronous access mechanis
Dear UNDI and PCI developers,
UNDI defines a Map_Mem callback for mapping DMA buffers. The SnpDxe driver
implements this callback and converts it to a PCI_IO Map call. If the UNDI map
type is TO_AND_FROM_DEVICE then this results in a
EfiPciIoOperationBusMasterCommonBuffer mapping type.
The U
Dear ShellPkg Maintainer,
The attached patch fixes the 'mm' command for 32-bit systems. The format
strings are using notations that require UINTNs (like "0x%02x") but a UINT64
type was being passed instead. This patch adds a typecast to UINTN so the
print processing works correctly.
Contribu
70 matches
Mail list logo
