Josh Jameson | 26 Jun 19:55 2015

Subnet mask 255.255.255.255 doesn't work

Dear Developers,
First of all thank you for coding such an awesome piece of software.

I am having an issue where I need to provide /32 DHCP request where the 
gateway is outside the subnet.

For example consider the following DHCP offer;
  IP: 10.0.0.50
  Netmask: 255.255.255.255
  Gateway: 10.1.0.1

iPXE doesn't seem to communicate right. It times out when trying to get 
a HTTP request at http://10.1.0.1/. If I boot the same machine and 
network config into Linux or Windows I can access the URL.

Any help would be much appreciated.

Regards,
Josh Jameson
Bernd Wiebelt | 26 Jun 12:07 2015

[ipxe] support for BCM57766 (#37)

Same initialization as BCM57762 (used in Apple Thunderbolt-Gigabit-Ethernet-Adapter).

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

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

Commit Summary

  • support for BCM57766

File Changes

Patch Links:


Reply to this email directly or view it on GitHub.

<div>
<p>Same initialization as BCM57762 (used in Apple Thunderbolt-Gigabit-Ethernet-Adapter).</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/37">https://github.com/ipxe/ipxe/pull/37</a></p>

<h4>Commit Summary</h4>
<ul>
<li>support for BCM57766</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/37/files#diff-0">src/drivers/net/tg3/tg3.c</a>
    (1)
  </li>
  <li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/37/files#diff-1">src/drivers/net/tg3/tg3.h</a>
    (1)
  </li>
  <li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/37/files#diff-2">src/drivers/net/tg3/tg3_hw.c</a>
    (1)
  </li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href="https://github.com/ipxe/ipxe/pull/37.patch">https://github.com/ipxe/ipxe/pull/37.patch</a></li>
  <li><a href="https://github.com/ipxe/ipxe/pull/37.diff">https://github.com/ipxe/ipxe/pull/37.diff</a></li>
</ul>
<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/37">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>
Arthur Gautier | 25 Jun 16:17 2015

[ipxe] [wip][freebsd] Initial support freebsd boot (#36)

Hi,

As this, this code does not work. I'm sending out this pull request to get feedback, and understand a bit better how memory is managed by ipxe.

The freebsd64 kernel is an elf64 kernel. The entry is an absolute virtual address. And the kernel expects to be placed at a specific address when booting. For that purpose, the freebsd loader relies on MMU to map destination virtual address to the physical address where the kernel has been allocated by the loader.
This mechanism is handled in the amd64_tramp.S and permits 32bit code to load 64bit kernel.

To perform this mapping, we need to allocate a PT4/3/2 pagetables and provide physical address to it. I'm unsure how to use the memory library in ipxe.

my comments are inline and feedback more than welcome :)

Thanks

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

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

Commit Summary

  • [freebsd] Initial support freebsd boot

File Changes

Patch Links:


Reply to this email directly or view it on GitHub.

<div>
<p>Hi,</p>

<p>As this, this code does not work. I'm sending out this pull request to get feedback, and understand a bit better how memory is managed by ipxe.</p>

<p>The freebsd64 kernel is an elf64 kernel. The entry is an absolute virtual address. And the kernel expects to be placed at a specific address when booting. For that purpose, the freebsd loader relies on MMU to map destination virtual address to the physical address where the kernel has been allocated by the loader.<br>
This mechanism is handled in the amd64_tramp.S and permits 32bit code to load 64bit kernel.</p>

<p>To perform this mapping, we need to allocate a PT4/3/2 pagetables and provide physical address to it. I'm unsure how to use the memory library in ipxe.</p>

<p>my comments are inline and feedback more than welcome :)</p>

<p>Thanks</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/36">https://github.com/ipxe/ipxe/pull/36</a></p>

<h4>Commit Summary</h4>
<ul>
<li>[freebsd] Initial support freebsd boot</li>
</ul>
<h4>File Changes</h4>
<ul>
<li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/36/files#diff-0">src/arch/i386/image/amd64_tramp.S</a>
    (140)
  </li>
  <li>
    A
    <a href="https://github.com/ipxe/ipxe/pull/36/files#diff-1">src/arch/i386/image/freebsd.c</a>
    (203)
  </li>
  <li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/36/files#diff-2">src/config/config.c</a>
    (1)
  </li>
  <li>
    M
    <a href="https://github.com/ipxe/ipxe/pull/36/files#diff-3">src/include/elf.h</a>
    (43)
  </li>
</ul>
<h4>Patch Links:</h4>
<ul>
<li><a href="https://github.com/ipxe/ipxe/pull/36.patch">https://github.com/ipxe/ipxe/pull/36.patch</a></li>
  <li><a href="https://github.com/ipxe/ipxe/pull/36.diff">https://github.com/ipxe/ipxe/pull/36.diff</a></li>
</ul>
<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/36">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>
Felnhofer, Roland | 17 Jun 10:08 2015

HP NC523SFP / QLogic 82XX (QLogic cLOM8214) UNDI Driver - Network communication - DHCP

Dear all,

 

we have currently the following issue with iPXE:

 

We have 6 HP DL380 each with 2 HP NC523SFP 10Gb NICs. PXE is only enabled on the first port of the first NIC.

We using chain-loading to load the iPXE stack.

The build in PXE boot without any problems, gets it’s IP address and all other parameters via DHCP without any problems.

The iPXE stack gets loaded and initialized without issues as well.

When it comes to request a DHCP address the NIC sends its DHCP… which is received by the server. On the server you can see that a DHCP…. Gets sent back to the “iPXE”-server.

After a while the “iPXE”-server responses with an timeout.

 

I’m sure you need addition information so tackle the problem! So what would it be?

 

Mit freundlichen Grüßen / Best regards

 

Roland Felnhofer

 

Attachment (smime.p7s): application/pkcs7-signature, 6181 bytes
<div><div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Dear all,<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">we have currently the following issue with iPXE:<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">We have 6 HP DL380 each with 2 HP NC523SFP 10Gb NICs. PXE is only enabled on the first port of the first NIC.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">We using chain-loading to load the iPXE stack.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">The build in PXE boot without any problems, gets it&rsquo;s IP address and all other parameters via DHCP without any problems.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">The iPXE stack gets loaded and initialized without issues as well.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">When it comes to request a DHCP address the NIC sends its DHCP&hellip; which is received by the server. On the server you can see that a DHCP&hellip;. Gets sent back to the &ldquo;iPXE&rdquo;-server.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US">After a while the &ldquo;iPXE&rdquo;-server responses with an timeout.<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span lang="EN-US">I&rsquo;m sure you need addition information so tackle the problem! So what would it be?<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Mit freundlichen Gr&uuml;&szlig;en / Best regards<p></p></span></p>
<p class="MsoNormal"><span><p>&nbsp;</p></span></p>
<p class="MsoNormal"><span>Roland Felnhofer<p></p></span></p>
<p class="MsoNormal"><span lang="EN-US"><p>&nbsp;</p></span></p>
</div></div>
Tanner Rork | 10 Jun 02:41 2015

Help building EFI

I’m trying to get ipxe to work in UEFI but after it boots up it doesn’t see the network card. After some reading it seems that I need to build an efirom for my motherboard, however I can’t afford to break this motherboard. The driver in the ipxe.efi doesn’t work. I also don’t want to flash the motherboards ROM either. I was thinking I could make a .efidrv for the onboard NIC but I’m not sure if that would work or how to build it necessarily. Can you please advise? Also if I have to build an efirom (can’t do something non-permenant) can you please give some detailed instructions?

 

 

