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. Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot