From kraxel at redhat.com Mon Aug 3 07:37:14 2020 From: kraxel at redhat.com (Gerd Hoffmann) Date: Mon, 3 Aug 2020 09:37:14 +0200 Subject: [ipxe-devel] https booting In-Reply-To: <411ac2fb-1f3e-28f0-5c9a-6ff0806cfbf7@ipxe.org> References: <20200722120827.dq72uabrk26nllra@sirius.home.kraxel.org> <20200722122347.GF2324845@redhat.com> <20200722135538.wvblddvskp5j4wik@sirius.home.kraxel.org> <20200722141318.GJ2324845@redhat.com> <411ac2fb-1f3e-28f0-5c9a-6ff0806cfbf7@ipxe.org> Message-ID: <20200803073714.aeqffoct2l66ahrz@sirius.home.kraxel.org> On Fri, Jul 24, 2020 at 05:19:38PM +0100, Michael Brown wrote: > 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 Looks useful. (coreboot folks might want add cbfs: support). > 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. Well, it isn't that easy. fw_cfg isn't designed for a large number of files, and right now there is a hard limit of (IIRC) 32 entries. While adding an entry or two isn't that much of a problem, adding all *.der files (228 right now) hosted @ http://ca.ipxe.org/auto/ individually certainly is. So, we'll have to pass a certificate bundle as single file and have ipxe pick the certificate it needs from it. take care, Gerd From kraxel at redhat.com Mon Aug 3 08:04:37 2020 From: kraxel at redhat.com (Gerd Hoffmann) Date: Mon, 3 Aug 2020 10:04:37 +0200 Subject: [ipxe-devel] https booting In-Reply-To: <73923bb0-0a75-d8f1-fa49-87994e5354db@ipxe.org> References: <20200722120827.dq72uabrk26nllra@sirius.home.kraxel.org> <73923bb0-0a75-d8f1-fa49-87994e5354db@ipxe.org> Message-ID: <20200803080437.wlyslxdhuzlfacgn@sirius.home.kraxel.org> Hi, > > 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. It's also simple to create a mirror, for example to serve machines without direct internet connection. > 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. How much of the crosscert creation process is (or can can be) automated? Is it an option to update the certificates much more frequently? Say generate them every three days, be valid for 7 days (instead of 90)? Then just don't run a OCSP service? take care, Gerd From robin at smidsrod.no Mon Aug 3 11:01:28 2020 From: robin at smidsrod.no (=?UTF-8?Q?Robin_Smidsr=c3=b8d?=) Date: Mon, 3 Aug 2020 13:01:28 +0200 Subject: [ipxe-devel] [PATCH] [efi] implement api to convert pci address to host address In-Reply-To: References: <20200513125809.23216-1-pankaj.bansal@oss.nxp.com> Message-ID: <2acc4be6-47be-e308-6404-e2f4213d64c1@smidsrod.no> Not sure if this has been merged yet, but if not, try to add it as a pull request on the github repo, then it'll get more visibility. -- Robin On 2020-05-26 16:17, Pankaj Bansal wrote: > Hi Michael et. al > > Gentle ping. > > Regards, > Pankaj Bansal > >> -----Original Message----- >> From: Pankaj Bansal (OSS) >> Sent: Tuesday, May 12, 2020 6:29 PM >> To: Michael Brown >> Cc: ipxe-devel at lists.ipxe.org >> Subject: [PATCH] [efi] implement api to convert pci address to host address >> >> From: Pankaj Bansal >> >> The PCI device address may not be same as host address (CPU view address) >> To read/write directly to PCI device's BARs (without using >> EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Mem.Read() and >> EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Mem.Write()) we need to convert PCI >> device address to host address. >> >> The UEFI specifications 2.7 provide a method to translate the PCI device >> address to host address and vice versa. >> >> device address = host address + translation offset >> >> EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Configuration() method can provide us >> with >> the translation offset and host address range. >> >> Using this we can convert the PCI device address to host address. >> >> Signed-off-by: Pankaj Bansal >> --- >> src/include/ipxe/pci_io.h | 10 ++++ >> src/interface/efi/efi_pci.c | 60 ++++++++++++++++++++ >> 2 files changed, 70 insertions(+) >> >> diff --git a/src/include/ipxe/pci_io.h b/src/include/ipxe/pci_io.h >> index 10e69763..5806390d 100644 >> --- a/src/include/ipxe/pci_io.h >> +++ b/src/include/ipxe/pci_io.h >> @@ -122,4 +122,14 @@ int pci_write_config_word ( struct pci_device *pci, >> unsigned int where, >> int pci_write_config_dword ( struct pci_device *pci, unsigned int where, >> uint32_t value ); >> >> +/** >> + * retrieve Host Address corresponding to pci bus address >> + * >> + * @v pci PCI device >> + * @v bus_addr PCI Bus address >> + * @v len Length of region >> + * @ret io_addr Host address >> + */ >> +uint64_t pci_ioremap ( struct pci_device *pci, uint64_t bus_addr, size_t len ); >> + >> #endif /* _IPXE_PCI_IO_H */ >> diff --git a/src/interface/efi/efi_pci.c b/src/interface/efi/efi_pci.c >> index c1f451c9..b688210e 100644 >> --- a/src/interface/efi/efi_pci.c >> +++ b/src/interface/efi/efi_pci.c >> @@ -215,6 +215,66 @@ int efipci_write ( struct pci_device *pci, unsigned long >> location, >> return rc; >> } >> >> +/** >> + * retrieve Host Address corresponding to pci bus address >> + * >> + * @v pci PCI device >> + * @v bus_addr PCI Bus address >> + * @v len Length of region >> + * @ret io_addr Host address >> + */ >> +static uint64_t efi_pci_ioremap ( struct pci_device *pci, uint64_t bus_addr, >> + size_t len ) { >> + EFI_BOOT_SERVICES *bs = efi_systab->BootServices; >> + EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *root; >> + EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *config; >> + EFI_HANDLE handle; >> + EFI_STATUS efirc; >> + uint64_t bus_addr_start; >> + int rc; >> + >> + /* Identify root bridge */ >> + if ( ( rc = efipci_root ( pci, &handle, &root ) ) != 0 ) >> + goto err_root; >> + >> + /* Retrieves the current resource settings of this PCI root bridge */ >> + efirc = root->Configuration ( root, (void **) &config); >> + if (efirc != 0) { >> + rc = -EEFI ( efirc ); >> + DBGC ( pci, "EFIPCI " PCI_FMT "Retrieval of current resource " >> + "settings of PCI root bridge failed: %s\n", >> + PCI_ARGS ( pci ), strerror ( rc ) ); >> + goto err_configuration; >> + } >> + >> + /* According to UEFI 2.7, >> + * EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL::Configuration() >> + * returns host address instead of device address, >> + * while AddrTranslationOffset is not zero, and >> + * device address = host address + AddrTranslationOffset, so >> + * we convert host address to device address for range compare. >> + */ >> + while ( config->Desc == ACPI_ADDRESS_SPACE_DESCRIPTOR ) { >> + bus_addr_start = config->AddrRangeMin + >> + config->AddrTranslationOffset; >> + if ( ( config->ResType == ACPI_ADDRESS_SPACE_TYPE_MEM ) >> && >> + ( bus_addr_start <= bus_addr ) && >> + ( bus_addr_start + config->AddrLen >= bus_addr + len ) ) { >> + return ( bus_addr - config->AddrTranslationOffset ); >> + } >> + config++; >> + } >> + >> + return bus_addr; >> + >> +err_configuration: >> + bs->CloseProtocol ( handle, &efi_pci_root_bridge_io_protocol_guid, >> + efi_image_handle, handle ); >> +err_root: >> + return rc; >> +} >> + >> +PROVIDE_PCIAPI (efi, pci_ioremap, efi_pci_ioremap); >> PROVIDE_PCIAPI_INLINE ( efi, pci_num_bus ); >> PROVIDE_PCIAPI_INLINE ( efi, pci_read_config_byte ); >> PROVIDE_PCIAPI_INLINE ( efi, pci_read_config_word ); >> -- >> 2.17.1 > > _______________________________________________ > ipxe-devel mailing list > ipxe-devel at lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo/ipxe-devel > From robin at smidsrod.no Mon Aug 3 11:03:36 2020 From: robin at smidsrod.no (=?UTF-8?Q?Robin_Smidsr=c3=b8d?=) Date: Mon, 3 Aug 2020 13:03:36 +0200 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: References: Message-ID: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> I seem to recall that this initrd/cpio magic described in the document only works on legacy BIOS, not EFI. -- Robin On 2020-06-04 04:24, Etienne Champetier wrote: > Hello iPXE devs, > > The text at https://ipxe.org/appnote/debian_preseed suggests that you > can load a non cpio file, > put it as initrd= param, and that even for EFI mode iPXE will make a > cpio for you. > In my testing (and as discussed here > https://forum.ipxe.org/showthread.php?tid=7830&pid=11948#pid11948 by > others) > this is only working with cpio files when in EFI mode, so 2 questions: > - is this appnote/debian_preseed page just a design document that was > never implemented ? > - can someone update it to mention it's not working, or what options > are needed ? > > Thanks a lot > Etienne > _______________________________________________ > ipxe-devel mailing list > ipxe-devel at lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo/ipxe-devel > From mcb30 at ipxe.org Mon Aug 3 11:30:48 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Mon, 3 Aug 2020 12:30:48 +0100 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> References: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> Message-ID: <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> 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 From champetier.etienne at gmail.com Mon Aug 3 12:00:03 2020 From: champetier.etienne at gmail.com (Etienne Champetier) Date: Mon, 3 Aug 2020 15:00:03 +0300 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> References: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> Message-ID: Hi Michael Le lun. 3 ao?t 2020 ? 14:30, Michael Brown a ?crit : > > 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. Maybe I tested with an old version, but I was not able to load a file with relative path without it being a cpio in UEFI mode What worked for me, from an http server I chain load a ipxe script with something like ~~~~ kernel ../kernel/vmlinuz initrd=initrd.img initrd=myks.cfg.cpio inst.ks=file:/myks.cfg ... initrd ../kernel/initrd.img initrd ../ks/myks.cfg.cpio boot ~~~~ Etienne > > Michael From socha at socha.it Fri Aug 7 19:43:11 2020 From: socha at socha.it (Robert Socha) Date: Fri, 7 Aug 2020 21:43:11 +0200 Subject: [ipxe-devel] Passing parameters from PXELinux to iPXE Message-ID: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> Hi, This is more user-level question. But for last few days I'm unable to post question via forum.ipxe.org. I wonder if this supported option (passing parameters from PXELinux to iPXE) I have PXELinux boot: LABEL startipxe KERNEL ipxe.lkrn APPEND set MYVAR some-data And from chain loaded ipxe with embed script: #!ipxe echo MYVAR: ${MYVAR} ... other stuff I was unable to make this work (PXElinux from Ubuntu 20.04 syslinux package). I solved this for myself by some small hack in ipxe code. But I wonder if this should works out of the box? Best regards -- Robert Socha -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4038 bytes Desc: Kryptograficzna sygnatura S/MIME URL: From stappers at stappers.nl Fri Aug 7 20:20:09 2020 From: stappers at stappers.nl (Geert Stappers) Date: Fri, 7 Aug 2020 22:20:09 +0200 Subject: [ipxe-devel] Passing parameters from PXELinux to iPXE In-Reply-To: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> References: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> Message-ID: <20200807202009.vqak2lwebdllksab@gpm.stappers.nl> On Fri, Aug 07, 2020 at 09:43:11PM +0200, Robert Socha wrote: > Hi, > > This is more user-level question. But for last few days I'm unable to post > question via forum.ipxe.org. > > I wonder if this supported option (passing parameters from PXELinux to iPXE) > > > I have PXELinux boot: > > LABEL startipxe > KERNEL ipxe.lkrn > APPEND set MYVAR some-data > > And from chain loaded ipxe with embed script: > > #!ipxe > echo MYVAR: ${MYVAR} > ... other stuff > Why? > > > I was unable to make this work (PXElinux from Ubuntu 20.04 syslinux > package). > > I solved this for myself by some small hack in ipxe code. > > But I wonder if this should works out of the box? > > Best regards > -- > Robert Socha > > _______________________________________________ > ipxe-devel mailing list > ipxe-devel at lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo/ipxe-devel -- Groeten Geert Stappers -- Silence is hard to parse From socha at socha.it Fri Aug 7 20:44:50 2020 From: socha at socha.it (Robert Socha) Date: Fri, 7 Aug 2020 22:44:50 +0200 Subject: [ipxe-devel] Passing parameters from PXELinux to iPXE In-Reply-To: <20200807202009.vqak2lwebdllksab@gpm.stappers.nl> References: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> <20200807202009.vqak2lwebdllksab@gpm.stappers.nl> Message-ID: <83fc5fdb-22ec-d4d0-399c-045aa9c20fb1@socha.it> W dniu 07.08.2020 o?22:20, Geert Stappers pisze: > On Fri, Aug 07, 2020 at 09:43:11PM +0200, Robert Socha wrote: >> Hi, >> >> This is more user-level question. But for last few days I'm unable to post >> question via forum.ipxe.org. >> >> I wonder if this supported option (passing parameters from PXELinux to iPXE) >> >> >> I have PXELinux boot: >> >> LABEL startipxe >> KERNEL ipxe.lkrn >> APPEND set MYVAR some-data >> >> And from chain loaded ipxe with embed script: >> >> #!ipxe >> echo MYVAR: ${MYVAR} >> ... other stuff >> > > Why? > Thanks for asking. My use case is: I bootstrap hosts via PXELinux (I'm unable to change this - this internal DHCP's related issue). PXELinux templates are auto-generated via foreman (I know than I can try to replace (l)pxelinux.0 by ipxe binary - but this will require a lot of testing of other stuff). So host is booted via PXElinux, and I chain load IPXE via: DEFAULT boot LABEL boot KERNEL ipxe-foreman.lkrn APPEND ipxe:set PXEMAC MAC_FROM_TEMPLATE Where ipxe: part is my patch which parse img memory and pass this to system() function. Why I need that? I need this MAC address in my ipxe script to connect via same NIC (servers have more than one nic, and only one NIC is controlled by us/operator - other are user controlled and have user's DHCP servers too). I know that I can use undionly.kpxe - but this much slower than native drivers :) So i solved this by a little "hacking" in source code. And I only wonder if this "args passing" is any how supported in upstream iPXE? I trying to convince other co-workers to switch to native iPXE, but this will take some time. But after that the above will be for sure "my imaginary problem" :) Best regards -- Robert Socha From socha at socha.it Fri Aug 7 21:13:06 2020 From: socha at socha.it (Robert Socha) Date: Fri, 7 Aug 2020 23:13:06 +0200 Subject: [ipxe-devel] Passing parameters from PXELinux to iPXE In-Reply-To: <83fc5fdb-22ec-d4d0-399c-045aa9c20fb1@socha.it> References: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> <20200807202009.vqak2lwebdllksab@gpm.stappers.nl> <83fc5fdb-22ec-d4d0-399c-045aa9c20fb1@socha.it> Message-ID: <8845a8b6-ce54-c9e5-1e59-0e7bd26d5723@socha.it> W dniu 07.08.2020 o?22:44, Robert Socha pisze: > W dniu 07.08.2020 o?22:20, Geert Stappers pisze: >> On Fri, Aug 07, 2020 at 09:43:11PM +0200, Robert Socha wrote: >>> Hi, >>> >>> This is more user-level question. But for last few days I'm unable to >>> post >>> question via forum.ipxe.org. >>> >>> I wonder if this supported option (passing parameters from PXELinux >>> to iPXE) >>> >>> >>> I have PXELinux boot: >>> >>> LABEL startipxe >>> ?? KERNEL ipxe.lkrn >>> ?? APPEND set MYVAR some-data >>> >>> And from chain loaded ipxe with embed script: >>> >>> #!ipxe >>> echo MYVAR: ${MYVAR} >>> ... other stuff >>> >> >> Why? >> > > Thanks for asking. My use case is: > > I bootstrap hosts via PXELinux (I'm unable to change this -? this > internal DHCP's related issue). > > PXELinux templates are auto-generated via foreman (I know than I can try > to replace (l)pxelinux.0 by ipxe binary - but this will require a lot of > testing of other stuff). > > So host is booted via PXElinux, and I chain load IPXE via: > > DEFAULT boot > LABEL boot > ? KERNEL ipxe-foreman.lkrn > ? APPEND ipxe:set PXEMAC MAC_FROM_TEMPLATE > Another idea I have for this is: DEFAULT boot LABEL boot KERNEL /PXEMAC MAC_FROM_TEMPLATE/ipxe-foreman.lkrn And use pre-generated ipxe with embed MAC in script. Best regards -- Robert Socha From nikize at gmail.com Sat Aug 8 02:47:10 2020 From: nikize at gmail.com (Christian Nilsson) Date: Sat, 8 Aug 2020 04:47:10 +0200 Subject: [ipxe-devel] Passing parameters from PXELinux to iPXE In-Reply-To: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> References: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> Message-ID: On Fri, 7 Aug 2020, 21:43 Robert Socha, wrote: > Hi, > > This is more user-level question. But for last few days I'm unable to > post question via forum.ipxe.org. > > I wonder if this supported option (passing parameters from PXELinux to > iPXE) > > > I have PXELinux boot: > > LABEL startipxe > KERNEL ipxe.lkrn > APPEND set MYVAR some-data > > And from chain loaded ipxe with embed script: > > #!ipxe > echo MYVAR: ${MYVAR} > ... other stuff > > > > I was unable to make this work (PXElinux from Ubuntu 20.04 syslinux > package). > > I solved this for myself by some small hack in ipxe code. > > But I wonder if this should works out of the box? > > Best regards > -- > Robert Socha > > _______________________________________________ > ipxe-devel mailing list > ipxe-devel at lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo/ipxe-devel And so what actually happen when you use that append? Any error message or similar that is causing you issues? >From memory, any appended script will make the "autoboot" run that script, instead of the default DHCP and before all that any embedded script of course runs first? Have you checked the autoboot code? And what is the "hack" that you have made? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stappers at stappers.nl Sat Aug 8 04:09:51 2020 From: stappers at stappers.nl (Geert Stappers) Date: Sat, 8 Aug 2020 06:09:51 +0200 Subject: [ipxe-devel] Passing parameters from PXELinux to iPXE In-Reply-To: <8845a8b6-ce54-c9e5-1e59-0e7bd26d5723@socha.it> References: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> <20200807202009.vqak2lwebdllksab@gpm.stappers.nl> <83fc5fdb-22ec-d4d0-399c-045aa9c20fb1@socha.it> <8845a8b6-ce54-c9e5-1e59-0e7bd26d5723@socha.it> Message-ID: <20200808040951.byj5hfoulwxb6ux5@gpm.stappers.nl> On Fri, Aug 07, 2020 at 11:13:06PM +0200, Robert Socha wrote: > W dniu 07.08.2020 o?22:44, Robert Socha pisze: > > W dniu 07.08.2020 o?22:20, Geert Stappers pisze: > > > On Fri, Aug 07, 2020 at 09:43:11PM +0200, Robert Socha wrote: > > > > Hi, > > > > > > > > This is more user-level question. But for last few days I'm > > > > unable to post > > > > question via forum.ipxe.org. > > > > > > > > I wonder if this supported option (passing parameters from > > > > PXELinux to iPXE) > > > > > > > > > > > > I have PXELinux boot: > > > > > > > > LABEL startipxe > > > > ?? KERNEL ipxe.lkrn > > > > ?? APPEND set MYVAR some-data > > > > > > > > And from chain loaded ipxe with embed script: > > > > > > > > #!ipxe > > > > echo MYVAR: ${MYVAR} > > > > ... other stuff > > > > > > > > > > Why? > > > > > > > Thanks for asking. My use case is: > > > > I bootstrap hosts via PXELinux (I'm unable to change this -? this > > internal DHCP's related issue). Ah, that explains > > PXELinux templates are auto-generated via foreman (I know than I can try > > to replace (l)pxelinux.0 by ipxe binary - but this will require a lot of > > testing of other stuff). FWIW I'm glad I switched from pxelinux to iPXE ... > > So host is booted via PXElinux, and I chain load IPXE via: > > > > DEFAULT boot > > LABEL boot > > ? KERNEL ipxe-foreman.lkrn > > ? APPEND ipxe:set PXEMAC MAC_FROM_TEMPLATE > > > Another idea I have for this is: > > DEFAULT boot > LABEL boot > KERNEL /PXEMAC MAC_FROM_TEMPLATE/ipxe-foreman.lkrn > > And use pre-generated ipxe with embed MAC in script. > > Best regards > Robert Socha Groeten Geert Stappers -- Silence is hard to parse From socha at socha.it Tue Aug 11 06:11:38 2020 From: socha at socha.it (Robert Socha) Date: Tue, 11 Aug 2020 08:11:38 +0200 Subject: [ipxe-devel] Passing parameters from PXELinux to iPXE In-Reply-To: References: <26d48254-7ba9-869f-4b37-6574375321fc@socha.it> Message-ID: <13ae3e5b-ddc8-50d8-685b-4c3c4d5a9a5a@socha.it> Hi, W dniu 08.08.2020 o?04:47, Christian Nilsson pisze: > > And so what actually happen when you use that append? > Any error message or similar that is causing you issues? Well. Almost nothing (variable is unset). But with this append when I load wimboot (from ipxe script) - wimboot have problem to start (don't remember exact error message but imgfree command solved this for wimboot). > From memory, any appended script will make the "autoboot" run that > script, instead of the default DHCP and before all that any embedded > script of course runs first? Have you checked the autoboot code? Yes I did. But autoboot iterate over all interfaces - and I need only to boot via specific one (with selected MAC address). >And what is the "hack" that you have made? This is only for "research" purpose. I added code that "parse" APPEND data. For example: APPEND ipxe:set PXEMAC AA:BB:CC:DD:EE:FF ipxe: prefix is removed and rest is executed via system() call. My goal is to push somehow information for ipxe about MAC address (push from external source - ie. Foreman's template or via DHCP). I need to "boot" ipexe via correct interface (our servers have many interfaces, and only one is controlled by us, other are user controlled - so they could have user controlled DHCP servers). My two current ideas: Push this information via (isc) DHCP bootfile, for example for UEFI PXE Boot type: option bootfile-name = concat("/",binary-to-ascii (16, 8, "/", substring (hardware, 1, 6)),"/ipxe.efi"); And this will load /AA/BB/CC/DD/EE/FF/ipxe.efi This will require pre-generate ipxe.efi or generate them on the fly (with embed script with correct mac address). Second idea is to use DHCP to pass special "mark" about correct "network". For example: in DHCP: option ipxe.username "X-MGT-TAG-X"; And whit this sample script I'm able to locate correct net(n) interface: #!ipxe echo Platform: ${platform} ${manufacturer} ${product} imgfree echo Looking for management network on all interfaces... set n:int8 0 :loop echo Checking interface net${n} ifclose || ifopen net${n} || goto missing dhcp net${n} || inc n || goto missing iseq ${username} X-MGT-TAG-X || goto loop echo Management interface found: ${netX/ifname} ${netX/mac} goto done :missing echo Management interface not found! :done shell I miss-use "ipxe.username" in this example. Best regards -- Robert Socha From champetier.etienne at gmail.com Wed Aug 12 07:50:06 2020 From: champetier.etienne at gmail.com (Etienne Champetier) Date: Wed, 12 Aug 2020 10:50:06 +0300 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: References: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> Message-ID: Hi Michael, Le lun. 3 ao?t 2020 ? 15:00, Etienne Champetier a ?crit : > > Hi Michael > > Le lun. 3 ao?t 2020 ? 14:30, Michael Brown a ?crit : > > > > 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. 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 ? Creating a cpio file is 1 more hack that I would be happy to remove ;) Thanks in advance Etienne > > Maybe I tested with an old version, but I was not able to load a file > with relative path without it being a cpio in UEFI mode > What worked for me, from an http server I chain load a ipxe script > with something like > ~~~~ > kernel ../kernel/vmlinuz initrd=initrd.img initrd=myks.cfg.cpio > inst.ks=file:/myks.cfg ... > initrd ../kernel/initrd.img > initrd ../ks/myks.cfg.cpio > boot > ~~~~ > > Etienne > > > > > Michael From mcb30 at ipxe.org Wed Aug 12 11:30:19 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Wed, 12 Aug 2020 12:30:19 +0100 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: References: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> Message-ID: <314d92ef-1682-be20-cce1-19a52ffa9059@ipxe.org> 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 From nikize at gmail.com Wed Aug 12 11:42:36 2020 From: nikize at gmail.com (Christian Nilsson) Date: Wed, 12 Aug 2020 13:42:36 +0200 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: <314d92ef-1682-be20-cce1-19a52ffa9059@ipxe.org> References: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> <314d92ef-1682-be20-cce1-19a52ffa9059@ipxe.org> Message-ID: On Wed, 12 Aug 2020, 13:30 Michael Brown, wrote: > 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 > > > If one wants to add a extra configuration file as well, the extra cpio > header needs to be added to that file to work in efi mode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From champetier.etienne at gmail.com Wed Aug 12 12:55:36 2020 From: champetier.etienne at gmail.com (Etienne Champetier) Date: Wed, 12 Aug 2020 15:55:36 +0300 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: References: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> <314d92ef-1682-be20-cce1-19a52ffa9059@ipxe.org> Message-ID: Hi Christian, Le mer. 12 ao?t 2020 ? 14:42, Christian Nilsson a ?crit : > > On Wed, 12 Aug 2020, 13:30 Michael Brown, wrote: >> >> 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 >> >> If one wants to add a extra configuration file as well, the extra cpio header needs to be added to that file to work in efi mode. So you confirm that what is explained at https://ipxe.org/appnote/debian_preseed is not working anymore ? From nikize at gmail.com Wed Aug 12 14:03:49 2020 From: nikize at gmail.com (Christian Nilsson) Date: Wed, 12 Aug 2020 16:03:49 +0200 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: References: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> <314d92ef-1682-be20-cce1-19a52ffa9059@ipxe.org> Message-ID: On Wed, 12 Aug 2020, 14:55 Etienne Champetier, wrote: > Hi Christian, > > Le mer. 12 ao?t 2020 ? 14:42, Christian Nilsson a > ?crit : > > > > On Wed, 12 Aug 2020, 13:30 Michael Brown, wrote: > >> > >> 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 > >> > >> If one wants to add a extra configuration file as well, the extra cpio > header needs to be added to that file to work in efi mode. > > So you confirm that what is explained at > https://ipxe.org/appnote/debian_preseed is not working anymore ? > It works fine in pcbios mode For EFI it needs tweaks, and that is to add cpio header to the file in a separate step. Which also works in pcbios mode. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From champetier.etienne at gmail.com Wed Aug 12 14:18:36 2020 From: champetier.etienne at gmail.com (Etienne Champetier) Date: Wed, 12 Aug 2020 17:18:36 +0300 Subject: [ipxe-devel] appnote/debian_preseed instructions are wrong In-Reply-To: References: <2b16b21f-28fe-0b5e-6892-7625ebc9f284@smidsrod.no> <483ed488-afbe-76ca-7e33-8631acd6d40d@ipxe.org> <314d92ef-1682-be20-cce1-19a52ffa9059@ipxe.org> Message-ID: Le mer. 12 ao?t 2020 ? 17:04, Christian Nilsson a ?crit : > > On Wed, 12 Aug 2020, 14:55 Etienne Champetier, wrote: >> >> Hi Christian, >> >> Le mer. 12 ao?t 2020 ? 14:42, Christian Nilsson a ?crit : >> > >> > On Wed, 12 Aug 2020, 13:30 Michael Brown, wrote: >> >> >> >> 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 >> >> >> >> If one wants to add a extra configuration file as well, the extra cpio header needs to be added to that file to work in efi mode. >> >> So you confirm that what is explained at >> https://ipxe.org/appnote/debian_preseed is not working anymore ? > > It works fine in pcbios mode > For EFI it needs tweaks, and that is to add cpio header to the file in a separate step. > Which also works in pcbios mode. Thanks This confirm previous link is wrong and need fixing "ipxe loads debian/linux recognises it as efi stores it in memory with the command line, then loads debian/initrd.gz names it one.gz and stores it in memory, loads debian/preseed.cfg names it pressed.cfg and puts it in a cpio archive called two" From socha at socha.it Fri Aug 14 08:05:54 2020 From: socha at socha.it (Robert Socha) Date: Fri, 14 Aug 2020 10:05:54 +0200 Subject: [ipxe-devel] time command - store result in variable Message-ID: Hi, I'm doing some benchmarks (undi,snp, native drivers). And I needed to pass time results to external scripts. I added option to store time results in variable. And I can use it for example that way: #!ipxe set url http://100.100.100.69/100.bin set loops:int8 5 set n:int8 0 :benchmark imgfree time -n -s _bench${n} imgfetch ${url} inc n iseq ${n} ${loops} || goto benchmark set n:int8 0 :print echo Run ${n} took ${_bench${n}} ms inc n iseq ${n} ${loops} || goto print Patch: https://raw.githubusercontent.com/rjsocha/ipxe-misc-patches/master/time-store-to-variable/time.diff Any suggestion if this is correct way to store some data in variable? Best regards -- Robert Socha From geert.stappers at hendrikx-itc.nl Fri Aug 14 10:09:43 2020 From: geert.stappers at hendrikx-itc.nl (Geert Stappers) Date: Fri, 14 Aug 2020 12:09:43 +0200 Subject: [ipxe-devel] time command - store result in variable In-Reply-To: References: Message-ID: <4870c944-f3fc-e2ca-1d3e-d1567736dca0@hendrikx-itc.nl> On 14-08-2020 10:05, Robert Socha wrote: > Hi, > > I'm doing some benchmarks (undi,snp, native drivers). > And I needed to pass time results to external scripts. I added option to > store time results in variable. > > And I can use it for example that way: > > #!ipxe > set url http://100.100.100.69/100.bin > set loops:int8 5 > set n:int8 0 > > :benchmark > imgfree > time -n -s _bench${n} imgfetch ${url} > inc n > iseq ${n} ${loops} || goto benchmark > > set n:int8 0 > > :print > echo Run ${n} took ${_bench${n}} ms > inc n > iseq ${n} ${loops} || goto print > > > Patch: > https://raw.githubusercontent.com/rjsocha/ipxe-misc-patches/master/time-store-to-variable/time.diff > > > Any suggestion if this is correct way to store some data in variable? > FWIW Do know that "it works" is a large part of "the correct way" Regards Geert Stappers Who could resist to visit the above URL Who could not resist to leave the posting unanswered Who hopes for a posting like "it does work for me" From lbfeng at zd-tech.com.cn Mon Aug 17 10:59:13 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Mon, 17 Aug 2020 18:59:13 +0800 (CST) Subject: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform Message-ID: <47438ae8.b3c6.173fc12bf60.Coremail.lbfeng@zd-tech.com.cn> Hello, everone, 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: make ARCH=arm64 bin/undionly.kpxe It always fails, can't find the target. ======================================== kunlun at ubuntu:~/iPxe/ipxe/src$ make ARCH=arm64 bin-arm64-efi/undionly.kpxe /bin/sh: 1: git: not found make: *** No rule to make target `bin-arm64-efi/undionly.kpxe'. Stop. kunlun at ubuntu:~/iPxe/ipxe/src$ make ARCH=arm64 bin/undionly.kpxe /bin/sh: 1: git: not found arch/arm64/Makefile:33: arch/arm64/Makefile.pcbios: No such file or directory make: Failed to remake makefile `arch/arm64/Makefile.pcbios'. make: *** No rule to make target `bin/undionly.kpxe'. Stop. ======================================================== So, How to build a chainloading ipex for ARM64/ Thanks in advance. -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcb30 at ipxe.org Mon Aug 17 12:23:05 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Mon, 17 Aug 2020 13:23:05 +0100 Subject: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform In-Reply-To: <47438ae8.b3c6.173fc12bf60.Coremail.lbfeng@zd-tech.com.cn> References: <47438ae8.b3c6.173fc12bf60.Coremail.lbfeng@zd-tech.com.cn> Message-ID: <2facf0a3-3e94-edae-7da3-32e017214c64@ipxe.org> 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 From lbfeng at zd-tech.com.cn Tue Aug 18 01:50:52 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Tue, 18 Aug 2020 09:50:52 +0800 (CST) Subject: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform In-Reply-To: <2facf0a3-3e94-edae-7da3-32e017214c64@ipxe.org> References: <47438ae8.b3c6.173fc12bf60.Coremail.lbfeng@zd-tech.com.cn> <2facf0a3-3e94-edae-7da3-32e017214c64@ipxe.org> Message-ID: <20f2308a.e71c.173ff4313cb.Coremail.lbfeng@zd-tech.com.cn> Hello, Mr. Brown, Thank you very much. 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. Thanks. -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd ????"Michael Brown" ?????2020-08-17 20:23:05 ????"???" ,ipxe-devel at lists.ipxe.org ???Re: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform>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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikize at gmail.com Tue Aug 18 05:56:58 2020 From: nikize at gmail.com (Christian Nilsson) Date: Tue, 18 Aug 2020 07:56:58 +0200 Subject: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform In-Reply-To: <20f2308a.e71c.173ff4313cb.Coremail.lbfeng@zd-tech.com.cn> References: <47438ae8.b3c6.173fc12bf60.Coremail.lbfeng@zd-tech.com.cn> <2facf0a3-3e94-edae-7da3-32e017214c64@ipxe.org> <20f2308a.e71c.173ff4313cb.Coremail.lbfeng@zd-tech.com.cn> Message-ID: You can find some build target documentation at https://ipxe.org/appnote/buildtargets On Tue, 18 Aug 2020, 03:51 ???, wrote: > Hello, Mr. Brown, > > Thank you very much. > > 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. > > Thanks. > > -- > Best Regards > > Feng Libo > ZD Technology (Beijing) Co., Ltd > > > ????"Michael Brown" > ?????2020-08-17 20:23:05 > ????"???" ,ipxe-devel at lists.ipxe.org > ???Re: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform>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 at lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo/ipxe-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stappers at stappers.nl Tue Aug 18 09:08:59 2020 From: stappers at stappers.nl (Geert Stappers) Date: Tue, 18 Aug 2020 11:08:59 +0200 Subject: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform In-Reply-To: References: <47438ae8.b3c6.173fc12bf60.Coremail.lbfeng@zd-tech.com.cn> <2facf0a3-3e94-edae-7da3-32e017214c64@ipxe.org> <20f2308a.e71c.173ff4313cb.Coremail.lbfeng@zd-tech.com.cn> Message-ID: <20200818090859.gq2a4727et354s3l@gpm.stappers.nl> On Tue, Aug 18, 2020 at 07:56:58AM +0200, Christian Nilsson wrote: > On Tue, 18 Aug 2020, 03:51 ???, wrote: > > ????"Michael Brown" > > ?????2020-08-17 20:23:05 > > ????"???" ,ipxe-devel at lists.ipxe.org > > ???Re: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform>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 > > > > Hello, Mr. Brown, > > > > Thank you very much. > > > > 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. > > > You can find some build target documentation at > https://ipxe.org/appnote/buildtargets > Advice: Split the problem in two seperate problems 1: Have iPXE running on your ARM device 2: Get the special NIC running under iPXE Request: Use separate email thread for the separate problems Wish: patches Groeten Geert Stappers P.S. See the problem as a challenge or as a job 8^) -- Silence is hard to parse From lbfeng at zd-tech.com.cn Wed Aug 19 10:29:37 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Wed, 19 Aug 2020 18:29:37 +0800 (CST) Subject: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform In-Reply-To: <20200818090859.gq2a4727et354s3l@gpm.stappers.nl> References: <47438ae8.b3c6.173fc12bf60.Coremail.lbfeng@zd-tech.com.cn> <2facf0a3-3e94-edae-7da3-32e017214c64@ipxe.org> <20f2308a.e71c.173ff4313cb.Coremail.lbfeng@zd-tech.com.cn> <20200818090859.gq2a4727et354s3l@gpm.stappers.nl> Message-ID: <10c78a4d.a5e7.17406445cc9.Coremail.lbfeng@zd-tech.com.cn> Thanks, Geert, I will follow your advice. -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd ????"Geert Stappers" ?????2020-08-18 17:08:59 ????"???" ????iPXE ???Re: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform>On Tue, Aug 18, 2020 at 07:56:58AM +0200, Christian Nilsson wrote: >> On Tue, 18 Aug 2020, 03:51 ???, wrote: >> > ????"Michael Brown" >> > ?????2020-08-17 20:23:05 >> > ????"???" ,ipxe-devel at lists.ipxe.org >> > ???Re: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform>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 >> > >> > Hello, Mr. Brown, >> > >> > Thank you very much. >> > >> > 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. >> > >> You can find some build target documentation at >> https://ipxe.org/appnote/buildtargets >> > >Advice: Split the problem in two seperate problems > 1: Have iPXE running on your ARM device > 2: Get the special NIC running under iPXE > > >Request: Use separate email thread for the separate problems > > >Wish: patches > > > >Groeten >Geert Stappers > >P.S. >See the problem as a challenge or as a job 8^) >-- >Silence is hard to parse -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbfeng at zd-tech.com.cn Wed Aug 19 10:48:52 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Wed, 19 Aug 2020 18:48:52 +0800 (CST) Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? Message-ID: Hello, everyone, 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? Thanks -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcb30 at ipxe.org Wed Aug 19 13:24:50 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Wed, 19 Aug 2020 14:24:50 +0100 Subject: [ipxe-devel] How to build a chainloading ipxe on ARM64 platform In-Reply-To: <20f2308a.e71c.173ff4313cb.Coremail.lbfeng@zd-tech.com.cn> References: <47438ae8.b3c6.173fc12bf60.Coremail.lbfeng@zd-tech.com.cn> <2facf0a3-3e94-edae-7da3-32e017214c64@ipxe.org> <20f2308a.e71c.173ff4313cb.Coremail.lbfeng@zd-tech.com.cn> Message-ID: <17096f50-a598-21a8-059b-f31ccc49be17@ipxe.org> 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 From mcb30 at ipxe.org Wed Aug 19 13:26:20 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Wed, 19 Aug 2020 14:26:20 +0100 Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: References: Message-ID: 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 From nikize at gmail.com Wed Aug 19 15:14:21 2020 From: nikize at gmail.com (Christian Nilsson) Date: Wed, 19 Aug 2020 17:14:21 +0200 Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: References: Message-ID: On Wed, 19 Aug 2020 at 15:26, Michael Brown wrote: > 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 > Could it be a case of snponly not being chained via the nic, as such it will not try to initialize the device with snponly (or is that not an issue, and only relevant for undi)? If that is the case snp should work just fine. (but detect all nics instead) -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbankov at vmware.com Thu Aug 20 09:54:23 2020 From: dbankov at vmware.com (Dentcho Bankov) Date: Thu, 20 Aug 2020 09:54:23 +0000 Subject: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade Message-ID: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> Hello iPXE Developers, 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). Kindest regards, Dentcho Bankov -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbfeng at zd-tech.com.cn Thu Aug 20 09:28:12 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Thu, 20 Aug 2020 17:28:12 +0800 (CST) Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: References: Message-ID: Thanks, Christian and Michael, 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. -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd ????"Christian Nilsson" ?????2020-08-19 23:14:21 ????"Michael Brown" ????"???" ,iPXE ???Re: [ipxe-devel] can snponly.efi run without NII protocol installed? On Wed, 19 Aug 2020 at 15:26, Michael Brown wrote: 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 Could it be a case of snponly not being chained via the nic, as such it will not try to initialize the device with snponly (or is that not an issue, and only relevant for undi)? If that is the case snp should work just fine. (but detect all nics instead) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 1029419 bytes Desc: not available URL: From mcb30 at ipxe.org Thu Aug 20 13:43:18 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Thu, 20 Aug 2020 14:43:18 +0100 Subject: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade In-Reply-To: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> References: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> Message-ID: <7eed21b0-6139-f2b2-cfbc-397b0e32991f@ipxe.org> 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 From dbankov at vmware.com Thu Aug 20 13:55:41 2020 From: dbankov at vmware.com (Dentcho Bankov) Date: Thu, 20 Aug 2020 13:55:41 +0000 Subject: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade In-Reply-To: <7eed21b0-6139-f2b2-cfbc-397b0e32991f@ipxe.org> References: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> <7eed21b0-6139-f2b2-cfbc-397b0e32991f@ipxe.org> Message-ID: Hi Michael, I'm using gcc 4.8 in CentOS 6 and don' have much control of the environment but don't bother investigating I just wanted to make sure this is not a known issue. I'm currently trying in a different environment and hopefully will track this down soon. I'll post an update if it's worth sharing. Best regards, Dentcho Bankov ?On 20.08.20, 16:43, "Michael Brown" wrote: 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 https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fipxe.org%2F3c00e183&data=02%7C01%7Cdbankov%40vmware.com%7C207e833279e34cae3ea908d8450f0144%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637335278038841839&sdata=enh4%2FCmyIwahgsENsiC7ejMkP99omYHoO4roB%2FztwfE%3D&reserved=0 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 > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fipxe.org%2F420c6095&data=02%7C01%7Cdbankov%40vmware.com%7C207e833279e34cae3ea908d8450f0144%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637335278038851836&sdata=ZieMYJqb51HLeYJss0vMKRjWftj2%2B%2F8%2B851U4zxjkjI%3D&reserved=0 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 From dbankov at vmware.com Sat Aug 22 09:06:09 2020 From: dbankov at vmware.com (Dentcho Bankov) Date: Sat, 22 Aug 2020 09:06:09 +0000 Subject: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade In-Reply-To: References: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> <7eed21b0-6139-f2b2-cfbc-397b0e32991f@ipxe.org> Message-ID: <68611275-9A85-4F9D-B366-901ACCB3D4FB@vmware.com> Hi Michael, Just sharing my discoveries. 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. Best regards, Dentcho Bankov ?On 20.08.20, 16:55, "Dentcho Bankov" wrote: Hi Michael, I'm using gcc 4.8 in CentOS 6 and don' have much control of the environment but don't bother investigating I just wanted to make sure this is not a known issue. I'm currently trying in a different environment and hopefully will track this down soon. I'll post an update if it's worth sharing. Best regards, Dentcho Bankov On 20.08.20, 16:43, "Michael Brown" wrote: 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 https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fipxe.org%2F3c00e183&data=02%7C01%7Cdbankov%40vmware.com%7C207e833279e34cae3ea908d8450f0144%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637335278038841839&sdata=enh4%2FCmyIwahgsENsiC7ejMkP99omYHoO4roB%2FztwfE%3D&reserved=0 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 > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fipxe.org%2F420c6095&data=02%7C01%7Cdbankov%40vmware.com%7C207e833279e34cae3ea908d8450f0144%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637335278038851836&sdata=ZieMYJqb51HLeYJss0vMKRjWftj2%2B%2F8%2B851U4zxjkjI%3D&reserved=0 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 From mcb30 at ipxe.org Sun Aug 23 16:56:21 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Sun, 23 Aug 2020 17:56:21 +0100 Subject: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade In-Reply-To: <68611275-9A85-4F9D-B366-901ACCB3D4FB@vmware.com> References: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> <7eed21b0-6139-f2b2-cfbc-397b0e32991f@ipxe.org> <68611275-9A85-4F9D-B366-901ACCB3D4FB@vmware.com> Message-ID: 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 From lbfeng at zd-tech.com.cn Mon Aug 24 09:34:14 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Mon, 24 Aug 2020 17:34:14 +0800 (CST) Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: References: Message-ID: <58362ff3.ac88.1741fd17201.Coremail.lbfeng@zd-tech.com.cn> Hello, everyone, 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? Thanks. -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iPxe1.jpg Type: image/jpeg Size: 98648 bytes Desc: not available URL: From lbfeng at zd-tech.com.cn Mon Aug 24 09:43:04 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Mon, 24 Aug 2020 17:43:04 +0800 (CST) Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: References: Message-ID: <21b5c99.af2f.1741fd98be5.Coremail.lbfeng@zd-tech.com.cn> Hello, everyone, 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? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iPxe1.jpg Type: image/jpeg Size: 98648 bytes Desc: not available URL: From mcb30 at ipxe.org Mon Aug 24 10:52:45 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Mon, 24 Aug 2020 11:52:45 +0100 Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: References: Message-ID: <6ee30f58-d0f5-cdb7-7850-e38ee16aad3f@ipxe.org> 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 From mcb30 at ipxe.org Mon Aug 24 10:55:01 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Mon, 24 Aug 2020 11:55:01 +0100 Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: <58362ff3.ac88.1741fd17201.Coremail.lbfeng@zd-tech.com.cn> References: <58362ff3.ac88.1741fd17201.Coremail.lbfeng@zd-tech.com.cn> Message-ID: 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 From dbankov at vmware.com Mon Aug 24 13:27:57 2020 From: dbankov at vmware.com (Dentcho Bankov) Date: Mon, 24 Aug 2020 13:27:57 +0000 Subject: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade In-Reply-To: References: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> <7eed21b0-6139-f2b2-cfbc-397b0e32991f@ipxe.org> <68611275-9A85-4F9D-B366-901ACCB3D4FB@vmware.com> Message-ID: <9EBF9AAE-C6C0-4DCF-A0DB-9DBB99B29600@vmware.com> Hello Michael, 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! Best regards, Dentcho Bankov ?On 23.08.20, 19:56, "Michael Brown" wrote: 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fipxe%2Fipxe%2Fcommit%2Fbb74f00512995f15bf61517fc039f32713e0af73%23diff-25d902c24283ab8cfbac54dfa101ad31&data=02%7C01%7Cdbankov%40vmware.com%7C0a9a547283094c76108908d8478578b6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637337985894081924&sdata=Iofe7P4FResteFLp19ZvYoAK7qyBTMDJ549t3UEU5QA%3D&reserved=0 > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fipxe%2Fipxe%2Fpull%2F137&data=02%7C01%7Cdbankov%40vmware.com%7C0a9a547283094c76108908d8478578b6%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637337985894081924&sdata=EhM05z7VhZOX%2F1qjl058eHDudt5ZQlgZ7WmaDTdPDoo%3D&reserved=0 Could you let me know if this fixes the problem on gcc 4.5.3? Thanks, Michael From mcb30 at ipxe.org Mon Aug 24 13:48:40 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Mon, 24 Aug 2020 14:48:40 +0100 Subject: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade In-Reply-To: <9EBF9AAE-C6C0-4DCF-A0DB-9DBB99B29600@vmware.com> References: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> <7eed21b0-6139-f2b2-cfbc-397b0e32991f@ipxe.org> <68611275-9A85-4F9D-B366-901ACCB3D4FB@vmware.com> <9EBF9AAE-C6C0-4DCF-A0DB-9DBB99B29600@vmware.com> Message-ID: 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 From dbankov at vmware.com Mon Aug 24 14:55:10 2020 From: dbankov at vmware.com (Dentcho Bankov) Date: Mon, 24 Aug 2020 14:55:10 +0000 Subject: [ipxe-devel] Receiving http://ipxe.org/3c00e183 error after upgrade In-Reply-To: References: <50CD184C-08D2-4D7F-9AFA-E7D51F1FDFF6@vmware.com> <7eed21b0-6139-f2b2-cfbc-397b0e32991f@ipxe.org> <68611275-9A85-4F9D-B366-901ACCB3D4FB@vmware.com> <9EBF9AAE-C6C0-4DCF-A0DB-9DBB99B29600@vmware.com> Message-ID: <169E771A-37D6-4861-8928-D2651EA47A75@vmware.com> Awesome! I'm going to pull this ASAP. ?On 24.08.20, 16:48, "Michael Brown" wrote: 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 https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fgithub.com%2Fipxe%2Fipxe%2Fcommit%2F4bd064de2&data=02%7C01%7Cdbankov%40vmware.com%7Ce86c3ab8c37e4e5c3ad008d848346b8c%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637338737273071877&sdata=0G1TuHdP2%2B%2BrxvlNr6PqYJtrpbEAEgk%2BcE%2FMREBjUY8%3D&reserved=0 Michael From aaron.young at oracle.com Mon Aug 24 20:59:56 2020 From: aaron.young at oracle.com (aaron.young at oracle.com) Date: Mon, 24 Aug 2020 13:59:56 -0700 Subject: [ipxe-devel] [ipxe/ipxe] [efi] Add support for TPM measurement of ipxe scripts on EFI systems (#136) Message-ID: This PR adds a new --measure (-m) option to the chain/imgexec/boot commands that will perform a TPM measurement of an ipxe script prior to loading of the script on EFI systems. The code makes use of the EFI_TCG2_PROTOCOL->HashLogExtendEvent() protocol function provided by the UEFI firmware which will measure the script and create a TPM log entry for the script. NOTE: Only TPM2.0 is supported currently. TPM1.2 support is TBD. If the UEFI firmware does not support EFI_TCG2_PROTOCOL, the command is aborted with an error. See the TCG PC Client Platform Firmware Profile Specification and TCG EFI Protocol Specification for details. iPXE uses UEFI LoadImage() service function to load other image types which will automatically measure the image as part of the image load. Script image types are not loaded via LoadImage() and thus this new command option is needed to measure the scripts directly prior to load. Scripts need to be measured to comply with TCG specification which dictate that all binaries and configuration data must be measured for a complete measured/trusted boot. Example usage: chain -m http://1.2.3.4/script.ipxe Testing: I tested this code on a x86_64 server using qemu with a swtpm emulating TPM2.0. I verified that the proper TPM PCR (5) was updated and an TPM Event Log entry was created for the script. Thanks, -Aaron Young aaron.young at oracle.com ------------------------------------------------------------------------ You can view, comment on, or merge this pull request online at: https://github.com/ipxe/ipxe/pull/136 Commit Summary * [efi] Add support for TPM measurement of ipxe scripts on EFI systems File Changes ** * src/config/defaults/efi.h | 5 + * src/config/defaults/linux.h | 6 + * src/config/defaults/pcbios.h | 5 + * src/core/null_measure.c | 33 +++ * src/hci/commands/image_cmd.c | 19 +- * src/include/ipxe/efi/Protocol/Tcg2Protocol.h | 343 +++++++++++++++++++++++++++ * src/include/ipxe/efi/efi_measure.h | 23 ++ * src/include/ipxe/errfile.h | 6 + * src/include/ipxe/measure.h | 61 +++++ * src/include/ipxe/null_measure.h | 23 ++ * src/interface/efi/efi_measure.c | 170 +++++++++++++ * create mode 100644 src/core/null_measure.c * create mode 100644 src/include/ipxe/efi/Protocol/Tcg2Protocol.h * create mode 100644 src/include/ipxe/efi/efi_measure.h * create mode 100644 src/include/ipxe/measure.h * create mode 100644 src/include/ipxe/null_measure.h * create mode 100644 src/interface/efi/efi_measure.c Patch Links: * https://patch-diff.githubusercontent.com/raw/ipxe/ipxe/pull/136.patch * https://patch-diff.githubusercontent.com/raw/ipxe/ipxe/pull/136.diff ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.young at oracle.com Mon Aug 24 21:14:41 2020 From: aaron.young at oracle.com (aaron.young at oracle.com) Date: Mon, 24 Aug 2020 14:14:41 -0700 Subject: [ipxe-devel] [ipxe/ipxe] [efi] Add support for TPM measurement of ipxe scripts on EFI systems (#136) In-Reply-To: References: Message-ID: <7f21ec54-5f42-e23f-76a8-e4b94d2042f3@oracle.com> This PR adds a new --measure (-m) option to the chain/imgexec/boot commands that will perform a TPM measurement of an ipxe script prior to loading of the script on EFI systems. The code makes use of the EFI_TCG2_PROTOCOL->HashLogExtendEvent() protocol function provided by the UEFI firmware which will measure the script and create a TPM log entry for the script. NOTE: Only TPM2.0 is supported currently. TPM1.2 support is TBD. If the UEFI firmware does not support EFI_TCG2_PROTOCOL, the command is aborted with an error. See the TCG PC Client Platform Firmware Profile Specification and TCG EFI Protocol Specification for details. iPXE uses UEFI LoadImage() service function to load other image types which will automatically measure the image as part of the image load. Script image types are not loaded via LoadImage() and thus this new command option is needed to measure the scripts directly prior to load. Scripts need to be measured to comply with TCG specification which dictate that all binaries and configuration data must be measured for a complete measured/trusted boot. Example usage: chain -m http://1.2.3.4/script.ipxe Testing: I tested this code on a x86_64 server using qemu with a swtpm emulating TPM2.0. I verified that the proper TPM PCR (5) was updated and an TPM Event Log entry was created for the script. Thanks, -Aaron Young aaron.young at oracle.com ------------------------------------------------------------------------ You can view, comment on, or merge this pull request online at: https://github.com/ipxe/ipxe/pull/136 Commit Summary * [efi] Add support for TPM measurement of ipxe scripts on EFI systems File Changes ** * src/config/defaults/efi.h | 5 + * src/config/defaults/linux.h | 6 + * src/config/defaults/pcbios.h | 5 + * src/core/null_measure.c | 33 +++ * src/hci/commands/image_cmd.c | 19 +- * src/include/ipxe/efi/Protocol/Tcg2Protocol.h | 343 +++++++++++++++++++++++++++ * src/include/ipxe/efi/efi_measure.h | 23 ++ * src/include/ipxe/errfile.h | 6 + * src/include/ipxe/measure.h | 61 +++++ * src/include/ipxe/null_measure.h | 23 ++ * src/interface/efi/efi_measure.c | 170 +++++++++++++ * create mode 100644 src/core/null_measure.c * create mode 100644 src/include/ipxe/efi/Protocol/Tcg2Protocol.h * create mode 100644 src/include/ipxe/efi/efi_measure.h * create mode 100644 src/include/ipxe/measure.h * create mode 100644 src/include/ipxe/null_measure.h * create mode 100644 src/interface/efi/efi_measure.c Patch Links: * https://patch-diff.githubusercontent.com/raw/ipxe/ipxe/pull/136.patch * https://patch-diff.githubusercontent.com/raw/ipxe/ipxe/pull/136.diff ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaron.young at oracle.com Mon Aug 24 21:18:30 2020 From: aaron.young at oracle.com (aaron.young at oracle.com) Date: Mon, 24 Aug 2020 14:18:30 -0700 Subject: [ipxe-devel] [ipxe/ipxe] [efi] Add support for TPM measurement of ipxe scripts on EFI systems (#136) In-Reply-To: <7f21ec54-5f42-e23f-76a8-e4b94d2042f3@oracle.com> References: <7f21ec54-5f42-e23f-76a8-e4b94d2042f3@oracle.com> Message-ID: <579e296a-809c-c673-2ef6-b4431f77675b@oracle.com> This PR adds a new --measure (-m) option to the chain/imgexec/boot commands that will perform a TPM measurement of an ipxe script prior to loading of the script on EFI systems. The code makes use of the EFI_TCG2_PROTOCOL->HashLogExtendEvent() protocol function provided by the UEFI firmware which will measure the script and create a TPM log entry for the script. NOTE: Only TPM2.0 is supported currently. TPM1.2 support is TBD. If the UEFI firmware does not support EFI_TCG2_PROTOCOL, the command is aborted with an error. See the TCG PC Client Platform Firmware Profile Specification and TCG EFI Protocol Specification for details. iPXE uses UEFI LoadImage() service function to load other image types which will automatically measure the image as part of the image load. Script image types are not loaded via LoadImage() and thus this new command option is needed to measure the scripts directly prior to load. Scripts need to be measured to comply with TCG specification which dictate that all binaries and configuration data must be measured for a complete measured/trusted boot. Example usage: chain -m http://1.2.3.4/script.ipxe Testing: I tested this code on a x86_64 server using qemu with a swtpm emulating TPM2.0. I verified that the proper TPM PCR (5) was updated and an TPM Event Log entry was created for the script. Thanks, -Aaron Young aaron.young at oracle.com ------------------------------------------------------------------------ You can view, comment on, or merge this pull request online at: https://github.com/ipxe/ipxe/pull/136 Commit Summary * [efi] Add support for TPM measurement of ipxe scripts on EFI systems File Changes ** * src/config/defaults/efi.h | 5 + * src/config/defaults/linux.h | 6 + * src/config/defaults/pcbios.h | 5 + * src/core/null_measure.c | 33 +++ * src/hci/commands/image_cmd.c | 19 +- * src/include/ipxe/efi/Protocol/Tcg2Protocol.h | 343 +++++++++++++++++++++++++++ * src/include/ipxe/efi/efi_measure.h | 23 ++ * src/include/ipxe/errfile.h | 6 + * src/include/ipxe/measure.h | 61 +++++ * src/include/ipxe/null_measure.h | 23 ++ * src/interface/efi/efi_measure.c | 170 +++++++++++++ * create mode 100644 src/core/null_measure.c * create mode 100644 src/include/ipxe/efi/Protocol/Tcg2Protocol.h * create mode 100644 src/include/ipxe/efi/efi_measure.h * create mode 100644 src/include/ipxe/measure.h * create mode 100644 src/include/ipxe/null_measure.h * create mode 100644 src/interface/efi/efi_measure.c Patch Links: * https://patch-diff.githubusercontent.com/raw/ipxe/ipxe/pull/136.patch * https://patch-diff.githubusercontent.com/raw/ipxe/ipxe/pull/136.diff ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbfeng at zd-tech.com.cn Tue Aug 25 06:35:41 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Tue, 25 Aug 2020 14:35:41 +0800 (CST) Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: <6ee30f58-d0f5-cdb7-7850-e38ee16aad3f@ipxe.org> References: <6ee30f58-d0f5-cdb7-7850-e38ee16aad3f@ipxe.org> Message-ID: <3251aa73.5d5d.17424545713.Coremail.lbfeng@zd-tech.com.cn> Hello, Michael, 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? Thanks -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd ????"Michael Brown" ?????2020-08-24 18:52:45 ????"???" ,"Christian Nilsson" ????iPXE ???Re: [ipxe-devel] can snponly.efi run without NII protocol installed?>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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcb30 at ipxe.org Tue Aug 25 13:27:11 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Tue, 25 Aug 2020 14:27:11 +0100 Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: <3251aa73.5d5d.17424545713.Coremail.lbfeng@zd-tech.com.cn> References: <6ee30f58-d0f5-cdb7-7850-e38ee16aad3f@ipxe.org> <3251aa73.5d5d.17424545713.Coremail.lbfeng@zd-tech.com.cn> Message-ID: <2f7ba960-49f5-55d4-d555-717ba2e7a8d4@ipxe.org> 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 From lbfeng at zd-tech.com.cn Wed Aug 26 08:31:24 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Wed, 26 Aug 2020 16:31:24 +0800 (CST) Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: <2f7ba960-49f5-55d4-d555-717ba2e7a8d4@ipxe.org> References: <6ee30f58-d0f5-cdb7-7850-e38ee16aad3f@ipxe.org> <3251aa73.5d5d.17424545713.Coremail.lbfeng@zd-tech.com.cn> <2f7ba960-49f5-55d4-d555-717ba2e7a8d4@ipxe.org> Message-ID: <7db36335.13da5.17429e4a6df.Coremail.lbfeng@zd-tech.com.cn> Hello, Michael, 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. Thanks -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd ????"Michael Brown" ?????2020-08-25 21:27:11 ????"???" ????"Christian Nilsson" ,iPXE ???Re: [ipxe-devel] can snponly.efi run without NII protocol installed?>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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbfeng at zd-tech.com.cn Wed Aug 26 08:34:26 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Wed, 26 Aug 2020 16:34:26 +0800 (CST) Subject: [ipxe-devel] Params is not supported Message-ID: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> Hello, everyone, I download the latest ipxe and build for an ARM64 platform, it works fine. but it can't support the script command params? what else I need to do? Thanks -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd -------------- next part -------------- An HTML attachment was scrubbed... URL: From geert.stappers at hendrikx-itc.nl Wed Aug 26 09:13:06 2020 From: geert.stappers at hendrikx-itc.nl (Geert Stappers) Date: Wed, 26 Aug 2020 11:13:06 +0200 Subject: [ipxe-devel] Params is not supported In-Reply-To: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> References: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> Message-ID: On 26-08-2020 10:34, ??? wrote: > Hello, everyone, > > I download the latest ipxe and build for an ARM64 platform, it works > fine. but it can't support the script command params? Which symptoms? > what else I need to do? Compile with DEBUG=.... Regards Geert Stappers From lbfeng at zd-tech.com.cn Wed Aug 26 09:24:47 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Wed, 26 Aug 2020 17:24:47 +0800 (CST) Subject: [ipxe-devel] Params is not supported In-Reply-To: References: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> Message-ID: <6495cb37.150cc.1742a15835d.Coremail.lbfeng@zd-tech.com.cn> In ipxe shell, input params command, ipxe responds : params: command not found. if a script contains the params command, the same response. Thanks -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd ????"Geert Stappers" ?????2020-08-26 17:13:06 ????ipxe-devel at lists.ipxe.org ???Re: [ipxe-devel] Params is not supported>On 26-08-2020 10:34, ??? wrote: >> Hello, everyone, >> >> I download the latest ipxe and build for an ARM64 platform, it works >> fine. but it can't support the script command params? > >Which symptoms? > > >> what else I need to do? > >Compile with DEBUG=.... > > > >Regards >Geert Stappers > >_______________________________________________ >ipxe-devel mailing list >ipxe-devel at lists.ipxe.org >https://lists.ipxe.org/mailman/listinfo/ipxe-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikize at gmail.com Wed Aug 26 09:44:00 2020 From: nikize at gmail.com (Christian Nilsson) Date: Wed, 26 Aug 2020 11:44:00 +0200 Subject: [ipxe-devel] Params is not supported In-Reply-To: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> References: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> Message-ID: On Wed, 26 Aug 2020, 10:34 ???, wrote: > Hello, everyone, > I download the latest ipxe and build for an ARM64 platform, it works fine. > but it can't support the script command params? what else I need to do? > Thanks > > -- > Best Regards > > Feng Libo > ZD Technology (Beijing) Co., Ltd > _______________________________________________ > ipxe-devel mailing list > ipxe-devel at lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo/ipxe-devel Are we talking about https://ipxe.org/cmd/params#build_options ? Did you enable that at buildtime? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbfeng at zd-tech.com.cn Wed Aug 26 09:49:10 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Wed, 26 Aug 2020 17:49:10 +0800 (CST) Subject: [ipxe-devel] Params is not supported In-Reply-To: References: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> Message-ID: <743ae6c6.157c4.1742a2bd89f.Coremail.lbfeng@zd-tech.com.cn> Thank a lot. Mr. Nilsson. it is exactly the definition in src/ipxe/src/config/general.h -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd ????"Christian Nilsson" ?????2020-08-26 17:44:00 ????"???" ????iPXE ???Re: [ipxe-devel] Params is not supported On Wed, 26 Aug 2020, 10:34 ???, wrote: Hello, everyone, I download the latest ipxe and build for an ARM64 platform, it works fine. but it can't support the script command params? what else I need to do? Thanks -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd _______________________________________________ ipxe-devel mailing list ipxe-devel at lists.ipxe.org https://lists.ipxe.org/mailman/listinfo/ipxe-devel Are we talking about https://ipxe.org/cmd/params#build_options ? Did you enable that at buildtime? -------------- next part -------------- An HTML attachment was scrubbed... URL: From peter.vantilborgh at rva.be Mon Aug 24 13:33:35 2020 From: peter.vantilborgh at rva.be (Peter Van Tilborgh (RVA-ONEM)) Date: Mon, 24 Aug 2020 13:33:35 +0000 Subject: [ipxe-devel] Intel I219V-10 dhcp not working properly Message-ID: Hi, We recently received a new model (dell Latitude 5510) which comes with the Intel I219v-10 networkcard, but we are having dhcp issues with this model. We rebuilt our images from the latest source (downloaded from github today) but that did not help. Further investigation showed us that the device id was not in the list (drivers/net/intel.c). We therefore added the appropriate line ( "PCI_ROM ( 0x8086, 0x0d4f, "i219v-10", "I219-V (10)", INTEL_I219 )," ) and rebuilt the images. Again, no ip. Oddly, when we did not use an embedded script to run dhcp but booted to an ipxe shell and ran the dhcp command manually, it did work. We then increased the timeout between booting and running the dhcp command in our embedded script from 6 to 30 seconds. Still nothing Any clue what might be at issue here? Thanks, Peter Van Tilborgh, Sysadmin RVA. Disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From lbfeng at zd-tech.com.cn Wed Aug 26 09:36:34 2020 From: lbfeng at zd-tech.com.cn (=?GBK?B?t+HBorKo?=) Date: Wed, 26 Aug 2020 17:36:34 +0800 (CST) Subject: [ipxe-devel] Params is not supported In-Reply-To: References: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> Message-ID: <242a11f.154c5.1742a204f19.Coremail.lbfeng@zd-tech.com.cn> Hello, -- Best Regards Feng Libo ZD Technology (Beijing) Co., Ltd ????"Geert Stappers" ?????2020-08-26 17:13:06 ????ipxe-devel at lists.ipxe.org ???Re: [ipxe-devel] Params is not supported>On 26-08-2020 10:34, ??? wrote: >> Hello, everyone, >> >> I download the latest ipxe and build for an ARM64 platform, it works >> fine. but it can't support the script command params? > >Which symptoms? > > >> what else I need to do? > >Compile with DEBUG=.... > > > >Regards >Geert Stappers > >_______________________________________________ >ipxe-devel mailing list >ipxe-devel at lists.ipxe.org >https://lists.ipxe.org/mailman/listinfo/ipxe-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcb30 at ipxe.org Wed Aug 26 11:11:00 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Wed, 26 Aug 2020 12:11:00 +0100 Subject: [ipxe-devel] Params is not supported In-Reply-To: <743ae6c6.157c4.1742a2bd89f.Coremail.lbfeng@zd-tech.com.cn> References: <6c123ee8.13ed3.17429e76e19.Coremail.lbfeng@zd-tech.com.cn> <743ae6c6.157c4.1742a2bd89f.Coremail.lbfeng@zd-tech.com.cn> Message-ID: <7bcfc5d0-4553-75a9-aeb0-2b050175cabe@ipxe.org> 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 From mcb30 at ipxe.org Wed Aug 26 11:15:02 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Wed, 26 Aug 2020 12:15:02 +0100 Subject: [ipxe-devel] can snponly.efi run without NII protocol installed? In-Reply-To: <7db36335.13da5.17429e4a6df.Coremail.lbfeng@zd-tech.com.cn> References: <6ee30f58-d0f5-cdb7-7850-e38ee16aad3f@ipxe.org> <3251aa73.5d5d.17424545713.Coremail.lbfeng@zd-tech.com.cn> <2f7ba960-49f5-55d4-d555-717ba2e7a8d4@ipxe.org> <7db36335.13da5.17429e4a6df.Coremail.lbfeng@zd-tech.com.cn> Message-ID: 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 From pothana.golla at broadcom.com Thu Aug 27 03:28:53 2020 From: pothana.golla at broadcom.com (Pothana Golla) Date: Thu, 27 Aug 2020 08:58:53 +0530 Subject: [ipxe-devel] ESX doesnt work after IPXE upgrade Message-ID: Hi All After upgrade of IPXE ESX server installation doesn?t work as earlier version it stops boot.c32 and doesn?t move further I had replace the older version ipxe it works fine . kindly need your help in fixing the same. Regards *--------------------------------------------------- * *Pothana Golla* [image: cid:image001.png at 01D2464D.E1F79150][image: Description: Description: diwas's Avatar] O: 080-46116317 M: 9900214516 H: 08042158021 S1, Wipro Electronic City SEZ, Doddathogur Village, Begur Hobli, Bengaluru- 560100, Karnataka , INDIA P Please consider the environment before printing this email -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.gif Type: image/gif Size: 6311 bytes Desc: not available URL: From nikize at gmail.com Thu Aug 27 06:37:16 2020 From: nikize at gmail.com (Christian Nilsson) Date: Thu, 27 Aug 2020 08:37:16 +0200 Subject: [ipxe-devel] ESX doesnt work after IPXE upgrade In-Reply-To: References: Message-ID: On Thu, 27 Aug 2020 at 05:33, Pothana Golla wrote: > Hi All > > > > After upgrade of IPXE ESX server installation doesn?t work as earlier > version it stops boot.c32 and doesn?t move further I had replace the older > version ipxe it works fine . kindly need your help in fixing the same. > > > > Regards > Do you have any version numbers? or even better git commits with working and non working? Or if you could even do the https://ipxe.org/howto/bisect part, that would probably help. Also, have you checked the mailing list or forum for someone already reporting the same? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pothana.golla at broadcom.com Thu Aug 27 06:41:12 2020 From: pothana.golla at broadcom.com (Pothana Golla) Date: Thu, 27 Aug 2020 12:11:12 +0530 Subject: [ipxe-devel] ESX doesnt work after IPXE upgrade In-Reply-To: References: Message-ID: <8c640630b14b46d3c08810d9cc8679af@mail.gmail.com> OLD version is IPXE 1.0.0+ (827dd) and new Version IPXE 1.20.1+ (g9ee70) *From:* Christian Nilsson [mailto:nikize at gmail.com] *Sent:* Thursday, August 27, 2020 12:07 PM *To:* Pothana Golla *Cc:* iPXE *Subject:* Re: [ipxe-devel] ESX doesnt work after IPXE upgrade On Thu, 27 Aug 2020 at 05:33, Pothana Golla wrote: Hi All After upgrade of IPXE ESX server installation doesn?t work as earlier version it stops boot.c32 and doesn?t move further I had replace the older version ipxe it works fine . kindly need your help in fixing the same. Regards Do you have any version numbers? or even better git commits with working and non working? Or if you could even do the https://ipxe.org/howto/bisect part, that would probably help. Also, have you checked the mailing list or forum for someone already reporting the same? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcb30 at ipxe.org Thu Aug 27 14:10:57 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Thu, 27 Aug 2020 15:10:57 +0100 Subject: [ipxe-devel] ESX doesnt work after IPXE upgrade In-Reply-To: <8c640630b14b46d3c08810d9cc8679af@mail.gmail.com> References: <8c640630b14b46d3c08810d9cc8679af@mail.gmail.com> Message-ID: <37ae316f-3152-40b8-0eba-b367a088299e@ipxe.org> 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 From svinodhk at cisco.com Mon Aug 31 06:46:50 2020 From: svinodhk at cisco.com (Singaravelu Vinodhkumar -X (svinodhk - MINDTREE LIMITED at Cisco)) Date: Mon, 31 Aug 2020 06:46:50 +0000 Subject: [ipxe-devel] Steps to sign ipxe.efi and snponly.efi Message-ID: Hello Folks, We are trying to implement secure boot in iPXE and need help in understanding the process for the same. Followed the below procedure https://ipxe.org/appnote/etoken#uefi_secure_boot_signing_using_a_digicert_etoken We were facing lot of library dependency issues. So we decided to use DigiCert in Windows machine and got the cab file signed but even after signing it says not signed. Can somebody help me on this as we are stuck on this for quite sometime. Awaiting for you quick response on this. Regards, Vinodh -------------- next part -------------- An HTML attachment was scrubbed... URL: From yupai_hsu at clevo.com.tw Mon Aug 31 06:55:22 2020 From: yupai_hsu at clevo.com.tw (yupai_hsu at clevo.com.tw) Date: Mon, 31 Aug 2020 06:55:22 +0000 Subject: [ipxe-devel] About run iPXE.efi but display No configuration methods successed Message-ID: Hi, 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? [cid:image003.png at 01D67FA6.BFB3F930] Hope you can help, thank you. Yupai Hsu -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image003.png Type: image/png Size: 178103 bytes Desc: image003.png URL: From mcb30 at ipxe.org Mon Aug 31 16:56:17 2020 From: mcb30 at ipxe.org (Michael Brown) Date: Mon, 31 Aug 2020 17:56:17 +0100 Subject: [ipxe-devel] About run iPXE.efi but display No configuration methods successed In-Reply-To: References: Message-ID: <55a4e0b5-8f03-7bd8-0ce4-0c0243a0859f@ipxe.org> On 31/08/2020 07:55, yupai_hsu at 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