[ipxe-devel] "No iBFT detected" on Intel NUC
Floris Bos
bos at je-eigen-domein.nl
Mon Sep 29 12:58:49 UTC 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