Hi, experts:
I have a question about UEFI Shell App:
1. UEFI App’s EntryPoint usually is as below:
UefiMain (
IN EFI_HANDLEImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
When launches App at Shell command prompt:
EFI_LOADED_IMAGE_PROTOCOL / EFI_SHELL_PARAMETERS_PROTOCO
Hi,
I follow UDK Debugger user manual version 1.91 and my PCDs settings are
matching with real because values for PCDs I see in procesor datasheet.
Also, with success it connected to the UDK debugger tool+WinDbg andafter
that firmware stoped and after in WinDbg I command go and than it stoped in
M
Andrew,
This is what my findings after tracing the code with UEFI
Ubuntu.
When we run into Runtime core driver, page table has been
provided by OS, and OS has enabled virtual address. Even though we see
0x10:3b3cfc91 address as RIP register in runtime core
В Wed, 8 Apr 2015 18:17:53 -0500
"Scott Duplichan" пишет:
> Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote:
>
> ]Sent: Wednesday, April 08, 2015 03:52 PM
> ]To: Andrei Borzenkov; edk2-devel@lists.sourceforge.net
> ]Subject: Re: [edk2] How to disable serial console in OVMF?
> ]
> ]On 2015
> On Apr 8, 2015, at 7:39 PM, Li, Elvin wrote:
>
> Andrew,
> Thanks for clarification. I am not clear one thing what you said:
> 3) But the Runtime driver does not convert it’s self. It is still
> running after all. The Runtime driver does take the event.
>
> What is the prob
Andrew,
Thanks for clarification. I am not clear one thing what you said:
3) But the Runtime driver does not convert it’s self. It is still
running after all. The Runtime driver does take the event.
What is the problem here for runtime driver? Will there be extra
convert
> On Apr 8, 2015, at 6:31 PM, Li, Elvin wrote:
>
> Gabriel,
> Could you try the attached the patch in your environment? I adjust the
> report status code to the end of RuntimeDriverSetVirtualAddressMap (), which
> makes sure all pointers are finished to convert.
> I am checking on
PFA patch file.
On Thu, Apr 9, 2015 at 7:06 AM, Baban Devkate
wrote:
> Hi,
>
> Commit Message
>
>
> MdeModulePkg: Fixed Pointer truncation and incorrect bytes passed for PRP
> list creation.
>
> There were two issues in NvmExpressPassthru.c(
> MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmE
Hi,
Commit Message
MdeModulePkg: Fixed Pointer truncation and incorrect bytes passed for PRP
list creation.
There were two issues in NvmExpressPassthru.c(
MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressPassthru.c)-
1.PRP list entries were zeroed out as "PrpListBase" was getting trunca
Gabriel,
Could you try the attached the patch in your environment? I adjust the
report status code to the end of RuntimeDriverSetVirtualAddressMap (), which
makes sure all pointers are finished to convert.
I am checking on my side as well.
Thanks
Elvin
-Original Message-
Sorry, correct a typo.
In mReportStatusCodeLibStatusCodeProtocol->ReportStatusCode (ReportDispatcher
()), you added Debug_message_2 at the beginning of ReportDispatcher (), BUT it
was NOT printed.
Thanks
Elvin Li
-Original Message-
From: Li, Elvin
Sent: Thursday, April 09, 2015 9:13
Hi,
From your mail, my understanding is that:
//you added Debug_message_1 and it could be printed
return mReportStatusCodeLibStatusCodeProtocol->ReportStatusCode
In mReportStatusCodeLibStatusCodeProtocol->ReportStatusCode
(ReportDispatcher ()), you added Debug_mes
Jordan:
Thanks for your suggestion. I will send those patches by git send mail.
Yes. I don't touch ARM platform DSC. I will further clean up
Vlv2TbltDevicePkg.
Thanks
Liming
-Original Message-
From: Justen, Jordan L
Sent: Thursday, April 09, 2015 5:21 AM
To: Gao, Liming; edk2-de
Hi,
Commit bd1957b4 (svn 17123) moved the REPORT_STATUS_CODE() call
to report signaling EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE from before
the for() loop signaling all events to *after* that block, to
match the verb tense used in the PI spec.
This has no visible impact on booting Linux, but trying to
On 2015-04-08 07:44:40, Scott Duplichan wrote:
> Bruce Cran [mailto:bruce.c...@gmail.com] wrote:
>
> ]Sent: Tuesday, April 07, 2015 01:19 PM
> ]To: edk2-devel@lists.sourceforge.net
> ]Subject: Re: [edk2] [Patch 0/16] CorebootModulePkg/CorebootPayloadPkg:
> Various improvements
> ]
> ]On 4/6/2015
Prince,
Didn't you ask me the 'next steps' for this patch, and I asked you to
send it to edk2-devel? So, why didn't you send it before committing
it?
I think we should send all patches to edk2-devel for review before
committing them. But, in the case of Maintainers.txt, this seems even
more impor
Jordan Justen [mailto:jordan.l.jus...@intel.com] wrote:
]Sent: Wednesday, April 08, 2015 03:52 PM
]To: Andrei Borzenkov; edk2-devel@lists.sourceforge.net
]Subject: Re: [edk2] How to disable serial console in OVMF?
]
]On 2015-04-08 13:05:21, Andrei Borzenkov wrote:
]> Running the following
]>
]> q
On 2015-04-07 18:13:52, Gao, Liming wrote:
> Yes. I have sent the patch to clean up OvmfPkg, Nt32Pkg and DuetPkg.
I think the issue Gabriel was seeing was that LzmaDecompress.h was not
added under MdeModulePkg/Include/Guid.
Since you kept the old library, there is no immediate need to update
the
On 2015-04-08 13:05:21, Andrei Borzenkov wrote:
> Running the following
>
> qemu-system-x86_64 -bios /usr/share/qemu/ovmf-x86_64.bin -serial stdio
>
> all input/output is replicated to both graphic and serial console. I
> need to test EFI program that works with serial port and it makes it
> rath
Running the following
qemu-system-x86_64 -bios /usr/share/qemu/ovmf-x86_64.bin -serial stdio
all input/output is replicated to both graphic and serial console. I
need to test EFI program that works with serial port and it makes it
rather hard. Is it possible to make OVMF to use "standard" graphic
Bruce Cran [mailto:bruce.c...@gmail.com] wrote:
]Sent: Tuesday, April 07, 2015 01:19 PM
]To: edk2-devel@lists.sourceforge.net
]Subject: Re: [edk2] [Patch 0/16] CorebootModulePkg/CorebootPayloadPkg: Various
improvements
]
]On 4/6/2015 7:06 AM, Scott Duplichan wrote:
]
]> Well maybe so. I did use g
On 8 April 2015 at 16:25, Laszlo Ersek wrote:
> On 04/08/15 09:11, Ard Biesheuvel wrote:
>> This updates ArmVirtualizationMemoryInitPeiLib so that the PEI memory
>> region, i.e., the region that is used both before and after the MMU
>> and caches are enabled, is invalidated by virtual address befo
On 04/08/15 09:11, Ard Biesheuvel wrote:
> This updates ArmVirtualizationMemoryInitPeiLib so that the PEI memory
> region, i.e., the region that is used both before and after the MMU
> and caches are enabled, is invalidated by virtual address before
> enabling the MMU.
>
> This prevents issues whe
Reviewed-By: Olivier Martin
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 April 2015 08:11
To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin
Cc: roy.fr...@linaro.org; leif.lindh...@linaro.org; Ard Biesheuvel
Subject: [PATCH v3 5/
Reviewed-By: Olivier Martin
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 April 2015 08:11
To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin
Cc: roy.fr...@linaro.org; leif.lindh...@linaro.org; Ard Biesheuvel
Subject: [PATCH v3 4/
Reviewed-By: Olivier Martin
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 April 2015 08:11
To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin
Cc: roy.fr...@linaro.org; leif.lindh...@linaro.org; Ard Biesheuvel
Subject: [PATCH v3 3/
On 04/08/15 13:43, Ard Biesheuvel wrote:
> On 8 April 2015 at 13:38, Laszlo Ersek wrote:
>> On 04/08/15 13:33, Ard Biesheuvel wrote:
>>> On 8 April 2015 at 13:13, Ard Biesheuvel wrote:
On 8 April 2015 at 13:12, Olivier Martin wrote:
> Is the reason why it does not work is dependency iss
On 8 April 2015 at 13:43, Ard Biesheuvel wrote:
> On 8 April 2015 at 13:38, Laszlo Ersek wrote:
>> On 04/08/15 13:33, Ard Biesheuvel wrote:
>>> On 8 April 2015 at 13:13, Ard Biesheuvel wrote:
On 8 April 2015 at 13:12, Olivier Martin wrote:
> Is the reason why it does not work is depend
On 8 April 2015 at 13:38, Laszlo Ersek wrote:
> On 04/08/15 13:33, Ard Biesheuvel wrote:
>> On 8 April 2015 at 13:13, Ard Biesheuvel wrote:
>>> On 8 April 2015 at 13:12, Olivier Martin wrote:
Is the reason why it does not work is dependency issue on other PEIM
library?
>>>
>>> MODULE_
On 04/08/15 13:33, Ard Biesheuvel wrote:
> On 8 April 2015 at 13:13, Ard Biesheuvel wrote:
>> On 8 April 2015 at 13:12, Olivier Martin wrote:
>>> Is the reason why it does not work is dependency issue on other PEIM
>>> library?
>>
>> MODULE_TYPE must be either 'SEC' or 'PEIM' and not both. If we
ArmPlatformPkg/PrePi/PeiUniCore.inf is a SEC to ensure the EDK2 BaseTools
patches the FV with its entrypoint:
https://github.com/tianocore/edk2/blob/master/BaseTools/Source/C/GenFv/GenFvInternalLib.c#L1650
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent:
On 8 April 2015 at 13:33, Ard Biesheuvel wrote:
> On 8 April 2015 at 13:13, Ard Biesheuvel wrote:
>> On 8 April 2015 at 13:12, Olivier Martin wrote:
>>> Is the reason why it does not work is dependency issue on other PEIM
>>> library?
>>
>> MODULE_TYPE must be either 'SEC' or 'PEIM' and not bot
On 8 April 2015 at 13:13, Ard Biesheuvel wrote:
> On 8 April 2015 at 13:12, Olivier Martin wrote:
>> Is the reason why it does not work is dependency issue on other PEIM library?
>
> MODULE_TYPE must be either 'SEC' or 'PEIM' and not both. If we are
> going to use the library in modules of both f
On 8 April 2015 at 13:09, Laszlo Ersek wrote:
> On 04/08/15 09:10, Ard Biesheuvel wrote:
>> This updates ArmVirtualizationQemu.dsc to use the MemoryInitPeilLib
>> implementation for virt targets. The only difference between that one
>> and the original one is that the original one removes memory f
On 8 April 2015 at 13:12, Olivier Martin wrote:
> Is the reason why it does not work is dependency issue on other PEIM library?
MODULE_TYPE must be either 'SEC' or 'PEIM' and not both. If we are
going to use the library in modules of both flavors, it would be
cleaner just to use BASE
> Yes, usi
Is the reason why it does not work is dependency issue on other PEIM library?
Yes, using 'BASE' might fix the issue.
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 April 2015 12:07
To: Olivier Martin
Cc: edk2-devel@lists.sourceforge.net; ler...@redhat.c
On 04/08/15 09:10, Ard Biesheuvel wrote:
> This updates ArmVirtualizationQemu.dsc to use the MemoryInitPeilLib
> implementation for virt targets. The only difference between that one
> and the original one is that the original one removes memory from the
> available list if it overlaps the FD regio
On 8 April 2015 at 13:03, Olivier Martin wrote:
> That's correct!
>
Hmm, that doesn't seem to work.
Would there be any problem with making it a 'BASE' module type?
And making it a general dependency in [LibraryClasses]' rather than
for SEC or PEIM specifically?
> -Original Message-
> Fr
That's correct!
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 April 2015 12:01
To: Olivier Martin
Cc: edk2-devel@lists.sourceforge.net; ler...@redhat.com; roy.fr...@linaro.org;
leif.lindh...@linaro.org
Subject: Re: [PATCH v3 1/5] ArmPlatformPkg: do no
On 8 April 2015 at 12:58, Olivier Martin wrote:
> I have just had a look to understand the reason. And here is the reason...
> ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf is a PEIM module (MODULE_TYPE
> = PEIM); while all the declarations you quoted before are for the SEC module:
>
> [Librar
On 04/08/15 12:54, Ard Biesheuvel wrote:
> On 8 April 2015 at 12:46, Olivier Martin wrote:
>> This patch breaks the following builds:
>> - ArmPlatformPkg/ArmPlatformPkg.dsc
>> - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-A9x2.dsc
>> - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc
>>
I have just had a look to understand the reason. And here is the reason...
ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.inf is a PEIM module (MODULE_TYPE =
PEIM); while all the declarations you quoted before are for the SEC module:
[LibraryClasses.common.SEC]
MemoryInitPeiLib|ArmPlatformPkg/Mem
On 04/08/15 12:46, Olivier Martin wrote:
> This patch breaks the following builds:
> - ArmPlatformPkg/ArmPlatformPkg.dsc
> - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-A9x2.dsc
> - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc
> - (...)
>
> Always with the same issue:
> ArmPlatformP
On 8 April 2015 at 12:46, Olivier Martin wrote:
> This patch breaks the following builds:
> - ArmPlatformPkg/ArmPlatformPkg.dsc
> - ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-A9x2.dsc
> - ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc
> - (...)
>
> Always with the same issue:
> ArmPl
Reviewed-by: Olivier Martin
-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
Sent: 08 April 2015 08:11
To: edk2-devel@lists.sourceforge.net; ler...@redhat.com; Olivier Martin
Cc: roy.fr...@linaro.org; leif.lindh...@linaro.org; Ard Biesheuvel
Subject: [PATCH v3 2/
This patch breaks the following builds:
- ArmPlatformPkg/ArmPlatformPkg.dsc
- ArmPlatformPkg/ArmRealViewEbPkg/ArmRealViewEb-RTSM-A9x2.dsc
- ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA9x4.dsc
- (...)
Always with the same issue:
ArmPlatformPkg/ArmPlatformPkg.dsc(...): error 4000: Instance of libra
Hmm, moving the Ethernet stack initialization into the driver entrypoint is a
bit dirty but it looks to be the best solution so far. Thanks Andrew for the
suggestion.
Just to give more information on what I am trying to achieve with
EmbeddedPkg/Drivers/FdtPlatformDxe. I am trying to do the same
Correct my words here:
The support of source level debug through usb at MinnowMax wasn’t formally
claimed.
Thanks
Feng
From: Tian, Feng
Sent: Wednesday, April 08, 2015 16:24
To: edk2-devel@lists.sourceforge.net; elinux-minnowbo...@lists.elinux.org
Cc: He, Tim; Wei, David; Lin, Jie; Tian, Feng
S
Hi,
The support of source level debug through usb wasn’t formally claimed, which
means platform integrator needs extra work to enable this feature rather than
simply switching to source level debug usb instance.
If you are interested in this, you can do such work by yourself.
From the log you
MemoryInitPeim short-circuits its MemoryInitPeiLib dependency by including
the .c file directly. This prevents us from having a special implementation
for ArmVirtualizationPkg that performs additional cache maintenance before
enabling the MMU. So instead, make it depend on the library class.
Contr
Hello all,
This series implements explicit cache maintenance for the QEMU/KVM and
Xen build targets. This is necessary as, under virtualization, memory
regions that are manipulated with the MMU and caches off may be shadowed
by clean cachelines in system caches or lower level caches on other CPUs.
In order to prevent memory corruption issues caused by the fact that,
under virtualization, the guest is incoherent with the hypervisor's view
of memory until it enables its caches and MMU, this patch reshuffles the
init sequence so that the Xen shared memory regions are not touched
before the cach
This updates ArmVirtualizationMemoryInitPeiLib so that the PEI memory
region, i.e., the region that is used both before and after the MMU
and caches are enabled, is invalidated by virtual address before
enabling the MMU.
This prevents issues where data we modified with the caches and MMU
off may b
This removes the range size threshold for virtual address based cache
maintenance instructions that operate on VA ranges to be 'promoted' to
use set/way instructions.
Doing so is unsafe: set/way operations are fundamentally different
from VA operations, and really only suitable for cleaning or inv
This updates ArmVirtualizationQemu.dsc to use the MemoryInitPeilLib
implementation for virt targets. The only difference between that one
and the original one is that the original one removes memory from the
available list if it overlaps the FD region (which may be the case when
shadowing NOR flash
55 matches
Mail list logo
