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

[Jedrzej Kalinowski]

 On Thu, 12 May 2011 18:52:59 +0200, Jedrzej Kalinowski wrote:
> 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

 Hi,

 Maybe just some hint on how to debug it further or how can I find some 
 workaround?
-- 
 JK