why not simply booting ipxe directly (instead of pxelinux) and duplicate similar entries for your linux boot? at the end its a kernel, a initrd and some command line parameters for linux. You can do all this in ipxe.
> Am 03.02.2016 um 20:59 schrieb Krizak, Paul <pkri...@qualcomm.com>: > > The build process we use is, (from src dir) > > 1. make > 2. Edit /tmp/menu.ipxe. Example: > > #!ipxe > set use-cached 1 > dhcp net0 > kernel http://sdimg01.qualcomm.com/osd/wimboot > initrd http://sdimg01.qualcomm.com/osd/sccmfiles/BOOTMGR.EXE BOOTMGR.EXE > initrd http://sdimg01.qualcomm.com/osd/sccmfiles/BCD BCD > initrd http://sdimg01.qualcomm.com/osd/sccmfiles/BOOT.SDI BOOT.SDI > initrd http://sdimg01.qualcomm.com/osd/sccmfiles/BOOT.WIM BOOT.WIM > boot > > 3. make bin/ipxe.kkpxe EMBED=/tmp/menu.ipxe > 4. cp bin/ipxe.kkpxe /path/to/tftp/root/ipxe-sdimg01.kkpxe > > The pxelinux menu entry looks like this: > > LABEL Windows Imaging sdimg01 > MENU LABEL Windows Imaging - sdimg01 > PXE targets/windows/ipxe/ipxe-sdimg01.kkpxe > > I followed this same process after editing tg3.c. The first "make" did > indeed rebuild the ipxe core due to tg3.c being updated. The kkpxe build > also rebuilt embedded.c and generated a new ipxe.kkpxe binary. However, this > new binary still does not appear to recognize the NIC. > > We can try the UNDI-only build, but we'll have to go back and re-qualify a > boatload of hardware that currently works fine with the kkpxe solution. It > would be a lot easier for us if we could get kkpxe to work. > > ---- > Paul Krizak office: AF-250D > Staff IT Engineer, UCM desk: 858-651-2467 > Qualcomm, Inc cell: 512-791-0686 > > > -----Original Message----- > From: Christian Nilsson [mailto:nik...@gmail.com] > Sent: Wednesday, February 03, 2016 11:49 AM > To: Krizak, Paul > Cc: Doose, Michael; ipxe-devel@lists.ipxe.org > Subject: Re: [ipxe-devel] Request for Network support for HP Elitebook 745 G3 > (Broadcom NetXtreme Gigabit Ethernet Plus) > > On Wed, Feb 3, 2016 at 8:34 PM, Krizak, Paul <pkri...@qualcomm.com> wrote: >> I am fairly certain I'm using the latest version: >> >> --- /usr2/pkrizak/git/ipxe >> [pkrizak@melchior]$ git remote -v show >> origin git://git.ipxe.org/ipxe.git (fetch) >> origin git://git.ipxe.org/ipxe.git (push) >> >> --- /usr2/pkrizak/git/ipxe >> [pkrizak@melchior]$ git pull >> Already up-to-date. >> >> --- /usr2/pkrizak/git/ipxe >> [pkrizak@melchior]$ git rev-parse HEAD >> d0bfd830e4e5ddd1015dda66833a99b068b6a519 > > Yes that's the latest one, goodie ;) > >> >> If you're referring to the build number in some of the screenshots earlier >> in this thread -- you're right, that was the older build. We actually did >> build with the newer version and got the same results (but did not post >> newer screencaps that show the newer build version). >> >>>> Why kkpxe? >> >> We have a standard infrastructure based on pxelinux, so we are chain-loading >> iPXE specifically for Windows installs. Linux and ESX installs go through >> our standard pxelinux stuff. But it all has to live on the same network, so >> pxelinux is the "primary" bootloader. >> >> I did not develop the ipxe setup for Windows -- it was handed to me in this >> state. I don't know why we use kkpxe versus other types of bootloaders, >> except for "that's how it was set up". Is there a better way to get >> HTTP-based image downloads to work without needing kkpxe? > > > Ok yes, use undionly.kpxe (single k) that should work for all nics > that are chained (unless The underlaying UNDI implementation is buggy) > > Having pxelinux in the boot path is sometimes causing an issue so you > should try without it, for example by building the .usb version > instead and booting directly from a usb stick. > > http://forum.ipxe.org/showthread.php?tid=6989 > I'm guessing here, but kkpxe might actually be part of your issue. > > >> >> The key feature of ipxe that we're taking advantage of is its ability to use >> HTTP to retrieve a disk image, rather than TFTP. With Windows installs, we >> have to download a multi-hundred-MB image, which takes FOREVER over TFTP. >> Over HTTP it is much faster and more reliable (since it uses TCP instead of >> UDP). >> >>>> I'm quite sure I have added that to a build myself. >> >> Maybe it's still sitting in a feature branch and needs to be merged to >> master? It's definitely not in the code at the master branch. > > > It was a one time build and was never sent upstream. (I'm just a iPXE > user like yourself) > > >> >> I edited tg3.c and added the PCI_ROM macro, then recompiled. Same behavior >> as before. And I double-checked the build number, and it's the newest one >> (d0bf...) >> >> > > > What did you build? please try: make bin/14e41687.pxe DEBUG=tg3 > Or if you chain from pxelinux you might want make bin/14e41687.lkrn > DEBUG=tg3 instead > > undionly versions will never include specific nic versions, so it > won't make any difference. > > > > >> ---- >> Paul Krizak office: AF-250D >> Staff IT Engineer, UCM desk: 858-651-2467 >> Qualcomm, Inc cell: 512-791-0686 >> >> >> -----Original Message----- >> From: Christian Nilsson [mailto:nik...@gmail.com] >> Sent: Wednesday, February 03, 2016 11:07 AM >> To: Doose, Michael; Krizak, Paul >> Cc: ipxe-devel@lists.ipxe.org >> Subject: Re: [ipxe-devel] Request for Network support for HP Elitebook 745 >> G3 (Broadcom NetXtreme Gigabit Ethernet Plus) >> >> Hi, >> Sorry about 14e4-1687 not being included, let me return to that further >> down... >> >> On Tue, Feb 2, 2016 at 10:07 PM, Doose, Michael <mdo...@qualcomm.com> wrote: >>> Christian, >>> >>> Thanks so much for the response, I apologize for not better explaining our >>> situation. I hope the information below helps make things more clear. I >>> work on the Windows side and have a Unix engineer helping with the updates >>> on the pxe/ipxe side. >>> >>> We are now using iPXE 1.0.0+ (8f01). I have reached out to have the unit >>> folks check the niclist.pl for the Broadcom NIC. >> >> That is very old! >> commit 8f0173b5c8ac6de9e9fa8115e37357c2aeb88101 >> Date: Mon Dec 9 15:32:42 2013 +0000 >> >> Please use latest git master, cloning from >> https://git.ipxe.org/ipxe.git is recommended >> >>> >>> The error warning received was the following which referenced Legacy: "iPXE >>> initializing devices...WARNING: Using legacy NIC wrapper on >>> 00:00:00:00:00:00" >>> >>> On all our other systems we see: "iPXE initializing devices...ok" >>> >>> We are using .kkpxe with WIMBOOT and BOOTMGR.EXE, no EFI stuff. We are also >>> chain loading from SYSLINUX PXE to iPXE >> >> Why kkpxe?, and what's your boot path/steps up to the above "Using >> legacy NIC wrapper" message? >> For example is it loaded from USB or is pxelinux involved somewhere etc. >> Are you using ipxe.* or undionly.* >> if you use undionly.kpxe (note not kkpxe) then ipxe will use the >> BIOS/Firmware drivers, you could in that case try to upgrade BIOS. >> if you use ipxe.pxe (don't use kpxe when using this variant) then it >> will only use ipxes native drivers, since none exist that won't work, >> but it shouldn't try to detect a non existing nic. >> Or build bin/14e41687.pxe (see below for info about adding support) >> Another alternative would be to test with .usb version on a USB stick: >> http://ipxe.org/download#using_a_boot_cd-rom_or_usb_key >> >> >>> >>> In BIOS we have configured legacy mode: >>> Configure Legacy Support and Secure boot : "Legacy Support Enable and >>> Secure Boot Disable" >>> >>> -Mike >> >> Now about The missing 14e4-1687, I'm quite sure I have added that to a >> build myself. >> You could try to add it to tg3.c and see if it works >> >> PCI_ROM(0x14e4, 0x1687, "14e4-1687", "14e4-1687", 0), >> or patch at: http://ur1.ca/oh6r6 >> >> If it does not work then build with debugging enabled and see if that >> gives anything: >> make bin/14e41687.pxe DEBUG=tg3 >> This will enable the DBG statements in the tg3.c file >> for even more debug output use DEBUG=tg3,tg3_hw,tg3_phy >> >> If it works, it would be appriciated if you could run thru the >> testlist at http://ipxe.org/dev/driver >> If everything passes then we can add it to the main repo (it will >> probably be added if it works to boot with since it's better then >> nothing, but the more tested the better) >> >> /Christian >> >> >>> >>> -----Original Message----- >>> From: Christian Nilsson [mailto:nik...@gmail.com] >>> Sent: Tuesday, February 02, 2016 11:17 AM >>> To: Doose, Michael <mdo...@qualcomm.com> >>> Cc: ipxe-devel@lists.ipxe.org >>> Subject: Re: [ipxe-devel] Request for Network support for HP Elitebook 745 >>> G3 (Broadcom NetXtreme Gigabit Ethernet Plus) >>> >>> On Tue, Feb 2, 2016 at 7:48 PM, Doose, Michael <mdo...@qualcomm.com> wrote: >>>> Hey team, >>>> >>>> I pulled down the latest build this morning to try and add support for >>>> the new HP Elitebook 745 G3 (AMD) based notebook, but it is still >>>> defaulting to the Legacy and failing with all zeroes as the Mac Address. >>>> >>>> This unit runs a “Broadcom NetXtreme Gigabit Ethernet Plus” LAN >>>> Adapter. Is there anything you can suggest to try and add support for this >>>> unit? >>>> >>>> Thank you! >>>> >>>> Misc Hardware Info: >>>> >>>> Hardware IDs: >>>> PCI\VEN_14E4&DEV_1687 >>> >>> Hi, >>> >>> The 14e4-1687 have native supported in ipxe and should work, the first >>> thing to check in cases like this is the niclist that can be generated by >>> niclist.pl in the util directory. >>> >>> What do you mean by Legacy? Assuming you are using the latest git master, >>> what are your build command and which ipxe file are you using? >>> legacy might mean undionly.kpxe which do not have any native drivers in it. >>> you need ipxe.pxe or ipxe.efi depending on platform, you could also build >>> 14e41687.pxe/.efi to only support the specific nic. >>> >>> Your issues might also be related to buggy HP firmware: >>> http://lists.ipxe.org/pipermail/ipxe-devel/2015-November/004476.html >>> >>> Hope it helps, otherwise you can follow some of the steps described in the >>> above email thread and see if that gets you any further. >>> >>> /Christian > _______________________________________________ > ipxe-devel mailing list > ipxe-devel@lists.ipxe.org > https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel Andreas Fink DataCell ehf, Backbone ehf, Cajutel Inc, Alisanus GmbH ------------------------------------------------------------------ c/o Alisanus GmbH Clarastreasse 3, 4058 Basel, Switzerland E-Mail: andr...@fink.org https://www.fink.org Mobile: +41-78-6677333 Office: +41 61 6666330 Skype: andreasfink Jabber/XMPP: andr...@fink.org ICQ: 8239353 ------------------------------------------------------------------
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ ipxe-devel mailing list ipxe-devel@lists.ipxe.org https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
