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' agraf@suse.de; Heinrich Schuchardt xypron.glpk@gmx.de Cc: u-boot@lists.denx.de Subject: RE: UEFI on u-boot
Hi Alex
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Tuesday, January 16, 2018 7:52 PM To: Udit Kumar udit.kumar@nxp.com; Heinrich Schuchardt xypron.glpk@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.glpk@gmx.de] Sent: Tuesday, January 16, 2018 12:39 PM To: Udit Kumar udit.kumar@nxp.com; Alexander Graf
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:agraf@suse.de] Sent: Monday, January 15, 2018 5:02 PM To: Udit Kumar udit.kumar@nxp.com Cc: u-boot@lists.denx.de; Heinrich Schuchardt xypron.glpk@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:agraf@suse.de] >> Sent: Monday, January 15, 2018 2:45 PM >> To: Udit Kumar udit.kumar@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.