Re: [ipxe-devel] ipxe.org OSCP server check

[Michael Brown via ipxe-devel]

On 03/09/2023 11:11, Geert Stappers via ipxe-devel wrote:

When I do
   wget http://ca.ipxe.org/cross-ca.crt && \
   wget https://ca.ipxe.org/ca.crt && \
   openssl x509 -in cross-ca.crt -ocsp_uri -noout && \
   openssl ocsp -issuer ca.crt -cert cross-ca.crt -text -url 
http://ocsp.ipxe.org/ocsp/root/


I get output that ends with


Response Verify Failure
3072317184:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify 
error:../crypto/ocsp/ocsp_vfy.c:92:Verify error:unable to get local issuer 
certificate
3072317184:error:27069065:OCSP routines:OCSP_basic_verify:certificate verify 
error:../crypto/ocsp/ocsp_vfy.c:92:Verify error:self signed certificate in 
certificate chain
cross-ca.crt: good
This Update: Sep  1 11:01:57 2023 GMT
Next Update: Sep  3 09:50:03 2023 GMT


How to deal with those verify errors?


When using the openssl tools, you need to specify the iPXE root CA as 
the root of trust in order to match iPXE's verification results.  For 
the ocsp subcommand, the relevant option is "-CAfile".  For example:


  $ wget -q https://ca.ipxe.org/ca.crt
  $ wget -q https://ca.ipxe.org/cross-ca.crt
  $ wget -q https://ca.ipxe.org/cross/cross-gts-root-r4.crt

  $ openssl ocsp -CAfile ca.crt -issuer ca.crt \
 -cert cross-ca.crt \
 -url http://ocsp.ipxe.org/ocsp/root/
  Response verify OK
  cross-ca.crt: good
  This Update: Sep  1 11:01:57 2023 GMT
  Next Update: Sep  4 11:22:25 2023 GMT

  $ openssl ocsp -CAfile ca.crt -issuer cross-ca.crt \
 -cert cross-gts-root-r4.crt \
 -url http://ocsp.ipxe.org/ocsp/cross/
  Response verify OK
  cross-digicert-assured-id-root-ca.crt: good
  This Update: Sep  1 11:02:47 2023 GMT
  Next Update: Sep  4 11:22:43 2023 GMT

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] ipxe.org OSCP server issues?

[Michael Brown via ipxe-devel]

On 21/08/2023 18:57, Geert Stappers via ipxe-devel wrote:

On Mon, Nov 26, 2018 at 03:26:20PM +, Michael Brown wrote:

On 15/11/2018 21:21, Stephen Soltesz wrote:

Are there any known issues with the ipxe.org <http://ipxe.org> OSCP
servers?

Yesterday I was able to boot a test server but today I'm getting an
error message for http://ipxe.org/err/432fe3


On 16/11/2018 18:32, Damien Radtke wrote:

I was attempting to boot a new server via Vultr using an iPXE
script, and was given an error message directing me to
http://ipxe.org/err/432fe3. I also tried to connect to IRC to ask about
it, but either my chat client or the server didn't seem to be working
properly. Is the OCSP server down, and if so is there a timeframe for
when it will be back up?


I missed the start of November OCSP reissuing, sorry.  This should now be
working again.



To me it seems some simular actions is needed.


It looks as though the cross-signed certificate OCSP server did not 
restart to pick up the new CRL this month, for some reason.  I've 
restarted it manually now - please let me know if the problem happens again.


Thanks,

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] commit 3ef4f7e2ef4a22ea1e2eccc72957d7bf3fe2f945 breaks "prompt --key" command

[Michael Brown via ipxe-devel]

On 07/07/2023 14:10, Michael Brown via ipxe-devel wrote:

On 07/07/2023 09:32, Sven Dreyer via ipxe-devel wrote:
I just noticed that my iPXE script containing a line "prompt --key 
0x197e [..]" stopped working. Pressing F12 acted like I was pressing a 
different key. This worked in my last build from June 11.


Thanks to the comprehensive documentation, I was able to bisect it to 
the following commit:


commit 3ef4f7e2ef4a22ea1e2eccc72957d7bf3fe2f945
Author: Michael Brown 
Date:   Tue Jul 4 14:31:07 2023 +0100

I build iPXE on Debian Bullseye amd64. The resulting binary (.iso) was 
booted on a Qemu VM, also amd64 architecture.


Just wanted to let you know. Thanks for this excellent piece of software!


That's a great catch, thank you.  That commit renumbered the internal 
encoding used for special keys (such as F12) to avoid collisions with 
the Unicode range, but neglected to allow for the fact that the internal 
encoding is exposed to scripts via the "prompt" and "menu" commands.


Will design a fix now.


Proposed fix is in https://github.com/ipxe/ipxe/pull/990

Thanks,

Michael


___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] commit 3ef4f7e2ef4a22ea1e2eccc72957d7bf3fe2f945 breaks "prompt --key" command

[Michael Brown via ipxe-devel]

On 07/07/2023 09:32, Sven Dreyer via ipxe-devel wrote:
I just noticed that my iPXE script containing a line "prompt --key 
0x197e [..]" stopped working. Pressing F12 acted like I was pressing a 
different key. This worked in my last build from June 11.


Thanks to the comprehensive documentation, I was able to bisect it to 
the following commit:


commit 3ef4f7e2ef4a22ea1e2eccc72957d7bf3fe2f945
Author: Michael Brown 
Date:   Tue Jul 4 14:31:07 2023 +0100

I build iPXE on Debian Bullseye amd64. The resulting binary (.iso) was 
booted on a Qemu VM, also amd64 architecture.


Just wanted to let you know. Thanks for this excellent piece of software!


That's a great catch, thank you.  That commit renumbered the internal 
encoding used for special keys (such as F12) to avoid collisions with 
the Unicode range, but neglected to allow for the fact that the internal 
encoding is exposed to scripts via the "prompt" and "menu" commands.


Will design a fix now.

Thanks,

Michael


___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] IPv6 DHCP Behavior

[Michael Brown via ipxe-devel]

On 05/04/2023 08:14, Ramesh Soni -X (ramsoni - Altran ACT S.A.S at 
Cisco) wrote:

Thanks, Michael, for your response. We have not provided the boot filename in 
DHCPv4 so it is picking the file from DHCPv6.
Although we are seeing some inconsistent behaviour here. We are seeing sometime 
DHCP initial messages itself is not sent by box itself due to which iPXE is not 
happening.
Do we have any known issues related to this? We are using " iPXE 1.0.0+ (eca5)" 
version.


Commit eca5 is not present on the master branch: you must be building 
from a local fork.  Please use the latest upstream iPXE master.


Thanks,

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] REG: Query on 9K MTU Testing flow

[Michael Brown via ipxe-devel]

On 14/03/2023 16:45, MohamedShah R wrote:
Thanks for the quick response. I am new to the PXE source code and tried 
out the below changes  for the experimental testing in the netdev_close 
api and it works fine.
Why can't we have a new api netdev_reopen() which does the same logic of 
netdev_close (except the code below) and calls the netdev_open existing 
api and calls the netdev_reopen api only from the "apply_netdev_settings".

Would it have any other side-effects? Please correct me if I am wrong.

*Commented out the below code in netdev_close api *
  num_configs = table_num_entries ( NET_DEVICE_CONFIGURATORS );

for ( i = 0 ; i < num_configs ; i++ )

intf_close ( >configs[i].job, -ECANCELED );


As per my previous email: even with that hack in place, there will still 
be unwanted side effects from calling netdev->op->close() and 
netdev->op->open(), such as restarting autonegotiation on the link (with 
some drivers).


Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] IPv6 DHCP Behavior

[Michael Brown via ipxe-devel]

On 03/04/2023 09:54, Andreas Fink wrote:

so which fileame or url is being used if both answers? the one which answers 
first (which would be unpredictable order)


If your network boot servers provide conflicting responses for the boot 
URL, then the behaviour is undefined.


Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] IPv6 DHCP Behavior

[Michael Brown via ipxe-devel]

On 03/04/2023 08:39, Ramesh Soni -X (ramsoni - Altran ACT S.A.S at 
Cisco) via ipxe-devel wrote:
We have both DHCPv4 and DHCPv6 running on same iPXE server. Our box is 
running iPXE code for downloading the image from ipv6, we have made 
entry in ipxe server dhcpd6.conf file for this box.


First our box tries DHCPv4 thorugh which it gets the default ipv4 ip 
address although it didn’t have default file name so it tries to check 
with DHCPv6. Even though ipv6 assignment was done but image downloading 
was getting failed.


Can you please suggest what will be the right behaviour on this? Is it 
fine to run both DHCPv4 and DHCPv6 on same iPXE server?


Yes, you can run both DHCPv4 and DHCPv6 on the same network.  iPXE will, 
by default, try both IPv4 and IPv6 simultaneously.  It will use the IPv4 
configuration from DHCPv4, and the IPv6 configuration from router 
solicitation and/or DHCPv6.  Either DHCPv4 or DHCPv6 may provide a boot 
filename or URL.


Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] REG: Query on 9K MTU Testing flow

[Michael Brown via ipxe-devel]

On 13/03/2023 21:31, Michael Brown via ipxe-devel wrote:
There is what looks like a bug when using DHCP to change MTU: the change 
of MTU requires the interface to be closed and reopened, but closing the 
interface will cause the initiating DHCP transaction itself to be aborted.


This probably requires the code in netdevice.c to be refactored slightly 
to allow for a netdev_reopen() call, which skips the intf_close() calls.


This is going to be very messy to support cleanly.  The combination of 
performing a close and reopen is fairly disruptive.  There are several 
other side effects from netdev_close() and netdev_open() (e.g. moving 
the device to the front of the "opened devices" list), which should 
probably be bypassed on an MTU change.


I have a draft change in the "mtureset" branch.  However, even with this 
added complexity, there is still the problem that on several drivers a 
close/reopen will have other disruptive side effects such as restarting 
autonegotiation.


I don't see a resolution to this any time soon.  Arguably the simplest 
workaround would be to remove the


   .tag = DHCP_MTU,

from the definition of mtu_setting.  This would prevent the MTU from 
being changed automatically by DHCP.  A script could still set the MTU 
explicitly using e.g.


  set netX/mtu ${netX.dhcp/26}

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] REG: Query on 9K MTU Testing flow

[Michael Brown via ipxe-devel]

On 13/03/2023 17:48, MohamedShah R wrote:

