Hi Alex, > -----Original Message----- > From: Alexander Graf [mailto:[email protected]] > Sent: Monday, January 15, 2018 5:02 PM > To: Udit Kumar <[email protected]> > Cc: [email protected]; Heinrich Schuchardt <[email protected]> > Subject: Re: UEFI on u-boot > > > > On 15.01.18 10:32, Udit Kumar wrote: > > Hi Alex > > > >> -----Original Message----- > >> From: Alexander Graf [mailto:[email protected]] > >> Sent: Monday, January 15, 2018 2:45 PM > >> To: Udit Kumar <[email protected]> > >> > >> 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) > > For a), if I say driver is UEFI and accessing hardware register, will this > > be > acceptable ? > > Yes, definitely. All you'd need to do is set the efi application type to > application, then register your protocols and access hardware registers using > direct MMIO access to their respective regions. Thanks > > Alex _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
