Michael Tautschnig | 29 May 17:00 2016
Picon

Is the definition of undi_loader as both procedure and object intended?

Dear iPXE developers,

I have noticed that undi_loader is defined both as a struct as well as a
procedure:

src/arch/i386/drivers/net/undiload.c has
static struct s_UNDI_LOADER __bss16 ( undi_loader );

while src/arch/i386/include/pxe.h (also include from the above file) has:
extern PXENV_EXIT_t undi_loader ( struct s_UNDI_LOADER *undi_loader );

Presumably the compiler's name mangling (renaming the latter to, e.g.,
_undi_loader) will ensure this works in practice. But is that the intended set
up? I would assume the following patch would avoid relying on such compiler
internals:

--- a/src/arch/i386/drivers/net/undiload.c
+++ b/src/arch/i386/drivers/net/undiload.c
 <at>  <at>  -45,8 +45,8  <at>  <at>  FILE_LICENCE ( GPL2_OR_LATER );
 #define EUNDILOAD( status ) EPLATFORM ( EINFO_EUNDILOAD, status )

 /** Parameter block for calling UNDI loader */
-static struct s_UNDI_LOADER __bss16 ( undi_loader );
-#define undi_loader __use_data16 ( undi_loader )
+static struct s_UNDI_LOADER __bss16 ( undi_loader_p );
+#define undi_loader __use_data16 ( undi_loader_p )

 /** UNDI loader entry point */
 static SEGOFF16_t __bss16 ( undi_loader_entry );

(Continue reading)

Michael Kuron | 28 May 16:49 2016

