Hi Heinrich,
On Wed, 12 Jul 2023 at 00:41, Heinrich Schuchardt xypron.glpk@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@linaro.org wrote:
On Mon, 10 Jul 2023 at 11:28, AKASHI Takahiro takahiro.akashi@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@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@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....
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@cano... [2] https://lore.kernel.org/all/20220802094933.69170-1-heinrich.schuchardt@canon...