[ipxe-devel] Problem chainloading iPXE from some legacy Intel PXE
Jedrzej Kalinowski
kalinoj1 at iem.pw.edu.pl
Thu May 12 16:52:59 UTC 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