Include the IPv6 drivers to enable the PXE6 support.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin
---
OvmfPkg/OvmfPkgIa32.dsc| 12 +++-
OvmfPkg/OvmfPkgIa32.fdf| 11 ++-
OvmfPkg/OvmfPkgIa32X64.dsc | 12 +++-
OvmfPkg/OvmfPkgIa32X64
Ok for me.
PS: you missed one line: Contributed-under: TianoCore Contribution Agreement 1.0
Reviewed-by: Feng Tian
-Original Message-
From: Ruffin, Chris
Sent: Thursday, December 18, 2014 02:08
To: edk2-devel@lists.sourceforge.net
Cc: Tian, Feng
Subject: [edk2] [PATCH v2] MdeModulePkg\
Hi guys,
I am studying the EnhancedFatDxe driver recently. I met a question when
looking into FatAccessCache() in DiskCache.c. As the "Routine Description"
says:
"2. Access of Data cache (CACHE_DATA):
The access data will be divided into UnderRun data, Aligned data and OverRun
data;
The UnderRun d
Hi, Gary
Thanks for your patch, I will follow our process to review and commit it.
Siyuan
-Original Message-
From: Gary Ching-Pang Lin [mailto:g...@suse.com]
Sent: Wednesday, December 17, 2014 5:24 PM
To: edk2-devel@lists.sourceforge.net
Cc: Fu, Siyuan
Subject: PXEv6 failed due to the t
The TranslateMmioOfwNodes() function recognizes the following OpenFirmware
device paths:
virtio-blk: /virtio-mmio@0a003c00/disk@0,0
virtio-scsi disk: /virtio-mmio@0a003a00/channel@0/disk@2,3
virtio-net NIC: /virtio-mmio@0a003e00/ethernet-phy@0
The new transla
The OpenFirmware device path nodes that QEMU generates for virtio-mmio
transports contain 64-bit hexadecimal values (16 nibbles) -- the base
addresses of the register blocks. In order to parse them soon,
ParseUnitAddressHexList() must parse UINT64 values.
Call sites need to be adapted, as expected
A number of tools depend on passing the kernel image, the initial ramdisk,
and the kernel command line to the guest on the QEMU command line (options
-kernel, -initrd, -append, respectively). At the moment, these QEMU
options work, but the guest kernel loaded this way is launched by a
minimal bina
Installing VenHw() device paths with this GUID, for the virtio-mmio
transports that we detect, enables other modules to recognize those
VenHw() nodes. (Note that the actual value doesn't change.)
In addition, to avoid reusing GUIDs in unrelated contexts, detach the
driver's FILE_GUID from its prev
and rebase OvmfPkg's PlatformBdsLib on the standalone library.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek
---
OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
| 3 +--
OvmfPkg/Library/QemuBootOrderLib/QemuBootOrder
Changes in v4:
- addressing review comments from Olivier & Peter (see per-patch notes)
- the fw_cfg MMIO selector & data registers are big endian now
- public branch:
https://github.com/lersek/edk2/commits/armvirt_fwcfg_efi_kernel_support_bz1128341_v4
Thanks
Laszlo
Laszlo Ersek (13):
ArmVirt
In PlatformBdsPolicyBehavior() we should follow the same pattern as in
OvmfPkg's: after the consoles are connected,
- connect all drivers and devices,
- enumerate all boot options,
- enter the Intel BDS FrontPage if the user presses a key different from
Enter.
We set the countdown to 3 seconds,
After reviewing OvmfPkg's use of its own QemuFwCfgLib instances, it is
clear that its only pre-DXE fw_cfg dependency concerns S3 support (the
QemuFwCfgS3Enabled() call in "PlatformPei/Platform.c").
For ARM guests, S3 is in the distant future, but we can see several
shorter term applications for fw
In the next patch(es) we'll customize the PlatformBdsLib instance used by
ArmVirtualizationQemu.dsc. Let's clone it first verbatim from
ArmPlatformPkg/Library/PlatformIntelBdsLib, changing only its FILE_GUID.
(Also, coding style errors like "missing space before open parenthesis"
and "missing spac
We have all the required pieces in place. Let's call
SetBootOrderFromQemu() in PlatformBdsPolicyBehavior().
We disable OFW-to-UEFI device path fragment translation for virtio-pci,
and enable it only virtio-mmio at this time.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: L
The default value of this PCD (in "IntelFrameworkModulePkg.dec")
identifies the "old shell" from EdkShellBinPkg. Our build includes the
"new" shell from ShellBinPkg/UefiShell/UefiShell.inf; let's specify the
FILE_GUID of that.
Otherwise, no boot option will be generated for the Shell application.
Qemu's firmware configuration interface for ARM consists of two MMIO
registers, a 16-bit selector, and a 64-bit data register that allows the
guest to transfer data with 8, 16, 32, and 64-bit wide accesses. Parse the
base address from the DTB, and expose the registers to the rest of DXE via
dynamic
Soon there will be more than one modules (in separate packages) that need
to have an understanding about the GUID used in the VenHw() device path
nodes that describe virtio-mmio transports. Define such a GUID explicitly.
Preserve the current value (which happens to be the FILE_GUID of
ArmPlatformP
In preparation for adding OpenFirmware-to-UEFI translation for "MMIO-like"
OFW device path fragments, let's turn the currently exclusive "PCI-like"
translation into "just one" of the possible translations.
- Rename TranslateOfwNodes() to TranslatePciOfwNodes(), because it is
tightly coupled to "
On 17 December 2014 at 19:50, Richard W.M. Jones wrote:
> I agree with Peter here, although -kernel w/o -initrd really is a
> developer option :-) Even qemu-sanity-check which is a program I
> wrote[1] that has probably the most minimal userspace that it's
> possible for Linux to have, still uses
On 2014-12-16 23:29:05, Tian, Feng wrote:
> Martin,
>
> Please review the latest patch again,
Once again, you did not supply a Contributed-under or Signed-off-by.
> in which partial read is supported.
I think Colin's version already supported this:
https://github.com/cfdrake/FileSystemPkg
stru
On 12/17/14 20:21, Peter Maydell wrote:
> On 17 December 2014 at 19:13, Laszlo Ersek wrote:
>> Lack of -initrd results in a zero-sized initrd file in the synthetic
>> filesystem, and a kernel command line parameter that references that
>> zero sized file ("initrd=initrd"), so the firmware code its
On 17 December 2014 at 19:13, Laszlo Ersek wrote:
> Lack of -initrd results in a zero-sized initrd file in the synthetic
> filesystem, and a kernel command line parameter that references that
> zero sized file ("initrd=initrd"), so the firmware code itself does not
> break.
>
> Second, AFAICT ther
On 12/17/14 18:44, Olivier Martin wrote:
> Hmm, it is possible I missed something in your patch.
> But am I right to understand this patch will bypass the BDS when the
> arguments '-kernel', '-initrd' and '-append' are added to qEmu?
Yes, definitely. That's an actual goal here, and it's how OVMF w
On 12/17/14 17:24, Olivier Martin wrote:
> Ok, I missed VIRTIO_TRANSPORT_DEVICE_PATH definition in VirtFdtDxe.
> Should this definition be moved into
> OvmfPkg/Include/Guid/VirtioMmioTransport.h?
> I checked if there were some protocols that were defining their special
> device path. And I found
>
MdeModulePkg\Bus\Ata\AtaAtapiPassThru: don't set PxSACT bit when issuing command
Setting a bit in the PxSACT register for a command in the command list
indicates to the controller that the command list slot contains a native queued
command (NCQ). This can cause problems with some controllers (one
Setting a bit in the PxSACT register for a command in the command list
indicates to the controller that the command list slot contains a
native queued command (NCQ). This can cause problems with some
controllers (one such controller is the Marvell 9128). Since NCQ
commands are not used, don't se
Hmm, it is possible I missed something in your patch.
But am I right to understand this patch will bypass the BDS when the
arguments '-kernel', '-initrd' and '-append' are added to qEmu?
I can see an issue if someone wants to reboot the 'virt' platform for
instance to try UEFI variable 'BootNext' a
Reviewed-By: Olivier Martin
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 11 December 2014 02:46
> To: edk2-devel@lists.sourceforge.net; drjo...@redhat.com;
> ard.biesheu...@linaro.org; peter.mayd...@linaro.org
> Subject: [edk2] [PATCH v3 11/13] ArmVirtualiz
Reviewed-By: Olivier Martin
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 11 December 2014 02:46
> To: edk2-devel@lists.sourceforge.net; drjo...@redhat.com;
> ard.biesheu...@linaro.org; peter.mayd...@linaro.org
> Subject: [edk2] [PATCH v3 12/13] ArmVirtualiz
Ok, I missed VIRTIO_TRANSPORT_DEVICE_PATH definition in VirtFdtDxe.
Should this definition be moved into
OvmfPkg/Include/Guid/VirtioMmioTransport.h?
I checked if there were some protocols that were defining their special
device path. And I found
MdePkg/Include/Protocol/DebugPort.h
If we do not mov
On 12/16/14 13:22, Olivier Martin wrote:
> I know you are not the author of the original patch, but our CI complains
> with the following coding style errors:
>
> ArmPlatformPkg/ArmVirtualizationPkg/Library/PlatformIntelBdsLib/IntelBdsPlat
> form.c:67 - missing space before open parenthesis - if
On 12/16/14 13:18, Olivier Martin wrote:
> Reviewed-By: Olivier Martin
Thanks. I had to rework the qemu patchset almost from the ground up, and
this patch needs to be updated too. (The fw_cfg registers will be big
endian. Long discussion on qemu-devel.)
Thanks!
Laszlo
>
>> -Original Messag
Hi,
I am trying to enable PXEv6 support in OvmfPkg. The new boot option showed
as expected after the drivers in NetworkPkg are included. However, the boot
image was never fetched after DHCPv6 server assigned an IPv6 address to the
client. I digged into NetworkPkg and found it failed to get the gat
33 matches
Mail list logo
