The function GcdAttributeToArmAttribute() is not used anywhere in the
code base, and is only defined for AARCH64 and not for ARM. It also
fails to set the bits for shareability and non-executability that we
require for correct operation. So remove it.
Contributed-under: TianoCore Contribution Agre
To prevent speculative intruction fetches from MMIO ranges that may
have side effects on reads, the architecture requires device mappings
to be created with the XN or UXN/PXN bits set (for the EL2 and EL1&0
translation regimes, respectively.)
Reported-by: Heyi Guo
Contributed-under: TianoCore Con
The bug was found when I wants to use this library to show logo in a specific
location other than the 9 pre-defined locations.
The change to this interface implictly tells that caller can specify other
location
using Offset* parameters relative to the 9 pre-defined locations.
Ruiyu Ni (2):
MdeM
The parameter name is also changed from Coordinate* to Offset* to
reflect that it's the offset to the location specified by Attribute.
For example, when the Attribute is Center, OffsetX and OffsetY are
used to specify the offset to the Center. OffsetX = 100 means
100 pixels right to the Center.
Co
The parameter name is also changed from Coordinate* to Offset* to
reflect that it's the offset to the location specified by Attribute.
For example, when the Attribute is Center, OffsetX and OffsetY are
used to specify the offset to the Center. OffsetX = 100 means
100 pixels right to the Center.
Co
Looks good.
Reviewed-by: Ye Ting
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang
Lubo
Sent: Friday, November 13, 2015 9:41 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting; Fu, Siyuan; Wu, Jiaxin
Subject: [edk2] [PATCH v2] NetworkPkg: Httpboot
Reviewed-by: Liming Gao
> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, November 11, 2015 6:07 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming
> Subject: [PATCH] MdeModulePkg PeiCore: PEI dispatcher need retry to process
> NOT_DISPATCHED FV
>
> A corner case like below wil
v2:
*version 1 can fix this issue by checking the TCP state. If it is in the
close-wait state,
then reconnect TCP. But consider another scenario,if an error occurs of the TCP
connection
between the first request() and second Request() to http server, it will not
work. So we
will use the TCP stat
> On Nov 12, 2015, at 11:21 AM, Michael Zimmermann
> wrote:
>
> thx for this information.
> I don't have any debug hw but UART.
>
> After some careful DEBUG printing and tracing the call stack using
> '__builtin_return_address(0)'
FYI the edk2 has a portable form of this RETURN_ADDRESS(0)
>
AppPkg/Python-2.7.10: Present patch in three reviewable chunks.
Due to the large number of changes, the previous submission of this patch
was not reviewable. This patch set presents the changes as three patches, each
containing a single type of change.
Patch 1/3: Remove irrelevant code.
Remove
AppPkg/Python-2.7.10: Update file for Python-2.7.10 inclusion.
Add copyright message.
Remove some redundant blank lines.
Remove a superfluous call to setup_confname_tables(m) from INITFUNC().
Signed-off-by: Daryl McDaniel
---
.../Python/Python-2.7.10/PyMod-2.7.10/Modules/edk2module.
AppPkg/Python-2.7.10: Rename identifiers beginning with "posix_" to "edk2_".
Rename identifiers to have an edk2_ prefix instead of posix_ in order to
conform to the convention used in other environment-specific Python modules.
This also makes the names match the module instead of implying that the
thx for this information.
I don't have any debug hw but UART.
After some careful DEBUG printing and tracing the call stack using
'__builtin_return_address(0)' I found that the application's dead happens
at 'WaitForEvent' and that there aren't any long running events(it returns
from CoreDispatchEve
> On Nov 12, 2015, at 9:05 AM, Michael Zimmermann
> wrote:
>
> thx, this perfectly explains my situation(that EDK2 shell stops while
> printing sth. like the map or waiting for this 5s startup.nsh timeout).
>
> So this means that processing the event queue is caused by any API call which
> n
Please don't drop the list and other CC's from the discussion when the
initial report is sent to the list. Keeping full context.
On 11/11/15 08:38, P.A.M. van Dam (Pascal) wrote:
> On Mon, Nov 09, 2015 at 10:02:52PM +0100, Laszlo Ersek wrote:
>> On 11/09/15 14:50, P.A.M. van Dam (Pascal) wrote:
>>
thx, this perfectly explains my situation(that EDK2 shell stops while
printing sth. like the map or waiting for this 5s startup.nsh timeout).
So this means that processing the event queue is caused by any API call
which never returns to the DXE phase for some reason.
Is there a special way to deb
> On Nov 12, 2015, at 3:28 AM, Andrew Fish wrote:
>
>>
>> On Nov 12, 2015, at 3:22 AM, Andrew Fish wrote:
>>
>>
>>> On Nov 12, 2015, at 12:49 AM, Michael Zimmermann
>>> wrote:
>>>
>>> Stall was just an example, I can also use DEBUG. My timer interval is
>>> 100ms(I converted it from the 1
On Thu, Nov 12, 2015 at 11:35:28AM +, Leif Lindholm wrote:
> Hi Ard,
>
> On Mon, Nov 09, 2015 at 02:18:58PM +0100, Ard Biesheuvel wrote:
> > Mark all cached memory mappings as shareable (or inner shareable on
> > AArch64) so that our view of memory is kept coherent by the hardware.
> >
> > Th
On 12 November 2015 at 12:35, Leif Lindholm wrote:
> Hi Ard,
>
> On Mon, Nov 09, 2015 at 02:18:58PM +0100, Ard Biesheuvel wrote:
>> Mark all cached memory mappings as shareable (or inner shareable on
>> AArch64) so that our view of memory is kept coherent by the hardware.
>>
>> This is primarily r
Hi Ard,
On Mon, Nov 09, 2015 at 02:18:58PM +0100, Ard Biesheuvel wrote:
> Mark all cached memory mappings as shareable (or inner shareable on
> AArch64) so that our view of memory is kept coherent by the hardware.
>
> This is primarily relevant under virtualization (where a guest may migrate
> to
> On Nov 12, 2015, at 3:22 AM, Andrew Fish wrote:
>
>
>> On Nov 12, 2015, at 12:49 AM, Michael Zimmermann
>> wrote:
>>
>> Stall was just an example, I can also use DEBUG. My timer interval is
>> 100ms(I converted it from the 100ns unit).
>>
>> What I meant with "thread mode code" is the "no
> On Nov 12, 2015, at 12:49 AM, Michael Zimmermann
> wrote:
>
> Stall was just an example, I can also use DEBUG. My timer interval is
> 100ms(I converted it from the 100ns unit).
>
> What I meant with "thread mode code" is the "normal" non IRQ context code
> running on the CPU. That means that
Stall was just an example, I can also use DEBUG. My timer interval is
100ms(I converted it from the 100ns unit).
What I meant with "thread mode code" is the "normal" non IRQ context code
running on the CPU. That means that there are actually two contexts in
EDK2, the exception(i.e. IRQ's like the
> On Nov 11, 2015, at 11:51 PM, Michael Zimmermann
> wrote:
>
> I've started investigating in the timer event problem and I think I have
> some weird problem with my platform drivers(I hope, so it's not a EDK2 bug).
>
> If I create a timer that runs every 100ms which does nothing but a
> stall
when the path contains space, it will report error for PATH Environment
update.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu
---
toolsetup.bat | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/toolsetup.bat b/toolset
when we make BaseTools, it report warnings about VfrError.cpp and VolInfo,
so this patch fix this warning.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu
---
Source/C/VfrCompile/VfrError.cpp | 2 +-
Source/C/VolInfo/VolInfo.c | 19 +--
26 matches
Mail list logo
