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

[Simon Glass]

Hi Tom,

On Tue, 12 Oct 2021 at 09:00, Tom Rini <trini at konsulko.com> wrote:
>
> 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.

OK good. Perhaps we should add a migration method for SPL_BLK? It
would be good to know where we are in terms of the size stuff. I don't
see a lot of boards rushing to use of-platdata, though.

Regards,
Simon