hi Achin,
On Sat Dec 01, 2018 at 05:08:50AM +0530, Achin Gupta wrote:
> Hi Sughosh,
>
> +Jiewen
>
> I took the patches for a spin and it looks like the FVP port is broken. Some
> reasons are:
>
> 1. The build breaks due to a reference to ArmMmuLib in StandaloneMmPkg.dsc
> 2. There is a broken d
Hi Leif,
> -Original Message-
> From: Leif Lindholm
> Sent: Thursday, November 1, 2018 11:20 AM
> To: Chris Co
> Cc: edk2-devel@lists.01.org; Ard Biesheuvel ;
> Michael D Kinney
> Subject: Re: [PATCH edk2-platforms 09/27] Silicon/NXP: Add headers for SoC-
> specific i.MX packages to use
Hi Sughosh,
+Jiewen
I took the patches for a spin and it looks like the FVP port is broken. Some
reasons are:
1. The build breaks due to a reference to ArmMmuLib in StandaloneMmPkg.dsc
2. There is a broken dependency on PL011UartClockLib in StandaloneMmPkg.dsc
3. GCC flags to enforce strict alig
The maximum value that can be represented by the native word size
of the *target* should be irrelevant when compiling tools that
run on the build *host*. So drop the definition of MAX_UINTN, now
that we no longer use it.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Bi
Parsing a string into an integer variable of the native word size
is not defined for the BaseTools, since the same tools may be used
to build firmware for different targets with different native word
sizes.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Replace invocations of StrHexToUintn() with StrHexToUint64(), so
that we can drop the former.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Jaben Carsey
---
BaseTools/Source/C/DevicePath/DevicePathFromText.c | 4 ++--
1 file changed, 2 insert
There should be no reason for the build tools to care about the native
word size of a particular target, so relying on a definition of MAX_UINTN
is definitely wrong, and most likely inaccurate on 32-bit build hosts.
So refactor the code in CommonLib and DevicePath so we no longer rely
on this defi
In the context of the BaseTools, there is no such thing as a native word
size, given that the same set of tools may be used to build a firmware
image consisting of both 32-bit and 64-bit modules.
So update StrToIpv4Address() and StrToIpv6Address() to use UINT64
types instead of UINTN types when pa
Replace the default size limit of IsDevicePathValid() with a value
that does not depend on the native word size of the build host.
64 KB seems sufficient as the upper bound of a device path handled
by UEFI.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Rev
Don't use the native word size string to number parsing routines,
but instead, use the 64-bit one and cast to UINTN.
Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c
which takes care to use Strtoi64 () unless it assumes the value fits
in 32-bit, so this change is a no-op eve
Commit message to mention what this patch is imlementing.
In addition, there is cleanup to remove #if 0 block below.
Both of this should be in commit message.
On Thu, 2018-11-29 at 16:46 +0800, Eric Jin wrote:
> Cc: Supreeth Venkatesh
> Contributed-under: TianoCore Contribution Agreement 1.1
> S
Could we add some details on VerfiySignature() func test
in the commit message?
Also, looks like there are additional cleanup of the file
in addition to VerfiySignature() func test. (see inline below)
Coulyou please update commit message with the details
of the cleanup.
On Thu, 2018-11-29 at 1
On Thu, 29 Nov 2018 at 18:59, Ard Biesheuvel wrote:
>
> On Wed, 28 Nov 2018 at 15:34, Ard Biesheuvel
> wrote:
> >
> > This v3 subsumes and/or supersedes
> >
> > [PATCH v2 00/13] ArmPkg, ArmVirtPkg: lift 40-bit IPA space limit
> > [PATCH] MdePkg/ProcessorBind.h AARCH64: limit MAX_ADDRESS to 48 bi
Felix,
I agree the obfuscation may not really be helpful. I've got a couple of
thoughts.
1) I agree that I don't think the DebugLib is inherently safe on APs. I wonder
if we could make a library class that was DebugLibMpSafe and have the same API
as DebugLib. That way the library class matches
One of the goals with this proposal is to minimize
the amount of source code that needs to be setup in
a WORKSPACE to build firmware for a given platform.
If a platform does not require any applications that
require the libc, then it would be better if the libc
related packages and applications tha
I do not think that expanding shellPkg would work since there is no requirement
that any of these apps depend on it. As was stated, MicroPythonPkg does not.
I also do not think that moving ShellPkg makes lots of sense since it is used
by many platforms.
-Jaben
> -Original Message-
> F
Ard:
OK. Will you send v2 patch to fix this issue?
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, November 29, 2018 11:18 PM
> To: Gao, Liming
> Cc: edk2-devel@lists.01.org; Laszlo Ersek ; Zhu, Yonghong
> ; Feng, Bob C
>
> Subject: Re
Oops! I think this change may have an issue.
Hold off and I'll let you know if that's the case.
--Jim
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dailey,
Jim
Sent: Friday, November 30, 2018 9:12 AM
To: liming@intel.com; michael.d.kin...
PathCleanUpDirectories does not handle "\..\" properly; it
returns "\" instead of "". This change fixes that
problem so that "" is returned.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jim Dailey
---
MdePkg/Library/BaseLib/FilePaths.c | 7 ++-
1 file changed, 6
Ray,
I agree with the premise that calling PEI services from AP should generally be
avoided.
However, the PEI services can be used on AP under certain special circumstances.
A couple of examples:
1. For debugging purposes. The MpInitLib contains 12 DEBUG calls and 19 ASSERT
calls. Depending on t
This covers the bulk of the information originally present in
https://github.com/tianocore/tianocore.github.io/wiki/ArmPlatformPkg-AArch64
regarding building and running the Foundation/Base FVP Platforms.
The sections on fetching source have been delegated to the root Readme.md
Contributed-under:
On Fri, Nov 30, 2018 at 12:28:27PM +0100, Ard Biesheuvel wrote:
> The ARM ArmMmuLib code currently does not take into account that
> setting permissions on a region should take into account that a
> region may not be mapped yet to begin with.
>
> So when updating a section descriptor whose old val
On Fri, Nov 30, 2018 at 12:28:26PM +0100, Ard Biesheuvel wrote:
> GetMemoryRegion() is used to obtain the attributes of an existing
> mapping, to permit permission attribute changes to be optimized
> away if the attributes don't actually change.
>
> The current ARM code assumes that a section mapp
The primary FV contains the firmware boot image, which is not
runtime updatable in our case. So exposing it to the NOR flash
driver is undesirable, since it may attempt to modify the NOR
flash contents. It is also rather pointless, since we don't
keep anything there that we care to expose. (the SEC
Rationale in patch #4. Patch #3 is a prerequisite patch that ensures
that we no longer need page #0 to be mapped for the NOR flash driver
to be able to expose it as a read/write block device.
Patches #1 and #2 are fixes for the ARM version of the ArmMmuLib driver
for bugs that get triggered by the
GetMemoryRegion() is used to obtain the attributes of an existing
mapping, to permit permission attribute changes to be optimized
away if the attributes don't actually change.
The current ARM code assumes that a section mapping or a page mapping
exists for any region passed into GetMemoryRegion(),
QEMU/mach-virt is rather unhelpful when it comes to tracking down
NULL pointer dereferences that occur while running in UEFI: since
we have NOR flash mapped at address 0x0, inadvertent reads go
unnoticed, and even most writes are silently dropped, unless you're
unlucky and the instruction in questi
The ARM ArmMmuLib code currently does not take into account that
setting permissions on a region should take into account that a
region may not be mapped yet to begin with.
So when updating a section descriptor whose old value is zero,
pass in the address explicitly.
Contributed-under: TianoCore
On Fri, 30 Nov 2018 at 12:00, Leif Lindholm wrote:
>
> On Fri, Nov 30, 2018 at 11:55:03AM +0100, Ard Biesheuvel wrote:
> > gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize will be removed, so
> > drop any overrides from the platforms in edk2-platforms.
> >
> > Contributed-under: TianoCore Contributio
On Fri, Nov 30, 2018 at 11:55:03AM +0100, Ard Biesheuvel wrote:
> gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize will be removed, so
> drop any overrides from the platforms in edk2-platforms.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by:
gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize will be removed, so
drop any overrides from the platforms in edk2-platforms.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Silicon/Hisilicon/Hisilicon.dsc.inc | 1 -
Silicon/Marvell
Thanks Laszlo/Andrew
Finally I manage to get logs from user-space, problem was fifo of PL011 uart
was not getting enable in case of direct boot.
But in case of boot via UiApp, some piece of code was setting serial port
attribute to enable this ( I still to figure out from where).
OS rely on bo
Good point. For BaseTools part, we also need to remove their user manual and
PosixLike in BaseTools\UserManuals and BaseTools\BinWrappers\PosixLike
directory.
Thanks
Liming
>-Original Message-
>From: Wu, Hao A
>Sent: Friday, November 30, 2018 4:15 PM
>To: Zhang, Shenglei ; edk2-devel@li
Reviewed-by: Bob Feng
Thanks Yonghong for his great works as Basetools maintainer.
-Original Message-
From: Zhu, Yonghong
Sent: Thursday, November 29, 2018 4:09 PM
To: edk2-devel@lists.01.org
Cc: Feng, Bob C ; Gao, Liming
Subject: [Patch] Maintainers.txt: Update BaseTools maintainers
Hi Jagadeesh,
I don't suggest to update BaseCryptLib to use a PCD in StandaloneMmPkg, it
makes other consumer of BaseCryptLib has dependency of StandaloneMmPkg.
Also ToDo code below is not acceptable to me. I am thinking you could consider
creating a new instance for BaseCryptLib such as "MmCr
For the DuetPkg change:
Reviewed-by: Hao Wu
For the BaseTools change:
I am not sure whether cleanup should also be done within directory:
edk2\BaseTools\UserManuals
I will let Liming to decide.
Sorry for not spotting this earlier.
Best Regards,
Hao Wu
> -Original Message-
> From: ed
Hello,
Please refer to the inline comments below:
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Friday, November 30, 2018 3:15 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH v6 2/2] Md
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Friday, November 30, 2018 2:48 AM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Subject: Re: [edk2] [PATCH v3 2/2] MdeModulePkg/SdMmcPciHcDxe: Add
> V4 64bit SDMA and ADMA2 su
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ashish Singhal
> Sent: Friday, November 30, 2018 3:15 AM
> To: edk2-devel@lists.01.org
> Cc: Ashish Singhal
> Subject: [edk2] [PATCH v6 1/2] MdeModulePkg/SdMmcPciHcDxe: Declare V4
> 64 bit addres
39 matches
Mail list logo
