Udit, Memory map differences would be expected as UiApp.efi is going to allocate memory too. The OS Loader starts off as an EFI Application so it needs to know EFI time allocations in addition to what allocations are legal for the OS to use.
In general how EFI communicates with the OS is via EFI NVRAM Variables. You can look at the Table in section "3.3 Globally Defined Variables" of the UEFI Spec. The OSprot will also figure out information about the platform from ACPI tables published by the EFI firmware. Also the OS Loader is an EFI App so it can access any protocol mentioned in the UEFI Spec. So form example on a Unix like OS the OS Loader may construct a Device Tree and pass it up to the kernel. It is going to be the code in the OS loader that does all this magic. If your working with a FOSS OS you may want to try and dump that device tree, and see if something is different. Then you could try to figure out the code in the OS Loader that produces that part of the device tree. Thanks, Andrew Fish > On Nov 28, 2018, at 5:42 PM, Udit Kumar <[email protected]> wrote: > > Hi , > I am looking for information/Help. If UEFI passed different information to > OS, in below boot path > > 1. Enter into Setup menu (By pressing Esc key), On display of UiApp.efi on > console, select device to boot OS > 2. Let the boot OS without user intervention from same device as of 1 > > I could see, UEFI pass different memory map in case of 1 and 2. > Is there some other/extra information is being shared with OS/OS Loader. > > For me, if I use 1) for booting then OS boots okay, > If I use option 2) for booting then when user-space prints are printed as > garbage. Whereas kernel space prints are good on serial console > > Thanks > Udit > _______________________________________________ > edk2-devel mailing list > [email protected] > https://lists.01.org/mailman/listinfo/edk2-devel _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
