All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: u-boot@lists.denx.de
Subject: [PATCH 2/2 v4] efi: ESRT creation tests
Date: Fri, 26 Feb 2021 15:17:42 +0100	[thread overview]
Message-ID: <ed87733c-a98e-f87b-e746-870a36d0c83a@gmx.de> (raw)
In-Reply-To: <53eee005-c38f-1be1-5ceb-b51d9b1ab7c7@gmx.de>

On 26.02.21 14:55, Heinrich Schuchardt wrote:
> On 23.02.21 17:50, Jose Marinho wrote:
>> This commmit exercises the ESRT creation -- introduced in the previous
>> commit -- in two tests.
>>
>> test 1:
>>  A fake FMP, with TEST_ESRT_NUM_ENTRIES FW images, is installed in the
>>  system leading to the corresponding ESRT entries being populated.
>>  The ESRT entries are checked against the datastructure used to
>>  initialize the FMP.
>>
>> test 1 invocation:
>>  make sandbox_capsule_defconfig all
>>  ./u-boot -d arch/sandbox/dts/test.dtb
>>  ut lib
>>
>> test 2:
>>  The test is part of test_efi_capsule_fw3.
>>
>>  In order to run the test the following must be added to
>>  sandbox_defconfig:
>>   +CONFIG_CMD_SF=y
>>   +CONFIG_CMD_MEMORY=y
>>   +CONFIG_CMD_FAT=y
>>   +CONFIG_DFU=y
>>
>>  The ESRT is printed in the u-boot shell by calling efidebug esrt.
>>  The test ensures that, after the capsule is installed, the  ESRT
>>  contains entries with the GUIDs:
>>   - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
>>   - EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
>>
>> test 2 invocation:
>>  sudo ./test/py/test.py --bd sandbox -k capsule_fw3 -l --build
>>
>> Signed-off-by: Jose Marinho <jose.marinho@arm.com>
>>
>> CC: Heinrich Schuchardt	<xypron.glpk@gmx.de>
>> CC: Sughosh Ganu <sughosh.ganu@linaro.org>
>> CC: AKASHI Takahiro <takahiro.akashi@linaro.org>
>> CC: Ilias Apalodimas <ilias.apalodimas@linaro.org>
>> CC: Andre Przywara <andre.przywara@arm.com>
>> CC: Alexander Graf <agraf@csgraf.de>
>> CC: nd at arm.com
>>
>> ---
>>  cmd/efidebug.c                                |  64 ++++++
>>  test/lib/Makefile                             |   1 +
>>  test/lib/efi_esrt.c                           | 191 ++++++++++++++++++
>>  .../test_efi_capsule/test_capsule_firmware.py |   4 +
>>  4 files changed, 260 insertions(+)
>>  create mode 100644 test/lib/efi_esrt.c
>>
>> diff --git a/cmd/efidebug.c b/cmd/efidebug.c
>> index a7dace2f80..5a9ff2bd9a 100644
>> --- a/cmd/efidebug.c
>> +++ b/cmd/efidebug.c
>> @@ -129,6 +129,61 @@ static int do_efi_capsule_show(struct cmd_tbl *cmdtp, int flag,
>>  	return CMD_RET_SUCCESS;
>>  }
>>
>> +#ifdef CONFIG_EFI_ESRT
>> +/**
>> + * do_efi_capsule_esrt() - manage UEFI capsules
>> + *
>> + * @cmdtp:	Command table
>> + * @flag:	Command flag
>> + * @argc:	Number of arguments
>> + * @argv:	Argument array
>> + * Return:	CMD_RET_SUCCESS on success,
>> + *		CMD_RET_USAGE or CMD_RET_RET_FAILURE on failure
>> + *
>> + * Implement efidebug "capsule esrt" sub-command.
>> + * The prints the current ESRT table.
>> + *
>> + *     efidebug capsule esrt
>> + */
>> +static int do_efi_capsule_esrt(struct cmd_tbl *cmdtp, int flag,
>> +			       int argc, char * const argv[])
>> +{
>> +	struct efi_system_resource_table *esrt = NULL;
>> +
>> +	if (argc != 1)
>> +		return CMD_RET_USAGE;
>> +
>> +	for (int idx = 0; idx < systab.nr_tables; idx++)
>> +		if (!guidcmp(&efi_esrt_guid, &systab.tables[idx].guid))
>> +			esrt = (struct efi_system_resource_table *)systab.tables[idx].table;
>> +
>> +	if (!esrt)
>> +		return CMD_RET_FAILURE;
>> +
>> +	printf("========================================\n");
>> +	printf("ESRT: fw_resource_count=%d\n", esrt->fw_resource_count);
>> +	printf("ESRT: fw_resource_count_max=%d\n", esrt->fw_resource_count_max);
>> +	printf("ESRT: fw_resource_version=%lld\n", esrt->fw_resource_version);
>> +
>> +	for (int idx = 0; idx < esrt->fw_resource_count; idx++) {
>> +		printf("[entry %d]==============================\n", idx);
>> +		printf("ESRT: fw_class=%pUL\n", &esrt->entries[idx].fw_class);
>> +		printf("ESRT: fw_type=%d\n", esrt->entries[idx].fw_type);
>> +		printf("ESRT: fw_version=%d\n", esrt->entries[idx].fw_version);
>> +		printf("ESRT: lowest_supported_fw_version=%d\n",
>> +		       esrt->entries[idx].lowest_supported_fw_version);
>> +		printf("ESRT: capsule_flags=%d\n",
>> +		       esrt->entries[idx].capsule_flags);
>> +		printf("ESRT: last_attempt_version=%d\n",
>> +		       esrt->entries[idx].last_attempt_version);
>> +		printf("ESRT: last_attempt_status=%d\n",
>> +		       esrt->entries[idx].last_attempt_status);
>> +	}
>> +	printf("========================================\n");
>> +
>> +	return CMD_RET_SUCCESS;
>
> With which configuration do we see any entry in the list?
>
> I only got:
>
> => efidebug capsule esrt
> ========================================
> ESRT: fw_resource_count=0
> ESRT: fw_resource_count_max=0
> ESRT: fw_resource_version=1
> ========================================
> =>
>
> with
>
> CONFIG_EFI_HAVE_CAPSULE_SUPPORT=y
> CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y
> CONFIG_EFI_CAPSULE_ON_DISK=y
> # CONFIG_EFI_CAPSULE_ON_DISK_EARLY is not set
> CONFIG_EFI_CAPSULE_FIRMWARE=y
> CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT=y
> # CONFIG_EFI_CAPSULE_AUTHENTICATE is not set
> CONFIG_EFI_CAPSULE_FIRMWARE_FIT=y
> CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y
>
> efidebug dh does not show any FMP protocol installed:
>
> => efidebug dh
> Handle           Protocols
> ================ ====================
> 000000007eef19c0 Device Path, Device Path To Text, Device Path
> Utilities, Device-Tree Fixup, Unicode Collation 2, HII String, HII
> Database, Random Number Generator
> 000000007eef1bb0 Simple Text Output
> 000000007eef1c20 Simple Text Input, Simple Text Input Ex
> 000000007eef1f60 Device Path, Block IO
> 000000007eef2130 Device Path, Block IO, System Partition, Simple File System
> 000000007eef2f10 Driver Binding
> 000000007eef4050 Simple Network, Device Path, PXE Base Code

@Sughosh, Takahiro

If EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in OsIndications
is not set, the FMP protocols are not installed.

Shouldn't the FMP protocols always be installed to process a
CapsuleUpdate() call? Otherwise efi_capsule_update_firmware() will fail
with EFI_UNSUPPORTED.

Best regards

Heinrich

  reply	other threads:[~2021-02-26 14:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-23 16:49 [PATCH 0/2 v4] Add ESRT and test ESRT creation Jose Marinho
2021-02-23 16:50 ` [PATCH 1/2 v4] efi: Add ESRT to the EFI system table Jose Marinho
2021-02-26 14:56   ` Heinrich Schuchardt
2021-02-23 16:50 ` [PATCH 2/2 v4] efi: ESRT creation tests Jose Marinho
2021-02-26 13:55   ` Heinrich Schuchardt
2021-02-26 14:17     ` Heinrich Schuchardt [this message]
2021-03-01  1:18       ` AKASHI Takahiro
2021-03-02 11:51     ` Jose Marinho

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=ed87733c-a98e-f87b-e746-870a36d0c83a@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=u-boot@lists.denx.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.