edMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
>
> b/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUncachedMemoryAllocationLib.inf
> deleted file mode 100644
> index 213188ac2c39..
> ---
> a/ArmPkg/Library/DebugUncachedMemoryAllocationLib/DebugUnc
t;Sent: 13 February 2017 13:05
> >>>To: Evan Lloyd
> >>>Cc: edk2-devel@lists.01.org; Leif Lindholm; ryan.har...@linaro.org
> >>>Subject: Re: [PATCH 4/4] ArmPkg:Provide GetTriggerType/SetTriggerType
> >>>functions
> >>>
> >>>(ap
(Intentionally sending my responses out of order)
Hi Evan,
On Fri, Feb 17, 2017 at 12:06:30PM +, Evan Lloyd wrote:
> Leif points out that “Ternaries are excellent when they increase
> code readability.”
>
> The debate would thus seem to be a subjective assessment of
> “readability”.
Indeed.
On Mon, Feb 27, 2017 at 02:38:05PM +, Ard Biesheuvel wrote:
> To prevent the initial MMU->GCD memory space map synchronization from
> stripping permissions attributes [which we cannot use in the GCD memory
> space map, unfortunately], implement the same approach as x86, and ignore
> SetMemoryAt
On Mon, Feb 27, 2017 at 03:33:56PM +, Ard Biesheuvel wrote:
> On 27 February 2017 at 15:32, Leif Lindholm wrote:
> > On Mon, Feb 27, 2017 at 02:38:05PM +, Ard Biesheuvel wrote:
> >> To prevent the initial MMU->GCD memory space map synchronization from
> >> st
On Mon, Feb 27, 2017 at 03:39:54PM +, Ard Biesheuvel wrote:
> On 27 February 2017 at 15:38, Leif Lindholm wrote:
> > On Mon, Feb 27, 2017 at 03:33:56PM +, Ard Biesheuvel wrote:
> >> On 27 February 2017 at 15:32, Leif Lindholm
> >> wrote:
> >> > O
> and the associated DebugUncachedMemoryAllocationLib library instance.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPkg/ArmPkg.dec | 1 -
> ArmVirtPkg/ArmVirtQemu.dsc
ntributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
This looks good. I'll make one non-functional ecomment, and you can
decide whether to incorporate it before pushing or not.
Reviewed-by: Leif Lindholm
> ---
>
> Terry: does this
On Thu, Mar 02, 2017 at 10:36:13AM +, Ard Biesheuvel wrote:
> Currently, any range passed to CpuArchProtocol::SetMemoryAttributes is
> fully broken down into page mappings if the start or the size of the
> region happens to be misaliged relative to the section size of 1 MB.
>
> This is going t
r = FirstLevelTable[FirstLevelIdx];
> + if (FlushTlbs != NULL) {
If FlushTlbs is optional, should it not be marked OPTIONAL above?
If you fold that in:
Reviewed-by: Leif Lindholm
> +*FlushTlbs = TRUE;
> + }
> }
>
> // Obtain page t
On Thu, Mar 02, 2017 at 10:36:15AM +, Ard Biesheuvel wrote:
> Enable the use of strict memory permissions on ARM by processing the
> EFI_MEMORY_RO and EFI_MEMORY_XP rather than ignoring them. As before,
> calls to CpuArchProtocol::SetMemoryAttributes that only set RO/XP
> bits will preserve the
ery EDK2:ish.
> * SetMemoryAttributes() is declared in the wrong header (and defined in
> ArmMmuLib for AARCH64 and in CpuDxe for ARM)
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
No need to wait for res
n Wed, Mar 01, 2017 at 04:31:40PM +, Ard Biesheuvel wrote:
> ... where it belongs, since AARCH64 already keeps it there, and
> non DXE users of ArmMmuLib (such as DxeIpl, for the non-executable
> stack) may need its functionality as well.
>
> While at it, rename SetMemoryAttributes to ArmSetMe
VirtualMask argument from ArmSetMemoryAttributes()'s
> prototype, and remove the dead code that referred to it.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPkg/Drivers/CpuDxe/CpuMmuCommon
On Wed, Mar 01, 2017 at 04:31:42PM +, Ard Biesheuvel wrote:
> Now that we have the prerequisite functionality available in ArmMmuLib,
> wire it up into ArmSetMemoryRegionNoExec, ArmClearMemoryRegionNoExec,
> ArmSetMemoryRegionReadOnly and ArmClearMemoryRegionReadOnly. This is
> used by the non-
vel Descriptors
> >> +typedef UINT32ARM_PAGE_TABLE_ENTRY;
> >> +
> >
> > Copied from ArmPkg/Drivers/CpuDxe/Arm/Mmu.c, but not deleted there.
> > Can it be, or can it be moved out into a header somewhere?
> >
> > No other comments.
> >
>
&
On Mon, Mar 06, 2017 at 03:55:42PM +0100, Ard Biesheuvel wrote:
> On 6 March 2017 at 15:12, Leif Lindholm wrote:
> > On Thu, Mar 02, 2017 at 10:36:13AM +, Ard Biesheuvel wrote:
> >> Currently, any range passed to CpuArchProtocol::SetMemoryAttributes is
> >>
On Mon, Mar 06, 2017 at 04:11:50PM +0100, Ard Biesheuvel wrote:
> On 6 March 2017 at 15:48, Leif Lindholm wrote:
> > On Thu, Mar 02, 2017 at 10:36:15AM +, Ard Biesheuvel wrote:
> >> Enable the use of strict memory permissions on ARM by processing the
> >> EFI_
der: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPkg/Drivers/CpuDxe/Arm/Mmu.c | 178 ++--
> 1 file changed, 86 insertions(+), 92 deletions(-)
>
> diff --git a/ArmPkg/Drivers/CpuDxe/Arm/Mm
tly, we
> only use ArmSetMemoryRegionNoExec(), so for now, we should be
> able to live with this.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPkg/Library/ArmMmuLib/Arm/ArmMmuLibCore.c |
nt 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c |
> 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git
> a/Arm
dingly.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPkg/Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c | 2
> +-
> 1 file changed, 1 insertion(+), 1 de
urity hole
> when the rest of the platform may be enforcing strict memory permissions
> on ordinary allocations.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPkg/Library/UncachedMemoryAlloc
ted-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmPkg/Drivers/CpuDxe/AArch64/Mmu.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/ArmPkg/Drivers/CpuDxe/AArch64/Mmu
; additional dependency on the FDT client code by the RTC driver.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
This seems like an improvement even without the rest of the series.
Reviewed-by: Leif Lindholm
> ---
> ArmVirtPkg/Libra
ion table if we want to leave it
> up
> +// to the OS to decide whether it prefers ACPI over DT.
> +//
I was going to complain about how it felt pointless to introduce this
only to delete it in 2/3, but I really like how it improves the
clarity of 3/3.
Reviewed-
gt; ACPI 2.0 configuration table, and only installing the FDT one if the
> ACPI one cannot be found.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Leif Lindholm
> ---
> ArmVirtPkg/ArmVirtPkg.dec| 10 --
Hi Laszlo,
Apologies, I didn't ignore this set, I just missed it (and felt Ard's
set was a clean solution to this behaviour change).
A few comments below.
On Thu, Mar 09, 2017 at 04:30:19PM +0100, Laszlo Ersek wrote:
> On 03/09/17 13:26, Ard Biesheuvel wrote:
> >>> Hi Laszlo,
> >>>
> >>> This lo
Reviewed-by: Leif Lindholm
On 9 Mar 2017 6:29 pm, "Laszlo Ersek" wrote:
> On 03/09/17 18:21, Ard Biesheuvel wrote:
> > From: Laszlo Ersek
> >
> > Add missing EFIAPI calling convention specifiers to STATIC function
> > that are exposed via the FdtClientPr
On Sat, Mar 11, 2017 at 08:38:19AM +0100, Laszlo Ersek wrote:
> >> "MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c". I
> >> think the above check should be reworked to look for the FADT
> >> (EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) with code lifted
> >> from these helpe
,7 +86,7 @@ LoadPeCoffImage (
>//
>// Allocate Memory for the image
>//
> - Buffer = AllocatePages (EFI_SIZE_TO_PAGES((UINT32)ImageContext.ImageSize));
> + Buffer = AllocateCodePages
> (EFI_SIZE_TO_PAGES((UINT32)ImageContext.ImageSize));
>ASSERT (Buffer != 0);
>
>
> --
> 2.7.4
Reviewed-by: Leif Lindholm
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
On Tue, Mar 14, 2017 at 09:03:43AM +, Ard Biesheuvel wrote:
> On 14 March 2017 at 09:00, Leif Lindholm wrote:
> > On Tue, Mar 14, 2017 at 08:01:04AM +, Ard Biesheuvel wrote:
> >> The recently introduced memory protection features inadvertently broke
> >> the
)) {
> -gBS->FreePages (Memory, Pages);
> -return Status;
> +goto FreePages;
> + }
> +
> + Status = mCpu->SetMemoryAttributes (mCpu, Memory, EFI_PAGES_TO_SIZE
> (Pages),
> + EFI_MEMORY_XP);
So, all other changes here are straightforward, bu
Well, the subject doesn't really match the content.
MdeModulePkg: add ARM/AARCH64 to AtaBusDxe VALID_ARCHITECTURES
Is a better match.
And since it's both non-functional and an obvious fix, I'd say you
could send this off to edk2-devel on its own if you change the
subject. (And add MdeModulePkg m
On Tue, Mar 07, 2017 at 04:15:07PM -0600, Jeremy Linton wrote:
> Create a new module that adds the callbacks to support
> the EFI SCSI pass-through protocol. These callbacks
> wrap around the existing ATA pass-through callbacks.
> In particular the SCSI command submission routine takes
> the SCSI c
On Tue, Mar 07, 2017 at 04:15:08PM -0600, Jeremy Linton wrote:
> Add EXT_SCSI_PASS_THRU structures to SI3132_PORT structure,
> along with helpers and new entry points.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeremy Linton
LGTM
Reviewed-by
On Tue, Mar 07, 2017 at 04:15:09PM -0600, Jeremy Linton wrote:
> The existing ATA pass-through routine builds the FIS and handles
> submission to the hardware. Break out the FIS submission part
> so that it can be utilized by the SCSI pass-through. Also,
> tighten up the error handling a bit. Start
On Tue, Mar 07, 2017 at 04:15:10PM -0600, Jeremy Linton wrote:
> There can be either ATA or ATAPI devices connected to
> each SATA port. We want to detect if the device is ATA
> and create a SATA_DP path or a SCSI_DP for ATAPI devices.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
>
On Tue, Mar 07, 2017 at 04:15:11PM -0600, Jeremy Linton wrote:
> Now that everything is in place, lets export the protocol,
> build the module, and remove the ATAPI unsupported flags.
> Now when we detect an ATAPI device on a port we flag it
> as such.
>
> Contributed-under: TianoCore Contribution
CPI_TABLE_PROTOCOL).
I greatly approve, but since you've already done this generically - is
there any good reason to keep this in ArmPkg?
I am strongly looking to get rid of "things that happen to have been
implemented for ARM" from there and pruning it down to contain only
thi
revious patch, with the exception that if this isn't
a good fit for MdeModulePkg, I'd rather take it in EmbeddedPkg than
ArmPkg.
Regards,
Leif
> Cc: Ard Biesheuvel
> Cc: Leif Lindholm
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek
&
3Enable to
>control the code
>
> If the AcpiTableDxe maintainers aren't opposed to another dynamic PCD
> like PcdAcpiS3Enable -- but in this case for controlling AcpiTableDxe --
> then I'm fine with it too.
>
> ... I knew that new PCDs in MdeModulePkg needed
On Sat, Mar 18, 2017 at 08:58:24PM +, Ard Biesheuvel wrote:
> Since commit 78c41ff519b1 ("ArmVirtPkg/FdtClientDxe: make DT table
> installation !ACPI dependent"), we inhibit the installation of the core
> ACPI tables when booting in DT mode, to relieve the OS from having to
> decide which hardw
Hi Mike,
I agree with Laszlo's comments (including that this looks really
good!). Just one question below:
On Fri, Mar 17, 2017 at 01:07:59AM +, Kinney, Michael D wrote:
> Hello,
>
> The following is an RFC proposal for using GitBook for tianocore
> documentation. This RFC is also availabl
Hi Ard,
Thanks for this.
On Mon, Aug 17, 2015 at 09:59:51AM +0200, Ard Biesheuvel wrote:
> No platforms use the ARMv6 (ARM11) support code anymore. In fact, the
> only reference to it in ArmPkg.dsc was commented out by Andrew in SVN
> r11298 (2011-02-03) so it may well be broken. So remove it.
I
uilds can also easily be switched to the GCC47 profile instead,
generating safe binaries. (May be worth adding that to the message
when committing?)
Reviewed-by: Leif Lindholm
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
> BaseTools/Co
On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote:
> On 12 August 2015 at 08:45, Ard Biesheuvel wrote:
> > Instead of omitting some drivers that are known to break the Foundation
> > model when ARM_FOUNDATION_FVP is defined, fix those drivers so that they
> > simply fail to load witho
On Tue, Aug 18, 2015 at 02:14:53PM +0200, Ard Biesheuvel wrote:
> On 18 August 2015 at 14:12, Leif Lindholm wrote:
> > On Tue, Aug 18, 2015 at 01:15:54PM +0200, Ard Biesheuvel wrote:
> >> On 12 August 2015 at 08:45, Ard Biesheuvel
> >> wrote:
> >> > In
Hi Ard,
Apologies for tardiness.
Could we move this into ShellPkg instead, since the mcmodel=tiny is
globally applied for AARCH64, and any other direct consumers would
also be affected by 2/2?
/
Leif
On Mon, Aug 10, 2015 at 12:27:26PM +0200, Ard Biesheuvel wrote:
> The DEBUG build of the Sh
he large model can still be
> selected by individual modules by adding -mcmodel=large to the
> appropriate CC_FLAGS.
Once ShellPkg situation resolves one way or the other:
Reviewed-by: Leif Lindholm
Tested-by: Leif Lindholm
Thanks for this.
/
Leif
> Contributed-under: TianoCore
Reviewed-by: Leif Lindholm
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
> v2: remove more outdated '#ifdef ARM_CPU_ARMv6' from ArmLib
>
> ArmPkg/ArmPkg.dsc | 4 -
>
On Wed, Aug 19, 2015 at 01:46:42PM +0200, Ard Biesheuvel wrote:
> The binaries of ShellBinPkg are generated with ShellPkg project 18222.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel
> ---
>
> These are built with the tiny code model, note the code s
Hi Scott,
Thanks for this. Apologies, I somehow missed it going past.
This same fix went in as part of Ard's CLANG series (r18193).
Regards,
Leif
On Sun, Jul 19, 2015 at 03:23:17PM -0500, Scott Duplichan wrote:
> Add type cast to fix new GCC5 warning for discarded-array-qualifiers.
> Also remov
Hi Bhupesh,
On Thu, Aug 20, 2015 at 11:03:07AM +, Sharma Bhupesh wrote:
> We are considering adding the support for a Freescale ARM64 based
> platform in the EDK2 tree and upstreaming the same.
As much as I would like to see more open source platform code, I
really want to get some structure
On Thu, Aug 20, 2015 at 01:17:20PM +, Sharma Bhupesh wrote:
> > > Modified License:
> > > -
> > >
> > > Copyright (c) 2009-2010, Apple Inc. All rights reserved.
> > > Copyright (c) 2011-2012, ARM Limited. All rights reserved.
> > > Copyright (c) 2015, Freescale Semiconductor, In
Hi Cecil,
I am a little bit confused - I cannot see any zip file?
Actually, I can also not see anything attached to the previous email
you sent, regarding nested includes in DSC/FDF files.
Regards,
Leif
On 20 August 2015 at 08:02, Sheng, Cecil (HPS SW) wrote:
> Hi,
>
> The patch file is too la
Hi,
On Wed, Aug 26, 2015 at 10:45:35AM +0800, Qiu Shumin wrote:
> Initialize the local pointer to avoid to free a dangling pointer.
>
> Cc: Jaben Carsey
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin
> ---
> ShellPkg/Library/UefiShellDriver1CommandsLib/Dr
error handling
InitializeConsolePipe () shadowed its own Status variable, and then
clobbered the top one before printing its error message. Instead,
use a NULL check on the LocateProtocol () output argument.
Also clean up coding style on the error path.
---
and you can have a
Reviewed-by: Leif Lindholm
/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
rkModulePkgTokenSpaceGuid.PcdLogoFile
>
> [Protocols]
>gEfiDevicePathFromTextProtocolGuid
> --
> 1.9.1
Sweet - I get the Tianocore logo on my FVP CLCD :)
Reviewed-by: Leif Lindholm
Tested-by: Leif Lindholm
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
rmationChange|FALSE
> + gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04,
> 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
> +!endif
> +
> [Components.common]
>MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>
> --
> 1.9.1
>
With the TRUE/FALSE message fix:
Reviewed-by: Leif Lindholm
Tested-by: Leif Lindholm
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
5, 0x04,
> 0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
> !endif
>
> +!if $(SECURE_BOOT_ENABLE) == TRUE
> + # override the default values from SecurityPkg to ensure images from all
> sources are verified in secure boot
> + gEfiSecurityPkgTokenSpaceGuid.PcdOp
> --
> 1.9.1
So, it's not a big deal, and I think this series is useful enough to
go in anyway, but with this patch and ArmBds, I end up with two
preconfigured boot menu entries for Shell:
---
[1] EFI Misc Device
[2] EFI Misc Device 1
[3] EFI Misc Device 2
[4] EFI Misc Device 3
[5] EFI Misc Device 4
[6] EFI Internal Shell
[7] EFI Misc Device 5
[8] Shell
[9] Boot Manager
Start:
---
I think this has now also discarded the default boot entry that used
to be on this platform with the ArmBds.
However, if Ryan does not object to that:
Reviewed-by: Leif Lindholm
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
On Tue, Sep 01, 2015 at 07:12:33PM +0200, Ard Biesheuvel wrote:
> On 1 September 2015 at 18:59, Leif Lindholm wrote:
> > On Tue, Sep 01, 2015 at 11:58:20AM +0200, Ard Biesheuvel wrote:
> >> The Intel BDS platform library still depends on the ARM BDS specific
> >
>>
>> On 13 August 2015 at 16:37, Heyi Guo wrote:
>>>
>>> NewNode is the node we found, while Node is the last node in the
>>> list. Also update mFreedBufferSize.
>>>
>>> Contributed-under: TianoCore Contribution Ag
On Tue, Sep 01, 2015 at 04:26:07PM +0200, Ard Biesheuvel wrote:
> Like the ArmVirtPkg platforms up until SVN r17713, the ArmPlatformPkg
> platforms built with the Intel BDS fail to signal the end-of-DXE event
> 'gEfiEndOfDxeEventGroupGuid' when entering the BDS phase, which results
> in some loss o
doesn't trigger S3 stuff in
> ArmVirtPkg, simply because S3 stuff *does not exist* there. So we can
> kick EndOfDxe first, then do the PCI enumeration, then download the ACPI
> tables (with the updated, PCI resource allocation-dependent contents) last.
OK.
Thanks for the det
G_COMMAND, HDLCD_DISABLE);
> }
> +
> +EFI_STATUS
> +LcdIdentify (
> + VOID
> + )
> +{
> + return EFI_SUCCESS;
> +}
> --
> 1.9.1
Thanks! Verified this fixes TC2 build.
Reviewed-by: Leif Lindholm
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
print,
>> we can see lots of level 1 tables created (for block of 1GB) even
>> when the region is large enough to use 512GB block size.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Heyi Guo
>> Cc: Leif Lindholm
>> Cc: A
On 6 September 2015 at 13:05, Ard Biesheuvel wrote:
> On 6 September 2015 at 14:04, Leif Lindholm wrote:
>> On 6 September 2015 at 12:52, Ard Biesheuvel
>> wrote:
>>> On 6 September 2015 at 10:15, Heyi Guo wrote:
>>>> There is a hidden bug for below code:
ries in the header for Juno.
> > This patch fixes these EFI_ACPI_*_0_MULTIPLE_APIC_DESCRIPTION_TABLE
> > macros by using appropriate v5.0 versions.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Sudeep Holla
> > Cc: Ryan Ha
-
> 1.9.1
So, this is mainly an OCD thing on my end, but is there any real
benefit to _not_ converting SystemMemoryBase to 64-bit? Doing so would
get rid of the other UINTN cast.
Either way:
Reviewed-by: Leif Lindholm
/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
On Wed, Sep 09, 2015 at 04:38:08PM +0200, Ard Biesheuvel wrote:
> On 9 September 2015 at 16:31, Leif Lindholm wrote:
> > On Tue, Sep 08, 2015 at 07:35:40PM +0200, Ard Biesheuvel wrote:
> >> Make sure that the PEI memory region is carved out of memory that is
> >> 32
On Wed, Sep 09, 2015 at 05:11:33PM +0200, Ard Biesheuvel wrote:
> On 9 September 2015 at 16:53, Leif Lindholm wrote:
> > On Wed, Sep 09, 2015 at 04:38:08PM +0200, Ard Biesheuvel wrote:
> >> On 9 September 2015 at 16:31, Leif Lindholm
> >> wrote:
> >> > O
Hi Bhupesh,
On Fri, Sep 18, 2015 at 02:03:10PM +, Sharma Bhupesh wrote:
> I have been trying my hands-on on replacing the current Legacy BDS
> loader with the EFI_STUB on a Freescale ARM64 SoC to load Linux and
> utilize the features of the EFI_STUB.
>
> I am taking a reference from ARM juno s
>>
>> Anyone with access to RVCT able to test this? I would highly appreciate it.
>>
>
> OK, I managed to get access to RVCT myself, and gave this a spin.
>
> As I had hoped, just removing the workaround in GenFw breaks the b
On Thu, Oct 01, 2015 at 02:30:56PM +0200, Ard Biesheuvel wrote:
> On 25 September 2015 at 03:08, Ard Biesheuvel
> wrote:
> > Instead of using the ARM builtin linker script for GNU ld, use the
> > new unified one instead. This will allow us to increase the section
> > alignment for DXE_RUNTIME_MOD
On Thu, Oct 01, 2015 at 03:10:20PM +0200, Ard Biesheuvel wrote:
> On 1 October 2015 at 14:52, Leif Lindholm wrote:
> > On Thu, Oct 01, 2015 at 02:30:56PM +0200, Ard Biesheuvel wrote:
> >> On 25 September 2015 at 03:08, Ard Biesheuvel
> >> wrote:
> >> >
CURE_BOOT_ENABLE = FALSE
>
> -[BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
> +[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
> + GCC:*_*_ARM_DLINK_FLAGS = -z common-page-size=0x1000
>GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x1
>
> [Librar
S= $(ARCHCC_FLAGS) $(PLATFORM_FLAGS)
> DEF(GCC44_ALL_CC_FLAGS) -mcmodel=tiny DEF(GCC_AARCH64_CC_FLAGS)
> DEFINE GCC49_ARM_DLINK_FLAGS = DEF(GCC48_ARM_DLINK_FLAGS)
> DEFINE GCC49_ARM_DLINK2_FLAGS= DEF(GCC48_ARM_DLINK2_FLAGS)
> DEFINE GCC49_AARCH64_DLINK_FLAGS = DEF(GC
ge below.
>// The PageLevel was calculated on the Base Address alignment but did not
> take in account the alignment
> --
> 1.9.1
Reviewed-by: Leif Lindholm
Thanks.
/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
alks
> - // flush and invalidate pages
> - ArmCleanInvalidateDataCache ();
> -
> - ArmInvalidateInstructionCache ();
> -
Yeah, this looks like a plain copy from the 32-bit code (where it is
needed ... although I'm not convinced this is the correct operation
even for 32-bit - need to revisit).
Th
> + return UpdateRegionMapping (
> + RootTable,
> + MemoryRegion->VirtualBase,
> + MemoryRegion->Length,
> + ArmMemoryAttributeToPageAttribute (MemoryRegion->Attributes) |
> TT_AF,
> + 0
> + );
> +}
> +
#
> SOMETIMES_CONSUMES
> +
> +[Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
> gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack ##
> SOMETIMES_CONSUMES
>
> [Depex]
> --
> 1.9.1
Fine from an ARM perspective, but I guess it needs a nod from Feng
Tian as well.
Reviewed-by: Leif Lindholm
/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
RelocateArmImage (
>
> if (*FixupData != NULL) {
>*FixupData = ALIGN_POINTER(*FixupData, sizeof(UINT64));
> - *(UINT64 *)(*FixupData) = *Fixup16;
>CopyMem (*FixupData, Fixup16, sizeof (UINT64));
> + *FixupData = *FixupData + sizeof(UINT64);
> }
p16, FixupVal);
> }
> +*FixupData = *FixupData + sizeof(UINT64);
> break;
>
>case EFI_IMAGE_REL_BASED_ARM_MOV32A:
> --
> 1.9.1
Reviewed-by: Leif Lindholm
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
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 Agreemen
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
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
ibutes & TT_UXN_MASK) {
> +// XN maps to UXN in the EL1&0 translation regime
> + if (Attributes & TT_XN_MASK) {
>TableAttributes = TT_TABLE_XN;
> }
> if (Attributes & TT_NS) {
> --
> 1.9.1
Nice cleanup, thanks.
Reviewed-by: Leif Lindholm
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
+, Supreeth Venkatesh wrote:
> 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:
Hi Yehuda,
On Thu, Oct 08, 2015 at 08:24:07AM +, Yehuda Yitschak wrote:
> I am new to the EDK2 projects and for starters I am trying to cross
> compile the project for aarch64 on an x86_64 host
>
> I looked around in Linaro website and Tiano-core website but
> couldn't find any instruction on
On Thu, Oct 08, 2015 at 10:04:24AM +, Yehuda Yitschak wrote:
> > > but when I try to compile using the "build" command the build script
> > > uses the x86 compiler and naturally it fails
> >
> > Any particular reason why you skipped past the first half of the page to
> > follow the instruction
Length
> + )
> +{
> + return RETURN_UNSUPPORTED;
> +}
> +
> +RETURN_STATUS
> +ArmSetMemoryRegionReadOnly (
> + IN EFI_PHYSICAL_ADDRESS BaseAddress,
> + IN UINT64Length
> + )
> +{
> + return RETURN_UNSUPPORTED;
> +}
> +
> +RETURN_STATUS
> +ArmClearMemoryRegionReadOnly (
> + IN EFI_PHYSICAL_ADDRESS BaseAddress,
> + IN UINT64Length
> + )
> +{
> + return RETURN_UNSUPPORTED;
> +}
> --
> 1.9.1
Provided you sort out the ArmSetMemoryRegionAttribute to
SetMemoryRegionAttribute renaming before committing:
Reviewed-by: Leif Lindholm
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
b/BaseTools/Scripts/PatchCheck.py
> new file mode 100644
Here is actually the only complaint I'm going to make, and it's a bit
random:
Even though scripts in edk2 don't tend to describe their interpreter
(#!), they do tend to be 100755 mode, which highlights them as
executables
On Sat, Oct 10, 2015 at 08:45:19AM -0700, Jordan Justen wrote:
> On 2015-10-10 04:07:22, Leif Lindholm wrote:
> > On Wed, Oct 07, 2015 at 07:53:18PM -0700, Jordan Justen wrote:
> > > This script can be used to check some expected rules for EDK II
> > > patches. It
On Mon, Oct 12, 2015 at 08:50:53AM +, Yehuda Yitschak wrote:
> Thanks. It worked fine.
> I assumed the linaro-edk2 GIT should be more up to date with ARM
> fixes but I think this is not the case here.
No, that will never be the case - we work upstream, so fixes only go
into linaro-edk2 after
/show_bug.cgi?id=1270279
> - http://thread.gmane.org/gmane.comp.bios.edk2.devel/2772/focus=2869
This all looks very sensible. One comment inline.
> Cc: Leif Lindholm
> Cc: Ard Biesheuvel
> Cc: Drew Jones
> Cc: Yehuda Yitschak
> Contributed-under: TianoCore Contributi
o separate
> > DEBUG statements?
>
> I'll break them up. I don't like overlong lines. :)
Sure.
> I assume you'd like to see the two sentences on separate lines in the
> log output as well (so that noone is tempted to search for the full line
> in the source). I
On Wed, Oct 14, 2015 at 01:00:15PM +0800, Qiu Shumin wrote:
> Cc: Jaben Carsey
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Qiu Shumin
Could we have a commit message, please?
Does this resolve an observed problem, or was it found through code
review?
Regards,
Leif
On Wed, Oct 14, 2015 at 04:29:27PM +0800, Eric Dong wrote:
> In current implementation, the "endif" opcode for suppressif has an end ";"
> for the statement opcode, but not for the option opcode. This is not a user
> friendly grammar. So this patch fixed this issue. Add an optional ";" end for
>
401 - 500 of 2408 matches
Mail list logo
