Link DXE_SMM_DRIVER, UEFI_DRIVER, UEFI_APPLICATION, and SMM_CORE against
a valid, non-asserting version of PcdLib, then switch them over to using
the "Dxe" instance of AcpiTimerLib (instead of the "Base" version).
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo
Use a PCD set from PEI to determine the legacy interrupt device
number appropriate for the underlying platform type during protocol
initialization.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo
Reviewed-by: Paolo Bonzini
Reviewed-by: Jordan Justen
Reviewed
Merge PciInitialization() and AcpiInitialization() into a single
function, PciAcpiInitialization(), and use a PCD set during PEI to
detect the underlying platform type (PIIX4 or Q35/MCH) and therefore
the addresses of the registers to be initialized.
Add LNK[A-H] routing target initialization for
Introduce macros to detect the underlying platform and access its
ACPI power management registers, based on querying the host bridge
device ID.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo
Reviewed-by: Paolo Bonzini
Reviewed-by: Jordan Justen
Reviewed-by:
Remove local power management register access macros in favor of
factored-out ones in OvmfPkg/Include/OvmfPlatforms.h
Next, AcpiTimerLib is split out into three instances, for use during
various stages:
- BaseRom: used during SEC, PEI_CORE, and PEIM;
- Dxe: used during DXE_DRIVER and DXE_
Remove hard-coded list of PCI devices for which the Interrupt Line
register is initialized. Instead, provide a "visitor" function to
initialize the register only for present and applicable PCI devices.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo
---
The o
Since in OVMF both PEI_CORE and PEIM run from RAM, and thus may
utilize global variables, use the "Base" AcpiTimerLib instance
(instead of BaseRom) to take advantage of the improved efficiency
of storing the timer register IO address in a global variable.
This leaves only SEC using the BaseRomAcpi
Set from PEI, this PCD allows subsequent stages (specifically
DXE_DRIVER and DXE_RUNTIME_DRIVER) to infer the underlying platform
type (e.g. PIIX4 or Q35/MCH) without the need to further query the
Host Bridge for its Device ID.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by:
New in version 5:
- v4 patches 1-3,5 are now patches 1-4 (this is the uncontroversial
stuff everyone already agrees with, so feel free to fast-forward)
- v4 patch 4 (AcpiTimerLib) is now patch 5
- followed by new patches 6 and 7, which promote some stages
toward smarter ins
Set up ACPI power management using registers determined based on
the underlying (PIIX4 or Q35/MCH) platform type.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gabriel Somlo
Reviewed-by: Paolo Bonzini
Reviewed-by: Jordan Justen
Reviewed-by: Gerd Hoffmann
Reviewed-by: L
> On Nov 8, 2014, at 2:51 PM, Jordan Justen wrote:
>
>>
>> I’m not saying this is the right solution, but we should ask the
>> question should we tie the override to the build_rule.template file
>> sections vs. trying to override the contents of these actions. That
>> is just a good thing for a
On 2014-11-07 20:03:09, Andrew Fish wrote:
> > On Nov 7, 2014, at 7:43 PM, Jordan Justen wrote:
> > On 2014-11-07 15:53:55, Andrew Fish wrote:
> >> I was having lunch today with Mike Kinney, and Vincent Zimmer
> >> (unfortunately no Tanqueray involved) and I think I’ve distilled the
> >> issue dow
> On Nov 8, 2014, at 2:33 PM, Jordan Justen wrote:
>
> To contradict my request for separate patches for each package, I do
> think this is a case where a single patch makes more sense even though
> it touches multiple packages.
>
> I don't really find the NOOPT target very interesting. I think
> On Nov 8, 2014, at 2:23 PM, Jordan Justen wrote:
>
> On 2014-11-04 15:05:52, Paulo Alcantara wrote:
>> The UDF bridge format allows UDF discs to be used with other filesystems. The
>> UDF filesystem must be located in the last disc session as per specification.
>>
>> An UDF bridge disc will n
To contradict my request for separate patches for each package, I do
think this is a case where a single patch makes more sense even though
it touches multiple packages.
I don't really find the NOOPT target very interesting. I think we
don't actually gain much with NOOPT since it can't often be us
On 2014-11-04 15:05:52, Paulo Alcantara wrote:
> The UDF bridge format allows UDF discs to be used with other filesystems. The
> UDF filesystem must be located in the last disc session as per specification.
>
> An UDF bridge disc will normally contain both ISO-9660 and UDF filesystems.
> Since the
On compilers, like clang, that support frame pointers it is possible to walk
the frame programmatically. So __builtin_return_address(n) works on the entire
frame. So why don’t we add an argument to RETURN_ADDRESS().
For VC++ you can do this:
#define RETURN_ADDRESS(_level) ((_level == 0) ? _Retu
Err, and I probably should have included the platform updates in the
same patch... Ignore that patch, and please consider the below
instead:
>From 628787ae75dfb71218d6fa8551a102a0ebb95567 Mon Sep 17 00:00:00 2001
From: Leif Lindholm
Date: Sat, 8 Nov 2014 10:26:53 +
Subject: [PATCH] Increase m
Some AArch64 platforms have RAM and flash devices >4GB.
Update some additional Pcd entries to 64-bit, and change
the corresponding PcdGet32 calls to PcdGet64.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leif Lindholm
---
ArmPkg/ArmPkg.dec
Did you like my workaround? :)
GenC.py:
———
@@ -1077,6 +1071,9 @@ def CreateLibraryPcdCode(Info, AutoGenC,
if PcdItemType == TAB_PCDS_FIXED_AT_BUILD or PcdItemType ==
TAB_PCDS_FEATURE_FLAG:
key = ".".join((Pcd.TokenSpaceGuidCName,Pcd.TokenCName))
+if DatumType == 'V
Declaration VOID* is wrong initially. It comes from IntelFrameworkModulePkg.dec
——
[PcdsFixedAtBuild, PcdsPatchableInModule]
## FFS filename to find the default BMP Logo file.
# @Prompt FFS Name of Boot Logo File
gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLogoFile |{ 0x99, 0x8b, 0xB2,
0x7B
You should submit patches for each package separately.
Depending on the situation, you may want to submit multiple patches
for each package:
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Partitioning
But, in this case, I think one patch per package is appropriate.
Also, you should
22 matches
Mail list logo