[ipxe-devel] "No iBFT detected" on Intel NUC
bos at je-eigen-domein.nl
Mon Sep 29 14:38:12 BST 2014
On 09/29/2014 03:18 PM, Michael Brown wrote:
> 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 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
Not sure if I understand that.
If the UNDI part ends at 571 Kb, wouldn't it be possible to place the
iBFT at say 572 Kb?
Note that the Linux iscsi_ibft module scans the entire memory region 512
Kb - 1024 Kb sequentially looking for a struct that starts with the
The iBFT doesn't have to start at 512 Kb exactly, you are supposed to be
able to place it at any 16-byte aligned memory location between 512 Kb
and 1024 Kb.
>> 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.
Thanks for the info.
Was using an old iPXE version until recently, and wasn't aware of the
More information about the ipxe-devel