Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox
On Fri, 17 Jun 2022 at 06:38, Takahiro Akashi wrote: > > Sughosh, > > On Wed, Jun 15, 2022 at 05:40:12PM +0530, Sughosh Ganu wrote: > > On Wed, 15 Jun 2022 at 11:07, Takahiro Akashi > > wrote: > > > > > > On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote: > > > > Add a python test script for testing the FWU Multi Bank Update > > > > functionality on the sandbox platform. The script has test cases for > > > > updation of the u-boot binary and the u-boot environment image to the > > > > non active bank. > > > > > > > > The FWU metadata is being stored on the SPI NOR flash, along with the > > > > updatable images, and the FWU metadata driver for MTD devices is being > > > > used for accessing the metadata. Certain FWU boottime checks are > > > > bypassed due to the unavailability of the EFI variable access very > > > > early in the boot on the sandbox platform -- the variable access is > > > > only available once the block disk image has been bound through the > > > > host interface. > > > > > > > > The FWU Multi Bank feature being enabled on the sandbox64 platform is > > > > enabling the RAW Firmware Management Protocol(FMP) instance, therefore > > > > the FIT FMP instance is being removed -- the FIT FMP is already being > > > > tested on the sandbox flattree variant. > > > > > > IMO, > > > Thinking of the importance of this feature, FIT FMP should also be > > > tested *with FWU*. > > > > How will the FWU update feature work for FIT images? As I understand > > So are you deliberately designing and proposing a solution that is > incompatible with (or not applicable to) an existing interface (FIT FMP)? Heh, why would anyone do that? The very fact that we are introducing support on two platforms, one with a GPT layout, and another with MTD is because the idea is to encourage adoption on multiple platforms. Secondly, this is a specification from Arm which was driven by Jose Marinho, and I believe he has incorporated feedback from various engineers for drafting the specification -- this specification is not limited only to platforms booting with u-boot. The main issue, as I see it, is that the FWU metadata is doing the bookkeeping for images that are present on the platform's storage device, and this just does not map with FIT which is a packaging mechanism. However, this being software, you can make changes to the fit_update function and incorporate the information from the metadata to write to the relevant locations. However, this needs to be thought through. > > > FIT, it is a way of packaging different firmware images into a single > > package. At the time of writing the images, the FIT image parser would > > check the image configuration, and write the images to their > > respective locations. As you are aware, for the FWU feature, the > > information about the images, and the update bank is obtained from the > > structure called metadata. How does the FIT update mechanism map with > > the FWU metadata which is used to identify which bank needs to be > > updated. The bank to which the image is to be written translates into > > the DFU alt_num value for that image, and this gets computed at > > runtime. In the case of the FIT image, as per my understanding, the > > alt_num value is irrelevant. So my question is, how do we map the > > information obtained from the FWU metadata to tell the FIT image > > writing function(fit_update) which locations do the images need to be > > written to. I think this needs some more thought. > > > > > > > > > Signed-off-by: Sughosh Ganu > > > > --- > > > > arch/sandbox/Kconfig | 6 + > > > > arch/sandbox/dts/test.dts | 45 ++- > > > > board/sandbox/sandbox.c | 49 +++ > > > > configs/sandbox64_defconfig | 12 +- > > > > include/fwu.h | 2 + > > > > lib/fwu_updates/Kconfig | 2 +- > > > > lib/fwu_updates/fwu.c | 18 +- > > > > lib/fwu_updates/fwu_mtd.c | 10 +- > > > > .../test_capsule_firmware_fit.py | 1 - > > > > .../py/tests/test_fwu_updates/capsule_defs.py | 10 + > > > > test/py/tests/test_fwu_updates/conftest.py| 78 > > > > .../test_fwu_updates/test_fwu_updates.py | 367 ++ > > > > 12 files changed, 587 insertions(+), 13 deletions(-) > > > > create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py > > > > create mode 100644 test/py/tests/test_fwu_updates/conftest.py > > > > create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py > > > > > > > > > > > > > > diff --git a/test/py/tests/test_fwu_updates/conftest.py > > > > b/test/py/tests/test_fwu_updates/conftest.py > > > > new file mode 100644 > > > > index 00..cdf824c3be > > > > --- /dev/null > > > > +++ b/test/py/tests/test_fwu_updates/conftest.py > > > > @@ -0,0 +1,78 @@ > > > > +# SPDX-License-Identifier: GPL-2.0+ > > > > +#
Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox
Sughosh, On Wed, Jun 15, 2022 at 05:40:12PM +0530, Sughosh Ganu wrote: > On Wed, 15 Jun 2022 at 11:07, Takahiro Akashi > wrote: > > > > On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote: > > > Add a python test script for testing the FWU Multi Bank Update > > > functionality on the sandbox platform. The script has test cases for > > > updation of the u-boot binary and the u-boot environment image to the > > > non active bank. > > > > > > The FWU metadata is being stored on the SPI NOR flash, along with the > > > updatable images, and the FWU metadata driver for MTD devices is being > > > used for accessing the metadata. Certain FWU boottime checks are > > > bypassed due to the unavailability of the EFI variable access very > > > early in the boot on the sandbox platform -- the variable access is > > > only available once the block disk image has been bound through the > > > host interface. > > > > > > The FWU Multi Bank feature being enabled on the sandbox64 platform is > > > enabling the RAW Firmware Management Protocol(FMP) instance, therefore > > > the FIT FMP instance is being removed -- the FIT FMP is already being > > > tested on the sandbox flattree variant. > > > > IMO, > > Thinking of the importance of this feature, FIT FMP should also be > > tested *with FWU*. > > How will the FWU update feature work for FIT images? As I understand So are you deliberately designing and proposing a solution that is incompatible with (or not applicable to) an existing interface (FIT FMP)? > FIT, it is a way of packaging different firmware images into a single > package. At the time of writing the images, the FIT image parser would > check the image configuration, and write the images to their > respective locations. As you are aware, for the FWU feature, the > information about the images, and the update bank is obtained from the > structure called metadata. How does the FIT update mechanism map with > the FWU metadata which is used to identify which bank needs to be > updated. The bank to which the image is to be written translates into > the DFU alt_num value for that image, and this gets computed at > runtime. In the case of the FIT image, as per my understanding, the > alt_num value is irrelevant. So my question is, how do we map the > information obtained from the FWU metadata to tell the FIT image > writing function(fit_update) which locations do the images need to be > written to. I think this needs some more thought. > > > > > > Signed-off-by: Sughosh Ganu > > > --- > > > arch/sandbox/Kconfig | 6 + > > > arch/sandbox/dts/test.dts | 45 ++- > > > board/sandbox/sandbox.c | 49 +++ > > > configs/sandbox64_defconfig | 12 +- > > > include/fwu.h | 2 + > > > lib/fwu_updates/Kconfig | 2 +- > > > lib/fwu_updates/fwu.c | 18 +- > > > lib/fwu_updates/fwu_mtd.c | 10 +- > > > .../test_capsule_firmware_fit.py | 1 - > > > .../py/tests/test_fwu_updates/capsule_defs.py | 10 + > > > test/py/tests/test_fwu_updates/conftest.py| 78 > > > .../test_fwu_updates/test_fwu_updates.py | 367 ++ > > > 12 files changed, 587 insertions(+), 13 deletions(-) > > > create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py > > > create mode 100644 test/py/tests/test_fwu_updates/conftest.py > > > create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py > > > > > > > > > diff --git a/test/py/tests/test_fwu_updates/conftest.py > > > b/test/py/tests/test_fwu_updates/conftest.py > > > new file mode 100644 > > > index 00..cdf824c3be > > > --- /dev/null > > > +++ b/test/py/tests/test_fwu_updates/conftest.py > > > @@ -0,0 +1,78 @@ > > > +# SPDX-License-Identifier: GPL-2.0+ > > > +# Copyright (c) 2020, Linaro Limited > > > +# Author: AKASHI Takahiro > > > > If this file is exactly same as test_efi_capsule/conftest.py, > > why not move all the tests (test_fwu_updates.py) to test_efi_capsule? > > The files are not exactly the same. There is use of the mkfwumdata > utility used for FWU tests, along with the capsule files that are > being generated. I had tried putting the code under the > test_efi_capsule directory, but the result was getting cluttered. Okay, but from my curiosity, how cluttered was it? It seems to me that you are simply adding extra setup steps. My simple concern is that, if there is a fair amount of common code between two tests, it should be unified for maintainability. -Takahiro Akashi > Which is why I decided to put the changes separately under the > test_fwu_updates directory. > > > > > The basic scenario of updating firmware, u-boot.bin and u-boot.env, > > is also the same, isn't it? The only difference is whether > > FWU_MULTI_BANK_UPDATE > > is enabled or not. > > There are two capsule files per image, one per bank.
Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox
On Wed, 15 Jun 2022 at 12:00, Takahiro Akashi
wrote:
>
> On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote:
> > Add a python test script for testing the FWU Multi Bank Update
> > functionality on the sandbox platform. The script has test cases for
> > updation of the u-boot binary and the u-boot environment image to the
> > non active bank.
>
> IIUC, your test doesn't not exercise neither accept-capsule nor
> revert capsule.
> I think those tests are crucial for verifying the code.
Yes, this is on my todo list. By default, all the images get accepted
by the firmware itself, which is being done in u-boot. In case the
oemflag bit 15 is set to 1 in the capsule header, the image acceptance
is done through the accept capsule. I will need to add support for
passing the oemflag parameter to the mkeficapsule, and then I can test
this. Will keep this on my todo list, and try to put it in the
upcoming versions.
-sughosh
>
> -Takahiro Akashi
>
> > The FWU metadata is being stored on the SPI NOR flash, along with the
> > updatable images, and the FWU metadata driver for MTD devices is being
> > used for accessing the metadata. Certain FWU boottime checks are
> > bypassed due to the unavailability of the EFI variable access very
> > early in the boot on the sandbox platform -- the variable access is
> > only available once the block disk image has been bound through the
> > host interface.
> >
> > The FWU Multi Bank feature being enabled on the sandbox64 platform is
> > enabling the RAW Firmware Management Protocol(FMP) instance, therefore
> > the FIT FMP instance is being removed -- the FIT FMP is already being
> > tested on the sandbox flattree variant.
> >
> > Signed-off-by: Sughosh Ganu
> > ---
> > arch/sandbox/Kconfig | 6 +
> > arch/sandbox/dts/test.dts | 45 ++-
> > board/sandbox/sandbox.c | 49 +++
> > configs/sandbox64_defconfig | 12 +-
> > include/fwu.h | 2 +
> > lib/fwu_updates/Kconfig | 2 +-
> > lib/fwu_updates/fwu.c | 18 +-
> > lib/fwu_updates/fwu_mtd.c | 10 +-
> > .../test_capsule_firmware_fit.py | 1 -
> > .../py/tests/test_fwu_updates/capsule_defs.py | 10 +
> > test/py/tests/test_fwu_updates/conftest.py| 78
> > .../test_fwu_updates/test_fwu_updates.py | 367 ++
> > 12 files changed, 587 insertions(+), 13 deletions(-)
> > create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py
> > create mode 100644 test/py/tests/test_fwu_updates/conftest.py
> > create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py
> >
> > diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
> > index 5f55c7f28e..2985572083 100644
> > --- a/arch/sandbox/Kconfig
> > +++ b/arch/sandbox/Kconfig
> > @@ -84,3 +84,9 @@ config SYS_FDT_LOAD_ADDR
> > See `doc/arch/sandbox.rst` for more information.
> >
> > endmenu
> > +
> > +config FWU_NUM_BANKS
> > + default 2
> > +
> > +config FWU_NUM_IMAGES_PER_BANK
> > + default 2
> > diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> > index 8f93775ff4..f11fa8733f 100644
> > --- a/arch/sandbox/dts/test.dts
> > +++ b/arch/sandbox/dts/test.dts
> > @@ -1145,11 +1145,48 @@
> > pinctrl-names = "default";
> > pinctrl-0 = <_spi0_pins>;
> >
> > - spi.bin@0 {
> > + spi0: spi.bin@0 {
> > reg = <0>;
> > compatible = "spansion,m25p16", "jedec,spi-nor";
> > spi-max-frequency = <4000>;
> > sandbox,filename = "spi.bin";
> > +
> > + partitions {
> > + compatible = "fixed-partitions";
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + uuid = "af9e8c96-bec5-48be-9dab-3491c04b1366";
> > +
> > + partition@0 {
> > + label = "Metadata";
> > + reg = <0x0 0x2>;
> > + };
> > +
> > + /* FWU Multi bank update partitions */
> > + partition@10 {
> > + label = "U-Boot-Bank0";
> > + reg = <0x10 0x1>;
> > + uuid =
> > "a8f61787-5d68-4c9d-9e4a-37bb0df99da7";
> > + };
> > +
> > + partition@12 {
> > + label = "U-Boot-ENV-Bank0";
> > + reg = <0x12 0x1>;
> > + uuid =
> > "ea9d59af-e0e8-4ef5-9b16-4c80ff67524c";
> > + };
> > +
> > +
Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox
On Wed, 15 Jun 2022 at 11:07, Takahiro Akashi wrote: > > On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote: > > Add a python test script for testing the FWU Multi Bank Update > > functionality on the sandbox platform. The script has test cases for > > updation of the u-boot binary and the u-boot environment image to the > > non active bank. > > > > The FWU metadata is being stored on the SPI NOR flash, along with the > > updatable images, and the FWU metadata driver for MTD devices is being > > used for accessing the metadata. Certain FWU boottime checks are > > bypassed due to the unavailability of the EFI variable access very > > early in the boot on the sandbox platform -- the variable access is > > only available once the block disk image has been bound through the > > host interface. > > > > The FWU Multi Bank feature being enabled on the sandbox64 platform is > > enabling the RAW Firmware Management Protocol(FMP) instance, therefore > > the FIT FMP instance is being removed -- the FIT FMP is already being > > tested on the sandbox flattree variant. > > IMO, > Thinking of the importance of this feature, FIT FMP should also be > tested *with FWU*. How will the FWU update feature work for FIT images? As I understand FIT, it is a way of packaging different firmware images into a single package. At the time of writing the images, the FIT image parser would check the image configuration, and write the images to their respective locations. As you are aware, for the FWU feature, the information about the images, and the update bank is obtained from the structure called metadata. How does the FIT update mechanism map with the FWU metadata which is used to identify which bank needs to be updated. The bank to which the image is to be written translates into the DFU alt_num value for that image, and this gets computed at runtime. In the case of the FIT image, as per my understanding, the alt_num value is irrelevant. So my question is, how do we map the information obtained from the FWU metadata to tell the FIT image writing function(fit_update) which locations do the images need to be written to. I think this needs some more thought. > > > Signed-off-by: Sughosh Ganu > > --- > > arch/sandbox/Kconfig | 6 + > > arch/sandbox/dts/test.dts | 45 ++- > > board/sandbox/sandbox.c | 49 +++ > > configs/sandbox64_defconfig | 12 +- > > include/fwu.h | 2 + > > lib/fwu_updates/Kconfig | 2 +- > > lib/fwu_updates/fwu.c | 18 +- > > lib/fwu_updates/fwu_mtd.c | 10 +- > > .../test_capsule_firmware_fit.py | 1 - > > .../py/tests/test_fwu_updates/capsule_defs.py | 10 + > > test/py/tests/test_fwu_updates/conftest.py| 78 > > .../test_fwu_updates/test_fwu_updates.py | 367 ++ > > 12 files changed, 587 insertions(+), 13 deletions(-) > > create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py > > create mode 100644 test/py/tests/test_fwu_updates/conftest.py > > create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py > > > > diff --git a/test/py/tests/test_fwu_updates/conftest.py > > b/test/py/tests/test_fwu_updates/conftest.py > > new file mode 100644 > > index 00..cdf824c3be > > --- /dev/null > > +++ b/test/py/tests/test_fwu_updates/conftest.py > > @@ -0,0 +1,78 @@ > > +# SPDX-License-Identifier: GPL-2.0+ > > +# Copyright (c) 2020, Linaro Limited > > +# Author: AKASHI Takahiro > > If this file is exactly same as test_efi_capsule/conftest.py, > why not move all the tests (test_fwu_updates.py) to test_efi_capsule? The files are not exactly the same. There is use of the mkfwumdata utility used for FWU tests, along with the capsule files that are being generated. I had tried putting the code under the test_efi_capsule directory, but the result was getting cluttered. Which is why I decided to put the changes separately under the test_fwu_updates directory. > > The basic scenario of updating firmware, u-boot.bin and u-boot.env, > is also the same, isn't it? The only difference is whether > FWU_MULTI_BANK_UPDATE > is enabled or not. There are two capsule files per image, one per bank. Also, the FWU metadata is being written to the SPI NOR device, which is being formatted as a MTD partitioned device. The underlying update mechanism is the same, yes. -sughosh > > -Takahiro Akashi > > > + > > +import os > > +import os.path > > +import re > > +from subprocess import call, check_call, check_output, CalledProcessError > > +import pytest > > +from capsule_defs import * > > + > > +# > > +# Fixture for UEFI capsule test > > +# > > + > > +@pytest.fixture(scope='session') > > +def efi_capsule_data(request, u_boot_config): > > +"""Set up a file system to be used in UEFI capsule and > > + authentication test. > > + > > +Args: > > +
Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox
On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote:
> Add a python test script for testing the FWU Multi Bank Update
> functionality on the sandbox platform. The script has test cases for
> updation of the u-boot binary and the u-boot environment image to the
> non active bank.
IIUC, your test doesn't not exercise neither accept-capsule nor
revert capsule.
I think those tests are crucial for verifying the code.
-Takahiro Akashi
> The FWU metadata is being stored on the SPI NOR flash, along with the
> updatable images, and the FWU metadata driver for MTD devices is being
> used for accessing the metadata. Certain FWU boottime checks are
> bypassed due to the unavailability of the EFI variable access very
> early in the boot on the sandbox platform -- the variable access is
> only available once the block disk image has been bound through the
> host interface.
>
> The FWU Multi Bank feature being enabled on the sandbox64 platform is
> enabling the RAW Firmware Management Protocol(FMP) instance, therefore
> the FIT FMP instance is being removed -- the FIT FMP is already being
> tested on the sandbox flattree variant.
>
> Signed-off-by: Sughosh Ganu
> ---
> arch/sandbox/Kconfig | 6 +
> arch/sandbox/dts/test.dts | 45 ++-
> board/sandbox/sandbox.c | 49 +++
> configs/sandbox64_defconfig | 12 +-
> include/fwu.h | 2 +
> lib/fwu_updates/Kconfig | 2 +-
> lib/fwu_updates/fwu.c | 18 +-
> lib/fwu_updates/fwu_mtd.c | 10 +-
> .../test_capsule_firmware_fit.py | 1 -
> .../py/tests/test_fwu_updates/capsule_defs.py | 10 +
> test/py/tests/test_fwu_updates/conftest.py| 78
> .../test_fwu_updates/test_fwu_updates.py | 367 ++
> 12 files changed, 587 insertions(+), 13 deletions(-)
> create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py
> create mode 100644 test/py/tests/test_fwu_updates/conftest.py
> create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py
>
> diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
> index 5f55c7f28e..2985572083 100644
> --- a/arch/sandbox/Kconfig
> +++ b/arch/sandbox/Kconfig
> @@ -84,3 +84,9 @@ config SYS_FDT_LOAD_ADDR
> See `doc/arch/sandbox.rst` for more information.
>
> endmenu
> +
> +config FWU_NUM_BANKS
> + default 2
> +
> +config FWU_NUM_IMAGES_PER_BANK
> + default 2
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 8f93775ff4..f11fa8733f 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -1145,11 +1145,48 @@
> pinctrl-names = "default";
> pinctrl-0 = <_spi0_pins>;
>
> - spi.bin@0 {
> + spi0: spi.bin@0 {
> reg = <0>;
> compatible = "spansion,m25p16", "jedec,spi-nor";
> spi-max-frequency = <4000>;
> sandbox,filename = "spi.bin";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + uuid = "af9e8c96-bec5-48be-9dab-3491c04b1366";
> +
> + partition@0 {
> + label = "Metadata";
> + reg = <0x0 0x2>;
> + };
> +
> + /* FWU Multi bank update partitions */
> + partition@10 {
> + label = "U-Boot-Bank0";
> + reg = <0x10 0x1>;
> + uuid =
> "a8f61787-5d68-4c9d-9e4a-37bb0df99da7";
> + };
> +
> + partition@12 {
> + label = "U-Boot-ENV-Bank0";
> + reg = <0x12 0x1>;
> + uuid =
> "ea9d59af-e0e8-4ef5-9b16-4c80ff67524c";
> + };
> +
> + partition@14 {
> + label = "U-Boot-Bank1";
> + reg = <0x14 0x1>;
> + uuid =
> "52377abf-c4e4-4d0b-aafd-ba081a500847";
> + };
> +
> + partition@16 {
> + label = "U-Boot-ENV-Bank1";
> + reg = <0x16 0x1>;
> + uuid =
> "4e01d1fa-eebb-437e-9cfe-e7dfbcd04bb3";
> + };
> + };
> };
> spi.bin@1
Re: [PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox
On Thu, Jun 09, 2022 at 06:00:10PM +0530, Sughosh Ganu wrote:
> Add a python test script for testing the FWU Multi Bank Update
> functionality on the sandbox platform. The script has test cases for
> updation of the u-boot binary and the u-boot environment image to the
> non active bank.
>
> The FWU metadata is being stored on the SPI NOR flash, along with the
> updatable images, and the FWU metadata driver for MTD devices is being
> used for accessing the metadata. Certain FWU boottime checks are
> bypassed due to the unavailability of the EFI variable access very
> early in the boot on the sandbox platform -- the variable access is
> only available once the block disk image has been bound through the
> host interface.
>
> The FWU Multi Bank feature being enabled on the sandbox64 platform is
> enabling the RAW Firmware Management Protocol(FMP) instance, therefore
> the FIT FMP instance is being removed -- the FIT FMP is already being
> tested on the sandbox flattree variant.
IMO,
Thinking of the importance of this feature, FIT FMP should also be
tested *with FWU*.
> Signed-off-by: Sughosh Ganu
> ---
> arch/sandbox/Kconfig | 6 +
> arch/sandbox/dts/test.dts | 45 ++-
> board/sandbox/sandbox.c | 49 +++
> configs/sandbox64_defconfig | 12 +-
> include/fwu.h | 2 +
> lib/fwu_updates/Kconfig | 2 +-
> lib/fwu_updates/fwu.c | 18 +-
> lib/fwu_updates/fwu_mtd.c | 10 +-
> .../test_capsule_firmware_fit.py | 1 -
> .../py/tests/test_fwu_updates/capsule_defs.py | 10 +
> test/py/tests/test_fwu_updates/conftest.py| 78
> .../test_fwu_updates/test_fwu_updates.py | 367 ++
> 12 files changed, 587 insertions(+), 13 deletions(-)
> create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py
> create mode 100644 test/py/tests/test_fwu_updates/conftest.py
> create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py
>
> diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
> index 5f55c7f28e..2985572083 100644
> --- a/arch/sandbox/Kconfig
> +++ b/arch/sandbox/Kconfig
> @@ -84,3 +84,9 @@ config SYS_FDT_LOAD_ADDR
> See `doc/arch/sandbox.rst` for more information.
>
> endmenu
> +
> +config FWU_NUM_BANKS
> + default 2
> +
> +config FWU_NUM_IMAGES_PER_BANK
> + default 2
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 8f93775ff4..f11fa8733f 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -1145,11 +1145,48 @@
> pinctrl-names = "default";
> pinctrl-0 = <_spi0_pins>;
>
> - spi.bin@0 {
> + spi0: spi.bin@0 {
> reg = <0>;
> compatible = "spansion,m25p16", "jedec,spi-nor";
> spi-max-frequency = <4000>;
> sandbox,filename = "spi.bin";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + uuid = "af9e8c96-bec5-48be-9dab-3491c04b1366";
> +
> + partition@0 {
> + label = "Metadata";
> + reg = <0x0 0x2>;
> + };
> +
> + /* FWU Multi bank update partitions */
> + partition@10 {
> + label = "U-Boot-Bank0";
> + reg = <0x10 0x1>;
> + uuid =
> "a8f61787-5d68-4c9d-9e4a-37bb0df99da7";
> + };
> +
> + partition@12 {
> + label = "U-Boot-ENV-Bank0";
> + reg = <0x12 0x1>;
> + uuid =
> "ea9d59af-e0e8-4ef5-9b16-4c80ff67524c";
> + };
> +
> + partition@14 {
> + label = "U-Boot-Bank1";
> + reg = <0x14 0x1>;
> + uuid =
> "52377abf-c4e4-4d0b-aafd-ba081a500847";
> + };
> +
> + partition@16 {
> + label = "U-Boot-ENV-Bank1";
> + reg = <0x16 0x1>;
> + uuid =
> "4e01d1fa-eebb-437e-9cfe-e7dfbcd04bb3";
> + };
> + };
> };
> spi.bin@1 {
> reg = <1>;
> @@ -1633,6 +1670,12 @@
[PATCH v5 23/23] sandbox: fwu: Add support for testing FWU feature on sandbox
Add a python test script for testing the FWU Multi Bank Update
functionality on the sandbox platform. The script has test cases for
updation of the u-boot binary and the u-boot environment image to the
non active bank.
The FWU metadata is being stored on the SPI NOR flash, along with the
updatable images, and the FWU metadata driver for MTD devices is being
used for accessing the metadata. Certain FWU boottime checks are
bypassed due to the unavailability of the EFI variable access very
early in the boot on the sandbox platform -- the variable access is
only available once the block disk image has been bound through the
host interface.
The FWU Multi Bank feature being enabled on the sandbox64 platform is
enabling the RAW Firmware Management Protocol(FMP) instance, therefore
the FIT FMP instance is being removed -- the FIT FMP is already being
tested on the sandbox flattree variant.
Signed-off-by: Sughosh Ganu
---
arch/sandbox/Kconfig | 6 +
arch/sandbox/dts/test.dts | 45 ++-
board/sandbox/sandbox.c | 49 +++
configs/sandbox64_defconfig | 12 +-
include/fwu.h | 2 +
lib/fwu_updates/Kconfig | 2 +-
lib/fwu_updates/fwu.c | 18 +-
lib/fwu_updates/fwu_mtd.c | 10 +-
.../test_capsule_firmware_fit.py | 1 -
.../py/tests/test_fwu_updates/capsule_defs.py | 10 +
test/py/tests/test_fwu_updates/conftest.py| 78
.../test_fwu_updates/test_fwu_updates.py | 367 ++
12 files changed, 587 insertions(+), 13 deletions(-)
create mode 100644 test/py/tests/test_fwu_updates/capsule_defs.py
create mode 100644 test/py/tests/test_fwu_updates/conftest.py
create mode 100644 test/py/tests/test_fwu_updates/test_fwu_updates.py
diff --git a/arch/sandbox/Kconfig b/arch/sandbox/Kconfig
index 5f55c7f28e..2985572083 100644
--- a/arch/sandbox/Kconfig
+++ b/arch/sandbox/Kconfig
@@ -84,3 +84,9 @@ config SYS_FDT_LOAD_ADDR
See `doc/arch/sandbox.rst` for more information.
endmenu
+
+config FWU_NUM_BANKS
+ default 2
+
+config FWU_NUM_IMAGES_PER_BANK
+ default 2
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8f93775ff4..f11fa8733f 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -1145,11 +1145,48 @@
pinctrl-names = "default";
pinctrl-0 = <_spi0_pins>;
- spi.bin@0 {
+ spi0: spi.bin@0 {
reg = <0>;
compatible = "spansion,m25p16", "jedec,spi-nor";
spi-max-frequency = <4000>;
sandbox,filename = "spi.bin";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ uuid = "af9e8c96-bec5-48be-9dab-3491c04b1366";
+
+ partition@0 {
+ label = "Metadata";
+ reg = <0x0 0x2>;
+ };
+
+ /* FWU Multi bank update partitions */
+ partition@10 {
+ label = "U-Boot-Bank0";
+ reg = <0x10 0x1>;
+ uuid =
"a8f61787-5d68-4c9d-9e4a-37bb0df99da7";
+ };
+
+ partition@12 {
+ label = "U-Boot-ENV-Bank0";
+ reg = <0x12 0x1>;
+ uuid =
"ea9d59af-e0e8-4ef5-9b16-4c80ff67524c";
+ };
+
+ partition@14 {
+ label = "U-Boot-Bank1";
+ reg = <0x14 0x1>;
+ uuid =
"52377abf-c4e4-4d0b-aafd-ba081a500847";
+ };
+
+ partition@16 {
+ label = "U-Boot-ENV-Bank1";
+ reg = <0x16 0x1>;
+ uuid =
"4e01d1fa-eebb-437e-9cfe-e7dfbcd04bb3";
+ };
+ };
};
spi.bin@1 {
reg = <1>;
@@ -1633,6 +1670,12 @@
compatible = "sandbox,regmap_test";
};
};
+
+ fwu-mdata {
+ compatible = "u-boot,fwu-mdata-mtd";
+ fwu-mdata-store = <>;
+ mdata-offsets = <0x0 0x1>;
+ };
};
#include
