public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
To: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Masahisa Kojima <masahisa.kojima@linaro.org>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>,
	u-boot@lists.denx.de, Simon Glass <sjg@chromium.org>
Subject: Re: [PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL
Date: Fri, 7 Jul 2023 16:16:11 +0900	[thread overview]
Message-ID: <ZKe7uwKGUYMp6ByD@laputa> (raw)
In-Reply-To: <3bab3fdc-23d1-85fd-5cc8-7ed9c77097a4@gmx.de>

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.

> We strive to synchronize what is happening on the driver model level and
> on the UEFI level. I would prefer a design where we have a UCLASS_BLK
> driver ram disks and the EFI_RAM_DISK_PROTOCOL is a one method of
> managing ram disk devices.

That said, I agree to starting with U-Boot block device implementation,
UEFI_DISK comes automatically. It benefits both U-Boot proper and
UEFI subsystem equally as well.
(That is also what I meant to say in my first response.)

> A big issue we have is RAM management. malloc() can only assign limited
> amount of memory which is probably too small for the RAM disk you are
> looking at. We manage page sized memory in the EFI sub-system but this
> is not integrated with the LMB memory checks.

Not sure, is it enough simply to add some restrictions on the start size
and the size when a memory region is specified for a raw disk?

-Takahiro Akashi

> The necessary sequence of development is probably:
> 
> * Rework memory management
> * Implement ramdisks as UCLASS_BLK driver
> * Implement the EFI_RAM_DISK_PROTOCOL based on the UCLASS_BLK driver.
> 
> Best regards
> 
> Heinrich
> 
> > 
> > Note that the installation process may not proceed
> > after the distro installer calls ExitBootServices()
> > since there is no hand-off process for the block device of
> > memory mapped ISO image.
> > 
> > The EFI_RAM_DISK_PROTOCOL was tested with the
> > debian network installer[1] on qemu_arm64 platform.
> > The example procedure is as follows.
> >   => tftpboot 41000000 mini.iso
> >   => efidebug disk load 41000000 $filesize
> > 
> > After these commands, ISO image is mounted like:
> > 
> >   => efidebug dh
> > 
> >      000000007eec5910 (efiblk#0)
> >        /RamDisk(0x41000000,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)
> >        Block IO
> > 
> >      000000007eec6140 (efiblk#0:1)
> >        /RamDisk(0x41000000,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(1,0x01,0,0x0,0x33800)
> >        Block IO
> > 
> >      000000007eec62b0 (efiblk#0:2)
> >        /RamDisk(0x41000000,4974afff,3d5abd30-4175-87ce-6d64-d2ade523c4bb,0x0)/HD(2,0x01,0,0x33800,0x10000)
> >        Block IO
> >        System Partition
> >        Simple File System
> > 
> >    => dm tree
> > 
> >      blk           0  [ + ]   efi_blk               `-- efiblk#0
> >      partition     0  [ + ]   blk_partition             |-- efiblk#0:1
> >      partition     1  [ + ]   blk_partition             `-- efiblk#0:2
> > 
> > Debian can be successfully installed with this RAM disk on QEMU.
> > 
> > [TODO]
> > - udevices created in ./lib/efi_driver/efi_block_device.c::efi_bl_bind()
> >    are not removed when the efi_handle is removed.
> >    So after unload the RAM disk, udevices still exist.
> >    I plan to add a udevice removal process in ./lib/efi_driver/efi_uclass.c::efi_uc_stop().
> >    In addition, I also plan to add unbind() callback in struct efi_driver_ops.
> > 
> > 
> > [1] https://deb.debian.org/debian/dists/bookworm/main/installer-arm64/current/images/netboot/mini.iso
> > 
> > Masahisa Kojima (4):
> >    efi_loader: add RAM disk device path
> >    efi_loader: add EFI_RAM_DISK_PROTOCOL implementation
> >    cmd: efidebug: add RAM disk mount command
> >    efi_selftest: add EFI_RAM_DISK_PROTOCOL selftest
> > 
> >   cmd/efidebug.c                           | 117 ++++++
> >   include/efi_api.h                        |  32 ++
> >   include/efi_loader.h                     |   4 +
> >   lib/efi_driver/efi_uclass.c              |   7 +-
> >   lib/efi_loader/Kconfig                   |   6 +
> >   lib/efi_loader/Makefile                  |   1 +
> >   lib/efi_loader/efi_device_path_to_text.c |  14 +
> >   lib/efi_loader/efi_ram_disk.c            | 334 +++++++++++++++
> >   lib/efi_loader/efi_setup.c               |   6 +
> >   lib/efi_selftest/Makefile                |   1 +
> >   lib/efi_selftest/efi_selftest_ram_disk.c | 511 +++++++++++++++++++++++
> >   lib/uuid.c                               |   4 +
> >   12 files changed, 1035 insertions(+), 2 deletions(-)
> >   create mode 100644 lib/efi_loader/efi_ram_disk.c
> >   create mode 100644 lib/efi_selftest/efi_selftest_ram_disk.c
> > 
> > 
> > base-commit: e2e2aea5733f0d23cd9593bbefe5c803c552dcb9
> 

  reply	other threads:[~2023-07-07  7:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-07  4:00 [PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL Masahisa Kojima
2023-07-07  4:00 ` [PATCH 1/4] efi_loader: add RAM disk device path Masahisa Kojima
2023-07-07  4:00 ` [PATCH 2/4] efi_loader: add EFI_RAM_DISK_PROTOCOL implementation Masahisa Kojima
2023-07-07  4:00 ` [PATCH 3/4] cmd: efidebug: add RAM disk mount command Masahisa Kojima
2023-07-07  4:00 ` [PATCH 4/4] efi_selftest: add EFI_RAM_DISK_PROTOCOL selftest Masahisa Kojima
2023-07-07  5:17 ` [PATCH 0/4] introduce EFI_RAM_DISK_PROTOCOL AKASHI Takahiro
2023-07-07  6:29 ` Heinrich Schuchardt
2023-07-07  7:16   ` AKASHI Takahiro [this message]
2023-07-07  8:19     ` Masahisa Kojima
2023-07-07  9:12       ` AKASHI Takahiro
2023-07-10  2:13         ` Masahisa Kojima
2023-07-10  2:28           ` AKASHI Takahiro
2023-07-11  6:23             ` Masahisa Kojima
2023-07-11 19:13               ` Simon Glass
2023-07-12  6:41                 ` Heinrich Schuchardt
2023-07-12 14:00                   ` Simon Glass
2023-07-07  8:10   ` Masahisa Kojima

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZKe7uwKGUYMp6ByD@laputa \
    --to=takahiro.akashi@linaro.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=masahisa.kojima@linaro.org \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=xypron.glpk@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox