aQuantia AQtion PXE Compatability?

[Sebastian Roth]

@madnm Looks like iPXE added a driver just a few weeks ago: https://github.com/ipxe/ipxe/issues/294

So follow what George posted about compiling iPXE and there is a pretty good chance you get it to PXE boot. Than also update the FOS kernel to make sure it will pick up the NIC as well.

[madnm]

Hey guys,

Thanks for the help - I updated/recompiled iPXE as well as updated the Kernel to 5.15.19

Unfortunately I’m still getting the same issue- after that I tried compiling this branch of iPXE since it looked like it had the marvell/aquantia drivers: https://github.com/ipxe/ipxe/tree/7cfd66c389067fe0d0af65bbbe00954e6835e154/src/drivers/net/marvell

After doing that, I get what looks like some sort of hardware id or something after the initializing devices text, but then the workstation just reboots and I get the same issue as before.

Totally possible these are bad drivers though - I look forward to hearing what you think

[Sebastian Roth]

@madnm said in aQuantia AQtion PXE Compatability?:

Unfortunately I’m still getting the same issue- after that I tried compiling this branch of iPXE since it looked like it had the marvell/aquantia drivers: https://github.com/ipxe/ipxe/tree/7cfd66c389067fe0d0af65bbbe00954e6835e154/src/drivers/net/marvell

Oh well, I didn’t notice this has not been merged into the official iPXE master branch. See the pull request is still open and there is a bit of poking on this topic but not much.

Please try building the vendor specific only driver binary via make bin/marvell.pxe and see if that binary behaves differently. You can also try building marvell.kpxe and marvell.kkpxe. In some cases buggy BIOS implementations can only code with one of those.

As well post the PCI IDs of your particular network card found via lspci -nn | grep -i net or Windows device manager. Compare the PCI IDs with those found in the code.

[madnm]

Ok so I ended giving up and manually imaged the computers with clonezilla, but I did try your suggestions and will post in case anyone else comes across this and has the time to take another stab at it-

For the life of me I could not compile the Marvell drivers - on a tangent while troubleshooting I found the most recent reply on that pull request pretty funny

So I blame the Marvell devs and will try to avoid them at all costs in the future, haha

PCI IDs:

AQC108 - [1d6a:d108]
Intel I210 [8086:1533]

[george1421]

@madnm We do have an alternative to pxe booting into ipxe. We can usb boot into the FOS Engine bypassing iPXE. It would be interesting to see if FOS Linux could talk to that network adapter.

[Sebastian Roth]

@madnm said in aQuantia AQtion PXE Compatability?:

AQC108 - [1d6a:d108]

OK, so at least this PCI ID is in the Code as “AQC08 Marvell AQtion 5Gbit Network Adapter”. So that’s a good start.

While I understand you have moved forward to get this system imaged it would still be great to keep looking into this to help make this work at some stage for you and/or the community.

Have you tried using the ipxe.pxe binary (make bin/ipxe.pxe) when building the mentioned commit that includes the marvell driver?

[george1421]

@madnm Just an observation here.

The screen shot you provided in your OP indicates you are trying to pxe boot a bios computer. You should be using undionly.kpxe for the boot file. In this case the only network driver included is the undi driver, which is (should be) universal. If you were sending ipxe.kpxe then I could understand why you have a driver issue.

On the uefi side, you should be using the snp.efi boot loader, this is akin to the undionly.kpxe driver is to bios mode. The snp driver is the only driver loaded in the snp,efi file. Again this is a generic driver that uses the network adapters built in snp interface. So as I see it it shouldn’t be necessary to include the drivers into iPXE unless you want to use the ipxe.efi boot loader.

[Sebastian Roth]

@george1421 said in aQuantia AQtion PXE Compatability?:

You should be using undionly.kpxe for the boot file. In this case the only network driver included is the undi driver, which is (should be) universal. If you were sending ipxe.kpxe then I could understand why you have a driver issue.

While you are right with this in general I might add that some hardware doesn’t play nice with the universal UNDI (legacy BIOS) or SNP (UEFI) interfaces. I guess this is the case with this AQN-108 as well.

@madnm See more details on the different iPXE binaries here: https://ipxe.org/appnote/buildtargets

[Sebastian Roth]

@madnm I had a go with this myself and was able to build a marvel only iPXE binary using the following command: make bin/aqc1xx.pxe

Sorry for pointing you the wrong direction at first. I am not an iPXE developer and hardly know their source code and build fundamentals. Making it up as I go.

So here is what I did:

git clone https://github.com/ipxe/ipxe marvell_test
cd marvell_test
git fetch origin pull/370/head:test-marvell-branch
git checkout test-marvell-branch
cd src/
wget -O ipxescript https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/src/ipxe/src/ipxescript
cd config/
wget -O console.h https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/src/ipxe/src/config/console.h
sed -i 's/dynamic/us/g' console.h
wget -O general.h https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/src/ipxe/src/config/general.h
wget -O settings.h https://raw.githubusercontent.com/FOGProject/fogproject/dev-branch/src/ipxe/src/config/settings.h
cd ..
make bin/aqc1xx.pxe EMBED=ipxescript

Now copy bin/aqc1xx.pxe to your TFTP directory and point your DHCP to that filename. Be aware that other machines will probably fail to PXE boot on that binary.

And if that doesn’t PXE boot your machine you can go ahead and enabling debugging output: make bin/aqc1xx.pxe EMBED=ipxescript DEBUG=aqc1xx,atl_hw

[madnm]

@sebastian-roth Sorry for the super late reply - had to reimage one of the hosts again and came back to this - the binary built using your instructions here worked! Thanks a ton

[Sebastian Roth]

@madnm You are welcome.