Hi Heinrich, On Thu, 9 Sept 2021 at 04:40, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > > > On 9/9/21 10:57 AM, Simon Glass wrote: > > Hi Heinrich, > > > > On Wed, 8 Sept 2021 at 12:04, Heinrich Schuchardt <xypron.g...@gmx.de> > > wrote: > >> > >> > >> > >> On 9/8/21 3:33 PM, Simon Glass wrote: > >>> Add a block driver which handles read/write for EFI block devices. This > >>> driver actually already exists ('efi_block') but is not really suitable > >>> for use as a real U-Boot driver: > >>> > >>> - The operations do not provide a udevice > >> > >> efi_bl_bind() creates a udevice by calling blk_create_device() when an > >> EFI application calls ConnectController() for a handle with an > >> EFI_BLOCK_IO_PROTOCOL. > >> > >> Please, explain in some detail what you think is wrong with the existing > >> code. > > > > See below: > > > >> > >>> - The code is designed for running as part of EFI loader, so uses > >>> EFI_PRINT() and EFI_CALL(). > >>> - It creates block devices for all the partitions too, which is not > >>> somthing we want to support in this way > > No, it creates a block device for the handle that was passed to > ConnectController(). The handles for the partitions are created by > U-Boot and these are not backed by separate block devices.
OK, that is hard to discover so thank you for explaining it. The other items stand, in any case. > > Best regards > > Heinrich > > >>> - The bind method probes the device, which is not permitted > >>> - It uses 'EFI' as its parent device > > All devices that the UEFI sub-system uses must be probed., It is fine to probe a device but this must not be done in the bind() method. Hopefully the reason for this is obvious? > > >>> > >>> The new driver is more 'normal', just requiring its platform data be set > >>> up in advance. > > No clue what you mean by "in advance". It is a software like iPXE that > produces a handle at runtime and then calls ConnectController(). When > that call is done we must create a block device which is in status > probed, create handles for the partitions and install protocol > interfaces on these partitions. In advance of using the device. Basically we can pass the platform data into the device_bind() call, so it has it right from the start. Please understand that, while the existing EFI uclass is wonky, for the reasons I have clearly explained in this patch, my intent in explaining this is to motivate adding a new uclass. I am not trying to change the existing uclass. It is just one of many wonky things in the original EFI implementation that predates your efforts. - Simon > > Best regards > > Heinrich > > >>> > >>> Signed-off-by: Simon Glass <s...@chromium.org> > >> > >> Please, separate this series in two. One for U-Boot on EFI and one for > >> U-Boot's UEFI implementation. > > > > Again I'm not sure what you mean here. Please point to something you > > don't want in this series, which is focussed on the app. > > > >> > >> Best regardss > >> > >> Heinrich > >> > >>> --- > >>> > >>> drivers/block/Kconfig | 10 ++++ > >>> drivers/block/Makefile | 1 + > >>> drivers/block/efi_blk.c | 115 ++++++++++++++++++++++++++++++++++++++++ > >>> include/efi.h | 11 ++++ > >>> 4 files changed, 137 insertions(+) > >>> create mode 100644 drivers/block/efi_blk.c > >>> > > > > Regards, > > Simon > >