> On May 28, 2018, at 1:36 PM, Bill Paul wrote:
>
> Of all the gin joints in all the towns in all the world, Ni, Ruiyu had to
> walk
> into mine at 19:55 on Sunday 27 May 2018 and say:
>
>> No. There is no such instance.
>>
>> My understanding:
>> Segment is just to separate the PCI device
On 05/28/2018 03:36 PM, Bill Paul wrote:
Of all the gin joints in all the towns in all the world, Ni, Ruiyu had to walk
into mine at 19:55 on Sunday 27 May 2018 and say:
No. There is no such instance.
My understanding:
Segment is just to separate the PCI devices to different groups.
Each group
Hi Ray,
On 06/01/18 09:22, Ruiyu Ni wrote:
> Current DxeResetSystemLib depends on UefiRuntimeLib because it calls
> EfiResetSystem() API exposed by UefiRuntimeLib.
>
> Due to the commit XXX which reverts UefiRuntimeLib to only support
I really just cursorily skimmed the commit messages here, but
(Subject changed)
I guess this is a question of UEFI spec interpretation. In the Console
I/O Protocol description of Version 2.5 of the spec (page 456), it says:
If the Scan Code is set to 0x00 then the Unicode character is
valid and should be used.
To me that clearly says it all. The
2018-06-01 18:57 GMT+02:00 Ard Biesheuvel :
> On 1 June 2018 at 18:43, Marcin Wojtas wrote:
>> 2018-06-01 17:30 GMT+02:00 Ard Biesheuvel :
>>> On 1 June 2018 at 16:32, Marcin Wojtas wrote:
PEI phase will allow to use more robust platform initialization,
with new features like the capsul
On 1 June 2018 at 18:43, Marcin Wojtas wrote:
> 2018-06-01 17:30 GMT+02:00 Ard Biesheuvel :
>> On 1 June 2018 at 16:32, Marcin Wojtas wrote:
>>> PEI phase will allow to use more robust platform initialization,
>>> with new features like the capsule support. Wire up all
>>> dependencies for that p
Thanks.
Series:
Reviewed-by: Leif Lindholm
Pushed as ba32985a06..0923068a48.
On Fri, Jun 01, 2018 at 10:21:12AM +0800, Haojian Zhuang wrote:
> Do some basic initliazation on peripherals, such as pins and
> regulators.
>
> The hardcoding code is taken from non-open reference code.
> Can't fix i
2018-06-01 17:30 GMT+02:00 Ard Biesheuvel :
> On 1 June 2018 at 16:32, Marcin Wojtas wrote:
>> PEI phase will allow to use more robust platform initialization,
>> with new features like the capsule support. Wire up all
>> dependencies for that purpose.
>>
>> Contributed-under: TianoCore Contributi
2018-06-01 18:08 GMT+02:00 Ard Biesheuvel :
> On 1 June 2018 at 18:02, Marcin Wojtas wrote:
>> Hi Ard,
>>
>> 2018-06-01 17:32 GMT+02:00 Ard Biesheuvel :
>>> On 1 June 2018 at 16:32, Marcin Wojtas wrote:
From: David Sniatkiwicz
This patch adds necessary code that allows to update
On 1 June 2018 at 18:02, Marcin Wojtas wrote:
> Hi Ard,
>
> 2018-06-01 17:32 GMT+02:00 Ard Biesheuvel :
>> On 1 June 2018 at 16:32, Marcin Wojtas wrote:
>>> From: David Sniatkiwicz
>>>
>>> This patch adds necessary code that allows to update
>>> firmware on Armada7k8k platforms, using generic g
Hi Ard,
2018-06-01 17:32 GMT+02:00 Ard Biesheuvel :
> On 1 June 2018 at 16:32, Marcin Wojtas wrote:
>> From: David Sniatkiwicz
>>
>> This patch adds necessary code that allows to update
>> firmware on Armada7k8k platforms, using generic gRT->UpdateCapsule,
>> i.e.
>> * PlatformFlashAccessLib
On 1 June 2018 at 16:32, Marcin Wojtas wrote:
> Hi,
>
> Hereby I submit a capsule support for Marvell Armada platforms.
> Capsule preparation must be done in two steps, it requires additional
> build flag (-D CAPSULE_ENABLE), so by default nothing changes. Also the
> solution is using generic EDK2
On 1 June 2018 at 16:32, Marcin Wojtas wrote:
> From: David Sniatkiwicz
>
> This patch adds necessary code that allows to update
> firmware on Armada7k8k platforms, using generic gRT->UpdateCapsule,
> i.e.
> * PlatformFlashAccessLib implementation to write data to SPI flash
> * SystemFirmwar
On 1 June 2018 at 16:32, Marcin Wojtas wrote:
> PEI phase will allow to use more robust platform initialization,
> with new features like the capsule support. Wire up all
> dependencies for that purpose.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas
>
On 1 June 2018 at 16:32, Marcin Wojtas wrote:
> When using PEI phase, UEFI interprets 0x0 address
> of boot FV as an error. In order to avoid it, shift
> it to 0x1000 and put a hardcoded 'jump to 0x1000' at
> offset 0x0. This patch is a preparation for using PEI
> by Armada platforms.
>
> Contribu
On 1 June 2018 at 17:13, Yao, Jiewen wrote:
> Got it. Thanks.
>
> Reviewed-by: jiewen@intel.com
>
Thanks all
Pushed as c4061d18ef53
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Friday, June 1, 2018 8:11 AM
>> To: Yao, Jiewen
>> Cc: Zen
Got it. Thanks.
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, June 1, 2018 8:11 AM
> To: Yao, Jiewen
> Cc: Zeng, Star ; edk2-devel@lists.01.org;
> leif.lindh...@linaro.org
> Subject: Re: [edk2] [PATCH] Si
On 1 June 2018 at 17:09, Yao, Jiewen wrote:
> I am about to agree.
>
> Would you please share a real example on how this PCD is used in some open
> source platforms?
>
Please refer to this patch
https://lists.01.org/pipermail/edk2-devel/2018-March/022914.html
Thanks,
Ard.
>> -Original Mes
I am about to agree.
Would you please share a real example on how this PCD is used in some open
source platforms?
Thank you
Yao Jiewen
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, June 1, 2018 3:06 AM
> To: Zeng, Star ; Yao, Jiewen
> C
I agree to add this checker.
Reviewed-by: Liming Gao
> -Original Message-
> From: Marcin Wojtas [mailto:m...@semihalf.com]
> Sent: Friday, June 1, 2018 9:58 PM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng ; Kinney, Michael D
> ; Gao, Liming ;
> leif.lindh...@linaro.org; ard.biesheu..
PEI phase will allow to use more robust platform initialization,
with new features like the capsule support. Wire up all
dependencies for that purpose.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf | 15 +++
All required components are in place, so we can now
add all necessary dependencies to build and use capsule support
for Armada7k8k platforms. It is conditionally enabled
with '-D CAPSULE_ENABLE' flag added during build time.
Because the capsule generation must be sequential,
due to boot requiremen
Hi,
Hereby I submit a capsule support for Marvell Armada platforms.
Capsule preparation must be done in two steps, it requires additional
build flag (-D CAPSULE_ENABLE), so by default nothing changes. Also the
solution is using generic EDK2 drivers and libraries, so all
wiki/howtos from Tianocore
When using PEI phase, UEFI interprets 0x0 address
of boot FV as an error. In order to avoid it, shift
it to 0x1000 and put a hardcoded 'jump to 0x1000' at
offset 0x0. This patch is a preparation for using PEI
by Armada platforms.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-b
From: David Sniatkiwicz
This patch adds necessary code that allows to update
firmware on Armada7k8k platforms, using generic gRT->UpdateCapsule,
i.e.
* PlatformFlashAccessLib implementation to write data to SPI flash
* SystemFirmwareDescriptor for FMP protocol
* SystemFirmwareUpdateConfig t
(+ MdeModulePkg maintainers)
On 1 June 2018 at 15:58, Marcin Wojtas wrote:
> Until now the possible errors returned from processing
> boot firmware volume were not checked, which could cause
> misbehavior in further booting stages. Add relevant assert.
>
> Contributed-under: TianoCore Contributio
Until now the possible errors returned from processing
boot firmware volume were not checked, which could cause
misbehavior in further booting stages. Add relevant assert.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
Signed-off-by: Jan Dabros
---
MdeModul
On 1 June 2018 at 14:34, Moorthy Baskaravenkatraman Sambamoorthy
wrote:
> Sorry for that. I have mistakenly followed the same template used for the
> last reviewed RDKPkg upstream.
> Let me remove that field and send for review again.
>
Please read the instructions here
https://github.com/tianoc
Sorry for that. I have mistakenly followed the same template used for the
last reviewed RDKPkg upstream.
Let me remove that field and send for review again.
Regards,
Moorthy
On 1 June 2018 at 17:45, Ard Biesheuvel wrote:
> On 1 June 2018 at 14:14, Moorthy Baskaravenkatraman Sambamoorthy
> wro
On 1 June 2018 at 14:14, Moorthy Baskaravenkatraman Sambamoorthy
wrote:
> Hi Ard,
>
> RDK package Secure boot and DRI application for QEMU platform were
> up-streamed by Kalyan under edk2-platforms. Now, I'm continuing the same for
> further maintenance.
>
That is fine. But that does *not* allow
Hi Ard,
RDK package Secure boot and DRI application for QEMU platform were
up-streamed by Kalyan under edk2-platforms. Now, I'm continuing the same
for further maintenance.
Regards,
Moorthy
On 1 June 2018 at 17:34, Ard Biesheuvel wrote:
> On 1 June 2018 at 13:03, Moorthy Baskaravenkatraman
>
On 1 June 2018 at 13:03, Moorthy Baskaravenkatraman
wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Moorthy Baskaravenkatraman
>
> Reviewed-by: Ard Biesheuvel
Excuse me? I don't remember reviewing these changes.
> ---
> Platform/Comcast/RDKQemu/RDKQemu.dsc |
Change GCC SMM stack size from 0x2000 to 0x4000 to align with VS build BIOS.
Please refer to this check in:
b2c3aeb0b4bcbc85aa2634de441201b86f4274ae
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang
Cc: David Wei
---
Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 5 ++
Change BIOS version for 0.98 release.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang
Cc: David Wei
---
Vlv2TbltDevicePkg/BiosId.env | 4 ++--
Vlv2TbltDevicePkg/BiosIdD.env| 4 ++--
Vlv2TbltDevicePkg/BiosIdR.env| 4 ++--
Vlv2TbltDevicePkg/BiosIdx64D
Change GCC SMM stack size from 0x2000 to 0x4000 to align with VS build BIOS.
Please refer to this check in:
b2c3aeb0b4bcbc85aa2634de441201b86f4274ae
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang
Cc: David Wei
---
Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc | 5 ++
On 1 June 2018 at 13:05, Leif Lindholm wrote:
> On Fri, Jun 01, 2018 at 12:59:38PM +0200, Ard Biesheuvel wrote:
>> Update to RELEASE build of commit aa20e0414fb3.
>>
>> This implements the override of the north SMMU page tables to make
>> the ECAM spaces appear sane to the OS.
>>
>> Contributed-un
On Fri, Jun 01, 2018 at 12:59:38PM +0200, Ard Biesheuvel wrote:
> Update to RELEASE build of commit aa20e0414fb3.
>
> This implements the override of the north SMMU page tables to make
> the ECAM spaces appear sane to the OS.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-of
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Moorthy Baskaravenkatraman
Reviewed-by: Ard Biesheuvel
---
Platform/Comcast/RDKQemu/RDKQemu.dsc | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Platform/Comcast/RDKQemu/RDKQemu.dsc
b/Platform/Comc
EDK2 latest dependencies resolved for RDK Qemu platform
Moorthy Baskaravenkatraman (1):
Platform/Comcast: EDK2 dependencies resolved for RDK Qemu platform
* DevicePathLib library class added in DxeMain *
NvVarStoreFormattedLib added in VariableRuntimeDxe *
DevicePathLib a
Update to RELEASE build of commit aa20e0414fb3.
This implements the override of the north SMMU page tables to make
the ECAM spaces appear sane to the OS.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Source changes:
https://git.linaro.org/leg/noupstrea
(1) Lock SMRAM with EFI_SMM_ACCESS2_PROTOCOL.Lock() before PCI bus enumeration.
This is for DMA protection.
(2) Call InstallReadyToLock after PCI enumeration and initialization of
trusted console. If InstallReadyToLock is called before PCI enumeration, some
silicon drivers would fail to save S3
On Thu, May 31, 2018 at 10:16:08PM +0100, Leif Lindholm wrote:
> On Thu, May 31, 2018 at 12:46:32PM +0200, Ard Biesheuvel wrote:
> > Enable some of the status code reporting infrastructure in patch #1 so
> > we can include the FPDT DXE driver in patch #2 which produces the FPDT
> > diagnostic table
On 31 May 2018 at 11:14, Leif Lindholm wrote:
> On Wed, May 30, 2018 at 08:19:28PM +0200, Ard Biesheuvel wrote:
>> Extend the static stage 2 page tables with a set of level 3 tables that
>> describe the ECAM space in a manner that allows the north SMMU to be used
>> to make the ECAM space appear s
On 31 May 2018 at 11:12, Zeng, Star wrote:
> It could be reused by platform SystemFirmwareDescriptor, for example.
> Vlv2TbltDevicePkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
> QuarkPlatformPkg/Feature/Capsule/SystemFirmwareDescriptor/SystemFirmwareDescriptor.inf
>
>
On 1 June 2018 at 11:51, Leif Lindholm wrote:
> On Fri, Mar 16, 2018 at 04:13:16PM +, Ard Biesheuvel wrote:
>> Now that the NOR flash layout has been updated to split the actual SCP
>> firmware from the startup code and the builtin flasher, we can add the
>> SCP image to the capsule update to
On Fri, Mar 16, 2018 at 04:13:16PM +, Ard Biesheuvel wrote:
> Now that the NOR flash layout has been updated to split the actual SCP
> firmware from the startup code and the builtin flasher, we can add the
> SCP image to the capsule update to make it field upgradeable.
>
> This involves some r
Reviewed-by: zwei4
Thanks,
David Wei
Intel SSG/STO/UEFI BIOS
-Original Message-
From: Guo, Mang
Sent: Friday, June 1, 2018 5:19 PM
To: edk2-devel@lists.01.org
Cc: Wei, David
Subject: [Patch][edk2-platforms/devel-MinnowBoardMax-UDK2017]
Vlv2TbltDevi
Reviewed-by: Liming Gao
> -Original Message-
> From: Ni, Ruiyu
> Sent: Friday, June 1, 2018 3:22 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zeng, Star
> Subject: [PATCH 3/3] MdePkg/UefiRuntimeLib: Do not allow to be linked by DXE
> driver
>
> When UefiRuntimeLib links to a DX
Change NvStorageVariable.bin because setup variable structure was changed.
CC: Wei, David
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Guo Mang
---
Vlv2TbltDevicePkg/Stitch/Gcc/NvStorageVariable.bin | Bin 253952 -> 253952 bytes
1 file changed, 0 insertions(+), 0 delet
On 23 May 2018 at 15:51, AlexeiFedorov wrote:
> From: Alexei Fedorov
>
> Programming Reference for Base FVPs describes 2 Generic Memory-mapped
> Timer frames with Non-secure access permitted to frame #1.
> However ACPI GTDT lists both timer frames #0 and #1 with
> Secure Timer flag being set in G
Thanks/Ray
> -Original Message-
> From: edk2-devel On Behalf Of Liu Yu
> Sent: Thursday, May 31, 2018 9:15 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] UDK debugger Tool for Qemu under Linux
>
> Sorry to send a global mail
>
> Did anyone ever debug uefi program in Qemu with UDK
Because the DxeResetSystemLib calls gRT->ResetSystem(), make sure
the gRT->ResetSystem() implementation doesn't call into
DxeResetSystemLib to avoid chicken-egg issue.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni
Cc: Star Zeng
Cc: Liming Gao
---
MdeModulePkg/
When UefiRuntimeLib links to a DXE driver, its constructor
still registers a Virtual Address Change event. The event callback
will get called when RT.SetVirtualAddressMap() is called from OS.
But when the driver is a DXE driver, the memory occupied by the
callback function might be zeroed or used b
Current DxeResetSystemLib depends on UefiRuntimeLib because it calls
EfiResetSystem() API exposed by UefiRuntimeLib.
Due to the commit XXX which reverts UefiRuntimeLib to only support
DXE_RUNTIME_DRIVER, removing UefiRuntimeLib dependency makes the
DxeResetSystemLib can be used by DXE drivers.
Co
Ruiyu Ni (3):
MdeModulePkg/DxeResetSystemLib: Avoid depending on UefiRuntimeLib
MdeModulePkg: Make sure ResetSystemRuntimeDxe uses ResetSystemLibNull
MdePkg/UefiRuntimeLib: Do not allow to be linked by DXE driver
MdeModulePkg/Library/DxeResetSystemLib/DxeResetSystemLib.c | 10 +-
55 matches
Mail list logo
