hi Simon,
On Fri, 7 Oct 2022 at 00:37, Simon Glass sjg@chromium.org wrote:
Hi Sughosh,
On Thu, 6 Oct 2022 at 03:07, Sughosh Ganu sughosh.ganu@linaro.org wrote:
Add test cases for accessing the FWU Metadata on the sandbox platform. The sandbox platform also uses the metadata access driver for GPT partitioned block devices.
The FWU feature will be tested on the sandbox64 variant with a raw capsule. Remove the FIT capsule testing from sandbox64 defconfig -- the FIT capsule test will be run on the sandbox_flattree variant.
Signed-off-by: Sughosh Ganu sughosh.ganu@linaro.org Suggested-by: Heinrich Schuchardt xypron.glpk@gmx.de
Changes since V12: None
arch/sandbox/Kconfig | 6 + arch/sandbox/dts/test.dts | 7 +- board/sandbox/sandbox.c | 8 + configs/sandbox64_defconfig | 5 +- lib/fwu_updates/fwu.c | 6 + test/dm/Makefile | 1 + test/dm/fwu_mdata.c | 149 ++++++++++++++++++ test/dm/fwu_mdata_disk_image.h | 112 +++++++++++++
Can this be generated by the Python test setup? See setup_bootflow_image() for an example. Sandbox can access host files easily enough.
This is a dm test for the fwu-mdata uclass, and I was under the impression that the dm tests are to be written in C. Btw, with this setup, the GPT block device driver(drivers/fwu-mdata/gpt_blk.c) is being exercised for all the dm API's without any dummy operations or workarounds.
Otherwise, we could add it as a binary file, with instructions somewhere on how to generate it, as is done for drivers/video/fonts/ and other things.
Also I notice that the file is decompressed in U-Boot and then written out to the MMC device. Doesn't that affect other tests that use that device, i.e. the fastboot tests, given the comments there. If it passes CI, that's fine. But if there is a problem, you could add another mmc device, as is done here:
It does pass the CI tests, so it is not an issue. Thanks.
-sughosh
https://patchwork.ozlabs.org/project/uboot/list/?series=319949 (u-boot-dm/vpa-working)
Regards, Simon