Permit ProcessCapsules () to be called only a single time, after
EndOfDxe. This allows platforms that are able to update system
firmware after EndOfDxe (e.g., because the flash ROM is not locked
down) to do so at a time when a non-trusted console is up and running,
and progress can be reported to t
Implement ResetSystemLib's EnterS3WithImmediateWake() routine using
a jump back to the PEI entry point with interrupts and MMU+caches
disabled. This is only possible at boot time, when we are sure that
the current CPU is the only one up and running. Also, it depends on
the platform whether the PEI
ARM platforms have no restriction on when a system firmware update
capsule can be applied, and so it is not necessary to call
ProcessCapsules() twice. So let's drop the first invocation that
occurs before EndOfDxe, so that capsule updates will be applied
when the console is up and able to provide p
If the first call to UpdateImageProgress() fails, there is no point
in passing a pointer to it to Fmp->SetImage(), since it is highly
unlikely to succeed on any subsequent calls.
This permits the FMP implementation to fall back to an alternate means
of providing feedback to the user, e.g., via the
When capsule updates are staged for processing after a warm reboot,
they are copied into memory with the MMU and caches enabled. When
the capsule PEI gets around to coalescing the capsule, the MMU and
caches may still be disabled, and so on architectures where uncached
accesses are incoherent with
This is the delta of code required to implement PersistAcrossReset on ARM
systems, and to wire up the capsule handling routines in a way that makes
the new progress reporting code do something meaningful on such platforms.
Changes since v1:
- incorporate Star's feedback (#1, #2)
- add Leif's ack (
On 8 June 2018 at 04:57, Zeng, Star wrote:
> Without the patch, PopulateCapsuleInConfigurationTable is only run at first
> round.
> With the patch, PopulateCapsuleInConfigurationTable is only run at last round.
>
> Is that expected?
>
Yes. Otherwise, I need two global BOOLEANs to keep track of t
On 8 June 2018 at 08:21, Zeng, Star wrote:
> My thought is like below, FYR.
>
Thanks. That works for me.
I will update the patch.
> ===
> 8bf218e00d8bd5c4f01c83f3d16c636140d32fda
> .../Universal/CapsulePei/Common/CapsuleCoalesce.c | 37
> ++
My thought is like below, FYR.
===
8bf218e00d8bd5c4f01c83f3d16c636140d32fda
.../Universal/CapsulePei/Common/CapsuleCoalesce.c | 37 +++---
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git a/MdeModulePkg/Universal/Capsul
On 8 June 2018 at 04:53, Zeng, Star wrote:
> I suggest to use goto/adjust code to have one place for both paths to perform
> cache maintenance (with comments).
>
Something like this?
@@ -253,6 +254,7 @@ ValidateCapsuleByMemoryResource (
)
{
UINTN Index;
+ BOOLEAN F
Hi Matt,
Thanks. I've submitted patch v2 based on your feedbacks.
- ben
> From: Matt Delco [mailto:de...@google.com]
> Sent: Friday, June 8, 2018 1:07 AM
> To: Ma, Maurice
> Cc: You, Benjamin ; Agyeman, Prince
> ; edk2-devel@lists.01.org
> Subject: Re: [PATCH] CorebootModulePkg/CbSupportDxe:
Current implemenation sets PM1_CNT.SCI_EN bit at ReadyToBoot event.
However, this should not be done because this causes OS to skip triggering
FADT.SMI_CMD, which leads to the functions implemented in the SMI
handler being omitted.
This issue was identified by Matt Delco .
The fix does the follow
Zenith,
Stupid question, I'm not trying to derail the code review.
In a static lib world like EFI, I can't figure out why we need support for GOT
PC REL addressing modes? I say that as I would think they would be relocation
entries in object files, and then the final link would happen and t
Reviewed-by: Liming Gao
> -Original Message-
> From: Zhu, Yonghong
> Sent: Thursday, June 7, 2018 10:09 AM
> To: edk2-devel@lists.01.org
> Cc: Feng, YunhuaX ; Gao, Liming
> Subject: [Patch] BaseTools: Fix Section header size larger than elf file size
> bug
>
> From: Yunhua Feng
>
> A
Reviewed-by: Liming Gao
> -Original Message-
> From: Zhu, Yonghong
> Sent: Thursday, June 7, 2018 10:03 AM
> To: edk2-devel@lists.01.org
> Cc: Feng, YunhuaX ; Gao, Liming
> Subject: [Patch] BaseTools: Check elf sections alignment with
> MAX_COFF_ALIGNMENT
>
> From: Yunhua Feng
>
> Ad
Good patch.
Another choice is to use DEBUG_VERBOSE.
We see other driver uses DEBUG_VERBOSE for BlockIo service (Hao can comment on
that).
We'd better to align them for consistency.
Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Friday, June 8, 2018
Without the patch, PopulateCapsuleInConfigurationTable is only run at first
round.
With the patch, PopulateCapsuleInConfigurationTable is only run at last round.
Is that expected?
Jiewen, could you help check whether the patch meets the original design
purpose or any security concern?
Thanks,
I suggest to use goto/adjust code to have one place for both paths to perform
cache maintenance (with comments).
Thanks,
Star
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: Thursday, June 7, 2018 7:08 PM
To: edk2-devel@lists.01.org
Cc: leif.lindh...@lin
The patch 5a57246eab80 Rename String to StringUtils, but it didn't
update the UPT Tool for the import statement which cause UPT tool
break.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu
---
BaseTools/Source/Python/UPT/GenMetaFile/GenDecFile.py | 4 ++--
Next week is OK, take your time. I appreciate the test cases with build steps,
thanks!
BTW, I'm not sure where is the right place in edk2 to submit a patch's test
cases, but I do welcome the test case contribution.
Steven Shi
Intel\SSG\STO\UEFI Firmware
Tel: +86 021-61166522
iNet: 821-6522
>
Yes.
On 07.06.2018 17:56, Rafael Machado wrote:
> Nice initiative!
>
> Will the presentations be recorded and posted at youtube?
>
> Thanks
> Rafael R. Machado
>
> Em ter, 5 de jun de 2018 às 09:10, Philipp Deppenwiese
> mailto:zaolin.dais...@gmail.com>> escreveu:
>
> Dear Ladies and Gentleme
On 06/07/18 11:10, Ard Biesheuvel wrote:
> Lower the priority of the DEBUG print in EmmcReadWrite(), which
> is emitted for each read or write operation to the eMMC device,
> which clutters up the log output of builds created with DEBUG_INFO
> enabled.
>
> Suggested-by: Pipat Methavanitpong
> Con
On 06/07/18 12:46, Ard Biesheuvel wrote:
> KVM on ARM refuses to decode load/store instructions used to perform
> I/O to emulated devices, and instead relies on the exception syndrome
> information to describe the operand register, access size, etc.
> This is only possible for instructions that hav
Thanks for working on this. I did a quick test to confirm that things
still work okay. The code change looks fine though there's some optional
optimizations to consider:
The new code added to CbParseFadtInfo() is mostly to add debug checks but I
think it'll still result in a IO port access in a
yes I'll do that next time. Thanks for the hint.
Thanks
Michael
On Thu, Jun 7, 2018 at 9:10 AM Ard Biesheuvel wrote:
>
> On 7 June 2018 at 07:08, Michael Zimmermann wrote:
> > CC the arm maintainers
> > On Thu, Jun 7, 2018 at 7:07 AM Michael Zimmermann
> > wrote:
> >>
> >> From: M1cha
> >>
>
>
Hi Ard,
yes that fixes the problem too and looks much better, thx!
On Thu, Jun 7, 2018 at 9:05 AM Ard Biesheuvel wrote:
>
> On 7 June 2018 at 07:47, Michael Zimmermann wrote:
> > This was the warning(shown for __aeabi_memcpy, __aeabi_memcpy4 and
> > __aeabi_memcpy8):
> > ArmPkg/Library/Compiler
On 06/07/18 17:09, Ard Biesheuvel wrote:
> On 7 June 2018 at 17:08, Gao, Liming wrote:
>> Ard:
>> If this library instance is specific to ARM emulator with KVM, how about
>> add it into ArmVirtPkg?
>>
>
> Laszlo, do you want to take this question?
Certainly.
Liming, in commit b6d11d7c4678, w
This addresses all of the items I mentioned in my review of the
previous solution to this problem, so for me:
Reviewed-by: Leif Lindholm
On Thu, Jun 07, 2018 at 12:46:45PM +0200, Ard Biesheuvel wrote:
> KVM on ARM refuses to decode load/store instructions used to perform
> I/O to emulated device
On 7 June 2018 at 17:08, Ard Biesheuvel wrote:
> We intend to start distributing firmware update capsules that include the SCP
> firmware partition. In order to allow for more flexibility regarding whether
> a capsule contains this piece or not, update the flash access routines and
> the flash par
Nice initiative!
Will the presentations be recorded and posted at youtube?
Thanks
Rafael R. Machado
Em ter, 5 de jun de 2018 às 09:10, Philipp Deppenwiese <
zaolin.dais...@gmail.com> escreveu:
> Dear Ladies and Gentlemen,
>
> We invite you to the Open Source Firmware Conference 2018
> ( www.osf
Hi, Chao,
The update from NULL to real wrapper looks good to me.
Please also update the "Note" part in this INF's comment before your commit,
since SHA384/512 was noted as "not supported" before.
Reviewed-by: Long Qin
Best Regards & Thanks,
LONG, Qin
> -Original Message-
> From: edk
It looks good to me.
Reviewed-by: Maurice Ma
-Original Message-
From: You, Benjamin
Sent: Thursday, June 7, 2018 1:19
To: edk2-devel@lists.01.org
Cc: Ma, Maurice ; Agyeman, Prince
; de...@google.com
Subject: [PATCH] CorebootModulePkg/CbSupportDxe: Remove SCI_EN setting
Current impleme
On 7 June 2018 at 17:08, Gao, Liming wrote:
> Ard:
> If this library instance is specific to ARM emulator with KVM, how about
> add it into ArmVirtPkg?
>
Laszlo, do you want to take this question?
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sen
Ard:
If this library instance is specific to ARM emulator with KVM, how about add
it into ArmVirtPkg?
Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, June 7, 2018 6:47 PM
> To: edk2-devel@lists.01.org
> Cc: ler...@redhat.com
In order to allow for more flexibility when updating parts of the
firmware via capsule update, expand the description of the code FV
to cover the entire 4 MB region at the base of the NOR flash.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Silicon/Soc
We intend to start distributing firmware update capsules that include the SCP
firmware partition. In order to allow for more flexibility regarding whether
a capsule contains this piece or not, update the flash access routines and
the flash partition descriptions so we can update any part of the fir
In commit 913fdda9f4b9 ("Silicon/SynQuacerPlatformFlashAccessLib: don't
dereference FVB header fields"), we dropped all accesses to FVB header
field, which was necessary because the flash partition may not in fact
contain such a header. Instead, only an exact match on the base address
of the FV com
On Thu, Jun 07, 2018 at 01:08:11PM +0200, Ard Biesheuvel wrote:
> ARM platforms have no restriction on when a system firmware update
> capsule can be applied, and so it is not necessary to call
> ProcessCapsules() twice. So let's drop the first invocation that
> occurs before EndOfDxe, so that caps
On Thu, Jun 07, 2018 at 08:57:04AM +0200, Ard Biesheuvel wrote:
> On 6 June 2018 at 15:29, Laszlo Ersek wrote:
> > On 06/06/18 14:37, Ard Biesheuvel wrote:
> >> Implement ResetSystemLib's EnterS3WithImmediateWake() routine using
> >> a jump back to the PEI entry point with interrupts and MMU+cache
Enable SHA384/512 support in PEI phase.
Cc: Long Qin
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chao Zhang
Signed-off-by: Zhang, Chao B
---
CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/CryptoP
On 7 June 2018 at 14:55, Marcin Wojtas wrote:
> Hitherto mechanism of using static flag indicating
> Buffer Manager disabled state was wrong and resulted
> in cleaning only one controller's pools. This caused
> bad page state when OS booted and attempted to
> use the buffers.
>
> This patch implem
Hitherto mechanism of using static flag indicating
Buffer Manager disabled state was wrong and resulted
in cleaning only one controller's pools. This caused
bad page state when OS booted and attempted to
use the buffers.
This patch implements a fix, ensuring all controllers
will clean the Buffer M
Adds support for the following X64 ELF relocations to GenFw
R_X86_64_GOTPCREL
R_X86_64_GOTPCRELX
R_X86_64_REX_GOTPCRELX
CC: Shi Steven
CC: Yonghong Zhu
CC: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zenith432
---
BaseTools/Source/C/GenFw/Elf64Conv
There is a mistake in sign in the patch I posted
=
diff --git a/BaseTools/Source/C/GenFw/Elf64Convert.c
b/BaseTools/Source/C/GenFw/Elf64Convert.c
--- a/BaseTools/Source/C/GenFw/Elf64Convert.c
+++ b/BaseTools/Source/C/GenFw/Elf64Convert.c
@@ -962,7 +962,7 @@ WriteSections64 (
Verb
Switch to the more common flavor of firmware update capsules that are
only staged by the UpdateCapsule() service, and dispatched and processed
after a warm reboot.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/Socionext/DeveloperBox/DeveloperB
Replace the home cooked progress indication with calls into the new
(*Progress)() argument to PerformFlashWriteWithProgress(), which
allows the flash access routine to report progress via a platform
provided callback.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesh
These patches reimplement graphical progress reporting during capsule update.
They depend on MdeModulePkg and ArmPkg changes currently under review.
Patch #1 adds support for dispatching PersistAcrossReset capsules. This
requires a warm reboot implementation which is being proposed for ArmPkg.
Pa
Add support for PersistAcrossReset capsules, by setting the associated
PCD, and by enabling the warm reboot implementation that reenters PEI
with interrupts, caches and MMU disabled.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Platform/Socionext/Deve
On 17 April 2018 at 03:20, Guo Heyi wrote:
> Hi Ard,
>
> I tested mm -io on D05, for root bridge 4 with CPU IO address starting from
> 0x8_abff, and it worked; both mm -io 0x8abff and mm 0x8abff
> provided
> the same output. It seems there is no other limit for 64bit IO address after
When capsule updates are staged for processing after a warm reboot,
they are copied into memory with the MMU and caches enabled. When
the capsule PEI gets around to coalescing the capsule, the MMU and
caches may still be disabled, and so on architectures where uncached
accesses are incoherent with
ARM platforms have no restriction on when a system firmware update
capsule can be applied, and so it is not necessary to call
ProcessCapsules() twice. So let's drop the first invocation that
occurs before EndOfDxe, so that capsule updates will be applied
when the console is up and able to provide p
This is the delta of code required to implement PersistAcrossReset on ARM
systems, and to wire up the capsule handling routines in a way that makes
the new progress reporting code do something meaningful on such platforms.
Patch #1 ensures that the capsule data which is preserved in DRAM across
a
Permit ProcessCapsules () to be called only a single time, after
EndOfDxe. This allows platforms that are able to update system
firmware after EndOfDxe (e.g., because the flash ROM is not locked
down) to do so at a time when a non-trusted console is up and running,
and progress can be reported to t
If the first call to UpdateImageProgress() fails, there is no point
in passing a pointer to it to Fmp->SetImage(), since it is highly
unlikely to succeed on any subsequent calls.
This permits the FMP implementation to fall back to an alternate means
of providing feedback to the user, e.g., via the
Implement ResetSystemLib's EnterS3WithImmediateWake() routine using
a jump back to the PEI entry point with interrupts and MMU+caches
disabled. This is only possible at boot time, when we are sure that
the current CPU is the only one up and running. Also, it depends on
the platform whether the PEI
KVM on ARM refuses to decode load/store instructions used to perform
I/O to emulated devices, and instead relies on the exception syndrome
information to describe the operand register, access size, etc.
This is only possible for instructions that have a single input/output
register (as opposed to o
On 5 June 2018 at 15:04, Laszlo Ersek wrote:
> On 06/05/18 13:05, Ard Biesheuvel wrote:
>> KVM on ARM refuses to decode load/store instructions used to perform
>> I/O to emulated devices, and instead relies on the exception syndrome
>> information to describe the operand register, access size, etc
On 7 June 2018 at 12:27, Zeng, Star wrote:
> I think checking validity is other code's responsibility, after that the new
> code to perform cache maintenance. They are separated.
> I prefer to cover both paths.
>
OK, fair enough.
>
> Thanks,
> Star
> -Original Message-
> From: edk2-dev
I think checking validity is other code's responsibility, after that the new
code to perform cache maintenance. They are separated.
I prefer to cover both paths.
Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
Biesheuvel
Sent: T
On 7 June 2018 at 12:12, Zeng, Star wrote:
> Since capsule data pointer may be invalid (for example, point to MMIO), we
> enhanced code to validate the capsule by memory resource HOB, and *recommend*
> platform/silicon (memory reference code) to report memory resource HOB before
> capsule coale
Since capsule data pointer may be invalid (for example, point to MMIO), we
enhanced code to validate the capsule by memory resource HOB, and *recommend*
platform/silicon (memory reference code) to report memory resource HOB before
capsule coalescing.
To consider and compatible with some platform
On 7 June 2018 at 11:46, Zeng, Star wrote:
> Ok, I want to know whether others have some idea, so let's wait some time?
>
> About the code change, I have three minor comments below.
> 1. I suggest adding some code comment for the new line code.
OK
> 2. There are two paths in ValidateCapsuleByMem
Ok, I want to know whether others have some idea, so let's wait some time?
About the code change, I have three minor comments below.
1. I suggest adding some code comment for the new line code.
2. There are two paths in ValidateCapsuleByMemoryResource() to return TRUE,
should the new line code be
Lower the priority of the DEBUG print in EmmcReadWrite(), which
is emitted for each read or write operation to the eMMC device,
which clutters up the log output of builds created with DEBUG_INFO
enabled.
Suggested-by: Pipat Methavanitpong
Contributed-under: TianoCore Contribution Agreement 1.1
Si
Current implemenation sets PM1_CNT.SCI_EN bit at ReadyToBoot event.
However, this should not be done because this causes OS to skip triggering
FADT.SMI_CMD, which leads to the functions implemented in the SMI
handler being omitted.
This issue was identified by Matt Delco .
The fix does the follow
Reviewed-by: Liming Gao
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Wednesday, June 06, 2018 3:09 PM
>To: edk2-devel@lists.01.org
>Cc: Kinney, Michael D ; Shaw, Kevin W
>; Gao, Liming
>Subject: [edk2] [Patch] DSC Spec:
Reviewed-by: Liming Gao
>-Original Message-
>From: Zhu, Yonghong
>Sent: Tuesday, June 05, 2018 8:18 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming ; Kinney, Michael D
>; Shaw, Kevin W
>Subject: [Patch] Build spec: Add a Common PCD rules section for build report
>
>1. Add a Common PCD r
Reviewed-by: Liming Gao
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Yonghong Zhu
>Sent: Thursday, May 31, 2018 8:56 AM
>To: edk2-devel@lists.01.org
>Cc: Kinney, Michael D ; Shaw, Kevin W
>; Gao, Liming
>Subject: [edk2] [Patch 1/5] Build Sp
On 7 June 2018 at 07:08, Michael Zimmermann wrote:
> CC the arm maintainers
> On Thu, Jun 7, 2018 at 7:07 AM Michael Zimmermann
> wrote:
>>
>> From: M1cha
>>
Could you please use the same 'from' name+address as in the signoff?
That saves me the hassle of fixing it up manually.
>> GCC8 reported
On 7 June 2018 at 07:47, Michael Zimmermann wrote:
> This was the warning(shown for __aeabi_memcpy, __aeabi_memcpy4 and
> __aeabi_memcpy8):
> ArmPkg/Library/CompilerIntrinsicsLib/memcpy.c:42:6: error: '__aeabi_memcpy8'
> alias between functions of incompatible types 'void(void
> *, const void *,
70 matches
Mail list logo
