The protocol EFI_FORM_BROWSER_EXTENSION_PROTOCOL is defined in
MdeModulePkg\Include\Protocol\FormBrowserEx.h with EFI_ prefix although it is
not part of the UEFI spec.
(It was added by Intel - Liming - in Sep 2011)
IMHO it should be added to the UEFI spec otherwise it should not use the EFI_
pr
On 15 September 2016 at 16:48, Andrew Fish wrote:
>
>> On Sep 15, 2016, at 8:28 AM, Leif Lindholm wrote:
>>
>> On Thu, Sep 15, 2016 at 03:54:56PM +0100, Ard Biesheuvel wrote:
>>> The 'universal' PCI bus driver in MdeModulePkg contains a quirk to
>>> degrade 64-bit PCI MMIO BARs to 32-bit in the p
On 09/15/2016 10:48 AM, Andrew Fish wrote:
On Sep 15, 2016, at 8:28 AM, Leif Lindholm wrote:
On Thu, Sep 15, 2016 at 03:54:56PM +0100, Ard Biesheuvel wrote:
The 'universal' PCI bus driver in MdeModulePkg contains a quirk to
degrade 64-bit PCI MMIO BARs to 32-bit in the presence of an option
> On Sep 15, 2016, at 8:28 AM, Leif Lindholm wrote:
>
> On Thu, Sep 15, 2016 at 03:54:56PM +0100, Ard Biesheuvel wrote:
>> The 'universal' PCI bus driver in MdeModulePkg contains a quirk to
>> degrade 64-bit PCI MMIO BARs to 32-bit in the presence of an option
>> ROM on the same PCI controller.
On Thu, Sep 15, 2016 at 03:54:56PM +0100, Ard Biesheuvel wrote:
> The 'universal' PCI bus driver in MdeModulePkg contains a quirk to
> degrade 64-bit PCI MMIO BARs to 32-bit in the presence of an option
> ROM on the same PCI controller.
>
> This quirk is highly specific to not just the X64 archite
The 'universal' PCI bus driver in MdeModulePkg contains a quirk to
degrade 64-bit PCI MMIO BARs to 32-bit in the presence of an option
ROM on the same PCI controller.
This quirk is highly specific to not just the X64 architecture in general,
but to the PC platform in particular, given that only X6
On 15 September 2016 at 14:34, Ard Biesheuvel wrote:
> On 15 September 2016 at 14:30, Ard Biesheuvel
> wrote:
>> Patch #4 moves HighMemDxe to the FDT client protocol, and updates it to
>> handle #address-cells/#size-cells values of <1> as well as <2>, and lets
>> it deal with memory nodes whose
On 15 September 2016 at 15:15, Laszlo Ersek wrote:
> On 09/15/16 15:30, Ard Biesheuvel wrote:
>> Use the FDT client protocol rather than parsing the DT directly using
>> fdtlib. While we're at it, update the code so it deals correctly with
>> memory nodes that describe multiple disjoint regions in
On 09/15/16 15:30, Ard Biesheuvel wrote:
> Use the FDT client protocol rather than parsing the DT directly using
> fdtlib. While we're at it, update the code so it deals correctly with
> memory nodes that describe multiple disjoint regions in their "reg"
> properties, and make the code work with #a
On 15 September 2016 at 14:57, Laszlo Ersek wrote:
> On 09/15/16 15:30, Ard Biesheuvel wrote:
>> Add high level methods to iterate over all 'reg' properties of all DT
>> nodes whose device_type properties have the value "memory". Since we are
>> modifying the FdtClient protocol, update the protoco
On 09/15/16 15:30, Ard Biesheuvel wrote:
> Add high level methods to iterate over all 'reg' properties of all DT
> nodes whose device_type properties have the value "memory". Since we are
> modifying the FdtClient protocol, update the protocol and the only existing
> implementation at the same time
On 09/15/16 15:30, Ard Biesheuvel wrote:
> The FDT client protocol methods dealing with "reg" properties return
> the size of a 'reg' element. Currently, we have hardcoded this as '8',
> since #address-cells == #size-cells == 2 in most cases. However, for
> different values, have a single 'reg' ele
On 15 September 2016 at 14:38, Laszlo Ersek wrote:
> On 09/15/16 15:30, Ard Biesheuvel wrote:
>> Currently, the code in FdtClientDxe assumes #address-cells and
>
> s/and/are/?
>
No, amusingly, the second sentence started with #size-cells, and was
dropped completely by git commit due to the leadin
On 09/15/16 15:30, Ard Biesheuvel wrote:
> Currently, the code in FdtClientDxe assumes #address-cells and
s/and/are/?
Reviewed-by: Laszlo Ersek
> of tuples, this means the size of the entire property
> should always be a multiple of 16 bytes (i.e, 4 * sizeof(UINT32),
> not 8. So fix this.
>
>
On 15 September 2016 at 14:30, Ard Biesheuvel wrote:
> Patch #4 moves HighMemDxe to the FDT client protocol, and updates it to
> handle #address-cells/#size-cells values of <1> as well as <2>, and lets
> it deal with memory nodes whose 'reg' properties describe multiple disjoint
> regions.
>
> Pat
The FDT client protocol methods dealing with "reg" properties return
the size of a 'reg' element. Currently, we have hardcoded this as '8',
since #address-cells == #size-cells == 2 in most cases. However, for
different values, have a single 'reg' element size is not unambiguous,
since - however unl
Use the FDT client protocol rather than parsing the DT directly using
fdtlib. While we're at it, update the code so it deals correctly with
memory nodes that describe multiple disjoint regions in their "reg"
properties, and make the code work with #address-cells/#size-cells
properties of <1> as wel
Add high level methods to iterate over all 'reg' properties of all DT
nodes whose device_type properties have the value "memory". Since we are
modifying the FdtClient protocol, update the protocol and the only existing
implementation at the same time.
Contributed-under: TianoCore Contribution Agre
Currently, the code in FdtClientDxe assumes #address-cells and
of tuples, this means the size of the entire property
should always be a multiple of 16 bytes (i.e, 4 * sizeof(UINT32),
not 8. So fix this.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel
---
Ar
Patch #4 moves HighMemDxe to the FDT client protocol, and updates it to
handle #address-cells/#size-cells values of <1> as well as <2>, and lets
it deal with memory nodes whose 'reg' properties describe multiple disjoint
regions.
Patches #1 to #3 are somewhat preparatory in nature:
- Patch #1 is a
Mike,
I updated the library to be based on DxeRuntimePciExpressLib.
Here is the new patch.
Thanks,
Felix
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Felix Polyudov mailto:fel...@ami.com>>
==
diff --git a/MdePkg/Library/SmmPciExpressLib/PciExpressLib.c
b/MdePkg/Library
On 15 September 2016 at 10:01, Laszlo Ersek wrote:
> On 09/15/16 10:45, Sakar Arora wrote:
>> Hi
>>
>> This is in aarch64 UEFI context.
>>
>> The efi stub code ignores any memory nodes in the device tree. It
>> only relies on the UEFI memory map for memory info.
>>
>> In such a scenario, how can o
On Wed, Sep 14, 2016 at 05:14:19PM +, Kinney, Michael D wrote:
> MdePkg/Include/Library/UefiLib.h does have some helper macros for
> setting timer events periods that are in 100 nS units:
>
> #define EFI_TIMER_PERIOD_MICROSECONDS(Microseconds)
> MultU64x32((UINT64)(Microseconds), 10)
> #d
Hi Andrew, list,
Just a follow-up.
On Wed, Sep 07, 2016 at 08:34:47AM -0700, Andrew Fish wrote:
> > The symptom is a failed link step with the message:
> > /usr/bin/ld: unrecognised emulation mode: aarch64linux
> >
> > As a workaround, I was able to get my build functional again by
> > creating
On 09/15/16 10:45, Sakar Arora wrote:
> Hi
>
> This is in aarch64 UEFI context.
>
> The efi stub code ignores any memory nodes in the device tree. It
> only relies on the UEFI memory map for memory info.
>
> In such a scenario, how can one export discontiguous regions of
> system memory to the e
Hi
This is in aarch64 UEFI context.
The efi stub code ignores any memory nodes in the device tree. It only relies
on the UEFI memory map for memory info.
In such a scenario, how can one export discontiguous regions of system memory
to the efi stub? There seems to be only one way to inform UEFI
26 matches
Mail list logo
