[RFC 00/22] efi_loader: more tightly integrate UEFI disks to device model

[Tom Rini]

On Sun, Oct 10, 2021 at 08:14:00AM -0600, Simon Glass wrote:
> Hi Takahiro,
> 
> On Thu, 30 Sept 2021 at 23:02, AKASHI Takahiro
> <takahiro.akashi at linaro.org> wrote:
> >
> > The purpose of this RPC is to reignite the discussion about how UEFI
> > subystem would best be integrated into U-Boot device model.
> > In the past, I poposed a couple of patch series, the latest one[1],
> > while Heinrich revealed his idea[2], and the approach taken here is
> > something between them, with a focus on block device handlings.
> >
> > # The code is a PoC and not well tested yet.
> >
> > Disks in UEFI world:
> > ====================
> > In general in UEFI world, accessing to any device is performed through
> > a 'protocol' interface which are installed to (or associated with) the device's
> > UEFI handle (or an opaque pointer to UEFI object data). Protocols are
> > implemented by either the UEFI system itself or UEFI drivers.
> >
> > For block IO's, it is a device which has EFI_BLOCK_IO_PROTOCOL (efi_disk
> > hereafter). Currently, every efi_disk may have one of two origins:
> > a.U-Boot's block devices or related partitions
> >   (lib/efi_loader/efi_disk.c)
> > b.UEFI objects which are implemented as a block device by UEFI drivers.
> >   (lib/efi_driver/efi_block_device.c)
> >
> > All the efi_diskss as (a) will be enumelated and created only once at UEFI
> > subsystem initialization (efi_disk_register()), which is triggered by
> > first executing one of UEFI-related U-Boot commands, like "bootefi",
> > "setenv -e" or "efidebug".
> > EFI_BLOCK_IO_PROTOCOL is implemented by UEFI system using blk_desc(->ops)
> > in the corresponding udevice(UCLASS_BLK).
> >
> > On the other hand, efi_disk as (b) will be created each time UEFI boot
> > services' connect_controller() is executed in UEFI app which, as a (device)
> > controller, gives the method to access the device's data,
> > ie. EFI_BLOCK_IO_PROTOCOL.
> >
> > >>> more details >>>
> > Internally, connect_controller() search for UEFI driver that can support
> > this controller/protocol, 'efi_block' driver(UCLASS_EFI) in this case,
> > then calls the driver's 'bind' interface, which eventually installs
> > the controller's EFI_BLOCK_IO_PROTOCOL to efi_disk object.
> > 'efi_block' driver also create a corresponding udevice(UCLASS_BLK) for
> >   * creating additional partitions efi_disk's, and
> >   * supporting a file system (EFI_SIMPLE_FILE_SYSTEM_PROTOCOL) on it.
> > <<< <<<
> >
> > Issues:
> > =======
> > 1. While an efi_disk represents a device equally for either a whole disk
> >    or a partition in UEFI world, the device model treats only a whole
> >    disk as a real block device or udevice(UCLASS_BLK).
> >
> > 2. efi_disk holds and makes use of "blk_desc" data even though blk_desc
> >    in plat_data is supposed to be private and not to be accessed outside
> >    the device model.
> >    # This issue, though, exists for all the implmenetation of U-Boot
> >    # file systems as well.
> 
> Yes, this was a migration convenience and we should be able to unpick it now.
> 
> However we still have SPL_BLK so need to consider whether we can drop that.

To be clear here, in that I can hand-wave my way to seeing a use case
for lib/efi_loader/ under SPL, it would not be in a world where we also
still would be supporting the non-DM infrastructure, and is also not a
near-term goal.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20211012/a4b67f59/attachment.sig>