Hi Michael,
  Thanks for your response. Below is the flow- I have seen in the 
execution- it hits the intf_close as part of netdev_close called from 
apply_netdev_settings,.

https://github.com/ipxe/ipxe/blob/c4c03e5be867a9b7be4dc48fe6576deca1dce8d8/src/net/netdevice.c#L868
 
.


OK, now your original message makes sense to me.

The call to intf_close() that you see is closing any net device 
configuration methods (such as DHCP) that may still be running when the 
interface is closed.


The intf_close() call is simply sending a "close" message to the remote 
side of the interface (e.g. the DHCP protocol code).  As per the comment 
in the code, it does not actually close the interface at that point.


There is what looks like a bug when using DHCP to change MTU: the change 
of MTU requires the interface to be closed and reopened, but closing the 
interface will cause the initiating DHCP transaction itself to be aborted.


This probably requires the code in netdevice.c to be refactored slightly 
to allow for a netdev_reopen() call, which skips the intf_close() calls.


Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] REG: Query on 9K MTU Testing flow

[Michael Brown via ipxe-devel]

On 13/03/2023 03:16, MohamedShah R via ipxe-devel wrote:

 1. If our device configures netdev->mtu as 1500  and
netdev->max_pkt_len is 9128(above 9k).
 2. If the DHCP server sends MTU size as 9K.   

As per the code walk-through, I understand that this api 
"staticintapply_netdev_settings” get invoke and call the below part of 
code to handle the above scenario: In this case, as part of netdev_close 
, it gets called the intf_close and it didn’t call the intf_init/openas 
part of netdev_open api.


I think you've got lost somewhere in the code, sorry.  There is no path 
from netdev_close() to intf_close().  The generic object interfaces 
handled by intf_init(), intf_close(), etc, exist at a higher layer in 
the stack.


An MTU change for an open network interface via apply_netdev_setting() 
will result in the network devices .close() and .open() methods both 
being called.  Since receive buffers are allocated during .open(), this 
will result in all receive buffers having the correct size for the new MTU.


Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] linux16 /ipxe.lkrn output

[Michael Brown via ipxe-devel]

On 19/02/2023 21:29, Geert Stappers via ipxe-devel wrote:

What output to expect from ipxe.lkrn ( downloaded from
https://boot.ipxe.org ) when started from grub?


You should see the same output as when ipxe.lkrn is started from any 
other method, e.g.:


  iPXE initialising devices...ok

  iPXE 1.21.1+ -- Open Source Network Boot Firmware -- https://ipxe.org
  Features: DNS HTTP iSCSI TFTP SRP AoE ELF MBOOT PXE bzImage Menu PXEXT

  Press Ctrl-B for the iPXE command line...

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] iPXE and Secure Boot

[Michael Brown via ipxe-devel]

On 13/02/2023 21:05, Alex Chernyakhovsky wrote:
Where are you located geographically? Debian Developers are by-design 
well connected within the PGP web of trust, and there are likely folks 
that would be happy to meet you and sign your keys. The WoT is somewhat 
fickle in terms of the bars people use to determine if they're willing 
to sign each other's keys, but I have met plenty of folks that consider 
"in person meeting and show government ID" to be the bar. Take a look at 
https://wiki.debian.org/Keysigning/Coordination 
 and 
https://wiki.debian.org/DebianLocations 
.


Thank you, that's a helpful resource!  I'm geographically in Cambridge, 
UK.  I'll reach out to the local keysigning offers in that list.


Thanks,

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

[ipxe-devel] iPXE and Secure Boot

[Michael Brown via ipxe-devel]

Dear all,

I'm in the process of trying to get a UEFI shim signed so that we are 
able to provide iPXE binaries that can be booted on a system with UEFI 
Secure Boot enabled.


As part of the shim submission process, I need to create a PGP key 
(having never previously found a need for one), and get this signed by 
some existing established PGP keys.


If there is anyone on this list who has an established PGP key, has met 
me in person, and would be happy to sign my key after appropriate 
verification (e.g. a Zoom call), please let me know!


Thanks in advance,

Michael


OpenPGP_0x0235B10A00EB4450.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Issues with Broadcom NICs in Dell R7625

[Michael Brown via ipxe-devel]

On 20/01/2023 13:54, Thomas Walker wrote:

Anyway, I can move forward here.  I have no intention of ever needing to PXE off of bnxt, so I can 
leave it out.  And the "legacy NIC wrapper" warning appears to be cosmetic.  But I'm 
willing to debug further if that is helpful since I know you don't have the hardware in question.  
It is also worth noting that this hardware was just released, and everything is on "the one 
and only" firmware versions available.  So it is quite possible that these issues will all 
clear up as firmware matures.


Thanks for clarifying.  The bnxt driver (authored by Broadcom) has very 
few comments and includes a _lot_ of unnecessary code (14000 lines for 
bnxt compared to 3000 lines for the comparable intelxl driver).  I 
wouldn't even want to start debugging it remotely.  You are very welcome 
to have a go!


For future reference, in case anyone else finding this thread has hit 
problems with bnxt in iPXE and does need to be able to boot from it: the 
iPXE bnxt driver should probably be rewritten in its entirety to be much 
smaller and simpler.


Thanks,

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Issues with Broadcom NICs in Dell R7625

[Michael Brown via ipxe-devel]

On 19/01/2023 16:48, Thomas Walker via ipxe-devel wrote:

First off, I want to say thank you, the work done 2 years ago 
(https://github.com/ipxe/ipxe/commit/988d2c13cdf0f0b4140685af35ced70ac5b3283c) 
to fix walking through multiple instances of EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL 
worked like a charm on another system with a funky bus layout (this is the next 
generation of the system that I encountered that problem on).  All appears to 
be working on that front.  But I'm encontering 2 problems (on master from a 
couple of weeks back, 7147532c):

The 1G LOM is a Broadcom 5720, nearly identical to the previous generation 
server that works fine.  Both good and bad are vendor:dev 14e4:165f and 
subvendor 1028.  The older (working) system has a subdevice of 08ff whereas the 
newer (sort of working) one has a subdevice of 0a6b.

While ipxe does appear to "work" with this adapter, it prints:

WARNING: Using legacy NIC wrapper on 79:79:79:79:79:79

Where that MAC obviously bears no relation to the actual MAC on the device.


That will be a false positive detection of an ISA NIC.


This system also has an OCP slot fitted with a Broadcom 57414 (vendor:device 14e4:16d7 
and subvendor:subdevice 1407:4145) and manages to dhcp but not much more.  Enabling 
debugging (DEBUG=bnxt:2) shows that, when "Configuring", it starts spewing:

assert(!iob) failed at drivers/net/bnxt/bnxt.c line 468

over and over until it finally fails and ipxe exits.  In fact, I had to compile 
bnxt out completely in order to boot the system off of the 1G LOM.

Any suggestions for either of these?


I'm slightly confused by the report: are you saying that you _are_ able 
to boot from the LOM, but only if you compile out bnxt (or use a build 
that contains only the relevant LOM driver, such as bin-x86_64-efi/tg3.efi)?


Thanks,

Michael


___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Does imgextract keep writing to same named location by design?

[Michael Brown]

On 11/03/2022 16:44, John Hanks wrote:

I am using imgextract to download several images, like so

imgextract --name one http://master/one.img 
imgextract --name two http://master/two.img 
imgextract --name three http://master/three.img 
boot kernel initrd=initrd.magic initrd=one initrd=two initrd=three blah 
blah blah


So far so good, except that I wanted to try adding a lot of these but am 
restricted by the maximum kernel command line length. I naively tried


imgextract --name mysystem http://master/one.img 
imgextract --name mysystem http://master/two.img 
imgextract --name mysystem http://master/three.img 
boot kernel initrd=initrd.magic initrd=mysystem blah blah blah

and it worked!!! But, that seems way too easy, like I'm cheating. Is 
this expected to work this way or am I exploiting a bug that might get 
fixed later? I don't want to depend on this unless it's working this way 
on purpose.


You are triggering slightly undefined behaviour by using both 
"initrd=initrd.magic" and an explicit "initrd=" argument.


The "initrd=initrd.magic" will cause the kernel to already see an initrd 
that comprises the concatenation of all of the images as seen by 
"imgstat".  (The magic initrd will also include constructed CPIO headers 
for any images that have a non-empty argument list, but that's 
irrelevant for your use case.)


So, assuming that your images are all compressed CPIO initrd images that 
are amenable to concatenation, then you should be able to get the 
behaviour you want by simplifying your script to something like:


  imgextract http://master/one.img
  imgextract http://master/two.img
  imgextract http://master/three.img
  boot kernel initrd=initrd.magic

i.e. remove the (redundant) --name options, and tell the kernel to load 
only initrd.magic.


Hope that helps,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] QRcode (#102)

[Michael Brown via ipxe-devel]

> @NiKiZe Thanks! I tried a few things but it seems that im unable to get the 
> UCS-2 or 2byte char working for the ISO10646 charset.

iPXE is currently ASCII-only.  I am currently working on adding Unicode support 
in stages.  The first part (allowing the use of UTF-8 in iPXE scripts, allowing 
for statements such as `echo Héllö wõrld`) is working but not yet merged to 
master.  Unicode characters via keyboard input will be added in a subsequent 
stage.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/102#issuecomment-106218
You are receiving this because you commented.

Message ID: ___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Fixed bug in intel 10M/100M/1G NIC driver. (#52)

[Michael Brown via ipxe-devel]

This was cleaned up into commit https://github.com/ipxe/ipxe/commit/2d79b20f2

-- 
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/52#issuecomment-1036448623
You are receiving this because you commented.

Message ID: ___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Fixed bug in intel 10M/100M/1G NIC driver. (#52)

[Michael Brown via ipxe-devel]

Closed #52.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/52#event-6052904769
You are receiving this because you commented.

Message ID: ___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] iPXE working on 486(386?) hardware, hanging on init_librm

[Michael Brown]

On 02/02/2022 15:52, Nikolai Zhubr wrote:

https://github.com/ipxe/ipxe/commit/bc35b24e3

This was a fun problem to debug!


Oh, nice. The commit log was an entertaining reading!
I'll try to re-test it on some 486 as time permits later.

Now as the effect appeared to be still clearly algorythmic rather than 
some hidden timing/caching/pipelining mystery, it probably could be 
implemented in bochs so as emulated 486 also behaves the same way? For 
me it'd look quite usefull.


Go for it!  It looks as though the relevant code in bochs is in 
handleCpuModeChange():


 // CS segment in real mode always allows full access
 BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.p= 1;
 BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.segment  = 1;
 BX_CPU_THIS_PTR sregs[BX_SEG_REG_CS].cache.type =
   BX_DATA_READ_WRITE_ACCESSED;

To get behaviour roughly equivalent to what I observed (and what 
external articles such as http://www.rcollins.org/ddj/Aug98/Aug98.html 
suggest), you'd want to skip the setting of .cache.type (and possibly 
also .cache.p and .cache.segment) in that method, and add code in 
jmp_far16() and jmp_far32() to set .cache.type either before or after 
the call to load_seg_reg().


It should be possible to test by using the bochs magic breakpoint 
instruction ("xchgw %bx,%bx") to break into the bochs debugger 
immediately after the "Return to (flat) real mode" in iPXE's 
libprefix.S.  With the changes outlined above, you should be able to 
observe in the debugger that you have a non-writable code segment (type 
BX_CODE_EXEC_READ_ACCESSED) after the "lret", which then becomes a 
writable segment (type BX_DATA_READ_WRITE_ACCESSED) after the "ljmp".


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] iPXE working on 486(386?) hardware, hanging on init_librm

[Michael Brown]

On 30/01/2022 22:03, Nikolai Zhubr wrote:

For iPXE this fix is unnecessary but still last time I tried iPXE
would hang on 486 for some reason.


At least one part of this problem should now be fixed:

  https://github.com/ipxe/ipxe/commit/bc35b24e3

This was a fun problem to debug!

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Generating a BIOS/UEFI hybrid ISO image

[Michael Brown]

On 07/10/2021 14:52, Dean Westhead wrote:

Sorry ... I didnt want to take lots of your time if it is only me having this 
issue and everyone else is working fine.

In the old "working" ISO, there is the following files :

boot.cat
efiboot.img
ipxe.krn
isolinux.bin
isolinux.cfg

The new one that isnt seen as a EFI bootable disk has :

boot.catalog
esp.img
ipxe.lkrn
isolinux.big
isolinux.cfg

I will open the EFI image too and see what is in that as soon as i can and let 
you know about that too.


Thanks!  Most of those files are for BIOS booting: the relevant ones for 
UEFI are efiboot.img/esp.img, which should both be FAT filesystem images 
containing a file \EFI\Boot\BootX64.efi (which should be the ipxe.efi 
binary).


Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Generating a BIOS/UEFI hybrid ISO image

[Michael Brown]

On 07/10/2021 09:43, Dean Westhead wrote:

I have checked the files in the two ISO's ( one generated from the old geniso 
and one from teh new genfsimg ), and the files in them are very different.


Merely saying that they "are very different" does not really give me any 
useful information with which to be able to help.  What are the differences?


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Generating a BIOS/UEFI hybrid ISO image

[Michael Brown]

On 05/10/2021 15:18, Dean Westhead wrote:

Yes ... that is what i have been trying  and failing ! hehe !

it all "makes" without any errors and after installing the xorriso package the 
genfsimg runs without any errors too.

The only problem is that the outputted combined.iso will not boot a Dell UEFI 
laptop and RUFUS only sees the ISO as BIOS only too.

If I copy over to the src/util directory the old geniso file and add the rule 
into into the Makefile.pcbios to use it, the resultant
ISO file works fine on both BIOS and UEFI machines.

The ISO file is also about 1Mb smaller when created with the genfsimg than with 
the geniso file  almost like it is failing to add the
bin-x86_64-efi/ipxe.efi file.


Did you try comparing the contents of the .iso images generated through 
both methods, including the contents of the embedded UEFI boot image 
(the ESP)?


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Generating a BIOS/UEFI hybrid ISO image

[Michael Brown]

On 05/10/2021 09:38, Dean Westhead wrote:
I may be missing something, but since the commit changed the file 
src/util/geniso to src/util/genfsimg, I have not been able to generate 
an ISO file that can be used to boot both BIOS and UEFI ... it always 
only boots BIOS.


I admit that the changes that i was told to make to the geniso file, i 
cant make to genfsimg becasue it is very different and i dont want to 
break anything else in it !


Am I doing something wrong or is there a different set of instructions 
to modify genfsimg to make it create this ISO correctly ?


You no longer need to make any modifications to genfsimg: it is already 
capable of building a combined BIOS and UEFI ISO (and can also handle 
multiple UEFI architectures, if you want e.g. a combined ISO that can 
handle BIOS, x86_64 UEFI, and AArch64 UEFI).


As per "./util/genfsimg -h":

usage: ./util/genfsimg [OPTIONS] foo.lkrn|foo.efi [bar.lkrn|bar.efi,...]

where OPTIONS are:
 -h show this help
 -o FILEsave image to file
 -p PAD pad filesystem (in kB)
 -s SCRIPT  use executable script

so you can build a combined image in two stages using e.g.

  make bin/ipxe.lkrn bin-x86_64-efi/ipxe.efi

  ./util/genfsimg -o combined.iso \
  bin/ipxe.lkrn bin-x86_64-efi/ipxe.efi

You can also use the "-s" option to specify a script that will be used 
by platforms (without needing to build using EMBED=...).  This is 
particularly useful if you build an editable FAT filesystem image 
instead of an ISO, using e.g.


  ./util/genfsimg -o combined.img -s myscript.ipxe \
  bin/ipxe.lkrn bin-x86_64-efi/ipxe.efi

since you can then mount the FAT filesystem image and edit the script 
(saved as "autoexec.ipxe") without needing to recompile.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] read function issue (string: 256 char limit?)

[Michael Brown]

On 09/09/2021 08:48, Matteo Guglielmi wrote:

Would it be possible to extend the size limit of 256
characters of the read function?


Should be increased to 1024 in

  https://github.com/ipxe/ipxe/commit/2265a6519

Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] A couple of compile issues

[Michael Brown]

On 17/06/2021 13:50, Michael Brown wrote:
Even with a clean download ( before any of my messing about with it ! 
), i am getting compile errors with a basic make :


ar: creating bin/blib.a
objcopy: invalid option -- 'D'


This is a known issue introduced just a few days ago by commit 
https://github.com/ipxe/ipxe/commit/bf4ccd426


I'm looking into a fix now.


Should now be fixed in

  https://github.com/ipxe/ipxe/commit/51c88a4a6

Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] A couple of compile issues

[Michael Brown]

On 17/06/2021 11:36, Dean Westhead wrote:
Is it still necessary to make these mods or is the ability to build a 
single ISO that will boot EFI and non EFI machines now part of the 
master branch ?


This is now present in the master branch.

You can build an EFI .iso in what is hopefully the most intuitive way:

  make bin-x86_64-efi/ipxe.iso

The build syntax doesn't provide a way to express multi-platform .iso 
images, but you can build them in two stages using e.g.:


  make bin/ipxe.lkrn bin-x86_64-efi/ipxe.efi
  ./util/genfsimg -o combined.iso bin/ipxe.lkrn bin-x86_64-efi/ipxe.efi

It will correctly handle multiple CPU architectures, so you build a 
single .iso that works on x86 BIOS, i386 UEFI, x86_64 UEFI, arm64 UEFI, etc.


Even with a clean download ( before any of my messing about with it ! ), 
i am getting compile errors with a basic make :


ar: creating bin/blib.a
objcopy: invalid option -- 'D'


This is a known issue introduced just a few days ago by commit 
https://github.com/ipxe/ipxe/commit/bf4ccd426


I'm looking into a fix now.

Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

[ipxe-devel] IRC channel migration

[Michael Brown]

Along with most of the rest of the world, the #ipxe IRC channel has 
migrated from Freenode to Libera.Chat.  I'll maintain a presence in both 
for the next few weeks, but would encourage people to gradually migrate 
across whenever convenient.


There is also now a Matrix room #ipxe:matrix.org which provides an 
arguably prettier user interface: see


  https://app.element.io/#/room/#ipxe:matrix.org

The Matrix room is bridged to the Libera.Chat IRC channel: all messages 
sent from either side will appear in both, so you can use whichever user 
interface you prefer.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] 486 with a Realtek 8139

[Michael Brown]

On 16/05/2021 21:04, Michael Brown wrote:

On 16/05/2021 21:04, Nikolai Zhubr wrote:
Ok, no need for a floppy actually. Apparently the "boot partition" 
method is still usable as long as disk partitioning was performed 
carefully (I ran Msdos' fdisk utility on this same board to add a 
partition so as to avoid possible conflicts with BIOS' geometry 
settings).


The result is a total hang with no message displayed whatsoever and 
Caps Lock not responding.


I'm quite sure loading from disk is successfull, because from my 
previous attempts I know an error message would be displayed in case 
of a read failure.


Thanks for testing.  Next step is probably to try building with 
DEBUG=libprefix


I've sourced a 486 system (courtesy of some kind people who responded on 
Twitter) so should be able to also test for myself on Wednesday.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] 486 with a Realtek 8139

[Michael Brown]

On 16/05/2021 21:04, Nikolai Zhubr wrote:
Ok, no need for a floppy actually. Apparently the "boot partition" 
method is still usable as long as disk partitioning was performed 
carefully (I ran Msdos' fdisk utility on this same board to add a 
partition so as to avoid possible conflicts with BIOS' geometry settings).


The result is a total hang with no message displayed whatsoever and Caps 
Lock not responding.


I'm quite sure loading from disk is successfull, because from my 
previous attempts I know an error message would be displayed in case of 
a read failure.


Thanks for testing.  Next step is probably to try building with 
DEBUG=libprefix


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] 486 with a Realtek 8139

[Michael Brown]

On 16/05/2021 10:00, Nikolai Zhubr wrote:
I have to correct myself. The documentation does exist (online), however 
for me as a user it is arranged in a very unexpected manner, and it 
confuses to a surprisingly high degree. First, the material goes all 
upside-down: command line goes before build options, architecture of 
wimboot goes before build targets. One could suppose it does not matter 
(as long as the links are within a single page anyway), but yes it does 
matter quite a lot. Second, it is presented in way that somehow 
discourages long sequential reading (by "long" I mean more than 3 
lines), very much pushing the idea that as a user you only need to 
comprehence "cd src; make" at most, which is not always good enough.


To be fair: "cd src ; make" would have built you the exact bin/ipxe.pxe 
target that I already suggested using.


