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