On Mon, Mar 14, 2016 at 6:02 PM, Michael Brown wrote:
> On 14/03/16 14:44, shouldbe q931 wrote:
>>
>> BIOS booting errored with "console: command not found" so I added ||
>> to the end of the line, and it works for both G1 & G2 Hyper-V, and
>> BIOS PC
>>
>> As regards the NIC, I followed http://i
Ok... that makes sense. But still think SNP didn't work before the para driver
came along.
And I get about 3000-5000Mb/s on the SNP one... which I believe is work of your
magic, not Microsoft's great SNP?
-Original Message-
From: Michael Brown [mailto:mc...@ipxe.org]
Sent: den 14 mars
On 14/03/16 19:05, Andreas Hammarskjöld wrote:
I thought the SNP version was the updated driver? As iPXE didn't even boot Gen2
until you did the driver, i.e. snponly.efi did not work.
No. SNP is the fallback driver for UEFI iPXE, to be used if no native
driver is found. It's equivalent to t
I thought the SNP version was the updated driver? As iPXE didn't even boot Gen2
until you did the driver, i.e. snponly.efi did not work.
//A
-Original Message-
From: ipxe-devel-boun...@lists.ipxe.org
[mailto:ipxe-devel-boun...@lists.ipxe.org] On Behalf Of Michael Brown
Sent: den 14 mars
Ok, that's down to 235 lines total. I could strip it down more, but that would
mean stripping out documentation in EdidActive.h.
---
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/48#issuecomment-196474769___
ipxe-
Ok, I'm working on reducing this. What about the CRC check? Should I still
fail hard if it fails?
---
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/48#issuecomment-196463472___
ipxe-devel mailing list
ipxe-devel@
On 14/03/16 14:44, shouldbe q931 wrote:
BIOS booting errored with "console: command not found" so I added ||
to the end of the line, and it works for both G1 & G2 Hyper-V, and
BIOS PC
As regards the NIC, I followed http://ipxe.org/download and did "make
bin-x86_64-efi/ipxe.efi" did I miss somet
On Mon, Mar 14, 2016 at 3:48 PM, Ladi Prosek wrote:
> The goal here is to support booting from modern and transitional
> virtio-net devices using the new virtio 1.0 protocol. The code
> strives to comply with the virtio 1.0 spec and is heavily inspired
> by the Linux kernel implementation.
>
> Cha
This commit adds support for driving virtio 1.0 PCI devices.
In addition to various helpers, a number of vpm_ functions are
introduced to be used instead of their legacy vp_ counterparts
when accessing virtio 1.0 (aka modern) devices.
Signed-off-by: Ladi Prosek
---
src/drivers/bus/virtio-pci.c
This commit makes virtio-net support devices with VEN 0x1af4
and DEV 0x1041, which is how non-transitional (modern-only)
virtio-net devices are exposed on the PCI bus.
Transitional devices supporting both the old 0.9.5 and new 1.0
version of the virtio spec are driven using the new protocol.
Legac
Virtio 1.0 introduces new constants and data structures, common to
all devices as well as specific to virtio-net. This commit adds a
subset of these to be able to drive the virtio-net 1.0 network
device.
Signed-off-by: Ladi Prosek
---
src/drivers/net/virtio-net.h | 18 +
src/includ
The goal here is to support booting from modern and transitional
virtio-net devices using the new virtio 1.0 protocol. The code
strives to comply with the virtio 1.0 spec and is heavily inspired
by the Linux kernel implementation.
Changes from v1:
* removed the packed attribute from virtio struct
PCI devices may support more capabilities of the same type (for
example PCI_CAP_ID_VNDR) and there was no way to discover all of
them. This commit adds a new API pci_find_next_capability which
provides this functionality. It would typically be used like so:
for (pos = pci_find_capability(pci, PC
On Sun, Mar 13, 2016 at 11:18 PM, Michael Brown wrote:
> On 13/03/16 22:22, shouldbe q931 wrote:
> Try enabling CONSOLE_CMD (in config/general.h) and CONSOLE_FRAMEBUFFER (in
> config/console.h) and use a command such as "console -x 800 -y 600" to
> switch into a graphical framebuffer mode. That s
Looking at grub's code, it looks like it _might_ be reasonably sane to extract
the EDID when booting using a legacy BIOS. If this looks good, that will be
the next thing I look into.
---
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/48#issuecomment-1962991
Ok, here's a more elegant way of automatically choosing the resolution based on
the EDID returned by the monitor. This patch adds an "-a" option to the
console command that will automatically choose the best resolution.
edid.c and edid.h are originally from xrandr, but with some formatting chan
Can just confirm that this is an issue with Server 2012 and Windows 8 Hyper-V.
It goes away with Windows Server 2016 and Windows 10.
Workaround, do as Michael says, use console command to reset the UI.
-Original Message-
From: ipxe-devel-boun...@lists.ipxe.org
[mailto:ipxe-devel-boun...
17 matches
Mail list logo
