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@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.
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.
-Takahiro Akashi
# Honestly speaking, I'm not sure how U-Boot prohibits the access to the EFI RAM disk because the udevices are created for the RAM disk.
Thanks, Masahisa Kojima
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:2Debian 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/im...
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