If one of your goals was to offend someone with some experience trying to participate in discussion of another of your goals, congratulations on your success. Long ago, I have browsed the source code for rEFIt and the UEFI portions of gPXE and obviously the developer code in the UDK/ tianocore. I have built UEFI applications and run them under the Nt32 environment. I have read the entire PE COFF specification a looong time ago (and still have it handy) and have read much of the UEFI 2.3 specification (and still have it handy) some time ago. I installed and built Intel's UDK2010.UP3 some time ago. If you don't mind, let's wait for someone who has experience with building UEFI apps. As an example, the entry-point for these boot images might receive different, Windows-boot-manager-specific parameters instead of the usual (U)EFI ones, allowing for the applications to interface with the boot manager and, for example, its BCD and image-loading capabilities. There is no reason why Microsoft's BootMgr should allow you to chain arbitrary images, since by the time you've booted it, you are no longer in a (U)EFI-only environment. Same with lots of other (U)EFI applications. GRUB's EFI build's image type is IMAGE_SUBSYSTEM_EFI_APPLICATION. Same as BootMgr.efi, MemTest.efi and others. WinLoad.efi's image type is IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION. The subsystem flag for the winload.efi is 0x10, the subsystem flag for grub2.efi is 0xA. It's not (just?) a matter of signed UEFI. You haven't even shared what BCD entries you've tried, so nobody has any clue as to what BCD object type you have. How do you know this isn't like an "X Y problem"? If you'd share a bit more about your scenario, you might find out about alternatives in discussion. I wish I could go through GRUB2 first I can't. I am working within certain constraints which I have already specified.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |