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

[Tom Rini]

On Tue, Oct 12, 2021 at 05:37:45PM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 12 Oct 2021 at 15:13, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Tue, Oct 12, 2021 at 02:31:15PM -0600, Simon Glass wrote:
> > > 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.
> >
> > What do you mean?  Since we have platforms that need to support 12 or 16
> > KiB of space for SPL, we're not going to enforce SPL_DM.  But those
> > platforms can / do need to boot from MMC (SD card I think usually).
> >
> > In terms of platforms that could, but don't, enable SPL_BLK, that's just
> > the platforms that disable SPL_BLK today as it defaults to enabled when
> > possible.
> 
> Well I wonder if we can use of-platdata and DM then perhaps some of
> these will fit. The OMAP platform I sent patches for was close to
> complete, I think, and I believe that was one of the tightest.
> Actually I cannot remember what board that was...
> 
> The overhead is perhaps 7KB though, so maybe not suitable for 16KB.

It's only disabled on the vboot config, on am335x platforms.  Honestly,
I would suggest a separate thread and ask the board maintainers in
question why specifically it's off.  I know for
am335x_boneblack_vboot_defconfig it's inadvertent, it could be turned on
no problem I suspect.

-- 
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/3c17c25d/attachment.sig>