[ipxe-devel] Problem chainloading iPXE from some legacy Intel PXE

Jedrzej Kalinowski kalinoj1 at iem.pw.edu.pl
Thu May 12 17:52:59 BST 2011


 On Fri, 06 May 2011 18:59:41 +0000, Jedrzej Kalinowski wrote:
> On Thu, 5 May 2011 21:16:09 +0100, Michael Brown wrote:
>> On Thursday 05 May 2011 21:06:50 Jedrzej Kalinowski wrote:
>>>  I've placed this in the top of main(), before initialise() 
>>> function
>>>  call, and still got zeroes, starting at address 322e0e5c.
>>>
>>>  But I've got a hint ;)
>>>  I decided to try old gPXE 1.0.0 undionly.kpxe image and it worked 
>>> fine!
>>
>> Fantastic:
>>
>>     http://ipxe.org/howto/bisect
>>
>
> Hi Michael,
>
> Here's my result:
>
> 24b52ae47655109de38d8a40f91efb21aed788ef is the first bad commit
> commit 24b52ae47655109de38d8a40f91efb21aed788ef
> Author: Michael Brown <mcb30 at ipxe.org>
> Date:   Tue Apr 20 18:49:43 2010 +0100
>
>     [prefix] Add A20-enabling code in libflat
>
>     iPXE currently insists on residing in an even megabyte.  This 
> imposes
>     undesirably severe constraints upon our PMM allocation strategy, 
> and
>     limits our options for mechanisms to access ROMs greater than 
> 64kB in
>     size.
>
>     Add A20 handling code to libflat so that prefixes are able to 
> access
>     memory even in odd megabytes.
>
>     The algorithms and tuning parameters in the new A20 handling code 
> are
>     based upon a mixture of the existing iPXE A20 code and the A20 
> code
>     from the 2.6.32 Linux kernel.
>
>     Signed-off-by: Michael Brown <mcb30 at ipxe.org>
>
> :040000 040000 54825d8295b96d66cbf4ee1a55a15af78ea56dee
> 22a65069f23871a565e750ef99007e0c5e961195 M    src


 Hi Michael,

 Any chance, you could take a look into this?
 Unfortunately it kind of blocks me with iPXE deployment in my 
 environment...

 Jedrzej Kalinowski


More information about the ipxe-devel mailing list