[PATCH 0/5] gitlab: Fixes to get StarFive VisionFive2 into the sjg lab

This board fought valiantly against attempts to add it to my lab. After several hours of debugging, I found problems in the Labgrid integration (not included here), test.py and buildman
This series fixes these and the board now seems to be reliable enough.
Note that the board fails test_dm_compat
Link: https://github.com/labgrid-project/labgrid/pull/1411
Simon Glass (5): test/py: Provide the correct U_BOOT_SOURCE_DIR to getrole test/py: Handle u-boot-test-getrole failure buildman: Drop unused OUTPUT_FILE constant buildman: Record an error if a toolchain is missing gitlab: Add a StarFive VisionFive2 to the sjg lab
.gitlab-ci.yml | 5 +++++ test/py/conftest.py | 9 +++++++-- tools/buildman/boards.py | 1 - tools/buildman/builderthread.py | 8 ++++++-- 4 files changed, 18 insertions(+), 5 deletions(-)

The u-boot-test-getrole script runs before the normal environment variables have been set up. This is unavoidable since the script is providing necessary information to test.py
This means that U_BOOT_SOURCE_DIR is not set in the environment.
As a result, Labgrid uses its default source path, configured in its environment variable. While this may happen to work, it is not correct. Also, it causes problems when running from Gitlab, where the runner may not have access to that source path.
Provide the required source path in U_BOOT_SOURCE_DIR so that Labgrid does the right thing.
Signed-off-by: Simon Glass sjg@chromium.org Fixes: bf89a8f1fc2 ("test: Introduce the concept of a role")
[1] https://patchwork.ozlabs.org/project/uboot/patch/20241211131858.520639-1-sjg...
--- This patch is intended to be applied on top of [1], which fixes a similar issue, but only within pytest itself. It should be possible to drop that patch and just use this one, but it is a bit nonsensical to ask Labgrid for something which test.py already knows, so both patches are valuable.
test/py/conftest.py | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/test/py/conftest.py b/test/py/conftest.py index 509d19b449d..acc7e5e090c 100644 --- a/test/py/conftest.py +++ b/test/py/conftest.py @@ -158,6 +158,10 @@ def get_details(config): env['U_BOOT_BUILD_DIR'] = build_dir if build_dir_extra: env['U_BOOT_BUILD_DIR_EXTRA'] = build_dir_extra + + # Make sure the script sees that it is being run from pytest + env['U_BOOT_SOURCE_DIR'] = source_dir + proc = subprocess.run(cmd, capture_output=True, encoding='utf-8', env=env) if proc.returncode:

