[PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL

[Simon Glass]

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.

Regards,
Simon