From 625d40ab120dbc6f45dbd975857f8f87e422bd0f Mon Sep 17 00:00:00 2001 From: Jerome Forissier Date: Wed, 16 Oct 2024 11:56:26 +0200 Subject: [PATCH] test: boot: fix bootflow_cmd_label for when DSA_SANDBOX is disabled When DSA_SANDBOX is not set, the sandbox tests fail as follows: $ ./test/py/test.py --build-dir=$(pwd) -k bootdev_test_any [...] Scanning for bootflows with label '9' [...] Cannot find '9' (err=-19) This is due to the device list containing two less entries than expected. Therefore, look for label '7' when DSA_SANDBOX is disabled. The actual use case is NET_LWIP=y (to be introduced in later patches) which implies DSA_SANDBOX=n for the time being. Signed-off-by: Jerome Forissier --- test/boot/bootflow.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/test/boot/bootflow.c b/test/boot/bootflow.c index 6ad63afe90..154dea70a5 100644 --- a/test/boot/bootflow.c +++ b/test/boot/bootflow.c @@ -109,9 +109,17 @@ static int bootflow_cmd_label(struct unit_test_state *uts) * 8 [ ] OK mmc mmc2.bootdev * 9 [ + ] OK mmc mmc1.bootdev * a [ ] OK mmc mmc0.bootdev + * + * However with CONFIG_DSA_SANDBOX=n we have two fewer (dsa-test@0 and + * dsa-test@1). */ - ut_assertok(run_command("bootflow scan -lH 9", 0)); - ut_assert_nextline("Scanning for bootflows with label '9'"); + if (CONFIG_IS_ENABLED(DSA_SANDBOX)) { + ut_assertok(run_command("bootflow scan -lH 9", 0)); + ut_assert_nextline("Scanning for bootflows with label '9'"); + } else { + ut_assertok(run_command("bootflow scan -lH 7", 0)); + ut_assert_nextline("Scanning for bootflows with label '7'"); + } ut_assert_skip_to_line("(1 bootflow, 1 valid)"); ut_assertok(run_command("bootflow scan -lH 0", 0)); -- 2.39.5