[ipxe-devel] UEFI efi_image_exec path

[Niket Kandya]

Yes it does work with single efi image.

Thanks and Regards,
Niket Kandya,
Graduate Student CS,
Columbia University, NY


On Sun, Aug 25, 2013 at 4:13 PM, Jarrod Johnson
<jarrod.b.johnson at gmail.com>wrote:

> Out of curiosity, did it work without issue if you didn't have multiple
> efi executables in play?
>
> I've not had a reason to try that use case myself, I just chain
> esxboot.efi (modified for iPXE DL protocol) or elilo (also modified for
> IPXE DL protocol support).  I also had shell working with the simple
> filesystem support.  I tried to get microsoft efi boot manager to work, but
> it seems eager to jump on the network aspect of a chained device.  When I
> tried to start with a new device handle and put only simple file system
> support on it, it wasn't happy either.  I have not had reason to bother
> with microsoft bootloader in the 'tftp wim down' case, so I don't know how
> that would go (without ipxe protocol support, skipping ipxe makes sense)
>
>
> On Sun, Aug 25, 2013 at 3:24 PM, Niket Kandya <niketkandya at gmail.com>wrote:
>
>> Hi,
>>
>> I was wondering if any of you guys ran into/worked around this problem.
>>
>> Following my previous query about UEFI image execution,
>> I enabled snponly.efi image execution, partly from Jarrod's patch and
>> partly my own.
>>
>> My addition there was:
>> If you try to run 2 efi images 1 after the other, the second image wont
>> execute because protocol installation will fail on the device handle as
>> protocols are already installed. So I added a check before installation in
>> efi_image_exec in efi_file_install and efi_download_install. And similarly
>> to uninstall only when it was installed for that image.
>>
>> To simulate this easily, you can just try autoboot from the shell as the
>> first command and then after you have reached the shell AGAIN!, chain your
>> normal efi image.
>>
>> However I ran into a wierd issue, after the autoboot, when i try to load
>> an efi image, the cwuri is changed to the one from previous autoboot.
>>
>>
>> Thanks and Regards,
>> Niket Kandya,
>> Graduate Student CS,
>> Columbia University, NY
>>
>>
>> On Wed, Aug 7, 2013 at 5:36 PM, Jarrod Johnson <
>> jarrod.b.johnson at gmail.com> wrote:
>>
>>> If trying to use snponly.eif, the following two patches will help:
>>>
>>> https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/73d1ff05b058a2507fda0119825715fa2253d722
>>> and
>>>
>>> https://git.ipxe.org/vendor/xcat/ipxe.git/commitdiff/f411dcea1ce12ddcdfafa3fa2a89566a16f86bce
>>>
>>> I still have been meaning to make snponly.efi work from non chian booted
>>> scenarios (e.g. local vfat) but snponly.efi works fine with these two
>>> patches.
>>>
>>> Perhaps one day Michael will have spare time to double check my work,
>>> make sure I did it right, probably fudge it a tad, and merge it.  In the
>>> meantime it's been working swimmingly for me.
>>>
>>>
>>> On Mon, Jul 29, 2013 at 5:20 PM, Niket Kandya <niketkandya at gmail.com>wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> I was trying to chain boot an efi image.
>>>> My setup is all like traditional PXE with snponly.efi as the PXE file.
>>>>
>>>> While chainloading an EFI file, I always fail at last_opened_snpdev()
>>>> as it internally tries to find a PCI SNP device which it does not find. Is
>>>> the problem here itself ??
>>>>
>>>> Or what I understood that this can be the case as this is a software
>>>> interface with no PCI address. To fix that I tried installing the protocols
>>>> onto a new handle (initially NULL) and then loading the image, however the
>>>> image never finds any files to read. So I tried doing this on the
>>>> efi_image_handle itself. And this failed again with none of these protocols
>>>> even being found on the device handle of the new image. I also tried using
>>>> any efi_pci_device, but none is found.
>>>>
>>>> Any suggestions??
>>>>
>>>> Regards
>>>>
>>>> Thanks and Regards,
>>>> Niket Kandya,
>>>>
>>>> _______________________________________________
>>>> ipxe-devel mailing list
>>>> ipxe-devel at lists.ipxe.org
>>>> https://lists.ipxe.org/mailman/listinfo.cgi/ipxe-devel
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ipxe.org/pipermail/ipxe-devel/attachments/20130826/808b4d79/attachment.htm>