Debug builds are fairly specialised (and not something that most users 
will need), debugging a hang at this stage of operation is even more 
specialised, and getting iPXE working on a 30-year-old CPU is definitely 
well into the depths of obscure corner cases.


I personally dislike reading documentation that is polluted with corner 
cases and historical arcana.  The overriding goal of any documentation 
that I write is to make it easy for the reader to get the basic use case 
working as quickly as possible and with zero distractions.


For your testing: I would first suggest trying to boot iPXE from a 
storage medium such as a USB key (or floppy disk, given that you're 
talking about a 486-era system).  Both bin/ipxe.usb and bin/ipxe.dsk 
will also already be built by "cd src ; make".


I'm asking for this testing in order to eliminate problems potentially 
caused by interaction with your Etherboot ROM.


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] 486 with a Realtek 8139

[Michael Brown]

On 15/05/2021 22:56, Nikolai Zhubr wrote:
One note is that I had to compile using the default ancient system gcc 
compiler with:

"make -j1 bin/10ec8139.kpxe EMBED=chain.ipxe"
where gcc says:
gcc (SUSE Linux) 4.8.3

An attempt to cross-compile using my preferred 486 toolchain with gcc 
7.5 fails because DEPS start going circles forever. For that attempt, I 
used:

"make -j1 CROSS_COMPILE=... ARCH=x86 bin/10ec8139.kpxe EMBED=chain.ipxe"

Usually, the command line like above works fine.


Not sure where you got the notion of using "ARCH=x86" from - there is no 
"x86" build architecture supported in iPXE, no documentation suggesting 
that it does, and no documentation suggesting that "ARCH=..." should 
ever be specified on the build command line.  This will be the cause of 
your circular DEPS problem.


You can keep it simple and just build using any reasonably current (less 
than 10 years old) Linux distro's default gcc, with the command:


  make bin/10ec8139.pxe

(note .pxe rather than .kpxe - the .kpxe suffix is for the undionly.kpxe 
build target only, as per all available documentation).


There is no need to use -j1, and no need for any custom gcc toolchain.

You also have the option of using bin/ipxe.pxe, which will contain the 
full set of PCI NIC drivers.  There's a prebuilt version downloadable at 
all times from


  http://boot.ipxe.org/ipxe.pxe

Thanks for testing,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] 486 with a Realtek 8139

[Michael Brown]

On 05/05/2021 20:13, Michael Brown wrote:
For unlzma.S, just changing to ".arch i486" is fine, since there are no 
586-class instructions in that file.


For undinet.c, the "rdtsc" instructions are used only for profiling. 
It's probably not worth the marginally increased accuracy from having 
the rdtsc within the real-mode code: those TSC reads could be moved 
outside the REAL_CODE() block and implemented using the standard 
profile_xxx() functions instead of hardcoded "rdtsc" instructions.  (An 
alternative approach would be to conditionalise the presence of the 
"rdtsc" instructions, but it would need to be an exceptionally neat 
solution to justify such a special case.)


For rtc_entropy.c, the use of the TSC is intrinsic to the way that the 
code operates.  There is already an entropy_enable() call that is 
allowed to return an error to indicate that the entropy source is 
unusable: this could be extended to include a low-overhead check for the 
existence of the TSC.


With those changes, there would be no need for any compile-time option 
or accompanying documentation: the code would Just Work on a 486.


All three of the above are now implemented:

  https://github.com/ipxe/ipxe/commit/13c1abe10
  https://github.com/ipxe/ipxe/commit/05fcf1a2f
  https://github.com/ipxe/ipxe/commit/a6a8bb1a9

With the current master branch, I am able to boot successfully using 
iPXE on a (bochs-emulated) 486.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] 486 with a Realtek 8139

[Michael Brown]

On 07/05/2021 00:20, Nikolai Zhubr wrote:
I appologise for bugging you with ancient etherboot, please ignore if it 
is too much off topic. I'm just not sure how to proceed yet.


I'm pleased that you managed to get something working, but just to be 
clear: there is zero chance of any changes being accepted to a codebase 
that became obsolete around 15 years ago.


You're welcome to fork Etherboot and maintain it on your own, but if you 
want there to be any chance of what you need being supported upstream, 
then you'll need to work with the current iPXE codebase.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] 486 with a Realtek 8139

[Michael Brown]

On 05/05/2021 19:53, Nikolai Zhubr wrote:
Thanks for mentioning Bochs, I've copied your 486 config commandline and 
was able to build and start testing. Its way more handy than with real 
iron. It is even possible to disable e820 function by hand.


Now as long as 586+ requirement is not really critical for operation, 
maybe put such fragments into conditional ifdefs and introduce some 
config option (say LEGACY486) to allow 486-compatible builds?


I've gone to a *lot* of effort over the past 15 years to eliminate that 
kind of conditional ifdef from the codebase (see the various "#ifdef 
considered harmful" articles around the web).


For unlzma.S, just changing to ".arch i486" is fine, since there are no 
586-class instructions in that file.


For undinet.c, the "rdtsc" instructions are used only for profiling. 
It's probably not worth the marginally increased accuracy from having 
the rdtsc within the real-mode code: those TSC reads could be moved 
outside the REAL_CODE() block and implemented using the standard 
profile_xxx() functions instead of hardcoded "rdtsc" instructions.  (An 
alternative approach would be to conditionalise the presence of the 
"rdtsc" instructions, but it would need to be an exceptionally neat 
solution to justify such a special case.)


For rtc_entropy.c, the use of the TSC is intrinsic to the way that the 
code operates.  There is already an entropy_enable() call that is 
allowed to return an error to indicate that the entropy source is 
unusable: this could be extended to include a low-overhead check for the 
existence of the TSC.


With those changes, there would be no need for any compile-time option 
or accompanying documentation: the code would Just Work on a 486.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] 486 with a Realtek 8139

[Michael Brown]

On 05/05/2021 07:54, Martin Habets wrote:

Long ago Etherboot used to be i386 code.
Nowadays I think iPXE only runs on i586 or later,
e.g. arch/x86/prefix/unlzma.S has:
.arch i586

 From memory there are a couple of places in the code where
iPXE uses assembler opcodes that don't exist in 486.
Your best bet is probably using the old Etherboot code base and
debug/patch that.


A quick test indicates that unlzma.S will still build with ".arch i486". 
 AFAICT the only non-i386 instruction in there is "bswap", which should 
exist on a 486.


I did some quick testing in bochs configured for a 486 using:

  ./configure --enable-a20-pin --disable-x86_64 --enable-cpu-level=4 \
  --enable-pci --enable-e1000 --enable-debugger \
  --disable-debugger-gui --enable-readline \
  --enable-all-optimizations --enable-cdrom --disable-smp

This showed that iPXE is getting stuck on the "rdtsc" instruction, which 
is an undefined opcode on i486.


The rdtsc-based timer isn't causing the problem: the code in 
rdtsc_probe() already checks for an invariant TSC (which isn't present 
on i486) and so never issues the rdtsc instruction.


There are two remaining uses: in undinet_call() where the TSC value gets 
used only for profiling, and in rtc_sample() where the TSC value gets 
used as part of entropy generation.


Commenting out these instructions (via the attached patch) gave me an 
iPXE binary that worked fine on i486.


