|
回复: [edk2-devel] [Patch] [edk2-staging]BaseTools/Fmmt: Fixed FMMT Linux build break issue
gaoliming
Got it. Here should be _MAX_PATH. Yunhua, can you fix this build issue on Linux?
toggle quoted messageShow quoted text
Thanks Liming
-----邮件原件-----
|
|
|
|
Re: [PATCH v2 0/1] UefiPayloadPkg: Set default PciBaseSize on Ia32
Ma, Maurice <maurice.ma@...>
Reviewed-by:
toggle quoted messageShow quoted text
Maurice Ma <maurice.ma@...>
-----Original Message-----
|
|
|
|
Re: [PATCH v2 1/1] UefiPayloadPkg: Set default PciBaseSize on Ia32
Ma, Maurice <maurice.ma@...>
Reviewed-by:
toggle quoted messageShow quoted text
Maurice Ma <maurice.ma@...>
-----Original Message-----
|
|
|
|
Re: VariablePolicy: Final Changes Thread 1 - TPL Ordering
Bret Barkelew
I’ll try to take a look at that today. Thanks!
- Bret
From: Kinney, Michael D
Sent: Tuesday, October 13, 2020 11:22 AM To: Bret Barkelew; devel@edk2.groups.io; Andrew Fish; Kinney, Michael D Subject: [EXTERNAL] RE: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ordering
Hi Bret,
The concept of making the platform lock point configurable seems like a good idea from a platform porting perspective. If we had that feature would that make this better?
Have you studied the features DPC provides? It is functionally similar to having NOTIFY-1 and CALLBACK-1 TPL levels.
https://github.com/tianocore/edk2/blob/master/NetworkPkg/DpcDxe/Dpc.c
Thanks,
Mike
From: Bret Barkelew <Bret.Barkelew@...>
The problem with the other solution is that it doesn’t give the platform any flexibility to move which event the lock is attached to. For EDK2 default, we’re making it EndOfDxe, because that matches most platforms’ threat models. For Mu, we use ReadyToBoot.
The current “hack” makes that more difficult without multiple patches that we have to carry to remove the “fixed” ordering of the events.
That said, I do think I’ll clean that up and submit it, unless Sean reads this and stops me. 😉
- Bret
From: Michael D Kinney via groups.io
Hi Bret,
If the other solution more directly expresses the dependency and guarantees ordering, then it may not be considered a hack.
I prefer solutions that minimize the chances of failures and the need for platform developers to do extra work to integrate a feature or do extra work when they add an unrelated feature.
I see Laszlo’s proposal to add a new tag GUID protocol to detect and enforce ordering for this specific use case.
The network stack added a DPC (Deferred Procedure Call) Protocol to help with ordering issues and remove the introduction of extra TPL levels in an earlier version of the network stack. I am wondering of there is a more generic solution to this specific problem through the use of DPC.
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Like I said, I’m also happy to go with the lesser solution of replacing the hack that was already in the code. The last person didn’t care to solve this problem, and I’m good to not solve it, too. I mean, I think it’s turtles all the way down no matter what.
It was actually the ASSERT in the code that highlighted this problem to being with, so I would say that it’s doing its job. It’s incumbent upon the code author to determine what resource they’re trying to access and whether they’ve accessed it successfully, and I agree that it seems like an appropriate use of ASSERTs so long as it’s backed up with some OTHER appropriate action (even if that action is ignoring it).
- Bret
From: Kinney, Michael D
Bret,
How to platform creators know for the complete set of drivers if there is anything then need to worry about and why and what they need to address the concern? This is about order that events are signaled for a given event trigger. When a platform adds more driver that may use the same event triggers, how do they know if there is a potential for a race condition or not? If event notification functions are design to be independent of signaling order, then there is no issue. As soon as there are requirements for event notification functions to be executed in a specific order at a specific event trigger, we have to make sure the platform creator knows and preferably, the FW can tell them if they got it wrong.
Can your data/device manipulators and data/device protectors use case generate an ASSERT() if they are signaled in the wrong order?
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Agreed with your concern, Mike. This mechanism (and we can document it as such) should NOT be used to accomplish an explicit ordering (a la the “apriori list”). It’s just to provide a little separation for two patterns that we’ve seen time and again in our code: data/device manipulators and data/device protectors. It does not eliminate the necessity for platform creators to understand things like driver ordering if they have one driver that requires a protocol be installed or a bus connected.
- Bret
From: Kinney, Michael D
Hi Andrew,
I agree DXE drivers could use a PCD to make it configurable and prevent collisions with UEFI defined TPL levels.
Bret’s suggestion of adding a DXE scoped services to create events using non-UEFI defined TPL levels could be used with these TPL levels from PCDs. Would also allow DXE drivers to use TPL levels associated with the firmware interrupts in the range 17..30. Perhaps extensions to the DXE Services Table?
Still does not address my concern that many DXE drivers using these extra TPL levels may run into race conditions if more than one DXE driver selects the same TPL level. Platform integrators will need to understand the relative priorities of all DXE drivers that use extra TPL levels so they can assign values that both avoid collisions with future UEFI specs and prevent race conditions among DXE drivers.
Mike
From: Andrew Fish <afish@...>
Mike,
When I’ve done things like this in the past I think of making them configurable like via a PCD.
In terms of the #defines I think it makes more sense to just do math on the spec defined values. So TPL_CALLBACK + 1 or TPL_CALLBACK - 1 etc. I’ve got an lldb type formatter for TPL and it prints out <UEFI Spec TPL> [+ <extra>] as I think this is the clearest way to do it.
Thanks,
Andrew Fish
|
|
|
|
Re: VariablePolicy: Final Changes Thread 1 - TPL Ordering
Michael D Kinney
Hi Bret,
The concept of making the platform lock point configurable seems like a good idea from a platform porting perspective. If we had that feature would that make this better?
Have you studied the features DPC provides? It is functionally similar to having NOTIFY-1 and CALLBACK-1 TPL levels.
https://github.com/tianocore/edk2/blob/master/NetworkPkg/DpcDxe/Dpc.c
Thanks,
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Sent: Tuesday, October 13, 2020 10:57 AM To: devel@edk2.groups.io; Kinney, Michael D <michael.d.kinney@...>; Andrew Fish <afish@...> Subject: RE: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ordering
The problem with the other solution is that it doesn’t give the platform any flexibility to move which event the lock is attached to. For EDK2 default, we’re making it EndOfDxe, because that matches most platforms’ threat models. For Mu, we use ReadyToBoot.
The current “hack” makes that more difficult without multiple patches that we have to carry to remove the “fixed” ordering of the events.
That said, I do think I’ll clean that up and submit it, unless Sean reads this and stops me. 😉
- Bret
From: Michael D Kinney via groups.io
Hi Bret,
If the other solution more directly expresses the dependency and guarantees ordering, then it may not be considered a hack.
I prefer solutions that minimize the chances of failures and the need for platform developers to do extra work to integrate a feature or do extra work when they add an unrelated feature.
I see Laszlo’s proposal to add a new tag GUID protocol to detect and enforce ordering for this specific use case.
The network stack added a DPC (Deferred Procedure Call) Protocol to help with ordering issues and remove the introduction of extra TPL levels in an earlier version of the network stack. I am wondering of there is a more generic solution to this specific problem through the use of DPC.
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Like I said, I’m also happy to go with the lesser solution of replacing the hack that was already in the code. The last person didn’t care to solve this problem, and I’m good to not solve it, too. I mean, I think it’s turtles all the way down no matter what.
It was actually the ASSERT in the code that highlighted this problem to being with, so I would say that it’s doing its job. It’s incumbent upon the code author to determine what resource they’re trying to access and whether they’ve accessed it successfully, and I agree that it seems like an appropriate use of ASSERTs so long as it’s backed up with some OTHER appropriate action (even if that action is ignoring it).
- Bret
From: Kinney, Michael D
Bret,
How to platform creators know for the complete set of drivers if there is anything then need to worry about and why and what they need to address the concern? This is about order that events are signaled for a given event trigger. When a platform adds more driver that may use the same event triggers, how do they know if there is a potential for a race condition or not? If event notification functions are design to be independent of signaling order, then there is no issue. As soon as there are requirements for event notification functions to be executed in a specific order at a specific event trigger, we have to make sure the platform creator knows and preferably, the FW can tell them if they got it wrong.
Can your data/device manipulators and data/device protectors use case generate an ASSERT() if they are signaled in the wrong order?
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Agreed with your concern, Mike. This mechanism (and we can document it as such) should NOT be used to accomplish an explicit ordering (a la the “apriori list”). It’s just to provide a little separation for two patterns that we’ve seen time and again in our code: data/device manipulators and data/device protectors. It does not eliminate the necessity for platform creators to understand things like driver ordering if they have one driver that requires a protocol be installed or a bus connected.
- Bret
From: Kinney, Michael D
Hi Andrew,
I agree DXE drivers could use a PCD to make it configurable and prevent collisions with UEFI defined TPL levels.
Bret’s suggestion of adding a DXE scoped services to create events using non-UEFI defined TPL levels could be used with these TPL levels from PCDs. Would also allow DXE drivers to use TPL levels associated with the firmware interrupts in the range 17..30. Perhaps extensions to the DXE Services Table?
Still does not address my concern that many DXE drivers using these extra TPL levels may run into race conditions if more than one DXE driver selects the same TPL level. Platform integrators will need to understand the relative priorities of all DXE drivers that use extra TPL levels so they can assign values that both avoid collisions with future UEFI specs and prevent race conditions among DXE drivers.
Mike
From: Andrew Fish <afish@...>
Mike,
When I’ve done things like this in the past I think of making them configurable like via a PCD.
In terms of the #defines I think it makes more sense to just do math on the spec defined values. So TPL_CALLBACK + 1 or TPL_CALLBACK - 1 etc. I’ve got an lldb type formatter for TPL and it prints out <UEFI Spec TPL> [+ <extra>] as I think this is the clearest way to do it.
Thanks,
Andrew Fish
|
|
|
|
Re: VariablePolicy: Final Changes Thread 1 - TPL Ordering
Bret Barkelew
The problem with the other solution is that it doesn’t give the platform any flexibility to move which event the lock is attached to. For EDK2 default, we’re making it EndOfDxe, because that matches most platforms’ threat models. For Mu, we use ReadyToBoot.
The current “hack” makes that more difficult without multiple patches that we have to carry to remove the “fixed” ordering of the events.
That said, I do think I’ll clean that up and submit it, unless Sean reads this and stops me. 😉
- Bret
From: Michael D Kinney via groups.io
Sent: Tuesday, October 13, 2020 8:05 AM To: Bret Barkelew; Andrew Fish; edk2-devel-groups-io; Kinney, Michael D Subject: [EXTERNAL] Re: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ordering
Hi Bret,
If the other solution more directly expresses the dependency and guarantees ordering, then it may not be considered a hack.
I prefer solutions that minimize the chances of failures and the need for platform developers to do extra work to integrate a feature or do extra work when they add an unrelated feature.
I see Laszlo’s proposal to add a new tag GUID protocol to detect and enforce ordering for this specific use case.
The network stack added a DPC (Deferred Procedure Call) Protocol to help with ordering issues and remove the introduction of extra TPL levels in an earlier version of the network stack. I am wondering of there is a more generic solution to this specific problem through the use of DPC.
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Like I said, I’m also happy to go with the lesser solution of replacing the hack that was already in the code. The last person didn’t care to solve this problem, and I’m good to not solve it, too. I mean, I think it’s turtles all the way down no matter what.
It was actually the ASSERT in the code that highlighted this problem to being with, so I would say that it’s doing its job. It’s incumbent upon the code author to determine what resource they’re trying to access and whether they’ve accessed it successfully, and I agree that it seems like an appropriate use of ASSERTs so long as it’s backed up with some OTHER appropriate action (even if that action is ignoring it).
- Bret
From: Kinney, Michael D
Bret,
How to platform creators know for the complete set of drivers if there is anything then need to worry about and why and what they need to address the concern? This is about order that events are signaled for a given event trigger. When a platform adds more driver that may use the same event triggers, how do they know if there is a potential for a race condition or not? If event notification functions are design to be independent of signaling order, then there is no issue. As soon as there are requirements for event notification functions to be executed in a specific order at a specific event trigger, we have to make sure the platform creator knows and preferably, the FW can tell them if they got it wrong.
Can your data/device manipulators and data/device protectors use case generate an ASSERT() if they are signaled in the wrong order?
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Agreed with your concern, Mike. This mechanism (and we can document it as such) should NOT be used to accomplish an explicit ordering (a la the “apriori list”). It’s just to provide a little separation for two patterns that we’ve seen time and again in our code: data/device manipulators and data/device protectors. It does not eliminate the necessity for platform creators to understand things like driver ordering if they have one driver that requires a protocol be installed or a bus connected.
- Bret
From: Kinney, Michael D
Hi Andrew,
I agree DXE drivers could use a PCD to make it configurable and prevent collisions with UEFI defined TPL levels.
Bret’s suggestion of adding a DXE scoped services to create events using non-UEFI defined TPL levels could be used with these TPL levels from PCDs. Would also allow DXE drivers to use TPL levels associated with the firmware interrupts in the range 17..30. Perhaps extensions to the DXE Services Table?
Still does not address my concern that many DXE drivers using these extra TPL levels may run into race conditions if more than one DXE driver selects the same TPL level. Platform integrators will need to understand the relative priorities of all DXE drivers that use extra TPL levels so they can assign values that both avoid collisions with future UEFI specs and prevent race conditions among DXE drivers.
Mike
From: Andrew Fish <afish@...>
Mike,
When I’ve done things like this in the past I think of making them configurable like via a PCD.
In terms of the #defines I think it makes more sense to just do math on the spec defined values. So TPL_CALLBACK + 1 or TPL_CALLBACK - 1 etc. I’ve got an lldb type formatter for TPL and it prints out <UEFI Spec TPL> [+ <extra>] as I think this is the clearest way to do it.
Thanks,
Andrew Fish
|
|
|
|
[PATCH v2 1/1] Silicon/Qemu/Sbsa: Add SBSA-wdt entry to GTDT
Shashi Mallela
SBSA generic watchdog timer structure entry has been added
to GTDT table as per BSAv0.9. This enables acpi detection of wdt in qemu sbsa platform Signed-off-by: Shashi Mallela <shashi.mallela@...> --- Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc | 53 +++++++++++++++++--- 1 file changed, 45 insertions(+), 8 deletions(-) diff --git a/Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc b/Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc index d16778e01a5c..2312fd74e26d 100644 --- a/Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc +++ b/Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc @@ -24,27 +24,55 @@ #define SYSTEM_TIMER_BASE_ADDRESS 0xFFFFFFFFFFFFFFFF #endif -#define GTDT_TIMER_EDGE_TRIGGERED EFI_ACPI_5_0_GTDT_TIMER_FLAG_TIMER_INTERRUPT_MODE +#define GTDT_TIMER_EDGE_TRIGGERED EFI_ACPI_6_3_GTDT_TIMER_FLAG_TIMER_INTERRUPT_MODE #define GTDT_TIMER_LEVEL_TRIGGERED 0 -#define GTDT_TIMER_ACTIVE_LOW EFI_ACPI_5_0_GTDT_TIMER_FLAG_TIMER_INTERRUPT_POLARITY +#define GTDT_TIMER_ACTIVE_LOW EFI_ACPI_6_3_GTDT_TIMER_FLAG_TIMER_INTERRUPT_POLARITY #define GTDT_TIMER_ACTIVE_HIGH 0 #define GTDT_GTIMER_FLAGS (GTDT_TIMER_ACTIVE_LOW | GTDT_TIMER_LEVEL_TRIGGERED) +#define SBSA_PLATFORM_WATCHDOG_COUNT 1 +#define SBSA_PLATFORM_TIMER_COUNT (SBSA_PLATFORM_WATCHDOG_COUNT) + +#define SBSAQEMU_WDT_REFRESH_FRAME_BASE 0x50010000 +#define SBSAQEMU_WDT_CONTROL_FRAME_BASE 0x50011000 +#define SBSAQEMU_WDT_IRQ 44 + +#define GTDT_WDTIMER_EDGE_TRIGGERED EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_FLAG_TIMER_INTERRUPT_MODE +#define GTDT_WDTIMER_LEVEL_TRIGGERED 0 +#define GTDT_WDTIMER_ACTIVE_LOW EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_FLAG_TIMER_INTERRUPT_POLARITY +#define GTDT_WDTIMER_ACTIVE_HIGH 0 + +#define GTDT_WDTIMER_FLAGS (GTDT_WDTIMER_ACTIVE_HIGH | GTDT_WDTIMER_LEVEL_TRIGGERED) + +#define EFI_ACPI_6_3_SBSA_GENERIC_WATCHDOG_STRUCTURE_INIT( \ + RefreshFramePhysicalAddress, ControlFramePhysicalAddress, \ + WatchdogTimerGSIV, WatchdogTimerFlags) \ + { \ + EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG, \ + sizeof(EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE), \ + EFI_ACPI_RESERVED_WORD, \ + RefreshFramePhysicalAddress, \ + ControlFramePhysicalAddress, \ + WatchdogTimerGSIV, \ + WatchdogTimerFlags \ + } + #pragma pack (1) typedef struct { - EFI_ACPI_5_1_GENERIC_TIMER_DESCRIPTION_TABLE Gtdt; - } GENERIC_TIMER_DESCRIPTION_TABLE; + EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE Gtdt; + EFI_ACPI_6_3_GTDT_SBSA_GENERIC_WATCHDOG_STRUCTURE Gwdt; + } GENERIC_TIMER_DESCRIPTION_TABLES; #pragma pack () GENERIC_TIMER_DESCRIPTION_TABLE Gtdt = { { SBSAQEMU_ACPI_HEADER( - EFI_ACPI_5_1_GENERIC_TIMER_DESCRIPTION_TABLE_SIGNATURE, + EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE_SIGNATURE, GENERIC_TIMER_DESCRIPTION_TABLE, - EFI_ACPI_5_1_GENERIC_TIMER_DESCRIPTION_TABLE_REVISION + EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE_REVISION ), SYSTEM_TIMER_BASE_ADDRESS, // UINT64 PhysicalAddress 0, // UINT32 Reserved @@ -57,9 +85,18 @@ FixedPcdGet32 (PcdArmArchTimerHypIntrNum), // UINT32 NonSecurePL2TimerGSIV GTDT_GTIMER_FLAGS, // UINT32 NonSecurePL2TimerFlags 0xFFFFFFFFFFFFFFFF, // UINT64 CntReadBasePhysicalAddress - 0, // UINT32 PlatformTimerCount - 0 + SBSA_PLATFORM_TIMER_COUNT, // UINT32 PlatformTimerCount + sizeof(EFI_ACPI_6_3_GENERIC_TIMER_DESCRIPTION_TABLE), + // UINT32 PlatformTimerOffset + 0, // UINT32 VirtualPL2TimerGSIV + 0 // UINT32 VirtualPL2TimerFlags }, + EFI_ACPI_6_3_SBSA_GENERIC_WATCHDOG_STRUCTURE_INIT( + SBSAQEMU_WDT_REFRESH_FRAME_BASE, + SBSAQEMU_WDT_CONTROL_FRAME_BASE, + SBSAQEMU_WDT_IRQ, + GTDT_WDTIMER_FLAGS + ) }; // Reference the table being generated to prevent the optimizer from removing the -- 2.18.4
|
|
|
|
[PATCH v2 0/1] Add SBSA-wdt entry to GTDT
Shashi Mallela
To enable detection of qemu SBSA generic watchdog timer device,this
patch has been added to create sbsa-wdt entry into the GTDT table which helps firmware report the presence of SBSA-wdt to the OS. Changes in v2: - fixed patch indentation Shashi Mallela (1): Silicon/Qemu/Sbsa: Add SBSA-wdt entry to GTDT Silicon/Qemu/SbsaQemu/AcpiTables/Gtdt.aslc | 53 +++++++++++++++++--- 1 file changed, 45 insertions(+), 8 deletions(-) -- 2.18.4
|
|
|
|
Re: VariablePolicy: Final Changes Thread 1 - TPL Ordering
Michael D Kinney
Hi Bret,
If the other solution more directly expresses the dependency and guarantees ordering, then it may not be considered a hack.
I prefer solutions that minimize the chances of failures and the need for platform developers to do extra work to integrate a feature or do extra work when they add an unrelated feature.
I see Laszlo’s proposal to add a new tag GUID protocol to detect and enforce ordering for this specific use case.
The network stack added a DPC (Deferred Procedure Call) Protocol to help with ordering issues and remove the introduction of extra TPL levels in an earlier version of the network stack. I am wondering of there is a more generic solution to this specific problem through the use of DPC.
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Sent: Monday, October 12, 2020 3:14 PM To: Kinney, Michael D <michael.d.kinney@...>; Andrew Fish <afish@...>; edk2-devel-groups-io <devel@edk2.groups.io> Subject: RE: [edk2-devel] VariablePolicy: Final Changes Thread 1 - TPL Ordering
Like I said, I’m also happy to go with the lesser solution of replacing the hack that was already in the code. The last person didn’t care to solve this problem, and I’m good to not solve it, too. I mean, I think it’s turtles all the way down no matter what.
It was actually the ASSERT in the code that highlighted this problem to being with, so I would say that it’s doing its job. It’s incumbent upon the code author to determine what resource they’re trying to access and whether they’ve accessed it successfully, and I agree that it seems like an appropriate use of ASSERTs so long as it’s backed up with some OTHER appropriate action (even if that action is ignoring it).
- Bret
From: Kinney, Michael D
Bret,
How to platform creators know for the complete set of drivers if there is anything then need to worry about and why and what they need to address the concern? This is about order that events are signaled for a given event trigger. When a platform adds more driver that may use the same event triggers, how do they know if there is a potential for a race condition or not? If event notification functions are design to be independent of signaling order, then there is no issue. As soon as there are requirements for event notification functions to be executed in a specific order at a specific event trigger, we have to make sure the platform creator knows and preferably, the FW can tell them if they got it wrong.
Can your data/device manipulators and data/device protectors use case generate an ASSERT() if they are signaled in the wrong order?
Mike
From: Bret Barkelew <Bret.Barkelew@...>
Agreed with your concern, Mike. This mechanism (and we can document it as such) should NOT be used to accomplish an explicit ordering (a la the “apriori list”). It’s just to provide a little separation for two patterns that we’ve seen time and again in our code: data/device manipulators and data/device protectors. It does not eliminate the necessity for platform creators to understand things like driver ordering if they have one driver that requires a protocol be installed or a bus connected.
- Bret
From: Kinney, Michael D
Hi Andrew,
I agree DXE drivers could use a PCD to make it configurable and prevent collisions with UEFI defined TPL levels.
Bret’s suggestion of adding a DXE scoped services to create events using non-UEFI defined TPL levels could be used with these TPL levels from PCDs. Would also allow DXE drivers to use TPL levels associated with the firmware interrupts in the range 17..30. Perhaps extensions to the DXE Services Table?
Still does not address my concern that many DXE drivers using these extra TPL levels may run into race conditions if more than one DXE driver selects the same TPL level. Platform integrators will need to understand the relative priorities of all DXE drivers that use extra TPL levels so they can assign values that both avoid collisions with future UEFI specs and prevent race conditions among DXE drivers.
Mike
From: Andrew Fish <afish@...>
Mike,
When I’ve done things like this in the past I think of making them configurable like via a PCD.
In terms of the #defines I think it makes more sense to just do math on the spec defined values. So TPL_CALLBACK + 1 or TPL_CALLBACK - 1 etc. I’ve got an lldb type formatter for TPL and it prints out <UEFI Spec TPL> [+ <extra>] as I think this is the clearest way to do it.
Thanks,
Andrew Fish
|
|
|
|
[PATCH v2 1/1] UefiPayloadPkg: Set default PciBaseSize on Ia32
Marcello Sylvester Bauer <marcello.bauer@...>
* Add needed PcdPciExpressBaseSize default on Ia32 targets analog to X64 in:
8028b2907e20b21cd7d69639a36ac82a77c81dc1 * Remove no longer required build-time PcdPciExpressBaseAddress with regard= s to: 3900a63e3a1b9ba9a4105bedead7b986188cec2c Signed-off-by: Marcello Sylvester Bauer <marcello.bauer@...> Cc: Patrick Rudolph <patrick.rudolph@...> Cc: Maurice Ma <maurice.ma@...> Cc: Guo Dong <guo.dong@...> Cc: Benjamin You <benjamin.you@...> --- UefiPayloadPkg/UefiPayloadPkgIa32.dsc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc b/UefiPayloadPkg/UefiPay= loadPkgIa32.dsc index 12d7ffe81416..d1fcbbb50207 100644 --- a/UefiPayloadPkg/UefiPayloadPkgIa32.dsc +++ b/UefiPayloadPkg/UefiPayloadPkgIa32.dsc @@ -292,8 +292,6 @@ [PcdsFixedAtBuild] gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseMemory|FALSE=0D gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c= , 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0= x31 }=0D =0D - gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|$(PCIE_BASE)=0D -=0D !if $(SOURCE_DEBUG_ENABLE)=0D gEfiSourceLevelDebugPkgTokenSpaceGuid.PcdDebugLoadImageMethod|0x2=0D !endif=0D @@ -364,6 +362,7 @@ [PcdsDynamicDefault] gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|31=0D gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|100=0D gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0=0D + gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseSize|0=0D =0D ##########################################################################= ######=0D #=0D --=20 2.28.0
|
|
|
|
[PATCH v2 0/1] UefiPayloadPkg: Set default PciBaseSize on Ia32
Marcello Sylvester Bauer <marcello.bauer@...>
This commit fix UefiPayloadPkgIa32 build in master.
In commit 8028b2907e20b21cd7d69639a36ac82a77c81dc1 I did forget to set the default value for PcdPciExpressBaseSize on Ia32 Targets. This patch does insert it afterwards. It would be great if it could be merged asap. PS: I added the Ia32 target to our CI to avoid this issue in future. Sorry for the misfortune. v2: * Remove no longer required build-time PcdPciExpressBaseAddress Branch: https://github.com/9elements/edk2/tree/fix/UefiPayloadPkgIa32_V2 PR: https://github.com/tianocore/edk2/pull/1008 Marcello Sylvester Bauer (1): UefiPayloadPkg: Set default PciBaseSize on Ia32 UefiPayloadPkg/UefiPayloadPkgIa32.dsc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- 2.28.0
|
|
|
|
Re: [PATCH 3/5] MdePkg/BaseLib: use normal register init in ARM SetJump implementations
Ard Biesheuvel
On 10/1/20 8:37 PM, Leif Lindholm wrote:
There may be architectures on which there are benefits toActually, 'movs r0, #0' produces a smaller opcode here when building in Thumb2 mode :-) bx lr
|
|
|
|
Re: [Patch] [edk2-staging]BaseTools/Fmmt: Fixed FMMT Linux build break issue
Bob Feng
Hi Liming,
toggle quoted messageShow quoted text
What's purpose for the header file limits.h? Bob: To get the Macro PATH_MAX definition. There is no _MAX_DIR or _MAX_PATH Macro on Linux. Can you use _MAX_PATH in the code to replace _MAX_DIR? _MAX_PATH is defined here. Bob: The original code use _MAX_DIR. It does not cause the build break. If you and Yunhua confirm there should be _MAX_PATH, I can create another patch to change the _MAX_DIR to _MAX_PATH Thanks, Bob
-----Original Message-----
From: gaoliming <gaoliming@...> Sent: Tuesday, October 13, 2020 6:01 PM To: devel@edk2.groups.io; Feng, Bob C <bob.c.feng@...> Cc: 'Yunhua Feng' <fengyunhua@...> Subject: 回复: [edk2-devel] [Patch] [edk2-staging]BaseTools/Fmmt: Fixed FMMT Linux build break issue Bob: I add my comments. Thanks Liming -----邮件原件-----What's purpose for the header file limits.h? +#define _MAX_DIR PATH_MAXCan you use _MAX_PATH in the code to replace _MAX_DIR? _MAX_PATH is defined here. Thanks Liming +#endif
|
|
|
|
Re: [PATCH v1 1/1] ShellPkg/UefiShellAcpiViewCommandLib: acpi version update for GTDT
Leif Lindholm
On Fri, Oct 09, 2020 at 11:27:45 -0700, shashi.mallela@... wrote:
Hi Lief,Which is based on 6.2, which is based on 6.1, which is based on 6.0 as per my previous email. There is no benefit to changing to a different macro that expands to exactly the same value. Yes, it is a bit confusing that we apparently keep adding aliases for such basic things as signatures of standard tabled for each new release of ACPI, but it doesn't mean we have to add to the churn by changing unaffected code simply to "keep up". This patch has no functional changes, and does not improve the code, so I would recommend the ShellPkg maintainers ignore it. / Leif
|
|
|
|
Re: PKCS11
#include
Yao, Jiewen
If you have a PKCS11 library, you can port it and make it work in EDKII. I recommend you create a new library in CryptoPkg. Please don’t mix it work current BaseCryptoLib.
I am not sure the code license. If the PKCS11 lib is BSD license, or the one compatible with EDKII, you can add it to EDKII. But if PKCS11 lib is GPL or LGPL license, you have to separate the library to a standalone repo.
If you can provide more detail on which PKCS11 lib you are using, we can provide more suggestion.
Thank you Yao Jiewen
From: devel@edk2.groups.io <devel@edk2.groups.io>
On Behalf Of naveenkumar.senniyappan@...
Sent: Tuesday, October 13, 2020 1:40 PM To: devel@edk2.groups.io Subject: [edk2-devel] PKCS11 #include
how to integrate PKCS11 into EDK2 crypto Library.
|
|
|
|
回复: [edk2-devel] OpensslLib compiling error : cannot open include file : openssl/aes.h
gaoliming
Can you print the full build log and check the compiler include path?
toggle quoted messageShow quoted text
Is this a clean build issue or incremental build issue? Thanks Liming
-----邮件原件-----
|
|
|
|
回复: [edk2-devel] [Patch] [edk2-staging]BaseTools/Fmmt: Fixed FMMT Linux build break issue
gaoliming
Bob:
I add my comments. Thanks Liming -----邮件原件-----What's purpose for the header file limits.h? +#define _MAX_DIR PATH_MAXCan you use _MAX_PATH in the code to replace _MAX_DIR? _MAX_PATH is defined here. Thanks Liming +#endif
|
|
|
|
Re: smartcardreaderprotocol
naveenkumar.senniyappan@...
|
|
|
|
PKCS11
#include
naveenkumar.senniyappan@...
how to integrate PKCS11 into EDK2 crypto Library.
Is this possible to integrate PKCS11 lib into EDK2. I am trying to do PKCS11 standard token pin verification in UEFI layer. any one can you share your idea or any solution to that. thank you,
|
|
|
|
[PATCH] IntelFsp2Pkg/Tools: Fix a typo issue
fengyunhua
Error message:
raise Exception ("'%s' is not a valid directory!" % FvDir) NameError: name 'FvDir' is not defined FvDir should be fvDir. Cc: Chasel Chiu <chasel.chiu@...> Cc: Nate DeSimone <nathaniel.l.desimone@...> Cc: Star Zeng <star.zeng@...> Signed-off-by: Yunhua Feng <fengyunhua@...> --- IntelFsp2Pkg/Tools/PatchFv.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/IntelFsp2Pkg/Tools/PatchFv.py b/IntelFsp2Pkg/Tools/PatchFv.py index edb30c816b..0c8d908063 100644 --- a/IntelFsp2Pkg/Tools/PatchFv.py +++ b/IntelFsp2Pkg/Tools/PatchFv.py @@ -163,7 +163,7 @@ class Symbols: # If the fvDir is not a directory, then raise an exception # if not os.path.isdir(fvDir): - raise Exception ("'%s' is not a valid directory!" % FvDir) + raise Exception ("'%s' is not a valid directory!" % fvDir) # # If the Guid.xref is not existing in fvDir, then raise an exception -- 2.27.0.windows.1
|
|
|