On Thu, 9 Apr 2015, Laszlo Ersek wrote:
> On 04/09/15 14:39, BALATON Zoltan wrote:
>> with http transfer commencing normally after this, while with OVMF and
>> syslinux.efi I get the following:
>>
>> TCP 1654 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1039 TSecr=0
>> TCP http > 1654 [S
On 9 April 2015 at 19:12, Roy Franz wrote:
> On Thu, Apr 9, 2015 at 4:28 AM, 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
On Thu, Apr 9, 2015 at 4:28 AM, 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 preven
On 04/08/15 22:51, Jordan Justen wrote:
> 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
В Wed, 08 Apr 2015 13:51:43 -0700
Jordan Justen пишет:
> 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
EFI_SHELL_PROTOCOL is installed onto the UEFI Shell’s handle, not your
application. If you have nested copies of the UEFI Shell you may have multiple
copies of the protocol.
You can find a copy from like this also:
Status = gBS->LocateProtocol(
&gEfiShellProtocolGuid,
NULL,
There is a single global instance of the EFI_SHELL_PROTOCOL. Use HandleProtocol.
Tim
From: tiger...@zhaoxin.com [mailto:tiger...@zhaoxin.com]
Sent: Wednesday, April 08, 2015 11:42 PM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] EFI_SHELL_PROTOCOL installed on every App's imagehandle?
Hi,
On Thu, Apr 09, 2015 at 12:19:37PM +0200, Laszlo Ersek wrote:
> However, the primary problem is that virtual addresses may not be
> available for dereferencing *at all*, until after SetVirtualAddressMap()
> returns.
>
> The caller of SetVirtualAddressMap() is not required by the UEFI spec to
> mak
On 04/09/15 14:39, BALATON Zoltan wrote:
> with http transfer commencing normally after this, while with OVMF and
> syslinux.efi I get the following:
>
> TCP 1654 > http [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=64 TSval=1039 TSecr=0
> TCP http > 1654 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=146
unsubscribe
在 Laszlo Ersek ，2015年4月9日 下午8:27写道：On 04/09/15 13:28, 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
Hello,
Bringing back this conversation to this list as it seems to be within the
edk2 code now.
I've found that syslinux.efi fails when trying to download a file from
http. This fails with the efi version but works with the same PXE/HTTP
server and QEMU client not using OVMF and syslinux.efi b
On 04/09/15 13:28, Ard Biesheuvel wrote:
> 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 ins
On 04/09/15 13:28, Ard Biesheuvel wrote:
> This updates ArmVirtualization.dsc.inc to use the MemoryInitPeiLib
> 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
On 04/09/15 13:28, 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
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.
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 ArmVirtualization.dsc.inc to use the MemoryInitPeiLib
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
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
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
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
That was my initial suggestion.
I am guessing Michael's change should now be in the Intel internal review
process to be integrated soon.
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: 07 April 2015 14:11
To: Olivier Martin; Kinney, Michael D
Cc: edk2-devel@lists.so
> On Apr 9, 2015, at 1:21 AM, Vladimir Onipchuk wrote:
>
> Hi All,
>
> I have problems with my PCI device driver.
>
> Driver works great,
What does that mean?
> but after loading and installing it from Option Rom, I can't get access to
> (can't read) my Memory chips, mapped to the Memory s
> On Apr 9, 2015, at 3:19 AM, Laszlo Ersek wrote:
>
> On 04/09/15 07:59, Li, Elvin wrote:
>> 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 O
On 04/09/15 07:59, Li, Elvin wrote:
> 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:0
On 04/09/15 10:34, Li, Elvin wrote:
> Hi Gabriel,
>
> I have checked in the fix at 17136. Could you try the fix?
>
> On my side, I also observed UEFI Ubuntu and Windows 8.1
> boot failure. After applying 17136 fix, the issue was gone. I also
> verified the REPORT_S
+ adding self
On Thu, Apr 9, 2015 at 3:19 PM, Baban Devkate
wrote:
> Let's take one more sample..
>
> 3) Offset = 0KB, Transfer Length = 4K * 513 blocks = 2MB + 4K
>
> Prp1 = 0K to 4KB
>
> Prp2 = pointer to a Prp List which is followed by another Prp List.
>
> The first Prp List contain
Hi,
I put debug print in InitializeUsbDebugHardware() and I got this log :
SecStartup
Mono Status Code PEIM Loaded
Install PPI: 1F4C6F90-B06B-48D8-A201-BAE5F1CD7D56
Install PPI: AB294A92-EAF5-4CF3-AB2B-2D4BED4DB63D
Register PPI Notify: F894643D-C449-42D1-8EA8-85BDD8C65BDE
GGC: 0x0210 GM
Let's take one more sample..
3) Offset = 0KB, Transfer Length = 4K * 513 blocks = 2MB + 4K
Prp1 = 0K to 4KB
Prp2 = pointer to a Prp List which is followed by another Prp List.
The first Prp List contains 511 entries to read data from offset 4KB to
offset 2MB. the last one entry is a po
On 04/09/15 02:15, Gabriel L. Somlo wrote:
> 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.
>
>
Hi Gabriel,
I have checked in the fix at 17136. Could you try the fix?
On my side, I also observed UEFI Ubuntu and Windows 8.1 boot
failure. After applying 17136 fix, the issue was gone. I also verified the
REPORT_STATUS_CODE could work to print status code message
Could you add the below debug message to the beginning of
InitializeUsbDebugHardware() for further debugging?
DEBUG (( EFI_D_INFO, "UsbDbg: Handle = %08x, Base = %08x, Offset = %08x\n",
Handle, Handle->UsbDebugPortMemoryBase, Handle->DebugPortOffset ));
Please stick to 0.78 version and set pc
Hi All,
I have problems with my PCI device driver.
Driver works great, but after loading and installing it from Option Rom, I
can't get access to (can't read) my Memory chips, mapped to the Memory space
through PCI BAR's.
At the same time, my write transactions executes successfully, but read
Hi, Devkate
I agree the first one is a bug and need to be fixed like your proposal.
For the second one, sorry I couldn’t catch your point.
When the requested buffer size is larger than 2M, it means we need multiple PRP
list pages.
For example, when block size is 4K, memory page size is 4K
1)
33 matches
Mail list logo