[ipxe/ipxe] Apple (#54)

When booting iPXE over the network on a Mac via the method described at http://forum.ipxe.org/showthread.php?tid=7323&pid=11253#pid11253 (wrapping snponly.efi into a .nbi bundle and serving that via Apple's NetBoot/NetInstall service), one can chainload Linux kernels and EFI binaries just fine.
However, one cannot chainload Mac OS X 10.11 and higher because Apple does not use standard PXE EFI protocols to obtain the DHCP packet from EFI. For Mac OS X 10.10 and lower, this was no problem as the kernel contained a DHCP client (see bsd/kern/netboot.c, line 646) that was used when the DHCP packet could not be obtained from EFI. Mac OS X 10.11 removes that DHCP client and panics if no DHCP packet can be obtained from EFI.

This pull request adds support for the Apple NetBoot EFI protocol to iPXE so that iPXE can pass on its DHCP packet to the operating system.
With this patch applied, Mac OS X 10.11 and higher can be chainloaded like this:

set nbiname OSX-10111.nbi set serverip ${next-server} set tftpboot tftp://${serverip} set netbootsp0 /Library/NetBoot/NetBootSP0 set root-path nfs:${serverip}:${netbootsp0}:${nbiname}/NetInstall.dmg initrd --name x86_64\kernelcache ${tftpboot}/NetBoot/NetBootSP0/${nbiname}/i386/x86_64/kernelcache kernel ${tftpboot}/NetBoot/NetBootSP0/${nbiname}/i386/booter imgargs booter -v rp=${root-path} boot

Without this patch applied, the above only worked on Mac OS X 10.10.5 and lower.

Acknowledgements:
The details about the Apple NetBoot EFI protocol came from https://github.com/Piker-Alpha/macosxbootloader/blob/master/sdk/include/Protocol/AppleNetBoot/AppleNetBoot.h as Apple has not, to my knowledge, published a specification about their EFI protocols.

You can view, comment on, or merge this pull request online at:

  https://github.com/ipxe/ipxe/pull/54

Commit Summary

  • Apple NetBoot protocol
  • Reimplement Apple NetBoot protocol
  • Remove testing code
  • Merge remote-tracking branch 'origin/master' into apple

File Changes

Patch Links:


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

<div>
<p>When booting iPXE over the network on a Mac via the method described at <a href="http://forum.ipxe.org/showthread.php?tid=7323&amp;pid=11253#pid11253">http://forum.ipxe.org/showthread.php?tid=7323&amp;pid=11253#pid11253</a> (wrapping snponly.efi into a .nbi bundle and serving that via Apple's NetBoot/NetInstall service), one can chainload Linux kernels and EFI binaries just fine.<br>
However, one cannot chainload Mac OS X 10.11 and higher because Apple does not use standard PXE EFI protocols to obtain the DHCP packet from EFI. For Mac OS X 10.10 and lower, this was no problem as the kernel contained a DHCP client (see <a href="http://opensource.apple.com//source/xnu/xnu-2782.40.9/bsd/kern/netboot.c">bsd/kern/netboot.c</a>, line 646) that was used when the DHCP packet could not be obtained from EFI. Mac OS X 10.11 removes that DHCP client and panics if no DHCP packet can be obtained from EFI.</p>

<p>This pull request adds support for the Apple NetBoot EFI protocol to iPXE so that iPXE can pass on its DHCP packet to the operating system.<br>
With this patch applied, Mac OS X 10.11 and higher can be chainloaded like this:</p>

set nbiname OSX-10111.nbi
set serverip ${next-server}
set tftpboot tftp://${serverip}
set netbootsp0 /Library/NetBoot/NetBootSP0
set root-path nfs:${serverip}:${netbootsp0}:${nbiname}/NetInstall.dmg
initrd --name x86_64\kernelcache ${tftpboot}/NetBoot/NetBootSP0/${nbiname}/i386/x86_64/kernelcache
kernel ${tftpboot}/NetBoot/NetBootSP0/${nbiname}/i386/booter
imgargs booter -v rp=${root-path}
boot

<p>Without this patch applied, the above only worked on Mac OS X 10.10.5 and lower.</p>

<p>Acknowledgements:<br>
The details about the Apple NetBoot EFI protocol came from <a href="https://github.com/Piker-Alpha/macosxbootloader/blob/master/sdk/include/Protocol/AppleNetBoot/AppleNetBoot.h">https://github.com/Piker-Alpha/macosxbootloader/blob/master/sdk/include/Protocol/AppleNetBoot/AppleNetBoot.h</a> as Apple has not, to my knowledge, published a specification about their EFI protocols.</p>

<h4>You can view, comment on, or merge this pull request online at:</h4>
<p>&nbsp;&nbsp;<a href="https://github.com/ipxe/ipxe/pull/54">https://github.com/ipxe/ipxe/pull/54</a></p>

<h4>Commit Summary</h4>
<ul>
<li>Apple NetBoot protocol</li>
  <li>Reimplement Apple NetBoot protocol</li>
  <li>Remove testing code</li>
  <li>Merge remote-tracking branch 'origin/master' into apple</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/54/files#diff-0">src/image/efi_image.c</a>
    (8)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/54/files#diff-1">src/include/ipxe/applenetboot.h</a>
    (10)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/54/files#diff-2">src/include/ipxe/efi/Protocol/AppleNetBoot.h</a>
    (67)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/54/files#diff-3">src/interface/efi/efi_applenetboot.c</a>
    (68)
  </li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href="https://github.com/ipxe/ipxe/pull/54.patch">https://github.com/ipxe/ipxe/pull/54.patch</a></li>
  <li><a href="https://github.com/ipxe/ipxe/pull/54.diff">https://github.com/ipxe/ipxe/pull/54.diff</a></li>
</ul>
<p>&mdash;<br>You are receiving this because you are subscribed to this thread.<br>Reply to this email directly, <a href="https://github.com/ipxe/ipxe/pull/54">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe/AArTVEoDxDbeGIMxa1uZD45kmRBIPIaMks5qGFXrgaJpZM4IpFx9">mute the thread</a>.</p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  </div>
</div>
</div>
binoy deka | 27 May 14:49 2016
Picon

ipxe installation error

Hi ,

I have been trying to use ipxe to boot, install esxi on server. However there is some or other error which I am facing. Please find the steps below which I am following and let me know what's wrong that I am doing:

1. Open server, give the path for ipxe.iso which is downloaded in my local.
2. Reboot the server ilo
3. Starts booting, and in between the process prompts me to enter Ctrl+B to goto ipxe menu
4. I pressed. Out of all NETs, net1 is open and active for me
5. I configured ip, netmask, gateway, dns respectively by "set net1/ip x.x.x.x" command
6. typed dhcp
7. chain http://boot.ipxe.org/demo/boot.php, it throws connection timedout
8. I copied the boot.php to our project's http location and the timedout issue is resolved
9. BUT, there is error related to "vmlinuz-3.16.0-rc4" which is part of script.

Please let me know what is that I am doing wrong and how can this be resolved

Thanks,
Binoy
<div><div dir="ltr">Hi ,<div><br></div>
<div>I have been trying to use ipxe to boot, install esxi on server. However there is some or other error which I am facing. Please find the steps below which I am following and let me know what's wrong that I am doing:</div>
<div><br></div>
<div>1. Open server, give the path for ipxe.iso which is downloaded in my local.</div>
<div>2. Reboot the server ilo</div>
<div>3. Starts booting, and in between the process prompts me to enter Ctrl+B to goto ipxe menu</div>
<div>4. I pressed. Out of all NETs, net1 is open and active for me</div>
<div>5. I configured ip, netmask, gateway, dns respectively by "set net1/ip x.x.x.x" command</div>
<div>6. typed dhcp<br>7.&nbsp;chain <a href="http://boot.ipxe.org/demo/boot.php">http://boot.ipxe.org/demo/boot.php</a>, it throws connection timedout</div>
<div>8. I copied the boot.php to our project's http location and the timedout issue is resolved<br>9. BUT, there is error related to "<span>vmlinuz-3.16.0-rc4" which is part of script.</span>
</div>
<div><span><br></span></div>
<div><span>Please let me know what is that I am doing wrong and how can this be resolved</span></div>
<div><span><br></span></div>
<div><span>Thanks,</span></div>
<div><span>Binoy</span></div>
</div></div>
Vinson Lee | 27 May 21:05 2016

[PATCH] [build] Remove nested 'my' declaration.

Fix build error with perl >= 5.23.2.

Can't redeclare "my" in "my" at ./util/parserom.pl line 160, near ", "

Fixes: 68d8a44469ecd ("[build] Rewrite parserom.pl to support multiple source files")
Signed-off-by: Vinson Lee <vlee@...>
---
 src/util/parserom.pl | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/util/parserom.pl b/src/util/parserom.pl
index 28df606..5a849a5 100755
--- a/src/util/parserom.pl
+++ b/src/util/parserom.pl
 <at>  <at>  -157,7 +157,7  <at>  <at>  sub process_isa_rom {

 # Output Makefile rules for the specified ROM declarations
 sub print_make_rules {
-    my ( $state, my $image, my $desc, my $vendor, my $device, my $dup ) =  <at> _;
+    my ( $state, $image, $desc, $vendor, $device, $dup ) =  <at> _;
     unless ( $state->{'is_header_printed'} ) {
         print "# NIC\t\n";
         print "# NIC\tfamily\t$state->{family}\n";
--

-- 
2.8.3

Ladi Prosek | 25 May 09:12 2016
Picon

ipxe-virtio subtree announcement

Hi all,

Just a quick announcement that there's a new iPXE subtree at
https://github.com/ladipro/ipxe-virtio focused on Virtio networking
and related areas. The plan is to be sending regular pull requests to
ipxe/ipxe with reviewed patches. Any and all Virtio contributions are
welcome and will be responded to in a timely manner (please cc me).

Thanks,
Ladi
Chris Foran | 17 May 18:44 2016

Loader can only do ELF or bz2

Hi folks,

 

We are trying to get iPXE to be loaded by Intel’s ABL (Automotive Boot Loader).  ABL does some of the things a BIOS would do, but is highly stripped down and doesn’t provide a user interface.  It is designed to load either an ELF or bz2 (Linux kernel) image.  Does anyone have any advice for producing an iPXE image in ELF? 

 

Thanks!

 

-Chris Foran

<div>
<div class="WordSection1">
<p class="MsoNormal">Hi folks,<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">We are trying to get iPXE to be loaded by Intel&rsquo;s ABL (Automotive Boot Loader).&nbsp; ABL does some of the things a BIOS would do, but is highly stripped down and doesn&rsquo;t provide a user interface.&nbsp; It is designed to load either an ELF or bz2
 (Linux kernel) image. &nbsp;Does anyone have any advice for producing an iPXE image in ELF?&nbsp;
<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">Thanks!<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal">-Chris Foran<p></p></p>
</div>
</div>
Christian Hesse | 9 May 08:22 2016

[ipxe/ipxe] ath9k: fix buffer overrun for ar9287 (#53)

This backport is from linux kernel upstream commit:

commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5
Author: Arnd Bergmann arnd-r2nGTMty4D4@public.gmane.org
Date: Mon Mar 14 15:18:36 2016 +0100

ath9k: fix buffer overrun for ar9287

Code that was added back in 2.6.38 has an obvious overflow
when accessing a static array, and at the time it was added
only a code comment was put in front of it as a reminder
to have it reviewed properly.

This has not happened, but gcc-6 now points to the specific
overflow:

drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
~~~~~~~~~~~~~~~~~~~~~~~^

It turns out that the correct array length exists in the local
'intercepts' variable of this function, so we can just use that
instead of hardcoding '4', so this patch changes all three
instances to use that variable. The other two instances were
already correct, but it's more consistent this way.

Signed-off-by: Arnd Bergmann arnd-r2nGTMty4D4@public.gmane.org
Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
Signed-off-by: David S. Miller davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org

You can view, comment on, or merge this pull request online at:

  https://github.com/ipxe/ipxe/pull/53

Commit Summary

  • ath9k: fix buffer overrun for ar9287

File Changes

Patch Links:


You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

<div>
<p>This backport is from linux kernel upstream commit:</p>

<blockquote>
<p>commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5<br>
Author: Arnd Bergmann <a href="mailto:arnd@...">arnd@...</a><br>
Date:   Mon Mar 14 15:18:36 2016 +0100</p>

<p>ath9k: fix buffer overrun for ar9287</p>

<p>Code that was added back in 2.6.38 has an obvious overflow<br>
when accessing a static array, and at the time it was added<br>
only a code comment was put in front of it as a reminder<br>
to have it reviewed properly.</p>

<p>This has not happened, but gcc-6 now points to the specific<br>
overflow:</p>

<p>drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':<br>
drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]<br>
     maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];<br>
                   ~~~~~~~~~~~~~~~~~~~~~~~^</p>

<p>It turns out that the correct array length exists in the local<br>
'intercepts' variable of this function, so we can just use that<br>
instead of hardcoding '4', so this patch changes all three<br>
instances to use that variable. The other two instances were<br>
already correct, but it's more consistent this way.</p>

<p>Signed-off-by: Arnd Bergmann <a href="mailto:arnd@...">arnd@...</a><br>
Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")<br>
Signed-off-by: David S. Miller <a href="mailto:davem@...">davem@...</a></p>
</blockquote>

<h4>You can view, comment on, or merge this pull request online at:</h4>
<p>&nbsp;&nbsp;<a href="https://github.com/ipxe/ipxe/pull/53">https://github.com/ipxe/ipxe/pull/53</a></p>

<h4>Commit Summary</h4>
<ul>
<li>ath9k: fix buffer overrun for ar9287</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/53/files#diff-0">src/drivers/net/ath/ath9k/ath9k_eeprom.c</a>
    (7)
  </li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href="https://github.com/ipxe/ipxe/pull/53.patch">https://github.com/ipxe/ipxe/pull/53.patch</a></li>
  <li><a href="https://github.com/ipxe/ipxe/pull/53.diff">https://github.com/ipxe/ipxe/pull/53.diff</a></li>
</ul>
<p>&mdash;<br>You are receiving this because you are subscribed to this thread.<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/53">view it on GitHub</a></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  </div>
</div>
</div>
Christian Hesse | 7 May 21:20 2016
Picon
Gravatar

[PATCH 1/1] ath9k: fix buffer overrun for ar9287

From: Christian Hesse <mail@...>

This backport is from linux kernel upstream commit:

> commit 83d6f1f15f8cce844b0a131cbc63e444620e48b5
> Author: Arnd Bergmann <arnd@...>
> Date:   Mon Mar 14 15:18:36 2016 +0100
>
> ath9k: fix buffer overrun for ar9287
>
> Code that was added back in 2.6.38 has an obvious overflow
> when accessing a static array, and at the time it was added
> only a code comment was put in front of it as a reminder
> to have it reviewed properly.
>
> This has not happened, but gcc-6 now points to the specific
> overflow:
>
> drivers/net/wireless/ath/ath9k/eeprom.c: In function 'ath9k_hw_get_gain_boundaries_pdadcs':
> drivers/net/wireless/ath/ath9k/eeprom.c:483:44: error: array subscript is above array bounds [-Werror=array-bounds]
>      maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
>                    ~~~~~~~~~~~~~~~~~~~~~~~~~^~~
>
> It turns out that the correct array length exists in the local
> 'intercepts' variable of this function, so we can just use that
> instead of hardcoding '4', so this patch changes all three
> instances to use that variable. The other two instances were
> already correct, but it's more consistent this way.
>
> Signed-off-by: Arnd Bergmann <arnd@...>
> Fixes: 940cd2c12ebf ("ath9k_hw: merge the ar9287 version of ath9k_hw_get_gain_boundaries_pdadcs")
> Signed-off-by: David S. Miller <davem@...>

Signed-off-by: Christian Hesse <mail@...>
---
 src/drivers/net/ath/ath9k/ath9k_eeprom.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/drivers/net/ath/ath9k/ath9k_eeprom.c b/src/drivers/net/ath/ath9k/ath9k_eeprom.c
index f552aca..a204237 100644
--- a/src/drivers/net/ath/ath9k/ath9k_eeprom.c
+++ b/src/drivers/net/ath/ath9k/ath9k_eeprom.c
 <at>  <at>  -368,10 +368,9  <at>  <at>  void ath9k_hw_get_gain_boundaries_pdadcs(struct ath_hw *ah,

 	if (match) {
 		if (AR_SREV_9287(ah)) {
-			/* FIXME: array overrun? */
 			for (i = 0; i < numXpdGains; i++) {
 				minPwrT4[i] = data_9287[idxL].pwrPdg[i][0];
-				maxPwrT4[i] = data_9287[idxL].pwrPdg[i][4];
+				maxPwrT4[i] = data_9287[idxL].pwrPdg[i][intercepts - 1];
 				ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
 						data_9287[idxL].pwrPdg[i],
 						data_9287[idxL].vpdPdg[i],
 <at>  <at>  -381,7 +380,7  <at>  <at>  void ath9k_hw_get_gain_boundaries_pdadcs(struct ath_hw *ah,
 		} else if (eeprom_4k) {
 			for (i = 0; i < numXpdGains; i++) {
 				minPwrT4[i] = data_4k[idxL].pwrPdg[i][0];
-				maxPwrT4[i] = data_4k[idxL].pwrPdg[i][4];
+				maxPwrT4[i] = data_4k[idxL].pwrPdg[i][intercepts - 1];
 				ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
 						data_4k[idxL].pwrPdg[i],
 						data_4k[idxL].vpdPdg[i],
 <at>  <at>  -391,7 +390,7  <at>  <at>  void ath9k_hw_get_gain_boundaries_pdadcs(struct ath_hw *ah,
 		} else {
 			for (i = 0; i < numXpdGains; i++) {
 				minPwrT4[i] = data_def[idxL].pwrPdg[i][0];
-				maxPwrT4[i] = data_def[idxL].pwrPdg[i][4];
+				maxPwrT4[i] = data_def[idxL].pwrPdg[i][intercepts - 1];
 				ath9k_hw_fill_vpd_table(minPwrT4[i], maxPwrT4[i],
 						data_def[idxL].pwrPdg[i],
 						data_def[idxL].vpdPdg[i],
--

-- 
2.8.2

Ladi Prosek | 2 May 17:41 2016
Picon

[PATCH v3 0/3] [virtio] Enable and restore PCI device correctly

This series is a follow-up to our virtio 1.0 discussion. The
first patch adds two new functions as suggested by Michael and
the third one makes virtio-net call them.

Changes v1->v2:

* fixed comment 'busmaster' -> 'bus master'
* renamed functions 'enable_pci_device' -> 'pci_enable_device',
  'disable_pci_device' -> 'pci_restore_device'
* pci_enable_device takes the desired latency timer value in argument,
  special value of 0 makes it not touch the register
* tweaked debug output of pci_enable_device: 'device not enabled by
  BIOS!' -> 'device not fully enabled by BIOS!'
* new debug output in pci_restore_device: 'restoring PCI command to ..'
* new helper function for region type testing: virtnet_uses_region_type
* added a patch to renumber virtio_pci_region flags so they make more
  sense; this also fixes a bug where virtio_pci_unmap_capability could
  call iounmap on an uninitialized region
* adjusted commit messages

Changes v2->v3:

* removed the unused VIRTIO_PCI_REGION_NONE macro

Thanks!
Ladi

 src/drivers/bus/pci.c         | 58 +++++++++++++++++++++++++++++++++++--------
 src/drivers/bus/virtio-pci.c  | 10 ++++++++
 src/drivers/net/virtio-net.c  | 41 ++++++++++++++++++++++++++++--
 src/include/ipxe/pci.h        |  3 +++
 src/include/ipxe/virtio-pci.h |  6 ++---
 5 files changed, 103 insertions(+), 15 deletions(-)

Ladi Prosek | 2 May 15:11 2016
Picon

[PATCH v2 0/3] [virtio] Enable and restore PCI device correctly

This series is a follow-up to our virtio 1.0 discussion. The
first patch adds two new functions as suggested by Michael and
the third one makes virtio-net call them.

Changes v1->v2:

* fixed comment 'busmaster' -> 'bus master'
* renamed functions 'enable_pci_device' -> 'pci_enable_device',
  'disable_pci_device' -> 'pci_restore_device'
* pci_enable_device takes the desired latency timer value in argument,
  special value of 0 makes it not touch the register
* tweaked debug output of pci_enable_device: 'device not enabled by
  BIOS!' -> 'device not fully enabled by BIOS!'
* new debug output in pci_restore_device: 'restoring PCI command to ..'
* new helper function for region type testing: virtnet_uses_region_type
* added a patch to renumber virtio_pci_region flags so they make more
  sense; this also fixes a bug where virtio_pci_unmap_capability could
  call iounmap on an uninitialized region
* adjusted commit messages

I believe that I addressed all v1 comments, please let me know otherwise.

Thanks!
Ladi

 src/drivers/bus/pci.c         | 58 +++++++++++++++++++++++++++++++++++--------
 src/drivers/bus/virtio-pci.c  | 10 ++++++++
 src/drivers/net/virtio-net.c  | 41 ++++++++++++++++++++++++++++--
 src/include/ipxe/pci.h        |  3 +++
 src/include/ipxe/virtio-pci.h |  8 +++---
 5 files changed, 105 insertions(+), 15 deletions(-)

Mohammad Oslani | 30 Apr 14:54 2016

Windows loading issue

Hello,

We are trying to load windows over ipxe and followed over this page :
http://ipxe.org/wimboot

However I am unable to get it loaded correctly, after everything is
loaded and server boots up again I get always a blue scree. Do you
maybe know how I can troubleshoot this and solve this issue?

-- 
Mohammad Oslani
HugeServer Networks, LLC | Premium Dedicated Servers and Colocation
Mohammad@... | O : 888-842-8570 x1200 | F : 213-402-6061
Hello,

We are trying to load windows over ipxe and followed over this page :
http://ipxe.org/wimboot

However I am unable to get it loaded correctly, after everything is
loaded and server boots up again I get always a blue scree. Do you
maybe know how I can troubleshoot this and solve this issue?

--

-- 
Mohammad Oslani
HugeServer Networks, LLC | Premium Dedicated Servers and Colocation
Mohammad@... | O : 888-842-8570 x1200 | F : 213-402-6061

Gmane