Michael
diff --git a/src/arch/x86/drivers/net/undinet.c b/src/arch/x86/drivers/net/undinet.c
index 9b7d6d849..de6f4aa66 100644
--- a/src/arch/x86/drivers/net/undinet.c
+++ b/src/arch/x86/drivers/net/undinet.c
@@ -288,14 +288,14 @@ static int undinet_call ( struct undi_nic *undinic, unsigned int function,
 	 */
 	profile_start ( >total );
 	__asm__ __volatile__ ( REAL_CODE ( "pushl %%ebp\n\t" /* gcc bug */
-	   "rdtsc\n\t"
+	   //"rdtsc\n\t"
 	   "pushl %%eax\n\t"
 	   "pushw %%es\n\t"
 	   "pushw %%di\n\t"
 	   "pushw %%bx\n\t"
 	   "lcall *undinet_entry_point\n\t"
 	   "movw %%ax, %%bx\n\t"
-	   "rdtsc\n\t"
+	   //"rdtsc\n\t"
 	   "addw $6, %%sp\n\t"
 	   "popl %%edx\n\t"
 	   "popl %%ebp\n\t" /* gcc bug */ )
diff --git a/src/arch/x86/interface/pcbios/rtc_entropy.c b/src/arch/x86/interface/pcbios/rtc_entropy.c
index e9e6baa59..428397968 100644
--- a/src/arch/x86/interface/pcbios/rtc_entropy.c
+++ b/src/arch/x86/interface/pcbios/rtc_entropy.c
@@ -226,7 +226,7 @@ uint8_t rtc_sample ( void ) {
 			"testb %b2, %b2\n\t"
 			"jz 1b\n\t"
 			/* Read "before" TSC */
-			"rdtsc\n\t"
+			//"rdtsc\n\t"
 			/* Store "before" TSC on stack */
 			"pushl %0\n\t"
 			/* Wait for another RTC interrupt */
@@ -237,7 +237,7 @@ uint8_t rtc_sample ( void ) {
 			"testb %b2, %b2\n\t"
 			"jz 1b\n\t"
 			/* Read "after" TSC */
-			"rdtsc\n\t"
+			//"rdtsc\n\t"
 			/* Retrieve "before" TSC on stack */
 			"popl %1\n\t"
 			/* Disable interrupts */
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Allow user to edit a kernel command line before booting with a read timeout

[Michael Brown]

On 23/04/2021 11:46, Matteo Guglielmi wrote:

Would it be possible to ask for a read --timeout option
in order to automate the following script (unattended
boot)?

set cmdline selinux=0 console=ttyS0,115200n8 console=tty0
echo -n Kernel command line: ${}
read --timeout 5 cmdline
chain http://my.web.server/vmlinuz ${cmdline}


Done:

  https://github.com/ipxe/ipxe/commit/b2501dd12
  https://github.com/ipxe/ipxe/commit/323af9ee8

The timeout is in milliseconds (for consistency with all other iPXE 
--timeout options).


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] autoexec.ipxe and UEFI secure boot ?

[Michael Brown]

On 04/04/2021 16:42, Etienne Champetier wrote:

Since 
https://github.com/ipxe/ipxe/commit/a3f1e8fb6707811e6eb90e339d7ebe813fd89a63,
iPXE load autoexec.ipxe from filesystem allowing pretty much the same
use case as embedding configuration without the need to recompile iPXE
binary.

Now I'm wondering would it allow say RedHat to provide signed iPXE
binary (ipxe.efi)
and anyone to create a secure boot enabled iso with ipxe.efi and their
autoexec.ipxe or is this feature considered not safe to be signed ?


Yes, that would be possible.  iPXE scripts are deemed to be 
configuration data: they cannot be used to make arbitrary changes to 
system memory or to execute arbitrary unsigned code and so do not 
themselves require Secure Boot signing.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [SPAM] Connection is not working

[Michael Brown]

On 19/02/2021 17:22, Klaus Falke wrote:

Hi,
why this is not working:
image
*What I can do to fix it?*


First: please update your version of iPXE.  The version you are using is 
from 2013(!) or earlier since it predates commit


  https://github.com/ipxe/ipxe/commit/26b87b221

Once you have updated, check to see if the error still occurs.  If there 
is still an error, then please read the documentation on that error. 
For example, your current screenshot directs you to the error page


  https://ipxe.org/4c106035

You will find plenty of troubleshooting hints on that page.

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [edk2-devel] EfiRom vs. iPXE usability note

[Michael Brown]

On 19/02/2021 17:33, Laszlo Ersek wrote:

The PCI Firmware Spec does not seem to specify a particular "checksum
byte" in the option ROM format, it only seems to state that the bytes in
the option ROM must sum to zero.

This (apparently) allows option ROM providers to implement different
schemes for placing the checksum byte.

When talking about traditional BIOS ROMs, EfiRom considers the last byte
in the image the checksum byte. The assumption is that the last byte is
padding anyway, so it can be repurposed as a checksum byte.

On the other hand, iPXE's "util/catrom.pl", or more precisely,
"util/Option/ROM.pm", considers byte#6 -- a reserved byte -- in the PCI
Expansion ROM Header the checksum byte.

iPXE's choice is arguably safer, because it does not assume any
particular padding at the end of the traditional ROM BIOS image that
could be stolen as checksum byte.


Thank you for sharing this.  It made me curious as to the reason why we 
use that byte for the checksum.


As far as I can tell, it dates back to at least the ISA-era Plug and 
Play BIOS Specification v1.0a, which defines the option ROM header as 
including a 4-byte "initialization vector" occupying bytes 3-6 
inclusive, with the comment:


  The field is four bytes wide even though most implementations may
  adhere to the custom of defining a simple three byte NEAR JMP.
  The definition of the fourth byte may be OEM specific.

So, iPXE is safe to choose to use offset 6 as the checksum byte for any 
iPXE ROM images, knowing that future specification versions could not 
define an alternative use for this byte.



However, iPXE's "util/efirom" tool, which converts *.efidrv to *.efirom,
doesn't seem to offer "EFI compression", while EfiRom does (-ec option).
For QEMU live-migration compatibility, we further pad the *combined* ROM
images, currently to 256 KB. Abandoning EFI compression would eat up
approx. 80KB suddenly, and nearly exhaust our current padding. Hence the
above "hybrid" approach, where we retain EfiRom for the EFI
compression's sake, but use "util/catrom.pl" for combining the images.


That part, at least, I can fix:

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

iPXE now produces compressed EFI ROM images by default.  Thank you for 
pushing me to do this!



Assuming my reading of the PCI Firmware Spec is correct, I think that
not specifying a particular checksum byte, in the various headers, was a
mistake in the spec. It's difficult to combine ROMs of different origins
into a multi-ROM image, like this.


I concur with this interpretation.  As far as I can tell, there is no 
general solution for updating the checksum that is guaranteed to work on 
arbitrary BIOS ROM images.


As the closest thing to the OEM for iPXE: please consider this email to 
be the PnP "OEM specific" definition of the byte at offset 6 of the 
expansion ROM header as being the checksum byte for any iPXE ROMs. 
Tools working on _iPXE_ BIOS ROM images may update this byte as needed.


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [PATCH] [ath5k] Add missing AR5K_EEPROM_READ in ath5k_eeprom_read_turbo_modes

[Michael Brown]

On 16/02/2021 18:29, Bruce Rogers wrote:

The GCC11 compiler pointed out something that apparently no previous
compiler noticed: in ath5k_eeprom_pread_turbo_modes, local variable
val is used uninitialized. From what I can see, the code is just
missing an initial AR5K_EEPROM_READ. Add it right before the switch
statement.

Signed-off-by: Bruce Rogers 


Applied; thank you!

  https://github.com/ipxe/ipxe/commit/19d0fab40

I have no idea how this went unnoticed for so long by any compiler!

Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Diskless Cilent Centos via iSCSI

[Michael Brown]

On 15/02/2021 19:16, brent s. wrote:

On 2/12/21 11:43, Oliver Rath wrote:

Ist there something appropriate for Debian/Ubuntu?


For e.g. Focal release of Ubuntu, you would use this URL base (make sure
the initramfs and kernel filenames are the same, I didn't check):

http://archive.ubuntu.com/ubuntu/dists/focal/main/installer-amd64/current/legacy-images/netboot/ubuntu-installer/amd64/

For Debian, you can find the kernel and initrd.gz here:

https://deb.debian.org/debian/dists/buster/main/installer-amd64/current/images/netboot/debian-installer/amd64/


Thanks.

For a Red Hat installation, I can tell the initrd where to find the rest 
of the installer by adding e.g.


  inst.repo=http://mirror.centos.org/centos/8/BaseOS/x86_64/os

to the kernel command line.

Is there a direct equivalent for Debian/Ubuntu?  I've tried previously 
and given up, because it seemed as though the only option was to create 
a preseed.cfg file (which, in turn, seemed to require specifying a large 
number of unnecessary other values in addition to the single repository 
URL).


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Diskless Cilent Centos via iSCSI

[Michael Brown]

On 12/02/2021 16:43, Oliver Rath wrote:

  https://ipxe.org/howto/rh_san

Maybe it is interesting to know, that the path for RH Centos  *8* 
(instead of 7) changed to


http://mirror.centos.org/centos/8/BaseOS/x86_64/os/images/pxeboot/


Thanks.  I've updated the documentation to use this instead.


Ist there something appropriate for Debian/Ubuntu?


There probably is, but I've always found the Debian/Ubuntu network 
installation process to be much more convoluted.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Diskless Cilent Centos via iSCSI

[Michael Brown]

On 12/02/2021 07:04, pat...@chojecki.it wrote:

I have another problem with install CentOS 7
I try install CentOS on iSCSI target,I Can't install partition /boot on 
iSCSI target.


The problem arises from:


i instaled centos from cd


You need to perform an installation via the network, with the iSCSI 
drive connected as part of the network boot.  You can find appropriate 
instructions at


  https://ipxe.org/howto/rh_san

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Install Windows 10 via http

[Michael Brown]

On 05/02/2021 12:54, pat...@chojecki.it wrote:

Hi, I have next problem.
I can't install upgrade 1809+
What I do wrong? How I can upgrade OS?


Congratulations; it looks as though you have solved all of your 
iPXE-related issues.  Your system is successfully booting via iPXE from 
an iSCSI target, and you are able to install and run Windows 10 on an 
iSCSI disk.


Your Windows upgrade error is very firmly in the domain of "generic 
Windows problem" and is not related to iPXE.


You could start with the Microsoft troubleshooting advice for your error 
code 0xc1900101 at


https://support.microsoft.com/en-us/windows/get-help-with-windows-10-upgrade-and-installation-errors-ea144c24-513d-a60e-40df-31ff78b3158a

Good luck!

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Install Windows 10 via http

[Michael Brown]

On 03/02/2021 12:02, pat...@chojecki.it wrote:
Sorry for the poor english, but I have a problem with the ipxe 
configuration via http, on disk less client


https://ipxe.org/howto/winpe

I can install Windows 10 Enterprise LTSC 2019, but I can't install other 
Windows.

Im check Windows 10 Professional 1809, 1709 and latest. Crash over install.
Windows 10 Enterprise Crash over boot after install.

Config in attachment.

What am I doing wrong? How i can install Windows 10 Pro, on disk less client


Thank you for the detailed problem description (in the PDF)!  This is 
one of the best problem reports I have ever seen: you have included your 
configuration details plus screenshots showing exactly what happened.


Since the error has occurred within Windows Setup, you can examine the 
Windows setup log for more details.  Immediately after the "Windows 
installation cannot continue" message appears, you should be able to 
find the setup log in X:\Windows\panther\setupact.log


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] enable bin/ipxe.iso target to build on FreeBSD (#42)

[Michael Brown]

Closed #42.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/42#event-4268487577___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] enable bin/ipxe.iso target to build on FreeBSD (#42)

[Michael Brown]

This has been forward-ported and merged as 
https://github.com/ipxe/ipxe/commit/9557497e7 and 
https://github.com/ipxe/ipxe/commit/25b675c3d

Thank you!

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/42#issuecomment-770112583___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] enable bin/ipxe.iso target to build on FreeBSD (#42)

[Michael Brown]

@mcb30 commented on this pull request.



> @@ -120,7 +120,7 @@ case "${LEGACY}" in
;;
0)
# copy isolinux bootloader
-   cp ${ISOLINUX_BIN} ${dir}
+   install -m 644 ${ISOLINUX_BIN} ${dir}

Merged (in the replacement `util/genfsimg`) as 
https://github.com/ipxe/ipxe/commit/25b675c3d

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/42#pullrequestreview-579694643___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] enable bin/ipxe.iso target to build on FreeBSD (#42)

[Michael Brown]

@mcb30 commented on this pull request.



> @@ -58,19 +58,19 @@ NON_AUTO_MEDIA+= iso
 %iso:  %lkrn util/geniso
$(QM)$(ECHO) "  [GENISO] $@"
$(Q)ISOLINUX_BIN=$(ISOLINUX_BIN) LDLINUX_C32=$(LDLINUX_C32) \
-   VERSION="$(VERSION)" bash util/geniso -o $@ $<
+   VERSION="$(VERSION)" bash -e util/geniso -o $@ $<

`util/geniso` and `util/gensdsk` have been replaced with `util/genfsimg` which 
already includes a `set -e` within the script itself.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/42#pullrequestreview-579694405___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] enable bin/ipxe.iso target to build on FreeBSD (#42)

[Michael Brown]

@mcb30 commented on this pull request.



> @@ -95,6 +95,8 @@ SYSLINUX_DIR_LIST   := \
/usr/share/syslinux/modules/bios \
/usr/local/share/syslinux \
/usr/local/share/syslinux/bios \
+   /usr/local/share/syslinux/bios/core \
+   /usr/local/share/syslinux/bios/com32/elflink/ldlinux \

Merged (in the replacement `util/genfsimg`) as 
https://github.com/ipxe/ipxe/commit/9557497e7

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/42#pullrequestreview-579692599___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] chain http and "slow" network interfaces

[Michael Brown]

On 24/11/2020 20:13, Etienne Champetier wrote:

To work around situations where we can't run DHCP or ProxyDHCP, we
build a simple iPXE iso that loop on all interfaces and try to chain
to a predefined local link IPv6.
It works well until on some server the interface takes ~40s to
transmit anything (likely stp)
I've tried to use "chain --timeout 6 ..." but it timeouts after
15s, and ND are sent only for 10s in my tests.

For now I'm using a simple loop
~~
set chaincur:int32 0
set chainmax:int32 12
:loop_chain
chain --timeout 5000
http://[fe80::616e:6576:6961]/ipxe/${net${i}/hwaddr:hexhyp}.ipxe ||
inc chaincur && iseq ${chaincur} ${chainmax} || goto loop_chain
~~

I was wondering if it was the best way to really retry for 60s


That's probably the best way to handle it, if you really do have network 
infrastructure that imposes 40s delays on forwarding packets.


There is some limited support in iPXE that will defer DHCP timeout if it 
detects a "blocked link" (e.g. a non-forwarding STP port).  However, 
this will not help in your situation since you are not using DHCP.


The "iflinkwait" command could be extended to allow waiting for a link 
to become unblocked, but this is non-trivial since it is usually 
possible to detect a blocked link only once we start attempting to use it.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] EFI TPL for efi_currticks()

[Michael Brown]

On 08/12/2020 16:22, Petr Borsodi wrote:

why efi_currticks function restores the TPL to an "external" TPL (especially 
TPL_APPLICATION) and raises it back to TPL_CALLBACK?

This would not be necessary if the timer used TPL_NOTIFY for its event.


There are other system timers that may be running, that also need to be 
allowed to execute.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] ipxe issue with http server permission denied

[Michael Brown]

On 14/12/2020 13:25, Yi Yi3 Liang wrote:
I have encountered a problem and need to ask you in the process of 
setting up the ipxe environment,and this problem is described as follows:


The permission denied during ipxe boot due to my http server(Nginx for 
ubuntu) comes with username and password authentication:


So, how should I add the authentication code in the the following 
menu.ipxe file?


Official website navigation for this issue: https://ipxe.org/err/024361


HTTP basic authentication usernames and passwords are specified via the 
URI using the standard URI syntax:


  http://user:password@host:port/path

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Custom syslog port

[Michael Brown]

On 18/11/2020 11:46, Michael Schaller wrote:

Michael, a syslog URI sounds like a good idea to me.

I'm not aware of any RFC other than
https://tools.ietf.org/html/draft-lear-ietf-syslog-uri-00, which
proposes a rather odd URI syntax IMHO.
Others seem to use URIs like `[tcp/udp]://host:port` or they have
their own schemes.
I personally find a standard URI more idiomatic and it looks like this
could be nicely handled by `uribase`, which is currently an open iPXE
pull request: https://github.com/ipxe/ipxe/pull/114

URI examples:
* 
https://www.netiq.com/documentation/securelogin-88/installation_guide/data/b1hxlq7p.html
* 
https://docs.newrelic.com/docs/logs/enable-log-management-new-relic/enable-log-monitoring-new-relic/forward-your-logs-using-infrastructure-agent

Custom schemes examples:
* 
https://www.grandmetric.com/knowledge-base/design_and_configure/syslog-configure-syslog-server-logging-cisco/
* https://www.debian.org/releases/buster/amd64/ch05s03.en.html#installer-args


Thank you for doing the research.

We do already have support for `[tcp/udp]://host:port` as a URI syntax 
in iPXE so this could be a good minimal-code-size approach, given that 
there seems to be no globally agreed standard to which to conform.


We would still need to support the existing ${syslog} setting as an IPv4 
address (and only an IPv4 address), to maintain backwards compatibility 
and to allow for the syslog server to be set via DHCP option 7.


This suggests defining a new setting e.g. ${sysloguri} or ${loguri} and 
updating apply_syslog_settings() to something like:


- if ${sysloguri} is defined, then use that

- else if ${syslog6} is defined, then use that

- else if ${syslog} is defined, then use that

- use xfer_open_uri_string() or xfer_open_socket() as applicable for the 
choice taken


Given that a TCP connection (unlike UDP) can be closed by the remote 
end, it may also be worth separating out the xfer_open_*() logic and 
allowing the connection to be reopened if needed.


It may then be worth defining a syslogs:// URI opener (for 
syslog-over-TCP+TLS as already supported in syslogs.c), and potentially 
consolidating some of the logic between syslog.c and syslogs.c, while 
ensuring that the TLS stack doesn't get dragged in to builds that don't 
explicitly request it.


