hi Simon,
On Wed, 19 Jul 2023 at 06:41, Simon Glass sjg@chromium.org wrote:
Hi Sughosh,
On Mon, 17 Jul 2023 at 05:18, Sughosh Ganu sughosh.ganu@linaro.org wrote:
hi Simon,
On Sun, 16 Jul 2023 at 05:12, Simon Glass sjg@chromium.org wrote:
Hi Sughosh,
On Sat, 15 Jul 2023 at 07:46, Sughosh Ganu sughosh.ganu@linaro.org wrote:
The EFI capsule files can now be generated as part of u-boot build. This is done through binman. Add capsule entry nodes in the u-boot.dtsi for the sandbox architecture for generating the capsules. Remove the corresponding generation of capsules from the capsule update conftest file.
The capsules are generated through the config file for the sandbox variant, and through explicit parameters for the sandbox_flattree variant.
Also generate the FIT image used for testing the capsule update feature on the sandbox_flattree variant through binman. Remove the now superfluous its file which was used for generating this FIT image.
Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org
Changes since V3:
- Use blob nodes instead of incbin for including the binaries in FIT image.
- Enable generation of capsules with versioning support.
arch/sandbox/dts/u-boot.dtsi | 265 ++++++++++++++++++ test/py/tests/test_efi_capsule/conftest.py | 127 --------- .../tests/test_efi_capsule/uboot_bin_env.its | 36 --- 3 files changed, 265 insertions(+), 163 deletions(-) delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its
diff --git a/arch/sandbox/dts/u-boot.dtsi b/arch/sandbox/dts/u-boot.dtsi index 60bd004937..7b0250ac81 100644 --- a/arch/sandbox/dts/u-boot.dtsi +++ b/arch/sandbox/dts/u-boot.dtsi @@ -13,5 +13,270 @@ capsule-key = /incbin/(CONFIG_EFI_CAPSULE_ESL_FILE); }; #endif
binman: binman {multiple-images;};+};
+&binman {
itb {filename = "/tmp/capsules/uboot_bin_env.itb";fit {description = "Automatic U-Boot environment update";#address-cells = <2>;images {u-boot-bin {description = "U-Boot binary on SPI Flash";compression = "none";type = "firmware";arch = "sandbox";load = <0>;blob {filename = "/tmp/capsules/u-boot.bin.new";};hash-1 {algo = "sha1";};};u-boot-env {description = "U-Boot environment on SPI Flash";compression = "none";type = "firmware";arch = "sandbox";load = <0>;blob {filename = "/tmp/capsules/u-boot.env.new";};hash-1 {algo = "sha1";};};};};};+#ifdef CONFIG_EFI_USE_CAPSULE_CFG_FILE
capsule1 {capsule {cfg-file = CONFIG_EFI_CAPSULE_CFG_FILE;};};+#else
capsule2 {capsule {image-index = <0x1>;image-type-id = "09D7CF52-0720-4710-91D1-08469B7FE9C8";We seem to have a persistent problem with these appearing in the source code.
Perhaps you could add them to a header file and use GUID_MEANINGFUL_NAME here instead (also below).
In general, GUIDs should not be open-coded.
Okay. Will it be okay if I add these to a sandbox_capule.h. Earlier, I had similar GUID macros in the sandbox config header, and you had asked me to move them to the board file.
These are littered all over the place. Perhaps a new 'efi_guid.h'
Okay, I will add these under the efi_guid.h file.
header file that has all of them? We should also make sure they are in lib/uuid.c so they can be printed out.
Please note that these are GUID strings being used here in the generation of the capsule. What you refer to in lib/uuid.c are the actual variables of type efi_guid_t.
filename = "/tmp/capsules/u-boot.bin.new";capsule = "/tmp/capsules/Test01";There is something odd here. You should not need to specify an absolute pathname and should not use /tmp
The /tmp/capsules/ directory is being used for collating all the capsule testing related files. Both the input files as well as the output capsule files are being put under this directory. Do you see any issue with using this directory for the capsule files?
Yes, the binman tests need to run in the input and output directories provided, like all the other tests do. People need to be able to inspect those dirs to see what happened.
Please also check test failures:
testtools.testresult.real._StringException: Traceback (most recent call last): File "/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/binman/ftest.py", line 7012, in testCapsuleGenCapsuleFileMissing self.assertIn("Specify the output capsule file", File "/usr/lib/python3.10/unittest/case.py", line 1112, in assertIn self.fail(self._formatMessage(msg, standardMsg)) File "/usr/lib/python3.10/unittest/case.py", line 675, in fail raise self.failureException(msg) AssertionError: 'Specify the output capsule file' not found in "Filename 'payload.txt' not found in input path (/tmp/binmant.yjusbvaz) (cwd='/scratch/sglass/cosarm/src/third_party/u-boot/files')"
====================================================================== FAIL: binman.ftest.TestFunctional.testCapsuleGenCfgFile (subunit.RemotedTestCase) binman.ftest.TestFunctional.testCapsuleGenCfgFile
testtools.testresult.real._StringException: Traceback (most recent call last): File "/scratch/sglass/cosarm/src/third_party/u-boot/files/tools/binman/ftest.py", line 6958, in testCapsuleGenCfgFile self.assertTrue(os.path.exists(self.capsule_fname)) File "/usr/lib/python3.10/unittest/case.py", line 687, in assertTrue raise self.failureException(msg) AssertionError: False is not true
I had run my patches through CI before submission, so they work fine in the CI setup. I believe this could be because of non-existence of the input files under the /tmp/capsules/ directory. And like I mentioned in my other reply, this issue would just be with the testCapsuleGenCfgFile function. The rest of the tests do use the input and output directories that binman creates for testing.
-sughosh
Ran 522 tests in 1.881s
Regards, Simon