[ipxe-devel] "No iBFT detected" on Intel NUC

[Michael Brown]

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 
[8a44:0000,8a44:4438).

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 
from 463kB-503kB.

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.

Michael