[ipxe-devel] "No iBFT detected" on Intel NUC
mcb30 at ipxe.org
Mon Sep 29 14:18:19 BST 2014
On 29/09/14 13:58, Floris Bos wrote:
>> Check the segment addresses printed by pxeprefix.S when undionly.kkpxe
>> first loads. You will probably find that the relevant part of base
>> memory is already occupied by the PXE base code.
> Not sure how to interpret the output exactly.
> Can see where it starts, but what the highest address occupied?
> PXE->EB: !PXE at 8A44:0070, entry point at 8A44:0100
> UNDI code segment 8A44:4438, data segment 7DF9:C4B0 (503-571kB)
> UNDI device is PCI 03:00.0, type DIX+802.3
> 463kB free base memory after PXE unload
The segment:offset addresses shown there are actually segment:length
pairs. For example, the UNDI code segment occupies the region
You can see from the "(503-571kB)" that the UNDI code+data segments are
already occupying from 512kB upwards. The final "463kB free base
memory" indicates that the PXE base code+data segments must be occupying
Using undionly.kpxe (instead of .kkpxe) would not help, since even
without the PXE base code the memory from 503kB upwards is still occupied.
>> a) use undionly.kpxe instead of undionly.kkpxe; this will unload the
>> PXE base code and so should free up more memory.
>> b) use an iPXE native driver (e.g. ipxe.pxe or intel.pxe); this will
>> unload the whole underlying PXE stack.
> I kinda like the "set use-cached 1" functionality and I recall that only
> works with .kkpxe
> Or is there a fix possible that copies the cached DHCP response first,
> and then unloads the PXE stack?
All .*pxe prefixes now do that, even if you're using an iPXE native
driver. The "use-cached" setting no longer exists.
If you chainload undionly.kpxe, ipxe.pxe, intel.pxe, or any other .*pxe
version of iPXE, then the cached DHCP response will show up as the
"net<N>.dhcp" settings block when iPXE starts up. You can just "ifopen"
the network interface and you will already have a functional IPv4 stack.
More information about the ipxe-devel