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

Floris Bos bos at je-eigen-domein.nl
Mon Sep 29 13:58:49 BST 2014


On 09/29/2014 02:14 PM, Michael Brown wrote:
> On 28/09/14 14:54, Floris Bos wrote:
>> It seems the iBFT gets placed too low in memory.
>> The data MUST be located between 512K and 1024K according to the iBFT
>> specification, for the OS to find it there.
>
> Yes; this is a known problem.  When you use undionly.kpxe or 
> undionly.kkpxe then the underlying PXE stack remains resident in base 
> memory.  If this PXE stack is already occupying all of the memory from 
> 512kB upwards then there is no way for iPXE to place an iBFT in this 
> location.
>
> 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
iPXE initialising devices...ok
==


> You could try the following:
>
> 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?

-- 
Yours sincerely,

Floris Bos



More information about the ipxe-devel mailing list