PcdRsa2048Sha256PublicKeyBuffer is referenced but not used in the
library, that makes me a little confusing.
Actually, the PublicKeyData should be from the caller of
AuthenticateFmpImage() as input parameter, for example
EdkiiSystemCapsuleLib.
This patch is to remove the PCD reference in this libr
DEBUG((
DEBUG_ERROR,
"ItemOffsetList[%d](0x%lx) < ItemOffsetList[%d](0x%x)\n",
Index,
ItemOffsetList[Index],
Index, // Should be Index - 1
ItemOffsetList[Index - 1]
));
Cc: Jiewen Yao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Z
Good clean up.
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star
> Zeng
> Sent: Monday, April 16, 2018 4:41 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Zhang, Chao B
> ; Zeng, Star
> Subject: [ed
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star
> Zeng
> Sent: Monday, April 16, 2018 4:42 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Zeng, Star
> Subject: [edk2] [PATCH] MdeModulePkg DxeCapsule
Hi, experts:
I have a question about S1 state. (ACPI Spec)
It seems current UEFI BIOS not support S1 state.
For example:
Current desktop PC's UEFI BIOS, usually not report to OS that it support S1
state.
Thanks
?
?
CONFIDENTIAL NOTE:
This
On Fri, Apr 13, 2018 at 11:32:35PM +, Kinney, Michael D wrote:
> Leif,
>
> I am curious why a Swap class/instances is not sufficient.
>
> Currently EDK II follows the UEFI/PI specs, which for
> all supported CPU architectures use little endian ABI.
> The BaseIoLib follows the endianness of th
On Fri, Apr 13, 2018 at 11:43:27PM +, Chris Co wrote:
> Mva address calculation should use the left-shifted current
> section index instead of the left-shifted table base address.
>
> Using the table base address here has the side-effect of potentially
> causing an access violation depending o
On 12 April 2018 at 20:47, Thomas Abraham wrote:
> From: Vishwanatha HG
>
> Add the initial support for ARM's System Guidance for Infrastructure
> (SGI) platforms. SGI-575 is the supported platform in this initial
> implementation and can be extented to include support for upcoming
> SGI platform
On 13 April 2018 at 21:26, Leif Lindholm wrote:
> Cc: Andrew Fish
> Cc: Laszlo Ersek
> Cc: Michael D Kinney
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Leif Lindholm
> ---
> Maintainers.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Maintainers.txt
On 16 April 2018 at 08:15, Marcin Wojtas wrote:
> As MvFvbDxe driver is ready, we can now link NvVarStoreFormattedLib
> into VariableRuntimeDxe via NULL class resolution for all
> Armada7k8k platforms.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas
> --
As reported by Kojima-san, the PHY reference clock value we use in our
ACPI and DT descriptions is out of sync with the hardware. Replace
125 MHz with 250 MHz throughout.
Cc: Masahisa Kojima
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
Kojima-san,
Pl
On 15 March 2018 at 20:07, Leif Lindholm wrote:
> On Thu, Mar 08, 2018 at 05:03:16PM +, Ard Biesheuvel wrote:
>> Add a ACPI PPTT table describing the cache topology of the Seattle SoC.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel
>
> Looks pla
Hello everyone,
I'm doing a research project on efi security. I would like to do source
code debugging of OVMF. I want to step through the OVMF source code, set
break points, et cetera, preferably with gdb. I want to debug the
overall boot process. Is that possible?
I understand I can start
On Mon, Apr 02, 2018 at 10:51:53AM +0800, Guo Heyi wrote:
> Hi Ray and Leif,
>
> Any comments?
>
>
> On Mon, Mar 26, 2018 at 05:03:10PM +0800, Guo Heyi wrote:
> > Thanks Ray.
> >
> > Does that mean we need build the dynamic command driver separately and
> > store it
> > in other media instead
fixed an incorrect import found in Yonghong's review.
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 24 +--
BaseTools/Source/Python/AutoGen/BuildEngine.py
Thanks, I will test mm command and let you know the result.
Regards,
Heyi
On Fri, Apr 13, 2018 at 09:19:53AM +0200, Ard Biesheuvel wrote:
> On 13 April 2018 at 04:05, Guo Heyi wrote:
> > Hi Ard,
> >
> > Any comments?
> >
>
> Apologies for the delay. I have been travelling and am behind on emai
Hi Supreeth,
On Fri, Apr 06, 2018 at 03:42:11PM +0100, Supreeth Venkatesh wrote:
> The Standalone MM environment runs in S-EL0 in AArch64 on ARM Standard
> Platforms and is initialised during the SEC phase. ARM Trusted firmware
> in EL3 is responsible for initialising the architectural context for
Leif,
I agree that the opposite use case is a BE CPU
needing a LE operation.
I think we only need a single lib class and lib
Instance that does the byte swap and we should
not use Le or Be in any of the names of the class,
instance, or APIs. Just "Swap".
The 4 cases
* LE CPU, LE I/O. Use Bas
On 16/04/18 15:10, Kinney, Michael D wrote:
I agree that the opposite use case is a BE CPU
needing a LE operation.
I think we only need a single lib class and lib
Instance that does the byte swap and we should
not use Le or Be in any of the names of the class,
instance, or APIs. Just "Swap".
Hi Supreeth,
On Fri, Apr 06, 2018 at 03:42:12PM +0100, Supreeth Venkatesh wrote:
> This patch implements a firmware volume library that can be used by the
> Standalone management mode core module to parse the firmware volume.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-of
Hi Supreeth,
On Fri, Apr 06, 2018 at 03:42:13PM +0100, Supreeth Venkatesh wrote:
> MM memory check library library implementation. This library consumes
> MM_ACCESS_PROTOCOL to get MMRAM information. In order to use this
> library instance, the platform should produce all MMRAM range via
> MM_ACCE
Hi Ard,
> Please confirm that the modification to ogma_config.h is correct.
Thank you very much for your update.
We confirmed and your modification is correct.
Regards,
Masahisa
On 16 April 2018 at 20:00, Ard Biesheuvel wrote:
> As reported by Kojima-san, the PHY reference clock value we use i
This page was recently added to the TianoCore wiki. Please let me know if this
is useful info:
https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB
Thanks ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@int
There's an outdated link on
https://github.com/tianocore/tianocore.github.io/wiki/How-to-run-OVMF :
the "OVMF downloads area" link points to
http://sourceforge.net/projects/edk2/files/OVMF, which was last updated
in 2014.
--
Rebecca Cran
___
edk2-devel
I recommend you try building MdePkg as a test under any Linux environment.
NT32Pkg is designed for Windows environments.
https://github.com/tianocore/tianocore.github.io/wiki/UDK2018-How-to-Build#how-to-build-linux-like-system
Thanks . br
---
Brian Richardson, Senior Technical Marketing Engine
Thanks, I have corrected the links. Please let me know if there are any
additional issues ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richard...@intel.com -- @intel_brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/
On 04/16/2018 08:26 AM, Richardson, Brian wrote:
>
https://github.com/tianocore/tianocore.github.io/wiki/How-to-debug-OVMF-with-QEMU-using-GDB
Also useful for this topic:
https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt
HTH,
Lee
__
Hi Johannes,
On 04/16/18 13:09, Johannes Swoboda wrote:
> How are you ovmf developer debugging it?
In general I add DEBUG statements, grep the tree for protocol / PPI
GUIDs, and use an editor with good ctags support.
Here's another thread that you might find useful:
http://edk2-devel.narkive.c
I use Andrew WIP's stuff often as well. Just put the GdbSyms.inf in your DSC
(not FDF) and build. My .gdbinit script looks like this:
set architecture i386:x86-64:intel
target remote localhost:1234
source DebugPkg/Scripts/gdb_uefi.py
reload-uefi -o
Build/OvmfX64/DEBUG_GCC5/X64/DebugPkg/GdbSyms
move the single used class from FvImage to Eot
delete the FvImage file
remove FvImage from makefile
Cc: Liming Gao
Cc: Yonghong Zhu
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jaben Carsey
---
BaseTools/Source/Python/Eot/Eot.py | 26 +-
BaseTools/Source/Python/
On 04/16/18 10:13, Laszlo Ersek wrote:
> Here's another thread that you might find useful:
>
> http://edk2-devel.narkive.com/6BRVus92/qestion-about-how-to-debug-ovmf-on-qemu
I should get my Phabricator wiki running again, which has a
nicely-formatted version of that - I haven't set it up again a
On 04/16/18 12:07, Leif Lindholm wrote:
> On Fri, Apr 13, 2018 at 11:32:35PM +, Kinney, Michael D wrote:
>> Leif,
>>
>> I am curious why a Swap class/instances is not sufficient.
>>
>> Currently EDK II follows the UEFI/PI specs, which for all supported
>> CPU architectures use little endian ABI
On 04/16/18 07:40, Ard Biesheuvel wrote:
> (+ Laszlo)
>
> On 16 April 2018 at 07:09, Marcin Wojtas wrote:
>> Recent changes in the EDK2 mainline resulted in breaking
>> of compilation and booting of Armada platforms.
>> This patch adjust the MvFvbDxe driver by:
>>
>> * installation of gEdkiiNvVa
On 04/16/18 07:09, Marcin Wojtas wrote:
> Recent changes in the EDK2 mainline resulted in breaking
> RTC functionality of Armada platforms.
>
> The RealTimeClockLib instance calls gDS->SetMemorySpaceAttributes()
> in the LibRtcInitialize() public function. This DXE service depends
> on the CPU Arc
Hi Leif,
> -Original Message-
> From: Leif Lindholm
> Sent: Monday, April 16, 2018 3:44 AM
> To: Chris Co
> Cc: edk2-devel@lists.01.org; Ard Biesheuvel
> Subject: Re: [PATCH] ArmPkg/ArmMmuLib ARM: fix Mva to use idx instead
> of table base
>
> On Fri, Apr 13, 2018 at 11:43:27PM +,
On 04/16/18 07:41, Ard Biesheuvel wrote:
> On 15 April 2018 at 23:15, Laszlo Ersek wrote:
>> PlatformInitializeConsole() (called by PlatformBootManagerBeforeConsole())
>> adds elements of "gPlatformConsole" to ConIn / ConOut / ErrOut (as
>> requested per element) if at boot at least one of ConIn a
On 04/16/18 20:25, Rebecca Cran wrote:
> On 04/16/18 10:13, Laszlo Ersek wrote:
>
>> Here's another thread that you might find useful:
>>
>> http://edk2-devel.narkive.com/6BRVus92/qestion-about-how-to-debug-ovmf-on-qemu
>
> I should get my Phabricator wiki running again, which has a
> nicely-form
On 04/16/18 16:34, Michael Brown wrote:
> On 16/04/18 15:10, Kinney, Michael D wrote:
>> I agree that the opposite use case is a BE CPU
>> needing a LE operation.
>>
>> I think we only need a single lib class and lib
>> Instance that does the byte swap and we should
>> not use Le or Be in any of th
On 16/04/18 21:42, Laszlo Ersek wrote:
On 04/16/18 16:34, Michael Brown wrote:
On 16/04/18 15:10, Kinney, Michael D wrote:
I think we only need a single lib class and lib
Instance that does the byte swap and we should
not use Le or Be in any of the names of the class,
instance, or APIs. Just "
Hi
I don't think this lib is generic, because it hardcode the physical address
bits.
PhysicalAddressBits = 36;
For X86 CPU, we get it from CPUID. :-)
As enhancement, we may put most common C-code logic (such as CopyMem, or memmap
calculation) to StandaloneMmPkg/MemLib, and only include the Phy
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 you
fixed the issue in EFI shell mm command.
Thanks and
BTW, there is actually a bug with ATU configuration which will cause IO access
failure, and we need to apply an additional patch (this patch is generated after
PCI host bridge patch series) as attached to fix this.
Regards,
Heyi
On Tue, Apr 17, 2018 at 09:20:44AM +0800, Guo Heyi wrote:
> Hi Ard,
On Mon, Apr 16, 2018 at 01:33:56PM +0100, Leif Lindholm wrote:
> On Mon, Apr 02, 2018 at 10:51:53AM +0800, Guo Heyi wrote:
> > Hi Ray and Leif,
> >
> > Any comments?
> >
> >
> > On Mon, Mar 26, 2018 at 05:03:10PM +0800, Guo Heyi wrote:
> > > Thanks Ray.
> > >
> > > Does that mean we need build
Within function FatQueueTask(), the traverse of FAT subtasks for
executing the disk read/write is not delete-safe.
For the below case:
FatDiskIo(): When non-blocking access, creates subtasks and creates
event (FatOnAccessComplete, NOTIFY level) when subtasks finish.
FatQueueTask(): Traverses the
Changelog:
v2:
* Avoid to use hardcoding value. Create boot options by functions.
Haojian Zhuang (1):
ArmPkg/PlatformBootManagerLib: load boot options from platform
ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 81 ++
.../PlatformBootManagerLib.inf
Platform drivers sets up the array of predefined boot options.
ArmPkg/PlatformBootManager converts the array to boot options.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Haojian Zhuang
---
ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c | 81 ++
Create 4 boot options on HiKey960 platform. They're "Boot from SD",
"Grub", "Android Boot" and "Android Fastboot".
Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Leif Lindholm
Cc: Ard Biesheuvel
Cc: Laszlo Ersek
Signed-off-by: Haojian Zhuang
---
Platform/Hisilicon/HiKey960/HiKey9
Hi Laszlo,
2018-04-16 21:41 GMT+02:00 Laszlo Ersek :
> On 04/16/18 07:40, Ard Biesheuvel wrote:
>> (+ Laszlo)
>>
>> On 16 April 2018 at 07:09, Marcin Wojtas wrote:
>>> Recent changes in the EDK2 mainline resulted in breaking
>>> of compilation and booting of Armada platforms.
>>> This patch adjus
On 17 April 2018 at 07:15, Marcin Wojtas wrote:
> Hi Laszlo,
>
> 2018-04-16 21:41 GMT+02:00 Laszlo Ersek :
>> On 04/16/18 07:40, Ard Biesheuvel wrote:
>>> (+ Laszlo)
>>>
>>> On 16 April 2018 at 07:09, Marcin Wojtas wrote:
Recent changes in the EDK2 mainline resulted in breaking
of compi
When we first ported EDK2 to KVM/arm, we implemented a workaround for
the quirky timer handling on the KVM side. This has been fixed in
Linux commit f120cd6533d2 ("KVM: arm/arm64: timer: Allow the timer to
control the active state") dated 23 June 2014, which was incorporated
into Linux release 4.3.
Hi Ard,
2018-04-17 7:32 GMT+02:00 Ard Biesheuvel :
> On 17 April 2018 at 07:15, Marcin Wojtas wrote:
>> Hi Laszlo,
>>
>> 2018-04-16 21:41 GMT+02:00 Laszlo Ersek :
>>> On 04/16/18 07:40, Ard Biesheuvel wrote:
(+ Laszlo)
On 16 April 2018 at 07:09, Marcin Wojtas wrote:
> Recent c
On 17 April 2018 at 08:04, Marcin Wojtas wrote:
> Hi Ard,
>
> 2018-04-17 7:32 GMT+02:00 Ard Biesheuvel :
>> On 17 April 2018 at 07:15, Marcin Wojtas wrote:
>>> Hi Laszlo,
>>>
>>> 2018-04-16 21:41 GMT+02:00 Laszlo Ersek :
On 04/16/18 07:40, Ard Biesheuvel wrote:
> (+ Laszlo)
>
> O
Hi Mike,
Do we want to support BE CPUs, ?
If yes then Last discussion of Lazlo is valid, where driver don't need to take
care of CPU endianness.
Regards
Udit
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Kinney, Michael D
> Sent: Monda
53 matches
Mail list logo