Please don't dive in to implement it yet, but does that sound sensible?

Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Custom syslog port

[Michael Brown]

On 17/11/2020 20:44, Geert Stappers wrote:

On Tue, Nov 17, 2020 at 08:17:35PM +0100, Michael Schaller wrote:

On Tue, Nov 17, 2020 at 6:08 PM "Please elaborate" wrote:

On Tue, Nov 17, 2020 at 05:54:04PM +0100, Michael Schaller wrote:

So are there any comments or opinions on this feature request?


Please elaborate


I thought I did that with the previous reply:
https://lists.ipxe.org/pipermail/ipxe-devel/2020-November/007331.html

I'm happy to go into further detail or answer further questions...


Reveal your agenda:-)


Geert,

I personally find the explanation as already provided to be perfectly 
adequate.  There is no need to demand anything further.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Custom syslog port

[Michael Brown]

On 12/11/2020 12:56, Michael Schaller wrote:

We do automated installation testing for a whole array of different
hardware models (similar to https://autotest.github.io/).
Each machine logs to a dedicated syslog endpoint so that we have one
dedicated log per installation attempt per machine.
We create these syslog endpoints on demand per installation attempt
per machine on a central syslog service to collect the installer logs.
As this central syslog service needs to provide many syslog endpoints
at a given time we use whatever port is available when we create a new
endpoint.
A syslog endpoint will be given to the respective installer via an on
demand created ipxe script and it would be nice if we could also
collect the syslog of that on demand created ipxe script.


It wouldn't be a big code change to allow a custom port to be specified,
but I'd want to be convinced that it was necessary.


I'm aware that this is an incredibly exotic setup and this would be a
nice to have for us. So feel free to deny this feature request. ;-)


Thanks for the explanation.  It is a fairly exotic requirement.  I would 
be more comfortable implementing a more generic solution that e.g. 
allows a syslog URI to be specified, since that would allow for 
specifying a syslog server via DNS name as well as providing a port. 
Questions from me are therefore:


a) would a syslog URI setting work for your use case?

b) are you aware of any RFC (or similar) efforts to define a syslog URI?

Thanks,

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Custom syslog port

[Michael Brown]

On 12/11/2020 11:46, Michael Schaller wrote:
We use a central syslog service that provides syslog endpoints on a 
per-host basis with a random port per endpoint.


How hard would it be to add an iPXE setting that allows to configure the 
syslog port?
Something like `set syslog-port PORT` or `set syslog IP:PORT` would work 
for us.


The ${syslog} setting is an IPv4 address (with roots in the fact that it 
can be provided via DHCP option 7, in the form of an IPv4 address). 
There is an equivalent ${syslog6} setting for IPv6.


Any particular reason why the central syslog service needs to use 
separate ports per host?  As an RFC-defined protocol, syslog expects to 
receive messages from multiple hosts anyway, and every syslog 
implementation I've seen has the ability to utilise the remote host 
address in onward routing.


It wouldn't be a big code change to allow a custom port to be specified, 
but I'd want to be convinced that it was necessary.


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] How to reduce the image size

[Michael Brown]

On 18/09/2020 02:10, 丰立波 wrote:
I am testing the iPxe on a MIPS platform, the final image of snponly is 
about 900kB, and the network driver of the UEFI has some problem, it is 
very slow when downloading the iPxe image, and always fails with 
timeout. And even worse, the UEFI is already deployed, can't be changed. 
So, I think it could work to make a small iPxe image with the minimal 
functionalities for the defective UEFI.


There is no existing MIPS port of iPXE.  I am assuming that you may have 
modified the build process to support MIPS.  In doing so, you would have 
needed to provide implementations for several per-CPU-architecture 
functions.


My guess is that you have probably chosen to link in an external C 
library in order to achieve this, and that the bulk of your code size is 
coming from this external library.


Without seeing your modified code, we cannot sensibly help you.  You 
will need to publish the code in accordance with the GPL at some point 
anyway, so you may as well publish it now.


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] How to reduce the image size

[Michael Brown]

On 17/09/2020 10:15, 丰立波 wrote:
The size of snponly.efi is somewhat big for us, we just want a minimal 
functionality, how to reduce the image size in a good way.


