Hi Sughosh, On Mon, 14 Aug 2023 at 02:17, Sughosh Ganu <sughosh.g...@linaro.org> wrote: > > hi Simon, > > On Sat, 12 Aug 2023 at 22:33, Simon Glass <s...@chromium.org> wrote: > > > > Hi Sughosh, > > > > On Sat, 12 Aug 2023 at 09:40, Sughosh Ganu <sughosh.g...@linaro.org> wrote: > > > > > > hi Simon, > > > > > > On Sat, 12 Aug 2023 at 19:55, Simon Glass <s...@chromium.org> wrote: > > > > > > > > On Fri, 11 Aug 2023 at 23:58, Sughosh Ganu <sughosh.g...@linaro.org> > > > > wrote: > > > > > > > > > > The EFI capsule files can now be generated as part of u-boot > > > > > build through binman. Add capsule entry nodes for the sandbox > > > > > architecture for generating the capsules. These capsules are then used > > > > > for testing the EFI capsule update functionality on the sandbox > > > > > platforms. > > > > > > > > > > Remove the corresponding logic in the test setup which was used for > > > > > generation of these capsule which is now superfluous. > > > > > > > > > > Signed-off-by: Sughosh Ganu <sughosh.g...@linaro.org> > > > > > --- > > > > > Changes since V8: > > > > > * Build the capsules for all sandbox variants. > > > > > * Remove the type property by renaming the capsule nodes as > > > > > 'efi-capsule'. > > > > > > > > > > arch/sandbox/dts/sandbox.dts | 2 + > > > > > arch/sandbox/dts/sandbox_capsule.dtsi | 315 > > > > > ++++++++++++++++++ > > > > > arch/sandbox/dts/test.dts | 2 + > > > > > include/sandbox_efi_capsule.h | 21 ++ > > > > > test/py/tests/test_efi_capsule/conftest.py | 155 +-------- > > > > > .../tests/test_efi_capsule/uboot_bin_env.its | 36 -- > > > > > 6 files changed, 356 insertions(+), 175 deletions(-) > > > > > create mode 100644 arch/sandbox/dts/sandbox_capsule.dtsi > > > > > create mode 100644 include/sandbox_efi_capsule.h > > > > > delete mode 100644 test/py/tests/test_efi_capsule/uboot_bin_env.its > > > > > > > > Reviewed-by: Simon Glass <s...@chromium.org> > > > > > > > > One way to reduce the files is to put all the capsules in the same > > > > binman image. You could have 'size = <0x1000>' so they are all the > > > > same size. > > > > > > > > Then your test could check each one by iterating through the (single) > > > > file. > > > > > > This won't work, as the UEFI specification defines a particular format > > > of the capsule file. For multiple capsules, the individual capsule > > > files need to be present under the /EFI/UpdateCapsule/ directory on > > > the EFI System Partition. The spec does define a format in which a > > > single capsule file can have multiple payloads(input binaries). This > > > is planned to be supported once support has been added for generating > > > capsules through the config file. > > > > We continue to have challenges getting confused between testing and real > > world. > > > > For testing, we can do all sorts of things to make things simpler. We > > don't even need an EFI partition, etc. We can have a test which checks > > that U-Boot can decode an update and apply it, The current tests rely > > far too much on an end-to-end, black-box approach, as I might have > > mentioned. > > Okay, but I am stating the constraints on using a single combined file > based on the way the tests work today. So if we were to generate a > single file consisting of all the individual capsule files, that would > break the tests. That was my point.
Sure...my point is that the tests could use a bit of rework to make them easier and faster to run. Regards, Simon
