[PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL

[Simon Glass]

Hi Heinrich,

On Wed, 12 Jul 2023 at 00:41, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 7/11/23 21:13, Simon Glass wrote:
> > Hi,
> >
> > On Tue, 11 Jul 2023 at 00:23, Masahisa Kojima
> > <masahisa.kojima at linaro.org> wrote:
> >>
> >> On Mon, 10 Jul 2023 at 11:28, AKASHI Takahiro
> >> <takahiro.akashi at linaro.org> wrote:
> >>>
> >>> On Mon, Jul 10, 2023 at 11:13:12AM +0900, Masahisa Kojima wrote:
> >>>> On Fri, 7 Jul 2023 at 18:12, AKASHI Takahiro <takahiro.akashi at linaro.org> wrote:
> >>>>>
> >>>>> On Fri, Jul 07, 2023 at 05:19:33PM +0900, Masahisa Kojima wrote:
> >>>>>> Hi Akashi-san,
> >>>>>>
> >>>>>> On Fri, 7 Jul 2023 at 16:16, AKASHI Takahiro <takahiro.akashi at linaro.org> wrote:
> >>>>>>>
> >>>>>>> On Fri, Jul 07, 2023 at 08:29:12AM +0200, Heinrich Schuchardt wrote:
> >>>>>>>> On 7/7/23 06:00, Masahisa Kojima wrote:
> >>>>>>>>> This series introduces the EFI_RAM_DISK_PROTOCOL implementation.
> >>>>>>>>> The major purpose of this series is a preparation for EFI HTTP(S) boot.
> >>>>>>>>>
> >>>>>>>>> Now U-Boot can download the distro installer ISO image
> >>>>>>>>> via wget or tftpboot commands, but U-Boot can not mount
> >>>>>>>>> the downloaded ISO image.
> >>>>>>>>> By calling EFI_RAM_DISK_PROTOCOL->register API, user can
> >>>>>>>>> mount the ISO image and boot the distro installer.
> >>>>>>>>
> >>>>>>>> If I understand you correctly, with your design RAM disks will only
> >>>>>>>> exist in the EFI sub-system.
> >>>>>>>
> >>>>>>> Probably, not. As Kojima-san's "dm tree" shows, there is a U-Boot
> >>>>>>> block device (and associated partition devices) thanks to your
> >>>>>>> efi_driver framework.
> >>>>>>
> >>>>>> Read/Write the RAM disk is expected to be called from the EFI context, so
> >>>>>
> >>>>> An associated U-Boot block device should work as well on top of your
> >>>>> RAW_DISK_PROTOCOL via a generated RAM disk object (efi_disk).
> >>>>> That is why SYMPLE_FILE_SYSTEM_PROTOCOL, which solely relies on U-Boot's proper
> >>>>> filesystem subsystem, is installed to the RAM disk object.
> >>>>
> >>>> I now realize that my RAM_DISK_PROTOCOL implementation happens to work
> >>>> thanks to the block cache.
> >>>> When I disable CONFIG_BLOCK_CACHE and load some EFI application(it
> >>>> does set  'app_gd')
> >>>> before calling RAM_DISK_PROTOCOL service, RAM_DISK_PROTOCOL does not work.
> >>>> ConnectController fails.
> >>>>
> >>>>>
> >>>>>> native U-Boot can not access the RAM disk.
> >>>>>
> >>>>> I believe that, in theory, "fatls efidisk 0 1" (or efi_disk as an interface?)
> >>>>> should work even under your current implementation.
> >>>>
> >>>> "fatls efiloader 0:2" does not work.
> >>>> I think "efiloader" device is designed to be accessed from EFI application only
> >>>> even if it is listed by "dm tree".
> >>>
> >>> I don't believe so.
> >>> (the interface name may be "efi_blk" or "efiblk", though.)
> >>>
> >>> If the command fails, it's a bug. Must be fixed.
> >>
> >> "fatls efiloader 0:2" failed here:
> >> https://source.denx.de/u-boot/u-boot/-/blob/master/drivers/block/blk-uclass.c#L139
> >>
> >> This is because the parent is 'dm_root' for the device created by
> >> lib/efi_driver/efi_block_device.c,
> >> so uclass_id is different.
> >
> > The parent device of a UCLASS_BLK device MUST be a media uclass. It
> > cannot be root. I believe EFI has some suitable classes.
> >
> > At some point we will remove the uclass_id from struct blk_desc and
> > just use the parent's uclass ID.
>
> Hello Simon,
>
> we want to more tightly integrate EFI and DM.

Who is working on this? I have not seen a series for a while.

>
> If an EFI program like iPXE creates a handle for an iSCSI drive with the
> block IO protocol the parent of that handle will be a network device and
> nothing having to do with a block device.
>
> Introducing dummy devices like you did for the sandbox host block
> devices will only make integration of EFI and DM more complicated.
>
> As I indicated years before you have to use blk_desc->uclass_id instead
> of the parent uclass_id to identify block devices in
> blk_get_devnum_by_uclass_idname() [1][2].
>
> Removing class_id from struct blk_desc is a step against better future
> integration of EFI and DM.

I thought we discussed this before, but this his my understanding:
devices cannot exist in EFI that are not known by U-Boot. So if there
is a an iSCSI drive it should exist in U-Boot too, under DM.

Anyway, I hope this important work can restart soon.

Regards,
Simon


>
> Best regards
>
> Heinrich
>
> [1]
> https://lore.kernel.org/all/20221003093550.106304-1-heinrich.schuchardt@canonical.com/
> [2]
> https://lore.kernel.org/all/20220802094933.69170-1-heinrich.schuchardt@canonical.com/