You can disable features via the config/*.h files.

Out of interest, why do you need it reduced?  160kB is negligible on any 
current LAN, and UEFI does not have the same memory constrains as legacy 
BIOS.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] About run iPXE.efi but display No configuration methods successed

[Michael Brown]

On 31/08/2020 07:55, yupai_...@clevo.com.tw wrote:
We are currently receiving customer complaints about using iPXE, I want 
to ask about the implementation process of iPXE.


We run iPXE.efi on the local machine, and No configuration methods 
succeeded appears.


In the UEFI BIOS, is there any protocol failure to call that causes this 
message?


As per the error page at http://ipxe.org/040ee186 that error simply 
indicates that iPXE has not received any reply from the DHCP server. 
Check your DHCP server configuration.


Thanks,

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] ESX doesnt work after IPXE upgrade

[Michael Brown]

On 27/08/2020 07:41, Pothana Golla wrote:

OLD version is IPXE 1.0.0+ (827dd) and new Version IPXE 1.20.1+ (g9ee70)


Thank you.  As per Christian's suggestion, please follow the 
instructions at https://ipxe.org/howto/bisect to determine the commit 
that caused your problem.


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] can snponly.efi run without NII protocol installed?

[Michael Brown]

On 26/08/2020 09:31, 丰立波 wrote:

Thank for the support.

I skip the bs->DisconnectController in the function of 
efi_driver_connect, and my all protocols installed on a NIC controller 
can be kept. When bs->ConnectController is called, there already exist 
the SNP protocol, a new SNP protocol can't be installed. by this way, my 
own SNP protocol can keep on and serve others.


You seem to be ignoring what I am telling you.

Again:

* Your custom UEFI driver stack has the incorrect hierarchy of handles.

* Your SNP driver should bind to a hardware device handle and then 
install EFI_SIMPLE_NETWORK_PROTOCOL onto a new handle.


You must first fix your own SNP driver as I have described.

Your SNP driver will then work with iPXE as expected, without any hacks 
such as skipping the call to bs->DisconnectController.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Params is not supported

[Michael Brown]

On 26/08/2020 10:49, 丰立波 wrote:
Thank a lot. Mr. Nilsson. it is exactly the definition in 
src/ipxe/src/config/general.h


As per the documentation, you will need to add

  #define PARAM_CMD

in the relevant file (e.g. config/local/general.h) before building.

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] can snponly.efi run without NII protocol installed?

[Michael Brown]

On 25/08/2020 07:35, 丰立波 wrote:
MAC(3C6A2CB0886A, 0x1) is a hardware device, but not on a PCIe bus. Can 
iPxe install its own SNP protocol on this kind of device? or iPxe just 
use the original SNP protocol on the hardware device?


As I stated in my previous message:

It looks as though your custom UEFI driver stack has the incorrect 
hierarchy of handles.  My guess is that you may have some 
platform-specific driver providing the MAC(3C6A2CB0866A,0x1) handle as 
though it were a hardware device, and that your SNP driver then binds to 
this existing handle and installs EFI_SIMPLE_NETWORK_PROTOCOL as an 
additional protocol.


This would be incorrect behaviour: the SNP driver should bind to a 
hardware device handle and then install EFI_SIMPLE_NETWORK_PROTOCOL onto 
a new handle.


Try building with DEBUG=efi_driver:3 (which will dump additional 
information about the handle before and after disconnection).


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade

[Michael Brown]

On 24/08/2020 14:27, Dentcho Bankov wrote:

Confirmed.

Your change had solved the problem I observed when building iPXE in our 
official build environment where we use gcc-4.5.3 and binutils-2.17.50.0.15.

Thank you very much for taking care of this!


Thanks for confirming: have merged to master as

  http://github.com/ipxe/ipxe/commit/4bd064de2

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] can snponly.efi run without NII protocol installed?

[Michael Brown]

On 24/08/2020 10:34, 丰立波 wrote:
I get more trace, please take a look at the screenshot attached. In the 
function of efi_set_autoboot, a SNP protocol can be found on my NIC 
device handle, the local SNP protocol. Then, in the function of 
chained_supported, the SNP procotocol can still be found on my NIC 
device handle. However, later, in the function of startup in the file of 
init.c, the function of snpnet_start isn't listed in the startup 
function table, snpnet_start is not called. so, what wrong with it?


snpnet_start is unrelated to the startup functions handled by init.c. 
"git grep snpnet_start" will show you that snpnet_start is used as the 
.start method for struct efi_driver snp_driver in snp.c.


See my other email for suggested next debugging steps.

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] can snponly.efi run without NII protocol installed?

[Michael Brown]

On 20/08/2020 10:28, 丰立波 wrote:

I get a screenshot for debugging:
I think iPxe tried to replace the SNP protocol of my UEFI land with its 
own SNP driver(the driver code is in the directory of 
ipxe/src/drivers/net/efi/), first ipxe disconnect the my uefi driver, 
then connect its own driver, but at this point, connection failed.


There are two questions:
1. why the new connection failed?
2. Why iPXE try to replace my uefi driver, could iPxe just use the 
original driver? Thanks.


iPXE needs to disconnect other drivers (e.g. MnpDxe) from the SNP 
handle, so that it can have exclusive access to the network device.


From the screenshot it looks as though your custom UEFI driver stack 
has the incorrect hierarchy of handles.  My guess is that you may have 
some platform-specific driver providing the MAC(3C6A2CB0866A,0x1) handle 
as though it were a hardware device, and that your SNP driver then binds 
to this existing handle and installs EFI_SIMPLE_NETWORK_PROTOCOL as an 
additional protocol.


This would be incorrect behaviour: the SNP driver should bind to a 
hardware device handle and then install EFI_SIMPLE_NETWORK_PROTOCOL onto 
a new handle.  You can see this in action on a standard x86 UEFI system: 
the hardware device handle will be e.g.


  PciRoot(0x0)/Pci(0x3,0x0)

and the SNP device handle will then be e.g.

  PciRoot(0x0)/Pci(0x3,0x0)/MAC(525400123456,0x1).

Try building with DEBUG=efi_driver:3 (which will dump additional 
information about the handle before and after disconnection).


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade

[Michael Brown]

On 22/08/2020 10:06, Dentcho Bankov wrote:

First in my previous e-mail I've made a mistake about the version of the 
compiler I'm using. And the problem I'm observing is with:
1. gcc-4.5.3
2. binutils-2.17.50.0.15

I confirmed that with gcc-9.3 on Ubuntu 2020 everything works fine.

I did a binary search and surprisingly the change which causes the problem for 
me appeared to be 
https://github.com/ipxe/ipxe/commit/bb74f00512995f15bf61517fc039f32713e0af73#diff-25d902c24283ab8cfbac54dfa101ad31

The surprising part is that this change just adds a bunch of "extern" 
statements in asn1.h which for some reason changes the alignment of the asn1_algorithms 
link table. Further it seems these are added only to support some test code in rsa_test.c 
so to resolve my problem I just moved the extern statements from asn1_algorithms to the 
rsa_test.c.

So I'm writing this e-mail to also ask if it's worth posting the above change 
(moving the extern statements to rsa_test.c) as a pull request.


Thank you for researching and following up!

I suspect this relates to the fact that the extern declarations are 
missing the __asn1_algorithm modifiers.  I vaguely remember that gcc 
used to require __attribute__((aligned(...))) to be specified on the 
first declaration of a symbol.


I've created a pull request for this:

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

Could you let me know if this fixes the problem on gcc 4.5.3?

Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade

[Michael Brown]

On 20/08/2020 10:54, Dentcho Bankov wrote:
I’ve just pulled the latest iPXE code (after more than a couple of 
years) and started getting a http://ipxe.org/3c00e183 error when trying 
to boot over HTTPS.


Investigating a bit revealed that in my iPXE binary the asn1_algorithms 
link table entries are offset by 48 bytes while the size of the asn1 
_algorithm struct is 40 bytes so the ‘for_each_table_entry ( algorithm, 
ASN1_ALGORITHMS )’ doesn’t cycle over the asn1_algorithms in the link 
table correctly.


I tried adding a dummy field of 8 bytes to the asn1_algortihm struct 
which resolved the above error but then I started receiving 
http://ipxe.org/420c6095 so I suspect I’m not building iPXE correctly.


Could you please let me know if somebody else had observed a similar 
problem lately and what may be causing it (I suspect this may be related 
to some alignment/padding misconfiguration but don’t know how this is 
controlled).


Interesting.  Which compiler are you using?

We've had previous issues with icc adding unexpected packing, but I have 
not seen this problem with gcc.


Thanks,

Michael

___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] can snponly.efi run without NII protocol installed?

[Michael Brown]

On 19/08/2020 11:48, 丰立波 wrote:
The network interface controller in our platform only installs the SNP 
protocol, not install NII protocol. Is snponly.efi dependent on NII 
porotocol? now after chainloading snponly.efi, the function of autoboot 
can't find any network device in our platform, and then enter the shell. 
Is NII protocol necessary for the snponly.efi?


No, you do not need an NII protocol.  iPXE will work with your 
platform's SNP protocol.


You can build iPXE with DEBUG=efi_driver,snpnet to see any errors 
arising during detection of the NIC.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform

[Michael Brown]

On 18/08/2020 02:50, 丰立波 wrote:
How to build a iPxe only using UNDI/NII or SNP protocol provided by the 
UEFI platform firmware? The NIC card is very special in our platform, 
iPxe could not use it.


Either the bin-arm64-efi/ipxe.efi or bin-arm64-efi/snp.efi build targets 
will work.  Since iPXE will not have a native driver for your NIC, it 
will automatically fall back to using the UNDI/NII or SNP driver.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform

[Michael Brown]

On 17/08/2020 11:59, 丰立波 wrote:
My understanding of chainloading is iPxe will use the local Network 
Protocol already installed by UEFI network drivers, instead of 
installing its own network protocol. Is that correct? If yes, it is 
exactly we want. but we have a ARM64 platform, How to build a 
chainloading iPxe. I tried the command:


Yes, iPXE is capable of using the UNDI/NII or SNP protocols provided by 
the UEFI platform firmware.  It can also use its own native driver 
(which will usually be faster), if available.


To build, use

  make bin-arm64-efi/ipxe.efi

or

  make bin-arm64-efi/snp.efi

If you are cross-compiling then you will need to specify your 
cross-compilation prefix.  For example, to build an ARM64 binary on an 
x86_64 Fedora distro:


  make bin-arm64-efi/ipxe.efi CROSS=aarch64-linux-gnu

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] appnote/debian_preseed instructions are wrong

[Michael Brown]

On 12/08/2020 08:50, Etienne Champetier wrote:

The automagical construction of CPIO archives is indeed for legacy BIOS
only.  On UEFI, we provide the kernel with a virtual filesystem from
which it can load arbitrary files without needing a CPIO wrapper.


Do you have a working exemple (maybe I need a special path) ?
Does it need a recent kernel ? (I think I did my tests with CentOS 7 kernel)
Does it need a specific ipxe compile option ?


No specific iPXE compile option.  Any kernel built with CONFIG_EFI_STUB 
should work, which includes all current distro kernels as far as I know.


Any image downloaded by iPXE will be available within the virtual 
filesystem using the filename as shown by "imgstat".  Linux can access 
these files using the initrd= kernel command-line argument.


In the most simple example, something like:

  #!ipxe
  kernel http://boot.ipxe.org/demo/vmlinuz initrd=initrd.img
  initrd http://boot.ipxe.org/demo/initrd.img
  boot

From memory, the initrd= option supports a comma-separated list.  I 
can't immediately find documentation to support this, though.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] appnote/debian_preseed instructions are wrong

[Michael Brown]

On 03/08/2020 12:03, Robin Smidsrød wrote:

I seem to recall that this initrd/cpio magic described in the document
only works on legacy BIOS, not EFI.


The automagical construction of CPIO archives is indeed for legacy BIOS 
only.  On UEFI, we provide the kernel with a virtual filesystem from 
which it can load arbitrary files without needing a CPIO wrapper.


Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] https booting

[Michael Brown]

On 22/07/2020 15:13, Daniel P. Berrangé wrote:

We could easily define etc/ipxe/https/{ciphers,cacerts} paths in a
different format if better suited for iPXE. Libvirt can set the right
path depending on whether its booting a VM with EDK2 vs legacy BIOS


The most useful for iPXE would probably be to expose the fw_cfg 
mechanism as a URI scheme.  This would give a general mechanism allowing 
for use cases such as running a script provided by the host via e.g.


  chain fw_cfg:///opt/org.example/script.ipxe

The ${crosscert} setting could then be pointed at a base URL within the 
fw_cfg space, e.g.


  #define CROSSCERT "fw_cfg:///etc/ipxe/crosscert/auto"

This would then work in the same way under either BIOS or UEFI (or other 
custom firmware), would provide a feature with applicability broader 
than just obtaining certificates, and would avoid any potential problems 
from allocating enough RAM to parse every root certificate from iPXE's 
fixed 512kB internal heap.


What do you think?

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] https booting

[Michael Brown]

On 22/07/2020 14:21, Michael Brown wrote:

After looking at https://ipxe.org/cfg/crosscert I'm not convinced this
is a good idea though.  This would likely put quite some load to
ca.ipxe.org.  Also that machine becomes a single point of failure for
worldwide ipxe https boot, and looking through the mailing list I've
seen we already had (at least) two outages this year.


The crosscert fetches are static files (with iPXE including a query 
string only for debugging purposes), and it should be fairly 
straightforward for me to switch to hosting them in AWS S3 or 
equivalent.  The ca.ipxe.org domain is not used for anything else so 
could be pointed at a new hosting infrastructure with no disruption or 
code changes.


I've created https://github.com/ipxe/ipxe/issues/126 to track this part 
of the development work.  Please feel free to review the issue and add 
anything you think might be relevant.


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] https booting

[Michael Brown]

On 22/07/2020 13:08, Gerd Hoffmann wrote:

With the world moving to use https by default people start to ask for
https being enabled by default for the qemu boot roms.

We could simply flip the DOWNLOAD_PROTO_HTTPS switch in
src/config/qemu/general.h (ipxe git repo).  Note that this would only
affect booting in bios mode, for uefi qemu uses the efidrv builds which
implies https support is in the hands of the uefi firmware (edk2/ovmf).


The .efidrv builds can be used for booting via either the UEFI PXE flow 
(using iPXE as just a NIC driver) or via the iPXE flow (using iPXE as an 
application invoked via the NIC driver's EFI_LOAD_FILE_PROTOCOL entry 
point), so it might still be relevant to UEFI as well as BIOS.



After looking at https://ipxe.org/cfg/crosscert I'm not convinced this
is a good idea though.  This would likely put quite some load to
ca.ipxe.org.  Also that machine becomes a single point of failure for
worldwide ipxe https boot, and looking through the mailing list I've
seen we already had (at least) two outages this year.


The crosscert fetches are static files (with iPXE including a query 
string only for debugging purposes), and it should be fairly 
straightforward for me to switch to hosting them in AWS S3 or 
equivalent.  The ca.ipxe.org domain is not used for anything else so 
could be pointed at a new hosting infrastructure with no disruption or 
code changes.


I would worry more about the OCSP service for the cross-signed 
certificates, since OCSP does not just serve static responses.  This 
service is currently implemented using openca-ocspd running on a VM in 
AWS.  I'm very open to suggestions on more scalable ways to host this.



What happens if you sent crosscert to the empty string?


An empty string is equivalent to a deleted setting, so it will fall back 
to using the compiled-in default.



Will ipxe fail or will it boot without cert verification?


iPXE does need to be able to construct a full certificate chain leading 
back to its trusted root certificate.  If the crosscert source is 
unavailable then otherwise valid certs will be treated as invalid since 
the information required to validate them is not avaiable.



What does it take to mirror http://ca.ipxe.org/auto/?
Just "wget -r" everything and serve it?


For the crosscert files, yes.  There's still OCSP to think about; see above.


How does edk2 handle the root ca problem?


I'm also curious to know!

Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Improved NII driver logging (#39)

[Michael Brown]

This doesn't seem to add any information that isn't already available via 
`DEBUG=nii:3`, and introduces some unrelated whitespace changes.  Marking as 
rejected.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/39#issuecomment-662143166___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Improved NII driver logging (#39)

[Michael Brown]

Closed #39.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/39#event-3573394672___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

[ipxe-devel] [ipxe/ipxe] file:/ URIs for USB key after loading native USB drivers (#123)

[Michael Brown]

### Description

As a user, I want to be able to use the `file:/` URI syntax to refer to local 
files on a USB key from which iPXE was loaded even if iPXE includes native USB 
host controller drivers, since I expect this to work regardless of which 
drivers are included in the build.

Using the `file:/` URI syntax to refer to local files on a USB key from which 
iPXE was loaded will currently fail if the iPXE binary includes native USB host 
controller drivers, since iPXE's loaded image device handle will cease to be 
valid when iPXE disconnects the platform host controller drivers.

There is no way to prevent the loaded image's device handle from becoming 
invalid, so an alternative matching strategy will be required.  Recording the 
device path at startup and matching on device path may be a viable approach.

It may also be worth identifying other uses of `efi_loaded_image->DeviceHandle` 
to see if similar workarounds are required there.

### Acceptance criteria

* [ ] Ability to boot `bin-x86_64-efi/ecm.usb` (or other iPXE binary with 
native USB host controller drivers) from a USB key and to subsequently execute 
a script held on the USB key using the `file:/` URI syntax (with absolute path 
and no volume label, e.g. `chain file:/script.ipxe`)
* [ ] Other uses of `efi_loaded_image->DeviceHandle` have been identified and 
triaged

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/issues/123___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] IPXE fails to boot CentOS 8 (#122)

[Michael Brown]

Try instead:
```
:centos8m
kernel CentOS8.2x64/vmlinuz initrd=initrd.img 
ks=http://10.1.13.195/Centos8/kickstart-manual
initrd CentOS8.2x64/initrd.img
boot
```
(i.e. move the kernel command line arguments to the `kernel` line, and remove 
`ksdevice=bootif`)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/issues/122#issuecomment-661917854___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Fix typo in comment describing length codes (#121)

[Michael Brown]

Closed #121.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/121#event-3571721743___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Fix typo in comment describing length codes (#121)

[Michael Brown]

Merged as http://github.com/ipxe/ipxe/commit/8bc85ec6f; thanks

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/121#issuecomment-661914693___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Fix a GNUism that FreeBSD's sed(1) cannot deal with (#85)

[Michael Brown]

Closed #85.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/85#event-3571696996___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Fix a GNUism that FreeBSD's sed(1) cannot deal with (#85)

[Michael Brown]

Merged as http://github.com/ipxe/ipxe/commit/8d243e65c - thank you!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/85#issuecomment-661911930___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] successful wpa handshake (memcmp polarity) (#103)

[Michael Brown]

Closed #103.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/103#event-3571626809___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] successful wpa handshake (memcmp polarity) (#103)

[Michael Brown]

Good catch; thanks.  Pushed the memcmp fix as 
http://github.com/ipxe/ipxe/commit/0de5e6014 and pushed a simpler fix for the 
wpa_derive_ptk debug message as http://github.com/ipxe/ipxe/commit/ee2dc525b

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/103#issuecomment-661904071___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Fix pcbios memory accounting bug (#105)

[Michael Brown]

Looks good; thank you.  Merged as

  http://github.com/ipxe/ipxe/commit/45a0ca6de
  http://github.com/ipxe/ipxe/commit/6ec33b8d6

Thank you for debugging!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/105#issuecomment-661886196___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Fix pcbios memory accounting bug (#105)

[Michael Brown]

Closed #105.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/105#event-3571477118___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Change __divmoddi4 from int64 [unknown] to int64_t (#59)

[Michael Brown]

Closed #59.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/59#event-3571314819___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Change __divmoddi4 from int64 [unknown] to int64_t (#59)

[Michael Brown]

Merged in http://github.com/ipxe/ipxe/commit/cede0c5ba; thank you!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/59#issuecomment-661866855___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] gensdsk: fix default target (#76)

[Michael Brown]

Merged as http://github.com/ipxe/ipxe/commit/4277942ac; thank you.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/76#issuecomment-661862764___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] gensdsk: fix default target (#76)

[Michael Brown]

Closed #76.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/76#event-3571280770___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Add support for Solarflare SFN7122F 10Gb NIC (#110)

[Michael Brown]

Closed #110.

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/110#event-3562574413___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [ipxe/ipxe] Add support for Solarflare SFN7122F 10Gb NIC (#110)

[Michael Brown]

I think this PCI ID is included in commit 78ca890c3

-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/ipxe/ipxe/pull/110#issuecomment-660643060___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] [sfc] Add PCI ID for Solarflare SFC9120 and Solarflare SFC9140

[Michael Brown]

On 14/07/2020 16:59, LaDerrick H wrote:

This patch adds support for 2 Solarflare NICs.


Applied, thank you.

  http://github.com/ipxe/ipxe/commit/78ca890c3

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel

Re: [ipxe-devel] hardware support

[Michael Brown]

On 07/05/2020 03:21, Feng Guo wrote:
so I google the 
error->https://forum.ipxe.org/showthread.php?tid=17335->https://ipxe.org/appnote/buildtargets->https://ipxe.org/appnote/hardware_drivers


15b3:1018, which is ConnectX-5 VF, is not there, while 
15b3:1017(ConnectX-5) is there. I assume the code just check ConnectX-5 
instead of its VF.


Do you have any idea about this?


You could try adding a PCI_ROM() line to the appropriate place in 
drivers/infiniband/golan.c.  Whether or not it works depends on how 
closely the virtual function matches the physical function, in terms of 
the register programming interface.


You could also contact Mellanox to see if they are able to offer support 
for this.


Thanks,

Michael
___
ipxe-devel mailing list
ipxe-devel@lists.ipxe.org
https://lists.ipxe.org/mailman/listinfo/ipxe-devel