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

Jedrzej Kalinowski kalinoj1 at iem.pw.edu.pl
Fri May 6 19:59:41 BST 2011


 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

-- 
 JK


More information about the ipxe-devel mailing list