Hi Mark:
Forgive the manual formatting...I'm stuck with outlook ;)
> -Original Message-
> From: Mark Kettenis [mailto:mark.kette...@xs4all.nl]
> Sent: Friday, December 7, 2018 1:45 PM
[snip]
> But the contributor agreement only applies for people that want to
> contribute their code bac
> From: "Doran, Mark"
> Date: Fri, 7 Dec 2018 17:44:15 +
>
> Hi Mark:
>
> Thanks for your note. The terms and conditions for EDK II code include two
> elements today and they have to be considered together. Namely the
> Contributor Agreement and the two clause BSD outbound terms. Together
Matteo,
Since EDK II does use some content from a few other projects, we do
need content under other supported licenses to be allowed. However,
we have discussed these dependencies and would prefer they are included
as git-submodules so the sources are not in the EDK II repositories.
There will b
On Fri, 7 Dec 2018 at 09:28, Vijayenthiran Subramaniam
wrote:
>
> Add HDLCD platform library for SGI platform that implements platform
> callbacks for the Arm HDLCD driver.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Vijayenthiran Subramaniam
> ---
> Change from v
Ok from Arm side, as long as contributions submitted under the existing
TianoCore Contribution Agreement 1.1 (BSD 2-Clause) will still be accepted, as
it's somehow implied by point 3).
Thanks
Matteo
> -Original Message-
> From: Leif Lindholm
> Sent: 29 November 2018 22:54
> To: Kinney,
On Fri, 7 Dec 2018 at 15:33, Pete Batard wrote:
>
> Hi Ard,
>
> On 2018.12.07 14:08, Ard Biesheuvel wrote:
> > On Fri, 7 Dec 2018 at 13:13, Pete Batard wrote:
> >>
> >> Preamble:
> >>
> >> Because of its price point, ease of use and availability, the Raspberry Pi
> >> is
> >> undeniably one of t
Hi Ard,
On 2018.12.07 14:08, Ard Biesheuvel wrote:
On Fri, 7 Dec 2018 at 13:13, Pete Batard wrote:
Preamble:
Because of its price point, ease of use and availability, the Raspberry Pi is
undeniably one of the most successful ARM platform in existence today. Its
widespread adoption therefore
On 12/07/18 14:26, Knop, Ryszard wrote:
> Hi Laszlo,
> Regarding "functions that take variable arguments must be EFIAPI, even if
> they are STATIC (long story)" - what's the story? :)
If I remember correctly, the issue was that the VA_*() macros could not
be implemented on gcc -- or, on *all* sup
On Fri, 7 Dec 2018 at 13:13, Pete Batard wrote:
>
> Preamble:
>
> Because of its price point, ease of use and availability, the Raspberry Pi is
> undeniably one of the most successful ARM platform in existence today. Its
> widespread adoption therefore makes it a perfect fit as an EDK2 platform.
>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1381
In Dispatch mode FSP may consume PPI directly so creating
FSPM_ARCH_CONFIG_PPI to align with FSPM_ARCH_UPD.
Test: Verified on internal platform to boot with this PPI
installed successfully.
Cc: Nate DeSimone
Cc: Star Zeng
Contributed-und
Hi Laszlo,
Regarding "functions that take variable arguments must be EFIAPI, even if they
are STATIC (long story)" - what's the story? :)
Thanks, Richard.
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
Ersek
Sent: Friday, December 7, 2018
On December 7, 2018 at 5:00:55 AM, Laszlo Ersek
(ler...@redhat.com(mailto:ler...@redhat.com)) wrote:
> To be honest, I'm stumped how Mozilla could adopt (according to the
> article linked at the top) "Phabricator as the primary code review
> system for Firefox".
They previously used Review Bo
On 12/06/18 23:46, Bill Paul wrote:
> Of all the gin joints in all the towns in all the world, Peter Wiehe had to
> walk into mine at 14:34 on Thursday 06 December 2018 and say:
>
>> OK, another question:
>>
>> when writing an UEFI application, edk2 and gnu-efi have different 64bit
>> calling sch
On 12/07/18 12:22, Ard Biesheuvel wrote:
> On some architectures, the maximum representable address deviates from
> the virtual address range that is accessible by the firmware at boot
> time. For instance, on AArch64, UEFI mandates a 4 KB page size, which
> limits the address space to 48 bits, whi
On 12/07/18 12:23, Ard Biesheuvel wrote:
> Limit MAX_ALLOC_ADDRESS to 48 bits on AArch64 so that the memory
> handling routines running at boot time take care not to allocate
> memory that the CPU itself cannot access due to the fact that it
> runs with 4 KB pages and thus an address space that is
On Fri, 7 Dec 2018 at 13:47, Ard Biesheuvel wrote:
>
> On Fri, 7 Dec 2018 at 13:46, Laszlo Ersek wrote:
> >
> > On 12/07/18 12:23, Ard Biesheuvel wrote:
> > > Limit the PEI memory region so it will not extend beyond what we can
> > > address architecturally when running with 4 KB pages.
> > >
> >
On Fri, 7 Dec 2018 at 13:46, Laszlo Ersek wrote:
>
> On 12/07/18 12:23, Ard Biesheuvel wrote:
> > Limit the PEI memory region so it will not extend beyond what we can
> > address architecturally when running with 4 KB pages.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signe
On 12/07/18 12:23, Ard Biesheuvel wrote:
> The current ArmVirtMemoryInitPeiLib code splits the memory region passed
> via PcdSystemMemoryBase/PcdSystemMemorySize in two if the region extends
> beyond the MAX_ADDRESS limit. This was introduced for 32-bit ARM, which
> may support more than 4 GB of ph
On 12/07/18 12:23, Ard Biesheuvel wrote:
> Limit the PEI memory region so it will not extend beyond what we can
> address architecturally when running with 4 KB pages.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmPlatformPkg/MemoryInitPei
On 12/07/18 12:23, Ard Biesheuvel wrote:
> When creating the page tables for the 1:1 mapping, ensure that we don't
> attempt to map more than what is architecturally permitted when running
> with 4 KB pages, which is 48 bits of VA. This will be reflected in the
> value of MAX_ALLOC_ADDRESS once we
Preamble:
Because of its price point, ease of use and availability, the Raspberry Pi is
undeniably one of the most successful ARM platform in existence today. Its
widespread adoption therefore makes it a perfect fit as an EDK2 platform.
However, up until now, the Raspberry Pi hasn't been supporte
Hi,
I'd like to conclude my Phabricator investigation now. Indeed I have
spent a lot less time on it than on GitHub, however my reason for this
earlier finish is not bias or exhaustion. I believe to have found some
pretty critical functionality gaps in Phabricator, which make it
"secondary" how th
On Fri, Dec 07, 2018 at 11:43:14AM +0100, Ard Biesheuvel wrote:
> > I was worried the patch could regress some things, but unfortunately, I
> > couldn't name any specific area of concern. Sorry about that.
> >
>
> Sometimes a hunch should be taken more seriously, I suppose :-)
Nah, that's what th
On Fri, 7 Dec 2018 at 11:43, Ard Biesheuvel wrote:
>
> On Fri, 7 Dec 2018 at 11:41, Laszlo Ersek wrote:
> >
> > On 12/06/18 22:37, Ard Biesheuvel wrote:
> > > This reverts commit 82379bf6603274e81604d5a6f6bb14bdde616286.
> > >
> > > On AArch64, we can only use 48 address bits while running in UEF
Limit MAX_ALLOC_ADDRESS to 48 bits on AArch64 so that the memory
handling routines running at boot time take care not to allocate
memory that the CPU itself cannot access due to the fact that it
runs with 4 KB pages and thus an address space that is limited to
256 TB.
Contributed-under: TianoCore
When creating the page tables for the 1:1 mapping, ensure that we don't
attempt to map more than what is architecturally permitted when running
with 4 KB pages, which is 48 bits of VA. This will be reflected in the
value of MAX_ALLOC_ADDRESS once we override it for AArch64, so use that
macro instea
On some architectures, the maximum representable address deviates from
the virtual address range that is accessible by the firmware at boot
time. For instance, on AArch64, UEFI mandates a 4 KB page size, which
limits the address space to 48 bits, while more than that may be
populated on a particula
Limit the PEI memory region so it will not extend beyond what we can
address architecturally when running with 4 KB pages.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c | 4 ++--
1 file changed, 2 insertion
The current ArmVirtMemoryInitPeiLib code splits the memory region passed
via PcdSystemMemoryBase/PcdSystemMemorySize in two if the region extends
beyond the MAX_ADDRESS limit. This was introduced for 32-bit ARM, which
may support more than 4 GB of physical address space, but cannot address
all of i
Update the GCD memory map initialization code so it disregards
memory that is not addressable by the CPU at boot time. This
only affects the first memory descriptor that is added, other
memory descriptors are permitted that describe memory ranges
that may be accessible to the CPU itself only when e
Since modifying MAX_ADDRESS to limit the memory used at boot time has
turned out to be intractible, this series proposes another approach to do
the same, by introducing MAX_ALLOC_ADDRESS for firmware internal use.
I tested these patches with ArmVirtQemu in the following way:
- limit MAX_ALLOC_ADDR
Take MAX_ALLOC_ADDRESS into account in the implementation of the
page allocation routines, so that they will only return memory
that is addressable by the CPU at boot time, even if more memory
is available in the GCD memory map.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by
> From: "Kinney, Michael D"
> Date: Thu, 29 Nov 2018 18:39:28 +
As an OpenBSD developer I feel I have to point out that the OpenBSD
project considers Apache 2.0 to be a *restrictive* license.
http://www.openbsd.org/policy.html
We (currently) don't include EDK II code in the OpenBSD OS its
On Fri, 7 Dec 2018 at 11:41, Laszlo Ersek wrote:
>
> On 12/06/18 22:37, Ard Biesheuvel wrote:
> > This reverts commit 82379bf6603274e81604d5a6f6bb14bdde616286.
> >
> > On AArch64, we can only use 48 address bits while running in UEFI,
> > while the GCD and UEFI memory maps may describe up to 52 bi
On 12/06/18 22:37, Ard Biesheuvel wrote:
> This reverts commit 82379bf6603274e81604d5a6f6bb14bdde616286.
>
> On AArch64, we can only use 48 address bits while running in UEFI,
> while the GCD and UEFI memory maps may describe up to 52 bits of
> physical address space. For this reason, MAX_ADDRESS
Add HDLCD platform library for SGI platform that implements platform
callbacks for the Arm HDLCD driver.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Vijayenthiran Subramaniam
---
Change from v2:
No code change. Posting patch again with Change-Id removed.
Platform/ARM/
36 matches
Mail list logo
