Thanks Alex and Heinrich I guess function efi_add_memory_map will do, what I was looking for
Regards Udit > -----Original Message----- > From: Udit Kumar > Sent: Sunday, January 21, 2018 4:13 PM > To: 'Alexander Graf' <ag...@suse.de>; Heinrich Schuchardt > <xypron.g...@gmx.de> > Cc: u-boot@lists.denx.de > Subject: RE: UEFI on u-boot > > Hi Alex > > > -----Original Message----- > > From: Alexander Graf [mailto:ag...@suse.de] > > Sent: Tuesday, January 16, 2018 7:52 PM > > To: Udit Kumar <udit.ku...@nxp.com>; Heinrich Schuchardt > > <xypron.g...@gmx.de> > > Cc: u-boot@lists.denx.de > > Subject: Re: UEFI on u-boot > > > > > > > > On 16.01.18 09:35, Udit Kumar wrote: > > > > > > > > >> -----Original Message----- > > >> From: Heinrich Schuchardt [mailto:xypron.g...@gmx.de] > > >> Sent: Tuesday, January 16, 2018 12:39 PM > > >> To: Udit Kumar <udit.ku...@nxp.com>; Alexander Graf > <ag...@suse.de> > > >> Cc: u-boot@lists.denx.de > > >> Subject: Re: UEFI on u-boot > > >> > > >> On 01/16/2018 06:28 AM, Udit Kumar wrote: > > >>> Hi Alex, > > >>> > > >>>> -----Original Message----- > > >>>> From: Alexander Graf [mailto:ag...@suse.de] > > >>>> Sent: Monday, January 15, 2018 5:02 PM > > >>>> To: Udit Kumar <udit.ku...@nxp.com> > > >>>> Cc: u-boot@lists.denx.de; Heinrich Schuchardt > > >>>> <xypron.g...@gmx.de> > > >>>> Subject: Re: UEFI on u-boot > > >>>> > > >>>> > > >>>> > > >>>> On 15.01.18 10:32, Udit Kumar wrote: > > >>>>> Hi Alex > > >>>>> > > >>>>>> -----Original Message----- > > >>>>>> From: Alexander Graf [mailto:ag...@suse.de] > > >>>>>> Sent: Monday, January 15, 2018 2:45 PM > > >>>>>> To: Udit Kumar <udit.ku...@nxp.com> > > >>>>>> > > >>>>>> Hi Udit, > > >>>>>> > > >>>>>> On 15.01.18 10:09, Udit Kumar wrote: > > >>>>>>> Hi Alex, > > >>>>>>> Hope you are doing great, > > >>>>>>> > > >>>>>>> Could you help on UEFI over the u-boot. > > >>>>>>> 1- I couldn't locate EFI_DXE_SERVICES in u-boot, do you have > > >>>>>>> plan to add those > > >>>>>> > > >>>>>> Right now the model is that all device drivers are implemented > > >>>>>> by U-Boot and that only exposes their interfaces to EFI > applications. > > >>>>>> Implementing DXE in U-Boot would open quite a big can of worms, > > >>>>>> as it would really only be useful in compilation with PI which > > >>>>>> is a terrible > > >>>> interface :). > > >>>>> > > >>>>> Ok, > > >>>>> > > >>>>>>> 2- If I load a driver (with bootefi) which install few > > >>>>>>> protocols, is this ok to do with u-boot > > >>>>>> > > >>>>>> It depends on how much the driver does, but in general yes. > > >>>>>> Heinrich is currently working on making the iPXE iSCSI driver > > >>>>>> work, so his EFI payload would expose an EFI block device to > > >>>>>> yet another payload running > > >>>> after his. > > >>>>> > > >>>>> Thanks for this, > > >>>>> Heinrich, in this driver, are you accessing underneath > > >>>>> hardware register by UEFI-Driver and managing UEFI protocols or > > >>>>> you are relying on some h/w access exposed by u-boot driver > > >>>>> > > >>>>> > > >>>>> > > >>>>>>> 3- if you say, 2 is ok then I hope these protocols are kept in > > >>>>>>> some data base, and this new protocol can be opened by an > > >>>>>>> application > > >>>>>> > > >>>>>> Yes, the protocol database is now global and persistent across > > >>>>>> bootefi invocations. > > >>>>> > > >>>>> Thanks > > >>>>> > > >>>>>>> 4- if there is some known limitation, like we cannot run > > >>>>>>> DXE_driver etc > > >>>>>> > > >>>>>> What exactly are you trying to do? With the U-Boot UEFI > > >>>>>> implementation we're trying to find a sweet spot between > > >>>>>> implementing as much as makes sense, but not the whole UEFI > > >>>>>> world, as that would just bloat the code needlessly. > > >>>>> > > >>>>> I am trying to add a driver (DXE by definition) which > > >>>>> a) Access the hardware registers. (I said DXE could due to > > >>>>> hardware > > >>>>> registers) > > >>>>> b) Update memory map as well (AddMemorySpace call) > > >>>>> c) Finally it export a protocol, which could be used by its test > > >> application. > > >>>>> > > >>>>> For b) I am not able to find function call, > > >>>> > > >>>> What exactly beyond efi_allocate_pages() do you need? The EFI > > >>>> memory map is really only used as data source for EFI applications. > > >>>> The actual 1:1 U- Boot map is not influenced by it. > > >>> > > >>> I am exploring possibility, If a driver discover memory and want > > >>> to add > > >> this in system. > > >>> For example, at build time 1Gb is reserved for a given driver but > > >>> at run-time driver is told to use little less memory say 512Mb and > > >>> this driver can return back 512Mb to system (In UEFI call is being > > >>> AddMemorySpace under DXE services) > > >>> > > >> > > >> The UEFI specification defines different memory types which can be > > >> used when allocating memory. Whether a memory type can be used by > > an > > >> UEFI OS loader or an OS determines on the boottime exit event. Many > > >> classes of memory become generally available after exiting the > > >> boottime. This is decribed in chapter "7.2 Memory Allocation > > >> Services" of > > UEFI spec 2.7. > > > > > > For allocation this is perfectly fine. How a driver can update the > > > memory map. > > > > Any allocation simply overrides the memory map, so if you explicitly > > allocate CONVENTIONAL_MEMORY at an address that was declared as > MMIO > > space before, the efi memory map will get updated accordingly. > > > > > Let me ask this in other way, when we create UEFI memory map in > > > u-boot How we are creating this ? using memory node of device tree > > > or some other way. > > > > It uses board specific knowledge of memory ranges. > > Once UEFI memory map is created, then is this possible to add new memory > in this map , for the moment I am fine if using UEFI driver adding this > memory into board specific ranges and this is reflected back to UEFI map. > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