<div><div class="WordSection1">
<p class="MsoNormal">I&rsquo;m trying to get ipxe to work in UEFI but after it boots up it doesn&rsquo;t see the network card. After some reading it seems that I need to build an efirom for my motherboard, however I can&rsquo;t afford to break this motherboard. The driver in the ipxe.efi doesn&rsquo;t work. I also don&rsquo;t want to flash the motherboards ROM either. I was thinking I could make a .efidrv for the onboard NIC but I&rsquo;m not sure if that would work or how to build it necessarily. Can you please advise? Also if I have to build an efirom (can&rsquo;t do something non-permenant) can you please give some detailed instructions?<p></p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
<p class="MsoNormal"><p>&nbsp;</p></p>
</div></div>
Gerd Hoffmann | 10 Jun 13:31 2015
Picon

[PATCH] efi_snp: improve compliance with the EFI_SIMPLE_NETWORK_PROTOCOL spec

From: Laszlo Ersek <lersek@...>

The efi_snp interface dates back to 2008, when the GetStatus() interface
must have been seriously under-specified. The UEFI Specification (2.4)
specifies EFI_SIMPLE_NETWORK_PROTOCOL in detail however. In short:

- the Transmit() interface is assumed to link (not copy) the SNP client's
  buffer and return at once (without blocking), taking ownership of the
  buffer temporarily;

- the GetStatus() interface releases one of the completed (transmitted or
  internally copied) buffers back to the caller. If there are several
  completed buffers, it is unspecified which one is returned.

The EFI build of the grub boot loader actually verifies the buffer address
returned by GetStatus(), therefore in efi_snp we must at least fake the
queueing of client buffers. This patch doesn't track client buffers
together with the internally queued io_buffer structures, we consider a
client buffer recyclable as soon as we make a deep copy of it and queue
the copy internally.

Signed-off-by: Laszlo Ersek <lersek@...>
Signed-off-by: Gerd Hoffmann <kraxel@...>
---
 src/include/ipxe/efi/efi_snp.h |  6 +++++
 src/interface/efi/efi_snp.c    | 54 ++++++++++++++++++++++++------------------
 2 files changed, 37 insertions(+), 23 deletions(-)

diff --git a/src/include/ipxe/efi/efi_snp.h b/src/include/ipxe/efi/efi_snp.h
index a18bced..863a81a 100644
--- a/src/include/ipxe/efi/efi_snp.h
+++ b/src/include/ipxe/efi/efi_snp.h
 <at>  <at>  -18,6 +18,8  <at>  <at> 
 #include <ipxe/efi/Protocol/HiiDatabase.h>
 #include <ipxe/efi/Protocol/LoadFile.h>

+#define MAX_RECYCLED_TXBUFS 64
+
 /** An SNP device */
 struct efi_snp_device {
 	/** List of SNP devices */
 <at>  <at>  -44,6 +46,10  <at>  <at>  struct efi_snp_device {
 	 * Used in order to generate TX completions.
 	 */
 	unsigned int tx_count_txbufs;
+	/** Holds the addresses of recycled SNP client buffers; a ring. */
+	void *tx_recycled_txbufs[MAX_RECYCLED_TXBUFS];
+	/** The index of the first buffer to return to the SNP client. */
+	unsigned tx_first_txbuf;
 	/** Outstanding RX packet count (via "interrupt status") */
 	unsigned int rx_count_interrupts;
 	/** Outstanding RX packet count (via WaitForPacket event) */
diff --git a/src/interface/efi/efi_snp.c b/src/interface/efi/efi_snp.c
index 67fba34..c21af33 100644
--- a/src/interface/efi/efi_snp.c
+++ b/src/interface/efi/efi_snp.c
 <at>  <at>  -68,6 +68,14  <at>  <at>  static void efi_snp_set_state ( struct efi_snp_device *snpdev ) {
 		 */
 		mode->State = EfiSimpleNetworkInitialized;
 	}
+
+	if (mode->State != EfiSimpleNetworkInitialized) {
+		/* Zero the number of recycled buffers when moving to any other
+		 * state than Initialized. Transmit() and GetStatus() are only
+		 * valid in Initialized.
+		 */
+		snpdev->tx_count_txbufs = 0;
+	}
 }

 /**
 <at>  <at>  -446,12 +454,12  <at>  <at>  efi_snp_nvdata ( EFI_SIMPLE_NETWORK_PROTOCOL *snp, BOOLEAN read,
  *
  *  <at> v snp		SNP interface
  *  <at> v interrupts	Interrupt status, or NULL
- *  <at> v txbufs		Recycled transmit buffer address, or NULL
+ *  <at> v txbuf		Recycled transmit buffer address, or NULL
  *  <at> ret efirc		EFI status code
  */
 static EFI_STATUS EFIAPI
 efi_snp_get_status ( EFI_SIMPLE_NETWORK_PROTOCOL *snp,
-		     UINT32 *interrupts, VOID **txbufs ) {
+		     UINT32 *interrupts, VOID **txbuf ) {
 	struct efi_snp_device *snpdev =
 		container_of ( snp, struct efi_snp_device, snp );

 <at>  <at>  -485,30 +493,22  <at>  <at>  efi_snp_get_status ( EFI_SIMPLE_NETWORK_PROTOCOL *snp,
 		DBGC2 ( snpdev, " INTS:%02x", *interrupts );
 	}

-	/* TX completions.  It would be possible to design a more
-	 * idiotic scheme for this, but it would be a challenge.
-	 * According to the UEFI header file, txbufs will be filled in
-	 * with a list of "recycled transmit buffers" (i.e. completed
-	 * TX buffers).  Observant readers may care to note that
-	 * *txbufs is a void pointer.  Precisely how a list of
-	 * completed transmit buffers is meant to be represented as an
-	 * array of voids is left as an exercise for the reader.
-	 *
-	 * The only users of this interface (MnpDxe/MnpIo.c and
-	 * PxeBcDxe/Bc.c within the EFI dev kit) both just poll until
-	 * seeing a non-NULL result return in txbufs.  This is valid
-	 * provided that they do not ever attempt to transmit more
-	 * than one packet concurrently (and that TX never times out).
+	/* In efi_snp_transmit() we enqueue packets by copying them (not by
+	 * linking them), hence we can recycle them immediately to the SNP
+	 * client.
 	 */
-	if ( txbufs ) {
-		if ( snpdev->tx_count_txbufs &&
-		     list_empty ( &snpdev->netdev->tx_queue ) ) {
-			*txbufs = "Which idiot designed this API?";
+	if ( txbuf ) {
+		if ( snpdev->tx_count_txbufs ) {
+			unsigned first;
+
+			first = snpdev->tx_first_txbuf++;
+			snpdev->tx_first_txbuf %= MAX_RECYCLED_TXBUFS;
+			*txbuf = snpdev->tx_recycled_txbufs[first];
 			snpdev->tx_count_txbufs--;
 		} else {
-			*txbufs = NULL;
+			*txbuf = NULL;
 		}
-		DBGC2 ( snpdev, " TX:%s", ( *txbufs ? "some" : "none" ) );
+		DBGC2 ( snpdev, " TX:%p", *txbuf );
 	}

 	DBGC2 ( snpdev, "\n" );
 <at>  <at>  -560,6 +560,12  <at>  <at>  efi_snp_transmit ( EFI_SIMPLE_NETWORK_PROTOCOL *snp,
 	if ( efi_snp_claimed )
 		return EFI_NOT_READY;

+	assert ( snpdev->tx_count_txbufs <= MAX_RECYCLED_TXBUFS );
+	if ( snpdev->tx_count_txbufs == MAX_RECYCLED_TXBUFS ) {
+		/* No room to recycle another buffer. */
+		return EFI_NOT_READY;
+	}
+
 	/* Sanity checks */
 	if ( ll_header_len ) {
 		if ( ll_header_len != ll_protocol->ll_header_len ) {
 <at>  <at>  -626,7 +632,9  <at>  <at>  efi_snp_transmit ( EFI_SIMPLE_NETWORK_PROTOCOL *snp,

 	/* Record transmission as outstanding */
 	snpdev->tx_count_interrupts++;
-	snpdev->tx_count_txbufs++;
+	snpdev->tx_recycled_txbufs[(snpdev->tx_first_txbuf +
+				    snpdev->tx_count_txbufs++
+				   ) % MAX_RECYCLED_TXBUFS] = data;

 	return 0;

--

-- 
1.8.3.1

Kamil Czekirda | 3 Jun 18:04 2015
Picon

isolinux.bin in FreeBSD

Dear maintainer,

could you please add this path for isolinux.bin?

--- src/arch/i386/Makefile 2015-05-28 19:04:36.000000000 +0200
+++ src/arch/i386/Makefile 2015-06-03 17:52:04.419431282 +0200
<at> <at> -94,6 +94,7 <at> <at>
  /usr/share/syslinux/bios/isolinux.bin \
  /usr/local/share/syslinux/isolinux.bin \
  /usr/local/share/syslinux/bios/isolinux.bin \
+ /usr/local/share/syslinux/bios/core/isolinux.bin \
  /usr/lib/ISOLINUX/isolinux.bin
 ISOLINUX_BIN = $(firstword $(wildcard $(ISOLINUX_BIN_LIST)))
 

It's location in FreeBSD

Regards,
Kamil Czekirda
<div><div dir="ltr">Dear maintainer,<div><br></div>
<div>could you please add this path for isolinux.bin?</div>
<div><br></div>
<div>
<div>--- src/arch/i386/Makefile<span class="">	</span>2015-05-28 19:04:36.000000000 +0200</div>
<div>+++ src/arch/i386/Makefile<span class="">	</span>2015-06-03 17:52:04.419431282 +0200</div>
<div> <at>  <at>  -94,6 +94,7  <at>  <at> </div>
<div>&nbsp;<span class="">	</span>/usr/share/syslinux/bios/isolinux.bin \</div>
<div>&nbsp;<span class="">	</span>/usr/local/share/syslinux/isolinux.bin \</div>
<div>&nbsp;<span class="">	</span>/usr/local/share/syslinux/bios/isolinux.bin \</div>
<div>+<span class="">	</span>/usr/local/share/syslinux/bios/core/isolinux.bin \</div>
<div>&nbsp;<span class="">	</span>/usr/lib/ISOLINUX/isolinux.bin</div>
<div>&nbsp;ISOLINUX_BIN<span class="">	</span>= $(firstword $(wildcard $(ISOLINUX_BIN_LIST)))</div>
<div>&nbsp;</div>
</div>
<div><br></div>
<div>It's location in FreeBSD</div>
<div><br></div>
<div>Regards,<br>Kamil Czekirda</div>
</div></div>
Wim Week | 2 Jun 20:13 2015
Picon

HTTPS - unrecognised algorithm

Hi,

I'm having issues when using https (and undionly.kpxe)
When chaining a https URL I'm getting: "Operation not supported (http://ipxe.org/3c00e103)" (We're using "real" certificates, so not self-signed.)

I also tested on e.g https://google.com and here it works (no https error)

Recompiled with DEBUG=asn1 and it seems that the unrecognised algorithm is part of a certificate.
See screenshot at http://snag.gy/j2i8a.jpg

I'm testing with ipxe current from git (commit 6b7157c233541a4cb3c90021e8ca219b0b5dd358)

iPXE 1.0.0+ (6b71) -- Open Source Network Boot Firmware -- http://ipxe.org
Features: DNS HTTP HTTPS iSCSI TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT

Fiddling with the code, basically ignoring the errors, it works.

diff --git a/src/crypto/asn1.c b/src/crypto/asn1.c
index aca12bf..6715685 100644
--- a/src/crypto/asn1.c
+++ b/src/crypto/asn1.c
<at> <at> -507,7 +507,8 <at> <at> int asn1_algorithm ( const struct asn1_cursor *cursor,
        if ( ! *algorithm ) {
                DBGC ( cursor, "ASN1 %p unrecognised algorithm:\n", cursor );
                DBGC_HDA ( cursor, 0, cursor->data, cursor->len );
-               return -ENOTSUP_ALGORITHM;
+               //return -ENOTSUP_ALGORITHM;
+               return 0;
        }

        return 0;
diff --git a/src/crypto/x509.c b/src/crypto/x509.c
index 00eb226..c42bc52 100644
--- a/src/crypto/x509.c
+++ b/src/crypto/x509.c
<at> <at> -1763,7 +1763,8 <at> <at> int x509_validate_chain ( struct x509_chain *chain, time_t time,
        }

        DBGC ( chain, "X509 chain %p found no usable certificates\n", chain );
-       return -EACCES_USELESS;
+       //return -EACCES_USELESS;
+       return 0;
 }

<div><div dir="ltr">
<div>Hi,<br><br>I'm having issues when using https (and undionly.kpxe)<br>When chaining a https URL I'm getting: "Operation not supported (<a href="http://ipxe.org/3c00e103">http://ipxe.org/3c00e103</a>)" (We're using "real" certificates, so not self-signed.)<br><br>I also tested on e.g <a href="https://google.com">https://google.com</a> and here it works (no https error)<br><br>Recompiled with DEBUG=asn1 and it seems that the unrecognised algorithm is part of a certificate. <br>See screenshot at <a href="http://snag.gy/j2i8a.jpg">http://snag.gy/j2i8a.jpg</a><br><br>I'm testing with ipxe current from git (commit 6b7157c233541a4cb3c90021e8ca219b0b5dd358)<br><br>iPXE 1.0.0+ (6b71) -- Open Source Network Boot Firmware -- <a href="http://ipxe.org">http://ipxe.org</a><br>Features: DNS HTTP HTTPS iSCSI TFTP AoE ELF MBOOT PXE bzImage Menu PXEXT<br><br>Fiddling with the code, basically ignoring the errors, it works.<br>
</div>
<br><div>diff --git a/src/crypto/asn1.c b/src/crypto/asn1.c<br>index aca12bf..6715685 100644<br>--- a/src/crypto/asn1.c<br>+++ b/src/crypto/asn1.c<br> <at>  <at>  -507,7 +507,8  <at>  <at>  int asn1_algorithm ( const struct asn1_cursor *cursor,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if ( ! *algorithm ) {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DBGC ( cursor, "ASN1 %p unrecognised algorithm:\n", cursor );<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DBGC_HDA ( cursor, 0, cursor-&gt;data, cursor-&gt;len );<br>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return -ENOTSUP_ALGORITHM;<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //return -ENOTSUP_ALGORITHM;<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return 0;<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return 0;<br>diff --git a/src/crypto/x509.c b/src/crypto/x509.c<br>index 00eb226..c42bc52 100644<br>--- a/src/crypto/x509.c<br>+++ b/src/crypto/x509.c<br> <at>  <at>  -1763,7 +1763,8  <at>  <at>  int x509_validate_chain ( struct x509_chain *chain, time_t time,<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; DBGC ( chain, "X509 chain %p found no usable certificates\n", chain );<br>-&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return -EACCES_USELESS;<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; //return -EACCES_USELESS;<br>+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; return 0;<br>&nbsp;}<br><br>
</div>
</div></div>
Hannes Reinecke | 28 May 12:20 2015
Picon

Feedback on iBFT update?

Hi Micheal,

I've send an updated patchset for my IPv6 & iBFT support (cf
[PATCHv3 00/11] IPv6 and iBFT update).
With that I've _thought_ to have addressed your concerns.
Any feedback on them?
Note, there's a minor issue with the iBFT flags (which need to be
set correctly depending on which interface the system has booted
from), but before I'm resending that I'd like to get some feedback
on the overall state, most notably the IPv6 support.
Hardly a point in pursuing here if you don't like that approach ...

Cheers,

Hannes
--

-- 
Dr. Hannes Reinecke		               zSeries & Storage
hare <at> suse.de			               +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
_______________________________________________
ipxe-devel mailing list
ipxe-devel <at> lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
Michael Brown | 28 May 12:12 2015

Re: [ipxe] Add ixgbevf driver (#9)

Closed #9.


Reply to this email directly or view it on GitHub.

<div>
<p>Closed <a href="https://github.com/ipxe/ipxe/pull/9" class="issue-link" title="Add ixgbevf driver">#9</a>.</p>

<p>&mdash;<br>Reply to this email directly or <a href="https://github.com/ipxe/ipxe/pull/9#event-315839790">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>
Michael Bazzinotti | 26 May 16:24 2015

[PATCH] [iPXE] Add compile-time support for no modifier keys

From: "Michael J. Bazzinotti" <mbazzinotti@...>

This is a patch stemming from the discussion at
http://lists.ipxe.org/pipermail/ipxe-devel/2015-May/004237.html

This patch makes sure to add functionality without doing the following:

* break existing behavior
* add behavior inconsistent with on-screen instructions
* generate overly verbose on-screen instructions

It does this by adding a new preprocessor definition
MENU_KEYS_NO_MODIFIER, disabled by default. It can be enabled by
uncommenting the relative line in config/general.h.

Signed-off-by: Michael J. Bazzinotti <mbazzinotti@...>
---
 src/config/general.h      | 11 +++++++++++
 src/hci/tui/settings_ui.c | 30 ++++++++++++++++++++++++------
 src/usr/autoboot.c        |  7 +++++++
 3 files changed, 42 insertions(+), 6 deletions(-)

diff --git a/src/config/general.h b/src/config/general.h
index 7676f15..7087a63 100644
--- a/src/config/general.h
+++ b/src/config/general.h
 <at>  <at>  -30,6 +30,17  <at>  <at>  FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
 #define ROM_BANNER_TIMEOUT	( 2 * BANNER_TIMEOUT )

 /*
+ * Keyboard -- use of Modifier keys
+ *
+ * Some platforms do not support modifier keys, such as those using EFI
+ * 1.1 without support for the EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL (ie. Mac)
+ *
+ * If you are using a mac, or find that you cannot use Ctrl-B to cancel the
+ * autoboot process and enter a shell, try enabling this configuration option.
+ */
+//#define MENU_KEYS_NO_MODIFIER
+
+/*
  * Network protocols
  *
  */
diff --git a/src/hci/tui/settings_ui.c b/src/hci/tui/settings_ui.c
index be421cc..0970c12 100644
--- a/src/hci/tui/settings_ui.c
+++ b/src/hci/tui/settings_ui.c
 <at>  <at>  -35,6 +35,7  <at>  <at>  FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
 #include <ipxe/ansicol.h>
 #include <ipxe/jumpscroll.h>
 #include <ipxe/settings_ui.h>
+#include <config/general.h>
 #include <config/branding.h>

 /**  <at> file
 <at>  <at>  -43,6 +44,23  <at>  <at>  FILE_LICENCE ( GPL2_OR_LATER_OR_UBDL );
  *
  */

+/* Keys Configuration */
+#ifdef MENU_KEYS_NO_MODIFIER
+#define KEY_DISCARD_CHANGES ESC
+#define KEY_DELETE_SETTING BACKSPACE
+#define KEY_EXIT ESC
+#define KEY_DISCARD_CHANGES_STR "ESC"
+#define KEY_DELETE_SETTING_STR "BACKSPACE"
+#define KEY_EXIT_STR "ESC"
+#else
+#define KEY_DISCARD_CHANGES CTRL_C
+#define KEY_DELETE_SETTING CTRL_D
+#define KEY_EXIT CTRL_X
+#define KEY_DISCARD_CHANGES_STR "Ctrl-C"
+#define KEY_DELETE_SETTING_STR "Ctrl-D"
+#define KEY_EXIT_STR "Ctrl-X"
+#endif /* MENU_KEYS_NO_MODIFIER */
+
 /* Screen layout */
 #define TITLE_ROW		1U
 #define SETTINGS_LIST_ROW	3U
 <at>  <at>  -384,12 +402,12  <at>  <at>  static void draw_instruction_row ( struct settings_ui *ui ) {
 	if ( ui->row.editing ) {
 		msg ( INSTRUCTION_ROW,
 		      "Enter - accept changes" INSTRUCTION_PAD
-		      "Ctrl-C - discard changes" );
+		      KEY_DISCARD_CHANGES_STR " - discard changes" );
 	} else {
 		msg ( INSTRUCTION_ROW,
-		      "%sCtrl-X - exit configuration utility",
+		      "%s" KEY_EXIT_STR " - exit configuration utility",
 		      ( ( ui->row.origin == ui->settings ) ?
-			"Ctrl-D - delete setting" INSTRUCTION_PAD : "" ) );
+			KEY_DELETE_SETTING_STR " - delete setting" INSTRUCTION_PAD : "" ) );
 	}
 }

 <at>  <at>  -486,7 +504,7  <at>  <at>  static int main_loop ( struct settings *settings ) {
 				if ( ( rc = save_setting ( &ui ) ) != 0 )
 					alert ( " %s ", strerror ( rc ) );
 				/* Fall through */
-			case CTRL_C:
+			case KEY_DISCARD_CHANGES:
 				select_setting_row ( &ui, ui.scroll.current );
 				redraw = 1;
 				break;
 <at>  <at>  -516,7 +534,7  <at>  <at>  static int main_loop ( struct settings *settings ) {

 		/* Handle non-navigation keys */
 		switch ( key ) {
-		case CTRL_D:
+		case KEY_DELETE_SETTING:
 			if ( ! ui.row.setting.name )
 				break;
 			if ( ( rc = delete_setting ( ui.settings,
 <at>  <at>  -526,7 +544,7  <at>  <at>  static int main_loop ( struct settings *settings ) {
 			select_setting_row ( &ui, ui.scroll.current );
 			redraw = 1;
 			break;
-		case CTRL_X:
+		case KEY_EXIT:
 			return 0;
 		case CR:
 		case LF:
diff --git a/src/usr/autoboot.c b/src/usr/autoboot.c
index ccafeae..8d8c508 100644
--- a/src/usr/autoboot.c
+++ b/src/usr/autoboot.c
 <at>  <at>  -532,10 +532,17  <at>  <at>  static int shell_banner ( void ) {

 	/* Prompt user */
 	printf ( "\n" );
+#ifdef MENU_KEYS_NO_MODIFIER
+	return ( prompt ( "Press ESC for the " PRODUCT_SHORT_NAME
+			  " command line...",
+			  ( ( BANNER_TIMEOUT * TICKS_PER_SEC ) / 10 ),
+			  ESC ) == 0 );
+#else
 	return ( prompt ( "Press Ctrl-B for the " PRODUCT_SHORT_NAME
 			  " command line...",
 			  ( ( BANNER_TIMEOUT * TICKS_PER_SEC ) / 10 ),
 			  CTRL_B ) == 0 );
+#endif /* MENU_KEYS_NO_MODIFIER */
 }

 /**
--

-- 
2.3.6


Gmane