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

[Floris Bos]

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 
> [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.

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 
"iBFT" magic.
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.

https://github.com/torvalds/linux/blob/9a3c4145af32125c5ee39c0272662b47307a8323/drivers/firmware/iscsi_ibft_find.c


>> 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 
changes.

-- 
Yours sincerely,

Floris Bos