On 26/12/2023 11:28, Chang, Abner via groups.io wrote:
For the HTTPS connetion that doesn't require TLS peer verification,
EDKII_HTTPS_TLS_PLATFORM_POLICY_PROTOCOL is introduced to platform
developer to provide the TLS configure data that is different than
the default TLS configuration. The use c
On 28/12/2023 02:47, Chang, Abner via groups.io wrote:
On 26/12/2023 11:28, Chang, Abner via groups.io wrote:
Platform developer can provide this protoocl to EFI HTTP driver to
configure TLS using TLS conifg data provided by
EDKII_HTTPS_TLS_PLATFORM_POLICY_PROTOCOL for the specific HTTP
protocol
On 28/12/2023 15:04, Chang, Abner via groups.io wrote:
With the TLS protocol installed onto the same handle, I don't think you
then even need to use RegisterProtocolNotify(). On return from
EFI_HTTP_PROTOCOL.Request() you can open the TLS protocol on the handle
and immediately call SetSessionDat
On 28/12/2023 23:37, Chang, Abner via groups.io wrote:
As far as I am aware, EfiHttpRequest sets up all of the relevant data
structures but functions as a non-blocking open. If you reconfigure the
TLS session immediately after return from EfiHttpRequest() then this
reconfiguration should take ef
estion, I'm happy to add
Reviewed-by: Michael Brown
for this patch.
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113014): https://edk2.groups.io/g/devel/message/113014
Mute This Topic: https://groups.io/mt/1034
On 29/12/2023 15:07, Chang, Abner via groups.io wrote:
To locate TLS protocol from the HTTP handle and configure TLS configuration
data at the return from EfiHttpRequest during that short window of non-blocking
request is not reliable. It also doesn't make sense to ask upper layer
application
On 02/01/2024 06:06, Chang, Abner via groups.io wrote:
What do you think about:
- installing TLS on HTTP handle (as you have already implemented)
- using EDKII_HTTP_CALLBACK_PROTOCOL to catch the HttpEventInitSession
and perform whatever calls are needed to SetData() to modify the TLS
configura
On 02/01/2024 16:31, Chang, Abner via groups.io wrote:
From: Michael Brown
- Allow the call to Request() to perform its normal TLS configuration
via TlsConfigureSession(), as though the connection were going to
perform host verification etc as per the platform default policy. This
nstance->TlsChildHandle
+ with opened EFI_TLS_PROTOCOL and
EFI_TLS_CONFIGURATION_PROTOCOL.
As above.
Reviewed-by: Michael Brown
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113309): https://edk2.groups.io/g
turns EFI_SUCCESS to
the caller. The failure is pushed back to TLS DXE driver if the
HTTP communication actually requires certificate.
Reviewed-by: Michael Brown
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113310): https:/
Since this changes the ABI, you may want to also update the protocol
GUID to prevent strange errors if old and new binaries are used on the
same system.
Reviewed-by: Michael Brown
Thanks,
Michael
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Re
On 05/01/2024 08:41, Chang, Abner wrote:
We are not aware there is a TlsConnectSession() for TLS handshake using the
default TLS configuration data and it returns a failure as expected because the
default TLS configuration is TLS_VERIFY_HOST without certificate installed on
system.
This happen
On 09/01/2024 12:13, Laszlo Ersek wrote:
On 1/9/24 11:45, Ard Biesheuvel wrote:
Note that git am does support a 'From: ' header as the first line of
the commit log, and will use it correctly to supersede the From:
header in the SMTP envelope.
OTOH, that doesn't help in this case, IIUC. When th
On 16/01/2024 08:47, Gerd Hoffmann wrote:
I think the reason is that the next timer interrupt arriving while the
handler is running still is *much* more likely in virtual machines
because the vCPU does not get 100% of the of the physical CPU time
slice.
The interrupt handler can run for an arbi
On 16/01/2024 14:34, Laszlo Ersek wrote:
On 1/16/24 10:48, Michael Brown wrote:
IOW, my impression is that NestedInterruptTplLib can certainly handle
all scenarios thrown at it, but where it really matters is in the face
of an interrupt storm (not just "normal nesting"), and a storm i
On 17/01/2024 07:11, Ni, Ray wrote:
The above flow shows endless re-entrance of timer interrupt handler.
But, my question is: above flow only can happen in real platform when the below
4 steps occupies more time than the timer period (usually 10ms).
[Timer Interrupt #2]1. RaiseTPL
On 19/01/2024 13:14, Ni, Ray wrote:
So, the interrupt re-entrance we want to avoid is “env:NOTIFY” ->
“env:NOTIFY”, or “env:CALLBACK” -> “env:CALLBACK”, or “env:APPLICATION”
-> “env:APPLICATION”. Because it’s endless.
NestedTplInterruptLib was written to avoid it.
Yes, precisely this.
2.
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dec | 4
OvmfPkg/OvmfPkg.dec | 4
OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
OvmfPkg/CloudHv/CloudHvX64.dsc
On 19/01/2024 23:44, Ni, Ray wrote:
I still want to see if the RestoreTpl2 that does not enable interrupt is
added as a protocol, and how simple the lib could be.
RestoreTpl() always has to enable interrupts during its execution, since
interrupts must be allowed to occur while callbacks are ru
On 20/01/2024 07:03, Ni, Ray wrote:
Can you submit another patch to add Iret.h to the INF file [Sources] section?
Without that, incremental build might not work if changes are made in Iret.h.
Good catch, thank you. I will send a v2.
It doesn't support non-x86 CPU. Will ARM have similar prob
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dec | 4
OvmfPkg/OvmfPkg.dec | 4
OvmfPkg/AmdSev/AmdSevX64.dsc | 2 +-
OvmfPkg/CloudHv/CloudHvX64.dsc
Suggested-by: Ray Ni
Signed-off-by: Michael Brown
---
.../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf | 1 +
1 file changed, 1 insertion(+)
diff --git
a/MdeModulePkg/Library/NestedInterruptTplLib/NestedInterruptTplLib.inf
b/MdeModulePkg/Library/NestedInterruptTplLib
sources list
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Gerd Hoffmann
Cc: Michael D Kinney
Michael Brown (2):
MdeModulePkg: Move NestedInterruptTplLib to MdeModulePkg
MdeModulePkg: Add missing Iret.h to NestedInterruptTplLib sources list
MdeModulePkg/MdeModulePkg.dec | 4
On 22/01/2024 10:36, Laszlo Ersek wrote:
(1) Does LocalApicTimerDxe have any other dependencies on OvmfPkg than
the library class header?
In other words, can't we remove "OvmfPkg/OvmfPkg.dec" from this
[Packages] section, too?
I can't see anything else, so I'd suggest to remove
"OvmfPkg/OvmfPkg
IA32 and X64 only, since those are the only two architectures for
which DisableInterruptsOnIret() is currently supported.
Cc: Ray Ni
Cc: Laszlo Ersek
Cc: Gerd Hoffmann
Cc: Michael D Kinney
Reviewed-by: Laszlo Ersek
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dec
:
- Add missing Iret.h to NestedInterruptTplLib sources list
Changes since v2:
- Remove obsolete dependency of LocalApicTimerDxe on OvmfPkg
- Add to MdeModulePkg.dsc for build coverage
- Add self-tests
- Add support for Arm CPUs
Michael Brown (5):
MdeModulePkg: Move
Allow build system to detect changes to Iret.h.
Suggested-by: Ray Ni
Reviewed-by: Laszlo Ersek
Signed-off-by: Michael Brown
---
.../Library/NestedInterruptTplLib/NestedInterruptTplLib.inf | 1 +
1 file changed, 1 insertion(+)
diff --git
a/MdeModulePkg/Library/NestedInterruptTplLib
that we do not need
to consider the effect of this possible invariant violation on the
remainder of the logic.
Signed-off-by: Michael Brown
---
MdeModulePkg/Library/NestedInterruptTplLib/Tpl.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/MdeModulePkg/Library
time.
Only one test is performed by default (to avoid unnecessary system
startup delay). The number of tests performed can be controlled via
PcdNestedInterruptNumberOfSelfTests at build time.
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dec | 4
o use NestedInterruptTplLib and
verifying that ArmVirtQemu passes the NestedInterruptTplLib self-tests
for both ARM and AARCH64.
Cc: Ard Biesheuvel
Signed-off-by: Michael Brown
---
MdeModulePkg/MdeModulePkg.dsc | 2 +-
.../NestedInterruptTplLib.inf | 3 +++
.../Li
On 23/01/2024 15:51, Ard Biesheuvel wrote:
On Tue, 23 Jan 2024 at 16:31, Michael Brown wrote:
Add implementations of DisableInterruptsOnIret() for MDE_CPU_ARM and
MDE_CPU_AARCH64. In both cases, the saved IRQs-disabled and
FIQs-disabled flags are set in the stored processor status register
On 23/01/2024 16:32, Laszlo Ersek wrote:
On 1/23/24 16:31, Michael Brown wrote:
At TPL_HIGH_LEVEL, CPU interrupts are disabled (as per the UEFI
specification) and so we should never encounter a situation in which
an interrupt occurs at TPL_HIGH_LEVEL.
Restoring TPL to TPL_HIGH_LEVEL is always
On 23/01/2024 17:10, Laszlo Ersek wrote:
Other than that, the patch looks great to me; I'd only propose one
(superficial) improvement:
rather than include , scavenge
#ifdef MDE_CPU_ARM
#include
#elif defined (MDE_CPU_AARCH64)
#include
#endif
from it.
Reasons:
(a) Those are the headers that
On 23/01/2024 16:55, Laszlo Ersek wrote:
+ ///
+ /// Number of self-tests performed.
+ ///
+ UINTN SelfTestCount;
} NESTED_INTERRUPT_STATE;
/**
I suggest that the new field be UINT32. The (exclusive) limit is a
32-bit PCD. Making the counter (potentially) wider than the limit is
On 25/01/2024 07:57, Ni, Ray wrote:
This mail is to bring another approach to solve the stack-overflow due
to nested interrupts. Michael solved this problem in OVMF through
NestedInterruptTplLib.
I made a draft patch as attached “DxeCore.diff”. The patch simply to
avoid the interrupt in enabl
On 25/01/2024 13:54, Ni, Ray wrote:
I don't disagree with the approach, but it does break the API as per the
UEFI PI specification (version 1.8 section II-12.10), and so this is not
something that can just be dropped in as an EDK2 code change.
You think that the TimerInterruptHandler() doesn't
On 25/01/2024 15:06, Ni, Ray wrote:
I agree with you about the above PI spec clarifications.
Would you like to write a PI spec ECR?
I am not a UEFI Forum member, so I don't think I have standing to do
this. (I also don't have the spare time to do this for free, sorry.)
But I do not think t
On 01/11/2023 09:56, Ard Biesheuvel wrote:
On Wed, 1 Nov 2023 at 03:09, Pedro Falcato wrote:
On Wed, Nov 1, 2023 at 12:40 AM Joe L wrote:
Our CMN TRM showcases an example where ECAM and MMIO are two different regions
in the HN-I SAM. The implication is that we would expect a DSB between the
On 01/11/2023 12:51, Ard Biesheuvel wrote:
On Wed, 1 Nov 2023 at 13:25, Michael Brown wrote:
By my reading, the PCIe specification seems to therefore require
something stronger than an ordering guarantee: it requires the ability
for software to make a standalone determination that the write
On 01/11/2023 20:17, Joe L wrote:
Thanks for the discussion,
Are we saying that DataSynchronizationBarrier () before the return
from RootBridgeIoPciAccess() is not strong enough to determine that
the final ECAM write would have completed? According to Learn the
architecture - ARMv8-A memory s
On 03/11/2023 16:03, Kinney, Michael D wrote:
PCI Configuration read/write operations are non-posted, so the PCI
Configuration write operation should complete without the need for
an additional transaction. If you are seeing an issue, then it may
be in the implementation of the PciLib/PciSegment
On 19/02/2024 06:44, Hamit Can Karaca wrote:
I am having problem while booting Starlingx on iPXE on UEFI. It says
malformed binary and does not allow me to boot afterwards. What should I
do in BIOS to solve this problem?
I can boot Starlingx on other platforms using OEM BIOS.
Our platform is
On 22/02/2024 08:41, Zhou Jianfeng wrote:
--- a/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
+++ b/UefiCpuPkg/Library/CpuPageTableLib/CpuPageTableMap.c
@@ -20,13 +20,13 @@
**/
VOID
PageTableLibSetPte4K (
- IN OUT IA32_PTE_4K *Pte4K,
- IN UINT64 Offset,
-
On 23/02/2024 15:12, Zhou, Jianfeng wrote:
While it may well cause the compiler to generate less optimised code, there is
absolutely no way that this volatile declaration on a local stack variable can
possibly change the outcome of the code.
There can never be any meaningful side-effects from r
On 29/02/2024 13:02, Ni, Ray wrote:
A ideal solution is to not keep the interrupt disabled when
RestoreTPL(TPL_HIGH -> not TPL_HIGH) is executed in the timer interrupt
context because the interrupt handler will re-enable the interrupt with
arch specific instructions (e.g.: IRET for x86).
The pat
On 29/02/2024 16:43, Kinney, Michael D wrote:
Hi Michael,
Can you provide a pointer to the UEFI Spec statement this breaks?
II-9.7.1.3 RestoreTPL():
"When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has
been installed, then the full version of the Boot Service RestoreTPL()
On 29/02/2024 19:04, Paolo Bonzini wrote:
On 2/29/24 14:02, Ray Ni wrote:
In the end, it will lower the TPL to TPL_APPLICATION with interrupt
enabled.
However, it's possible that another timer interrupt happens just in
the end
of RestoreTPL() function when TPL is TPL_APPLICATION.
How do no
On 29/02/2024 19:09, Michael D Kinney wrote:
"When the DXE Foundation is notified that the EFI_CPU_ARCH_PROTOCOL has
been installed, then the full version of the Boot Service RestoreTPL()
can be made available. When an attempt is made to restore the TPL
level
to level below EFI_TPL_HIGH_LEVEL, t
On 29/02/2024 19:26, Michael D Kinney wrote:
I think one advantage of this new proposal is to prevent
an extra level of nesting and use of stack resources in
that extra level.
I think that's a negligible benefit. In the scenario as I outlined for
NestedInterruptTplLib, there is potentially on
On 01/03/2024 08:37, Paolo Bonzini wrote:
So I am starting to see more and more similarities between the two
approaches. I went a step further with fresh mind, removing the while
loop... and basically reinvented your and Michael's patch. :) The only
difference in the logic is a slightly differen
On 01/03/2024 09:33, Paolo Bonzini wrote:
On Fri, Mar 1, 2024 at 10:27 AM Michael Brown wrote:
It's possible that it doesn't matter. The new logic will effectively
mean that RestoreTPL() will restore not only the TPL but also the
interrupts-enabled state to whatever existed at the t
Reviewed-by: Michael Brown
Thanks,
Michael
On 01/03/2024 02:54, Zhou Jianfeng wrote:
Add volatile qualifier to page table related variable to prevent
compiler from optimizing away the variables which may lead to
unexpected result.
Signed-off-by: Zhou Jianfeng
Cc: Ray Ni
Cc: Laszlo Ersek
On 06/04/2024 16:53, Mike Beaton wrote:
The existing uninstall call was passing the wrong handle (parent object,
not the correct child object) and additionally passing the address
of a pointer to the interface to be removed rather than the pointer
itself, so always failed with EFI_NOT_FOUND. Afte
On 19/04/2024 11:02, Mike Beaton wrote:
Dear Michael,
I don't know if you had time to answer one follow-up question.
Obviously one thing that someone might want to do is to notify on
protocol installs and trap installs of this protocol - e.g. so that
something other than UefiBootManagerLib ca
On 08/05/2024 22:19, Ard Biesheuvel wrote:
I've always found that logic rather bizarre - there is no way the
implementation of the raw protocol can ensure that the caller uses it
correctly, and so enforcing a minimum read size is pointless and
arbitrary. And as you note, it has no basis in the UE
On 30/05/2024 10:31, Gerd Hoffmann wrote:
On Thu, May 30, 2024 at 01:07:45PM GMT, gaoliming via groups.io wrote:
If ASSERT trigs the exception, could call stack show each caller?
Turned out to be ipxe, apparently it has a exit-boot-services handler
which triggers all this.
iPXE shouldn't be
On 30/05/2024 11:33, Gerd Hoffmann wrote:
Most likely it is exactly this ...
As of commit
https://github.com/ipxe/ipxe/commit/6769a7c3c, we now deliberately leak
resources once ExitBootServices has been triggered by skipping the cleanup
calls to UninstallMultipleProtocolInterfaces etc.
... as
On 14/11/2019 16:07, Pete Batard wrote:
+typedef
+EFI_STATUS
+(EFIAPI *GET_MODEL_FAMILY) (
+ UINT32 *ModelFamily
+ );
+
typedef
EFI_STATUS
(EFIAPI *GET_FIRMWARE_REVISION) (
@@ -143,6 +150,7 @@ typedef struct {
GET_MODEL GetModel;
GET_MODEL_REVISIONGetModelRevision;
On 19/07/2019 12:53, Leif Lindholm wrote:
The patches look good, and I don't mind you upstreaming Michael's
code, *but* I don't want patches submitted with anyone other than the
contributor's Signed-off-by:. (It's the equivalent of saying "Yeah,
Michael says he's OK with https://developercertific
This standalone patch fixes FdtDxe.c to handle newer Raspberry Pi
device trees using the "ethernet0" alias (while retaining
compatibility with older device trees).
Michael Brown (1):
Platform/RPi3: Accept "ethernet" or "ethernet0" aliases in device tree
Pla
hernet alias") and U-Boot commit f8e57c6 ("fdt_support: Fixup
'ethernet' aliases not ending in digits").
Accept either "ethernet" or "ethernet0" as being the alias to the node
for which the MAC address should be updated.
Signed-off-by: Michael Brown
---
On 23/07/2019 11:34, Leif Lindholm wrote:
On Fri, Jul 19, 2019 at 06:29:07PM +0100, Michael Brown wrote:
Older device trees tend to use the alias "ethernet". Newer device
trees tend to use "ethernet0" since older versions of U-Boot would
skip aliases that do not include a
her alias, and with device trees that contain either (or
both) aliases.
Signed-off-by: Michael Brown
---
.../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/Platform/RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c
b/Platform/Raspbe
ot; aliases exist within the device tree.
The code is unfortunately much more verbose than v1, since there is no
convenient libfdt helper function for creating an alias.
I have attempted to match the existing coding style, but I apologise
in advance for any errors in so doing.
Michael Brown (1):
On 24/07/2019 19:53, Leif Lindholm wrote:
SanitizePSCI ();
CleanMemoryNodes ();
CleanSimpleFramebuffer ();
+ FixEthernetAliases ();
...would it be worth having a return value here and Print()ing a
message visible regardless of build profile if this function fails?
Yes, I think th
Most functions in FdtDxe currently return VOID and report errors using
only DEBUG. Update functions to return EFI_STATUS and report errors
using Print() so that errors are at least visible in non-debug builds.
Signed-off-by: Michael Brown
---
.../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 102
n
>> then follow up with a second patch to improve the error visibility in
>> non-debug builds?
>
> Yeah, that works for me.
As promised, here is the subsequent patch to improve error visibility
throughout FdtDxe.
Michael Brown (1):
Platform/RPi3: Report device tree modificat
Most functions in FdtDxe currently return VOID and report errors using
only DEBUG. Update functions to return EFI_STATUS and report errors
using Print() so that errors are at least visible in non-debug builds.
Signed-off-by: Michael Brown
---
.../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 102
(EFI_INVALID_PARAMETER seemed misleading to me, since there is nothing
wrong with the parameters provided by the caller.)
Michael Brown (1):
Platform/RPi3: Report device tree modification errors using Print()
.../RaspberryPi/RPi3/Drivers/FdtDxe/FdtDxe.c | 102 --
1 fil
On 22/05/2019 11:40, Tomas Pilar (tpilar) wrote:
Yeah, I just AllocateCopyPool the static struct on heap for each device. I can
honestly see how one would assume that a protocol instance would never be
installed on more than one handle, same as I assumed that using a statically
allocated struc
On 23/05/2019 10:46, Tomas Pilar (tpilar) wrote:
I was mostly puzzled by the double step. First find a parent device to
LoadedImage that support NII. Rather than using that device we will scan all
devices to see if any of them has the same NII protocol and if so we use that
one. I am not sure
On 26/09/2022 16:39, Clark-williams, Zachary wrote:
+ if (Profile->Password[StrLen (Profile->Password)] != '\0') {
+Profile->Password[StrLen (Profile->Password)] = L'\0'; }
+
I don't understand this change, StrLen returns the length of a Null-terminated Unicode string,
it means "Profile->
On 19/08/2020 19:13, Laszlo Ersek wrote:
I'm still undecided whether option#43 / tag#6 / bit#3 being clear means
we should *ignore* PXE_BOOT_SERVERS (tag#8), but I'm willing to defer to
you on that. So, I can give a cautious
Reviewed-by: Laszlo Ersek
for this patch.
FWIW, iPXE's equivalent l
On 20/08/2020 11:44, Maciej Rabeda wrote:
@Michael
I am now wondering whether bit 3 is actually relevant to server choice.
Bit 3:
== 0 -> prompt user to choose a boot file. Which means to me: show
minimal menu with prompt (tag 10 - PXE_MENU_PROMPT) and options (tag 9 -
PXE_BOOT_MENU).
== 1 ->
On 21/08/2020 12:19, Laszlo Ersek wrote:
On 08/19/20 20:46, Michael Brown wrote:
FWIW, iPXE's equivalent logic (based on a combination of what the PXE
spec says and what the Intel reference PXE implementation actually does,
which is not necessarily the same thing) is to *i
On 09/11/2021 08:40, Gerd Hoffmann wrote:
3. Require use of uncrustify tool before submitting patch review emails or
PRs.
* The required version would be a formally released version from the
fork maintained by Michael Kubacki until the changes can be upstreamed.
* https://d
On 22/11/2021 16:42, Michael D Kinney wrote:
You are also modifying the DebugLib in the paths where ASSERT() macros
are disabled. When they are disabled, we want all code/data associated
with ASSERT() to be removed by the optimizing compiler/linker. The source
code change appears to force a ref
On 23/11/2021 06:41, Marvin Häuser wrote:
23.11.2021 00:17:30 Michael Brown :
I would very strongly recommend having the non-debug version of the macro use
something like:
#define ASSERT(Expression) do { \
if (FALSE) { \
(VOID) (Expression
On 05/02/2021 08:28, Sivaraman Nainar wrote:
Hello Maciej:
I met an issue when tried to do the PXE boot with keeping the ipxe.efi
as boot file.
When iPXE.efi is set as boot file once it downloaded it again starts, it
does the download and start of iPXE continuously and at some point it
asse
On 19/02/2021 17:33, Laszlo Ersek wrote:
The PCI Firmware Spec does not seem to specify a particular "checksum
byte" in the option ROM format, it only seems to state that the bytes in
the option ROM must sum to zero.
This (apparently) allows option ROM providers to implement different
schemes fo
On 28/01/2022 12:47, Rao G wrote:
Attempting to Read SPIBAR 0x10 from BUS 0 Dev 1F Func 5
>>
ScSpiBar0 = MmioRead32 (SpiInstance->PchSpiBase +
PCI_BASE_ADDRESSREG_OFFSET) & 0xF000;
>>
The above code is throwing exception
PchSpiBase at 0xC00FD000
X64 Exception Type - 0E(#PF - Page-
On 01/02/2022 09:34, Sean Rhodes wrote:
Gather information from SMBIOS table rather than getting it
from the EFI SMBIOS protocol for coreboot builds.
Could you not avoid code duplication by exposing the SMBIOS table via
EFI_SMBIOS_PROTOCOL? This would provide a much more general solution
tha
On 02/02/2022 09:02, Sean Rhodes wrote:
Not quite sure how to implement that, are there any existing use cases
that I can look at?
From the way that your patch uses SMBIOS data, I'm assuming that your
use case involves a pre-existing SMBIOS table structure that is
constructed by something (e.
On 05/04/2021 00:01, Marvin Häuser wrote:
3. During my initial exploration, I discovered defective PPIs and
protocols (e.g. returning data with no corresponding size) originating
from the UEFI PI and UEFI specifications. Changes need to be discussed,
settled on, and submitted to the UEFI Forum.
On 07/04/2021 22:31, Marvin Häuser wrote:
Sorry, but I do not see why this would be the case. In fact the solution
is (temporary) co-existence, as already is the case with
InstallProtocolInterface() and InstallMultipleProtocolInterfaces()
InstallMultipleProtocolInterfaces() is not a breaking c
On 08/04/2021 09:53, Marvin Häuser wrote:
On 07.04.21 23:50, Michael Brown wrote:
InstallMultipleProtocolInterfaces() is not a breaking change: the
existence of InstallMultipleProtocolInterfaces() does not require any
change to the way that InstallProtocolInterface() is implemented or
On 08/04/2021 10:04, Marvin Häuser wrote:
Thank you a lot. One thing I noticed is that part of the quote I did not
see on the list before, so I marked it below.
On 08.04.21 00:10, Andrew Fish wrote:
The general UEFI (and UEFI PI) is we mostly add new things, and don’t
depreciated things to mai
On 08/04/2021 10:41, Marvin Häuser wrote:
No,
backwards-compatibility will not be broken in the sense that the old API
is absent or malfunctioning.
Perfect. :)
As I *have* said, I imagine there to be an
option (default true) to expose both variants.
Very much less perfect. The mere existe
On 08/04/2021 11:13, Marvin Häuser wrote:
Very much less perfect. The mere existence of such an option
immediately reimposes the burden on external code to support both,
because it opens up the possibility of running on systems where the
option is set to false.
One more time, I do not know w
On 08/04/2021 22:07, Marvin Häuser wrote:
PE is not a moving target, but EDK II is. The fact that even old and proven code
sometimes needs maintanance is evidental from the proposal and its so far positive
feedback. I'm not ready to duplicate code, I'd rather take the utilities out of the
curr
On 14/04/2021 20:34, Andrew Fish via groups.io wrote:
EFI does not have a concept of Volume names, EFI has a concept of EFI_HANDLEs
that contain device paths that indentify the volume.
The UEFI Shell has volume names, but that is a construct produced by the UEFI
Shell.
The filesystem label (
On 15/04/2021 06:28, Ethin Probst wrote:
- I hoped to add recording in case we in future want to add
accessibility aids like speech recognition (that was one of the todo
tasks on the EDK2 tasks list)
Is there any necessity for audio input and output to be implemented
within the same protocol?
On 16/04/2021 00:42, Ethin Probst wrote:
Forcing a particular channel mapping, sample rate and sample format on
everyone would complicate application code. From an application point
of view, one would, with that type of protocol, need to do the
following:
1) Load an audio file in any audio file f
On 16/04/2021 01:59, Ethin Probst wrote:
Also, I'm a bit confused. I've looked at several VirtIO devices now
and have seen things like this:
#define VIRTIO_PCI_DEVICE_SIGNATURE SIGNATURE_32 ('V', 'P', 'C', 'I')
// ...
UINT32 Signature;
I'm quite confused because I can't seem
On 27/04/2021 18:31, Andrew Fish via groups.io wrote:
One trick people have pulled in the past is to write a driver that
produces a “fake” PCI IO Protocol. The “fake” PCI IO driver abstracts
how the MMIO device shows up on the platform. This works well if the
MMIO device is really the same IP b
On 18/05/2021 19:42, Laszlo Ersek wrote:
On 05/18/21 09:51, Ni, Ray wrote:
Thanks for explaining why you don't think it's a good patch. I thought anytime
changing a code,
I should try to make it better, functional better, looks better.
My only point was that separate concerns should be implem
On 24/05/2021 20:26, Pedro Falcato wrote:
Me and my project have been selected for GSoC this year, under Michael
Kinney and bret. Thank you for the opportunity to collaborate with you
and improve Tianocore!
If anyone has any questions, please fire away :)
How do I get started? I'd like to find
On 28/05/2021 18:16, Pedro Falcato wrote:
2) Although I'd love to avoid journaling, which is a matter I'm not too
familiar with, I'm not entirely sure what simplifications may be done
because for one,
what happens if the power cuts during a write? It's unclear to me how a
FW filesystem driver m
On 04/06/2021 11:11, Laszlo Ersek wrote:
And, to reiterate, just because Confidential Computing is the
new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64
do not disappear. Regressing them, or making them unmaintainable due to
skyrocketing complexity, is not acceptable.
Tot
On 04/06/2021 11:43, Michael Brown wrote:
On 04/06/2021 11:11, Laszlo Ersek wrote:
And, to reiterate, just because Confidential Computing is the
new hot thing, the use cases for OvmfPkgIa32, OvmfPkgIa32X64, OvmfPkgX64
do not disappear. Regressing them, or making them unmaintainable due to
1 - 100 of 165 matches
Mail list logo