Thomas,
Given that there is HW that can generate random number that big, I think it
makes sense to add an API to RngLib for 128 bit values.
Mike
-Original Message-
From: Palmer, Thomas [mailto:thomas.pal...@hpe.com]
Sent: Tuesday, October 06, 2015 4:19 PM
To: Kinney, Michael D; edk2-de
Mike,
I will simplify the function you suggest. I do not know where the 10us
comes from.
Question: I have a HW RNG that can create 128bit random data at once.
With BaseRngLib as it is today, I need to call GetRandomNumber64 twice. If
there were a GetRandomNumber128, I can s
Thomas,
How about something like below to further simplify to one function and handle
alignment issues.
Also, do you know where the 10us delay comes from in RdRandGetSeed128()? Is
there a pointer to a document?
EFI_STATUS
EFIAPI
RdRandGetBytes (
IN UINTN Length,
OUT UINT8
Sigh. Here's what I did:
On 10/06/15 21:19, Shifflett, Joseph wrote:
> When looping through all PCI functions, code should not look for functions
> 1-7 if function 0 is not present or if function 0 indicates the device is not
> multifunction. Prior to this fix the code would use stale data in a
Use the new RngLib to provide the IA32/X64 random data for RngDxe.
Remove x86 specific functions from RdRand files.
Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files in
BaseRngLib.
Simplify RngDxe by using GetRandomNumber64 for both IA32 and X64 platforms.
Explicitly use UIN
1. Change Interrupt for Juno PCI Routing table
Interrupt Number Reference:
http://www.arm.com/files/pdf/DDI0515D1a_juno_arm_development_platform_soc_trm.pdf
table 3-3 page 3-7
2. Support for PCI IO range with ACPI on JUNO
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Sup
Thank you!
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Tuesday, October 06, 2015 2:53 PM
To: El-Haj-Mahmoud, Samer ;
edk2-devel@lists.01.org
Cc: Siyuan Fu
Subject: Re: [edk2] [PATCH] NetworkPkg: Remove unused local variables
On 10/06/15 17:38, El-Haj-Mahmoud
On 10/06/15 17:38, El-Haj-Mahmoud, Samer wrote:
> Anyone for review please?
I reproduced the build failure with Linaro's cross compiler (I added the
HTTP stack to ArmVirtQemu.dsc and cross-built it).
Reviewed-by: Laszlo Ersek
Build-tested-by: Laszlo Ersek
Because the fix is simple, obviously c
When looping through all PCI functions, code should not look for functions 1-7
if function 0 is not present or if function 0 indicates the device is not
multifunction. Prior to this fix the code would use stale data in a buffer to
determine if a device is multifunction even if function 0 is not
When looping through all PCI functions, code should not look for functions 1-7
if function 0 is not present or if function 0 indicates the device is not
multifunction. Prior to this fix the code would use stale data in a buffer to
determine if a device is multifunction even if function 0 is not
Thomas,
I think it would make this module simpler if you just use the 64-bit variant.
Mike
-Original Message-
From: Palmer, Thomas [mailto:thomas.pal...@hpe.com]
Sent: Tuesday, October 06, 2015 11:00 AM
To: Kinney, Michael D; edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH] Pkg-Modul
On 10/06/15 17:37, El-Haj-Mahmoud, Samer wrote:
> Sorry, this is the correct patch (v3) that needs to be committed.
I could help you with committing this, but I see the following issues
with the patch:
- It modifies two top level packages in one patch, for no obvious
reason.
- If the original au
Mike,
Thanks for your response. I was trying to preserve the previous code
as much as possible, so I did not rename the Word functions.
Are you suggesting that I can remove the "Word" functions entirely and
just use the 64 variants? If so, I'll refactor my patch accordingly.
Thomas,
In other EDK II functions, we use the name "Uintn" instead of "Word" for a
function that returns a value that is the natural size of the executing CPU.
Also, I do not think you need the internal work function to generate a natural
sized random number.
Both IA32 and X64 versions the Bas
Will do.
Thanks,
Supreeth
-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
Sent: Tuesday, October 06, 2015 10:47 AM
To: Supreeth Venkatesh
Cc: edk2-de...@ml01.01.org
Subject: Re: [PATCH] ArmPlatformPkg/ARMJunoPkg: Change Interrupt for PCI
Routing table
Hi Supreet
On Tue, Oct 06, 2015 at 01:48:17PM +0100, Ard Biesheuvel wrote:
> The non-privileged execute never (UXN) page table bit defined for the
> EL1&0 translation regime and the execute never (XN) bit defined for the
> EL2 and EL3 translation regimes happen to share the same bit position,
> but they are i
Reviewed-by: Samer El-Haj-Mahmoud
-Original Message-
From: Palmer, Thomas
Sent: Tuesday, October 06, 2015 11:38 AM
To: edk2-devel@lists.01.org
Cc: El-Haj-Mahmoud, Samer ; Palmer, Thomas
Subject: [PATCH] Pkg-Module: Integrate new RngLib into RngDxe
Use the new RngLib to provide the I
Use the new RngLib to provide the IA32/X64 random data for RngDxe.
Remove x86 specific functions from RdRand files.
Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files in
BaseRngLib.
A key piece to this change was creating a RdRandWord and RdRandGetWords
functions that could w
Hi Supreeth,
Thanks for this, and sorry for delay.
Could you update the title and commit message though - the title says
you're changing IRQ numbers and the body says you're you're adding PCI
IO ranges, but the patch does both of these.
I would suggest a title of "ArmPlatformPkg: Fixes for Juno A
Hi,
I searched the list and the most recent topic I found was 10-months-old and
said that no support for UBI/UBIFS was available at that time.
http://sourceforge.net/p/edk2/mailman/message/33144044/
That thread is similar to what I'm wanting to do, which is to have a raw flash
device for boot w
Anyone for review please?
-Original Message-
From: El-Haj-Mahmoud, Samer
Sent: Tuesday, September 29, 2015 6:02 PM
To: edk2-devel@lists.01.org
Cc: Siyuan Fu ; El-Haj-Mahmoud, Samer
; El-Haj-Mahmoud, Samer
Subject: [PATCH] NetworkPkg: Remove unused local variables
Fix gcc build errors
Sorry, this is the correct patch (v3) that needs to be committed.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ni, Ruiyu
Sent: Wednesday, September 30, 2015 12:35 AM
To: Shifflett, Joseph ; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: Re: [
Can I get help from someone to commit this change please?
-Original Message-
From: Ni, Ruiyu [mailto:ruiyu...@intel.com]
Sent: Wednesday, September 30, 2015 12:35 AM
To: Shifflett, Joseph ; El-Haj-Mahmoud, Samer
; edk2-devel@lists.01.org
Cc: Tian, Feng ; El-Haj-Mahmoud, Samer
Subject:
On Mon, Sep 28, 2015 at 12:03:42PM +0100, Sudeep Holla wrote:
> Hi,
>
> On 07/09/15 17:07, Sudeep Holla wrote:
> >Currently the MADT signature and revision is mapped to v1.0 macros
> >which results in MADT with incorrect entries in the header for Juno.
> >This patch fixes these EFI_ACPI_*_0_MULTIP
On 6 October 2015 at 13:18, Leif Lindholm wrote:
> On Fri, Sep 04, 2015 at 12:01:24PM +0200, Ard Biesheuvel wrote:
>> These are no longer used by any platform in the tree, nor are they
>> of any significance to any out of tree platforms.
>
> Yep, drop 'em.
>
> Reviewed-by: Leif Lindholm
>
Thanks
On 6 October 2015 at 12:15, Leif Lindholm wrote:
> On Mon, Sep 21, 2015 at 04:02:23PM -0700, Ard Biesheuvel wrote:
>> All our page tables are allocated from memory whose cacheability
>> attributes are inherited by the cacheability bits in the MMU control
>> register, so there is no need for explic
Enable the non-exec DXE stack feature when building for AARCH64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/Arm
Mark the DXE stack region as non-executable right before handing
off to the DXE core, by invoking the appropriate ArmLib function.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
---
MdeModulePkg/Core/DxeIplPeim/Arm/DxeLoadFunc.c
Move the page table traversal and splitting logic to a separate function
UpdateRegionMapping() and refactor it slightly so we can reuse it later to
implement non-executable regions, for the stack. This primarly involves
adding a value/mask pair to the function prototype that allows us to flip
arbit
Use the refactored UpdateRegionMapping () to traverse the translation
tables, splitting block entries along the way if required, and apply
a mask + or on each to set or clear the PXN/UXN/XN or RO bits.
For now, the 32-bit ARM versions remain unimplemented.
Contributed-under: TianoCore Contributio
The non-privileged execute never (UXN) page table bit defined for the
EL1&0 translation regime and the execute never (XN) bit defined for the
EL2 and EL3 translation regimes happen to share the same bit position,
but they are in fact defined distinctly by the architecture. So define
both bits expli
This series enables the non-exec DXE stack feature for AARCH64. It involves
some refactoring of ArmLib so we can reuse the bulk of the page table
manipulation code (patch #1,#2). Then, it is simply a matter of calling the
newly introduced ArmSetMemoryRegionNoExec () [patch #3] on the stack region
r
On Fri, Sep 04, 2015 at 12:01:24PM +0200, Ard Biesheuvel wrote:
> These are no longer used by any platform in the tree, nor are they
> of any significance to any out of tree platforms.
Yep, drop 'em.
Reviewed-by: Leif Lindholm
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-o
On Tue, Sep 29, 2015 at 10:29:00AM +0200, Ard Biesheuvel wrote:
> Advance the *FixupData pointer after use in the second relocation pass
> for runtime when handling ARM MOVW/MOVT immediate relocations.
>
> Note that using FixupData is somewhat pointless for relocations targeting
> instructions rat
On Tue, Sep 29, 2015 at 10:28:59AM +0200, Ard Biesheuvel wrote:
> The handling of ARM MOVW/MOVT relocations sets the FixupData twice (once
> incorrectly), but fails to advance the *FixupData pointer afterwards.
> This is not actually a problem, since the fixup data is never used but
> let's fix it
On Mon, Sep 21, 2015 at 04:02:25PM -0700, Ard Biesheuvel wrote:
> Mark the DXE stack region as non-executable right before handing
> off to the DXE core, by invoking the appropriate ArmLib function.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
On Mon, Sep 14, 2015 at 08:37:15AM +0200, Ard Biesheuvel wrote:
> Move the page table traversal and splitting logic to a separate function
> and refactor it slightly so we can reuse it later to implement non-executable
> regions, for the DXE stack.
>
> Contributed-under: TianoCore Contribution Agr
On Mon, Sep 21, 2015 at 04:02:23PM -0700, Ard Biesheuvel wrote:
> All our page tables are allocated from memory whose cacheability
> attributes are inherited by the cacheability bits in the MMU control
> register, so there is no need for explicit cache maintenance after
> updating the page tables.
38 matches
Mail list logo
