Hi Heinrich,
On Sat, 13 Nov 2021 at 02:29, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/8/21 06:29, AKASHI Takahiro wrote:
On Sun, Nov 07, 2021 at 09:43:22AM -0700, Simon Glass wrote:
Hi Heinrich,
On Sun, 7 Nov 2021 at 01:21, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 11/4/21 04:09, Simon Glass wrote:
At present UCLASS_EFI is used to represent an EFI filesystem among other things. The description of this uclass is "EFI managed devices" which is pretty vague. The only driver that uses this uclass is in fact not a real U-Boot driver, since its operations do not include a struct udevice.
Rather than mess with this, create a new UCLASS_EFI_MEDIA uclass to handle EFI media such as disks. Make this the uclass to use for EFI media so that it can be used with 'part list', for example.
The existing implementation using UCLASS_EFI remains as is, for discussion.
Signed-off-by: Simon Glass sjg@chromium.org
(no changes since v2)
Changes in v2:
Add MAINTAINERS entry
Show the correct interface type with 'part list'
Update the commit message to explain things better
MAINTAINERS | 3 +++ arch/sandbox/dts/test.dts | 4 ++++ disk/part.c | 5 ++++- drivers/block/Kconfig | 23 +++++++++++++++++++++++ drivers/block/Makefile | 3 +++ drivers/block/blk-uclass.c | 2 +- drivers/block/efi-media-uclass.c | 15 +++++++++++++++ drivers/block/sb_efi_media.c | 20 ++++++++++++++++++++ include/dm/uclass-id.h | 1 + test/dm/Makefile | 1 + test/dm/efi_media.c | 24 ++++++++++++++++++++++++ 11 files changed, 99 insertions(+), 2 deletions(-) create mode 100644 drivers/block/efi-media-uclass.c create mode 100644 drivers/block/sb_efi_media.c create mode 100644 test/dm/efi_media.c
[..]
[IF_TYPE_NVME] = UCLASS_NVME,
[IF_TYPE_EFI] = UCLASS_EFI,
[IF_TYPE_EFI] = UCLASS_EFI_MEDIA,Don't break existing code. Create a new if_type here.
My understanding is that this is not actually used at present. The tests appear to pass without trouble.
What problem are you seeing?
I want the following to be successful:
make sandconfig make menuconfig # set CONFIG_EFI_SELFTEST=y make -j$(nproc) ./u-boot -T setenv efi_selftest block device bootefi selftest ls efi 0:1 load efi 0:1 $fdt_addr_r hello.txt mm.b $fdt_addr_r
A file with the following string is loaded to memory: "Hello world!\r"
I still am lost here.
Do you mean CONFIG_CMD_BOOTEFI_SELFTEST=y
I cannot find CONFIG_EFI_SELFTEST
Assuming it is that, this is what I see when I try that on -next :
/tmp/b/sandbox/u-boot -T sandbox_serial serial: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19
U-Boot 2022.01-rc3-00126-gf89615088fb-dirty (Dec 03 2021 - 20:34:58 -0700)
Model: sandbox DRAM: 128 MiB WDT: Not starting gpio-wdt WDT: Not starting wdt@0 MMC: mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD) Loading Environment from nowhere... OK In: cros-ec-keyb Out: vidconsole Err: vidconsole Model: sandbox SCSI: Net: eth0: eth@10002000, eth5: eth@10003000, eth3: sbe5, eth6: eth@10004000, eth4: dsa-test-eth, eth2: lan0, eth7: lan1 Hit any key to stop autoboot: 0 => setenv efi_selftest block device => bootefi selftest Scanning disk mmc2.blk... Scanning disk mmc1.blk... Scanning disk mmc0.blk... Found 3 disks No EFI system partition Cannot install EFI_TCG2_PROTOCOL "dfu_alt_info" env variable not defined! Probably dfu_alt_info not defined "dfu_alt_info" env variable not defined! Probably dfu_alt_info not defined
Testing EFI API implementation
Selected test: 'block device'
Setting up 'block device' Setting up 'block device' succeeded
Executing 'block device' lib/efi_selftest/efi_selftest_block_device.c(404): TODO: Wrong volume label '', expected 'U-BOOT TEST' Executing 'block device' succeeded
Tearing down 'block device' Tearing down 'block device' succeeded
Summary: 0 failures
=> ls efi 0:1 Couldn't find partition efi 0:1 => load efi 0:1 $fdt_addr_r hello.txt Couldn't find partition efi 0:1 Can't set block device
What am I missing?
It works if I apply
[PATCH 1/1] blk: simplify blk_get_devnum_by_typename() https://lists.denx.de/pipermail/u-boot/2021-October/464585.html
If you want to keep the superfluous if_type-uclass table, please, use a separate if_type for each uclass in this patch and suggest an alternative fix for the test above.
Regards, Simon [..]