Thanks Heinrich > -----Original Message----- > From: Heinrich Schuchardt [mailto:[email protected]] > Sent: Tuesday, January 16, 2018 2:55 AM > To: Udit Kumar <[email protected]>; Alexander Graf <[email protected]> > Cc: [email protected] > Subject: Re: UEFI on u-boot > > > > On 01/15/2018 10:32 AM, 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 > > With the command bootefi you can load an executable that adds boottime > or runtime services. > > Unfortunatly there are some missing points: > > When loading the image the memory category reserved for the image is not > chosen in dependence of the image type. This will cause major trouble for > runtime drivers. > The exit() service does not call the unload function of the > driver/application.
Thanks for warning, for the moment I am ok with simple driver > >> > >> 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 > > > > U-Boot exposes the network interface as EFI simple network protocol. > iPXE provides TCP and iSCSI on top of the SNP. > It creates a handle and install the a block IO protocol on it. > When ConnectController is called the U-Boot EFI block driver creates the > partitions as children of aforementioned handle and installs the simple file > protocol on the child handles. > > See patch > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists. > denx.de%2Fpipermail%2Fu-boot%2F2018- > January%2F316708.html&data=02%7C01%7Cudit.kumar%40nxp.com%7Cc19b > 8ec63abb4ee7ff1908d55c5e7be8%7C686ea1d3bc2b4c6fa92cd99c5c301635%7 > C0%7C0%7C636516483235326220&sdata=wUx1fErZM2G6xjB7Aq89ntqs5bRGt > TXZKKcfLgWef4M%3D&reserved=0 Thanks, you rely on u-boot exports. Alex answered in previous post as in UEFI driver MMIO read/write is allowed > Regards > > Heinrich > > > > > > >>> 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, For a), if I say driver is > > UEFI and accessing hardware register, will this be acceptable ? > > > >> > >> Alex _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