This script can fail if there is no toolchain available for the board. At present this is not handled very nicely, in that only the error output is reported. It is much more useful to see everything, so combine stdout and stderr and report them both.
Signed-off-by: Simon Glass sjg@chromium.org ---
test/py/conftest.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/test/py/conftest.py b/test/py/conftest.py index acc7e5e090c..d4127dd0a93 100644 --- a/test/py/conftest.py +++ b/test/py/conftest.py @@ -162,10 +162,11 @@ def get_details(config): # Make sure the script sees that it is being run from pytest env['U_BOOT_SOURCE_DIR'] = source_dir
- proc = subprocess.run(cmd, capture_output=True, encoding='utf-8', + proc = subprocess.run(cmd, stdout=subprocess.PIPE, + stderr=subprocess.STDOUT, encoding='utf-8', env=env) if proc.returncode: - raise ValueError(proc.stderr) + raise ValueError(f"Error {proc.returncode} running {cmd}: '{proc.stderr} '{proc.stdout}'") # For debugging # print('conftest: lab:', proc.stdout) vals = {}

This is not actually used but its presence suggests that it is the filename for the board database. Drop it to avoid confusion.
Signed-off-by: Simon Glass sjg@chromium.org ---
tools/buildman/boards.py | 1 - 1 file changed, 1 deletion(-)
diff --git a/tools/buildman/boards.py b/tools/buildman/boards.py index 9e7b486656b..e7aa0d85a58 100644 --- a/tools/buildman/boards.py +++ b/tools/buildman/boards.py @@ -25,7 +25,6 @@ from u_boot_pylib import tools from u_boot_pylib import tout
### constant variables ### -OUTPUT_FILE = 'boards.cfg' CONFIG_DIR = 'configs' SLEEP_TIME = 0.03 COMMENT_BLOCK = f'''#

Buildman has always treated the lack of a toolchain as an infrastructure problem rather than a build failure.
However the logic for this is not correct, since it does not write a 'done' file in this case.
As a result, one of two things can happen.
1. If a previous build ran in the same (output) directory, the outcome of *that* build is recorded as the outcome of this one 2. Otherwise, no outcome is recorded
Obviously this inconsistency is not ideal. While (2) is rare, it can be very confusing as the build sort-of fails but does not produce any summary output with 'buildman -s'
Overall it seems better to attribute a toolchain issue to the boards that it affects. This results in clear failures which can be examined, no matter what happened in the .bm-work directory previously.
So write a 'done' file for each build when a toolchain is missing.
The end result of this patch is to make missing toolchains much more obvious. It should be things a bit easier for novice users.
Signed-off-by: Simon Glass sjg@chromium.org ---
tools/buildman/builderthread.py | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/tools/buildman/builderthread.py b/tools/buildman/builderthread.py index b5afee61aff..29e6cf32af1 100644 --- a/tools/buildman/builderthread.py +++ b/tools/buildman/builderthread.py @@ -19,6 +19,7 @@ import threading from buildman import cfgutil from patman import gitutil from u_boot_pylib import command +from u_boot_pylib import tools
RETURN_CODE_RETRY = -1 BASE_ELF_FILENAMES = ['u-boot', 'spl/u-boot-spl', 'tpl/u-boot-tpl'] @@ -555,10 +556,10 @@ class BuilderThread(threading.Thread): if result.return_code < 0: return
+ done_file = self.builder.get_done_file(result.commit_upto, + result.brd.target) if result.toolchain: # Write the build result and toolchain information. - done_file = self.builder.get_done_file(result.commit_upto, - result.brd.target) with open(done_file, 'w', encoding='utf-8') as outf: if maybe_aborted: # Special code to indicate we need to retry @@ -638,6 +639,9 @@ class BuilderThread(threading.Thread): result.brd.target) with open(sizes, 'w', encoding='utf-8') as outf: print('\n'.join(lines), file=outf) + else: + # Indicate that the build failure due to lack of toolchain + tools.write_file(done_file, '2\n', binary=False)
if not work_in_output: # Write out the configuration files, with a special case for SPL

I have one of these boards loaded with Ubuntu 24.10 (64-bit). Add an entry for it so that it can be used for testing.
Signed-off-by: Simon Glass sjg@chromium.org ---
.gitlab-ci.yml | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index f379c11a1ba..33ec4b2e417 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -691,3 +691,8 @@ nyan-big: variables: ROLE: nyan-big <<: *lab_dfn + +vision5: + variables: + ROLE: vision5 + <<: *lab_dfn

On 12/14/24 10:20, Simon Glass wrote:
I have one of these boards loaded with Ubuntu 24.10 (64-bit). Add an entry for it so that it can be used for testing.
Signed-off-by: Simon Glass sjg@chromium.org
.gitlab-ci.yml | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index f379c11a1ba..33ec4b2e417 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -691,3 +691,8 @@ nyan-big: variables: ROLE: nyan-big <<: *lab_dfn
+vision5:
- variables:
- ROLE: vision5
- <<: *lab_dfn
It is "visionfive2" not "vision5". There exists a JH7100 CPU based board the StarFive VisionFive, so this is not appropriate to name the StarFive VisionFive2 (JH7110 CPU based) as "vision5".
-E

Am 14. Dezember 2024 19:20:24 MEZ schrieb Simon Glass sjg@chromium.org:
I have one of these boards loaded with Ubuntu 24.10 (64-bit). Add an entry for it so that it can be used for testing.
Signed-off-by: Simon Glass sjg@chromium.org
.gitlab-ci.yml | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index f379c11a1ba..33ec4b2e417 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -691,3 +691,8 @@ nyan-big: variables: ROLE: nyan-big <<: *lab_dfn
+vision5:
vf2: would better allude to what it is. But it is your lab.
- variables:
- ROLE: vision5
- <<: *lab_dfn
Could you, please, add a comment line describing the entry.
Best regards
Heinrich

Hi Heinrich,
On Sat, 14 Dec 2024 at 14:15, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
Am 14. Dezember 2024 19:20:24 MEZ schrieb Simon Glass sjg@chromium.org:
I have one of these boards loaded with Ubuntu 24.10 (64-bit). Add an entry for it so that it can be used for testing.
Signed-off-by: Simon Glass sjg@chromium.org
.gitlab-ci.yml | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml index f379c11a1ba..33ec4b2e417 100644 --- a/.gitlab-ci.yml +++ b/.gitlab-ci.yml @@ -691,3 +691,8 @@ nyan-big: variables: ROLE: nyan-big <<: *lab_dfn
+vision5:
vf2: would better allude to what it is. But it is your lab.
OK
- variables:
- ROLE: vision5
- <<: *lab_dfn
Could you, please, add a comment line describing the entry.
Yes I can do that. I am also wondering if we could show some board details when gitlab uses the board, obtained from Labgrid.
Regards, Simon

On Sat, 14 Dec 2024 11:20:19 -0700, Simon Glass wrote:
This board fought valiantly against attempts to add it to my lab. After several hours of debugging, I found problems in the Labgrid integration (not included here), test.py and buildman
This series fixes these and the board now seems to be reliable enough.
Note that the board fails test_dm_compat
[...]
Applied to u-boot/master, thanks!
participants (4)
-
E Shattow
-
Heinrich Schuchardt
-
Simon Glass
-
Tom Rini