mirror of
https://gitlab.com/buildroot.org/buildroot.git
synced 2026-09-10 16:24:17 -09:00
master
11 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Peter Korsgaard
|
8ffa090560 |
support/testing: test_weston.py: use assertRunNotOk()
Use the helper to simplify the test. Signed-off-by: Peter Korsgaard <peter@korsgaard.com> |
||
|
Romain Naour
|
13a0129b0a |
support/testing: use larger runner to reduce the CI minute consumed per pipeline
Based on the first pipeline result [1], use larger runner for the following tests: tests.fs.test_oci.TestOci.test_run (01:08:15) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_dpdk.TestDPDK.test_run (01:08:36) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_z3.TestZ3.test_run (01:11:41) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_octave.TestOctave.test_run (01:21:57) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanSlirpNftables.test_run (01:21:15) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanSlirpIptables.test_run (01:21:25) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_mariadb.TestMariaDB.test_run (01:26:15) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanIptables.test_run (01:28:51) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanTini.test_run (01:29:08) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_podman.TestPodmanNftables.test_run (01:41:26) saas-linux-small-amd64 -> saas-linux-xlarge-amd64 tests.package.test_weston.TestWeston.test_run (01:26:17) saas-linux-large-amd64 -> saas-linux-2xlarge-amd64 tests.package.test_python_pyqt5.TestPythonPyQt5.test_run (01:41:33) saas-linux-large-amd64 -> saas-linux-2xlarge-amd64 tests.package.test_nodejs.TestNodeJSModuleHostBin.test_run (01:21:06) saas-linux-large-amd64 -> saas-linux-2xlarge-amd64 tests.package.test_flutter.TestFlutter.test_run (01:03:05) saas-linux-xlarge-amd64 -> saas-linux-2xlarge-amd64 For tests long that already use 2xlarge runner tag, we may have to run them on Gitlab runners owned by the Buildroot project. [1] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2562421098 Signed-off-by: Romain Naour <romain.naour@smile.fr> Signed-off-by: Arnout Vandecappelle <arnout@rnout.be> |
||
|
Romain Naour
|
c9df1b64b2 |
support/testing: generate runtime test jobs with runner tags
We have our own GitLab-CI runner, but with only one we can't run many
jobs in parallel so it takes a very long time before all the tests have
completed. In addition, if that runner goes down, we have nothing at
all.
GitLab offers the following machine types for hosted runners on Linux
x86-64 [1]. The default is the "small" runner. Using a larger runner
increases the "Cost factor" [2].
For opensource projects, the Cost factor is reduced to 0.5 (1 minute per
2 minutes of job time) whatever the runner type.
Runner Tag vCPUs Memory Storage Cost factor (OSS)
saas-linux-small-amd64 (default) 2 8 GB 30 GB 1 (0.5)
saas-linux-medium-amd64 4 16 GB 50 GB 2 (0.5)
saas-linux-large-amd64 (Premium and Ultimate only) 8 32 GB 100 GB 3 (0.5)
saas-linux-xlarge-amd64 (Premium and Ultimate only) 16 64 GB 200 GB 6 (0.5)
saas-linux-2xlarge-amd64 (Premium and Ultimate only) 32 128 GB 200 GB 12 (0.5)
Compute minutes consumed by a job is calculated by:
Job duration / 60 * Cost factor
(Job duration: The time, in seconds, that a job took to run, not
including time spent in the created or pending statuses.)
Thanks to the GitLab OSS program [3], Buildroot benefits from a free
Ultimate subscription and can use GitLab shared runners tagged with
saas-linux-{large, xlarge, 2xlarge}-amd64. In addition, we receive
50,000 free runner minutes per month.
In order to use one of those tags in Buildroot GitLab-CI jobs, we have
to classify all tests by resource requirement, to make sure the job
doesn't fail because it times out or has insufficient memory or disk
space. While we usually shouldn't use the largest runner for
everything, we can use larger runner without cost penalty thanks to
the cost factor reduced to 0.5 for opensource projects. This will
reduce the CI minutes consumed by a CPU intensive job.
First we introduce some new templates used to add the corresponding
runner tag to a runtime test job (reusing the GitLab terminology).
.runner-{small,medium,large,xlarge,2xlarge}
Most of our tests are fast (checkpackage, test_external_bootlin...), so
saas-linux-small-amd64 runner tag is enough. Default to this tag if
nothing else is specified.
Add a comment next to the test class to provide the runner tag.
This runner tag is retrieved when generating the
generated-gitlab-ci.yml file used to create the child pipeline where
the runtime test jobs are executed.
We use the list of runtime tests returned by node2:
"tests.boot.test_edk2.TestEdk2.test_run"
We convert each element of this list to get the path to the test source
file and the name of the test:
"support/testing/tests/boot/test_edk2.py"
TestEdk2
With that, we can grep into the test source file to retrieve the runner
tag placed one line above the test class:
# GitLab-runner: large
class TestEdk2(infra.basetest.BRTest):
Once the runner tag is retrieved, it's used to use the corresponding
runner template to the runtime test job:
tests.boot.test_edk2.TestEdk2.test_run: { extends: [ .runtime_test_base, .runner-large ]}
GitLab runners hosted by the Buildroot project should be able to run
any jobs, so they should be tagged with Gitlab runner tags
(saas-linux-{small,medium,large,xlarge,2xlarge}-amd64).
A specific runner tag "buildroot-runner" can be used to allow running
a job only on such runners.
If a test can't be executed by any shared GitLab-CI runners, we have
to use a runner owned by the Buildroot project. In this case we have
to use a specific template ".runner-buildroot-runner-only" in order to
add the specific runner tag "buildroot-runner" to the job running the
test. There is no such runtime test at the moment.
The proposed classification is based on a previous pipeline analysis
[5]:
- Tests lasting more than 3 hours will use 2xlarge runners.
- Tests lasting more than 2 hours will use xlarge runners.
- Tests lasting more than 1 hours will use large runners.
- Tests building a kernel or a toolchain will use medium runners.
- All other tests will use small runners when possible.
CI minute cost estimate:
tests.package.test_clang.TestClangCompilerRT.test_run lasts 4h25 on the
Buildroot runner. If we this duration for 2xlarge runners, the CI
minute consumed would be:
(15900 / 60) * 0.5 = 133
With 6 jobs using a 2xlarge runners we used ~795 CI minutes.
tests.package.test_kmscube.TestKmsCube.test_run list 2h04 on the
Buildroot runner. If we this duration for xlarge runners, the CI
minute consumed would be:
(7440 / 60) * 0.5 = 62
With 4 jobs using a xlarge runners we used ~248 CI minutes.
tests.package.test_weston.TestWeston.test_run last 1h15 on th
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(4500 / 60) * 0.5 = 37.5
With 28 jobs using a large runners we used ~1050 CI minutes.
tests.package.test_gstreamer1.TestGstreamer1.test_run last 46min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(2760 / 60) * 0.5 = 23
With 31 jobs using a medium runners we used ~713 CI minutes.
tests.package.test_python.TestPython3Py.test_run last 13min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(780 / 60) * 0.5 = 6.5
With 691 jobs using a medium runners we used ~4491 CI minutes.
In total, one pipeline for the runtime tests cost ~7297 CI minutes.
After a first try [6], we are actually using 8000 CI minutes per
pipeline.
We run such pipeline once a week (on Monday), one for each Buildroot
releases every 3 month, one for each stable and LTS release per month,
and one for each release candidate (3).
Worst case (release month):
(4 weeks + 1 release + 1 stable + 1 LTS + 3 release candidate) * 8000 CI
minutes: 80000 CI minutes / 50000.
So we would spend the minutes very quickly in the worst case scenario.
We have to keep one pipeline under 5000 CI minutes.
[1] https://docs.gitlab.com/ci/runners/hosted_runners/linux/#machine-types-available-for-linux---x86-64
[2] https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors
https://docs.gitlab.com/ci/pipelines/compute_minutes/#compute-usage-calculation
https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
[3] https://gitlab.com/buildroot.org/gitlab-oss
[4] https://docs.gitlab.com/ci/runners/hosted_runners/#gitlabcom-hosted-runner-workflow
[5] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2416603721
[6] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2562421098
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Arnout:
- simplify parsing of test_file and test_name;
- match the entire test_name instead of substring;
- assume "small" by default;
- remove the "small" tags;
- use "gitlab-runner" instead of "Gitlab-runner".
]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
|
||
|
Romain Naour
|
3713c3e82c |
Revert "support/testing: generate runtime test jobs with runner tags"
The CI minute cost estimate is wrong for two reasons:
1) Job duration was in minutes instead of seconds
2) The cost factor is really 0,5 [1] instead of
based on runner type * 0,5.
Due to this two mistake, the real CI minute cost is 7982.1 [2] instead
of 350.
Since we want to backport this patch, having a correct CI minute cost
estimate in the commit log would be better. Lets revert last changes
about runner tag and try again.
[1] https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
[2] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2562421098
This reverts commit
|
||
|
Romain Naour
|
38039415f8 |
support/testing: generate runtime test jobs with runner tags
We have our own GitLab-CI runner, but with only one we can't run many
jobs in parallel so it takes a very long time before all the tests have
completed. In addition, if that runner goes down, we have nothing at
all.
GitLab offers the following machine types for hosted runners on Linux
x86-64 [1]. The default is the "small" runner. Using a larger runner
increases the "Cost factor" [2]:
Runner Tag vCPUs Memory Storage Cost factor
saas-linux-small-amd64 (default) 2 8 GB 30 GB 1
saas-linux-medium-amd64 4 16 GB 50 GB 2
saas-linux-large-amd64 (Premium and Ultimate only) 8 32 GB 100 GB 3
saas-linux-xlarge-amd64 (Premium and Ultimate only) 16 64 GB 200 GB 6
saas-linux-2xlarge-amd64 (Premium and Ultimate only) 32 128 GB 200 GB 12
Compute minutes consumed by a job is calculated by:
Job duration / 60 * Cost factor
(Job duration: The time, in seconds, that a job took to run, not
including time spent in the created or pending statuses.)
Thanks to the GitLab OSS program [3], Buildroot benefits from a free
Ultimate subscription and can use GitLab shared runners tagged with
saas-linux-{large, xlarge, 2xlarge}-amd64. In addition, we receive
50,000 free runner minutes per month.
For opensource projects, the Cost factor is reduced by 0,5 (1 minute per
2 minutes of job time).
In order to use one of those tags in Buildroot GitLab-CI jobs, we have
to classify all tests by resource requirement, to make sure the job
doesn't fail because it times out or has insufficient memory or disk
space. We also don't want to use the largest runner for everything
because that would spend the minutes very quickly while the resources
aren't used efficiently (mostly serialized).
First we introduce some new templates used to add the corresponding
runner tag to a runtime test job (reusing the GitLab terminology).
.runner-{small,medium,large,xlarge,2xlarge}
Most of our tests are fast (checkpackage, test_external_bootlin...), so
saas-linux-small-amd64 runner tag is enough. Default to this tag if
nothing else is specified.
Add a comment next to the test class to provide the runner tag.
This runner tag is retrieved when generating the
generated-gitlab-ci.yml file used to create the child pipeline where
the runtime test jobs are executed.
We use the list of runtime tests returned by node2:
"tests.boot.test_edk2.TestEdk2.test_run"
We convert each element of this list to get the path to the test source
file and the name of the test:
"support/testing/tests/boot/test_edk2.py"
TestEdk2
With that, we can grep into the test source file to retrieve the runner
tag placed one line above the test class:
# GitLab-runner: large
class TestEdk2(infra.basetest.BRTest):
Once the runner tag is retrieved, it's used to use the corresponding
runner template to the runtime test job:
tests.boot.test_edk2.TestEdk2.test_run: { extends: [ .runtime_test_base, .runner-large ]}
GitLab runners hosted by the Buildroot project should be able to run any
jobs, so a specific runner tag "buildroot-runner" is used to allow
running a job on such runners. The "buildroot-runner" tag is used in
addition to GitLab ones to run a job on the Buildroot runner or on a
shared GitLab-CI runner.
If a test can't be executed by any shared GitLab-CI runners, we have
to use a runner owned by the Buildroot project. In this case we have
to use a specific template ".runner-buildroot-runner-only". There is no
such runtime test at the moment.
The proposed classification is based on a previous pipeline analysis
[5]:
- Tests lasting more than 3 hours will use 2xlarge runners.
- Tests lasting more than 2 hours will use xlarge runners.
- Tests lasting more than 1 hours will use large runners.
- Tests building a kernel or a toolchain will use medium runners.
- All other tests will use small runners when possible.
CI minute cost estimate:
tests.package.test_clang.TestClangCompilerRT.test_run lasts 4h25 on the
Buildroot runner. If we this duration for 2xlarge runners, the CI
minute consumed would be:
(265 / 60) * 12 * 0.5 = 26,5
With 6 jobs using a 2xlarge runners we used ~160 CI minutes.
tests.package.test_kmscube.TestKmsCube.test_run list 2h04 on the
Buildroot runner. If we this duration for xlarge runners, the CI
minute consumed would be:
(124 / 60) * 6 * 0.5 = 6,2
With 4 jobs using a xlarge runners we used ~37 CI minutes.
tests.package.test_weston.TestWeston.test_run last 1h15 on th
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(75 / 60) * 3 * 0.5 = 1.87
With 28 jobs using a large runners we used ~53 CI minutes.
tests.package.test_gstreamer1.TestGstreamer1.test_run last 46min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(46 / 60) * 2 * 0.5 = 0.76
With 31 jobs using a medium runners we used ~24 CI minutes.
tests.package.test_python.TestPython3Py.test_run last 13min on the
Buildroot runner. If we this duration for large runners, the CI
minute consumed would be:
(13 / 60) * 1 * 0.5 = 0.1
With 691 jobs using a medium runners we used ~69 CI minutes.
In total, one pipeline for the runtime tests cost ~350 CI minutes.
We run such pipeline once a week (on Monday), one for each Buildroot
releases every 3 month, one for each stable and LTS release per month,
and one for each release candidate (3).
Worst case (realse month):
(4 weeks + 1 release + 1 stable + 1 LTS + 3 release candidate) * 350 CI
minutes: 3500 CI minutes / 50000.
So we should be able to run our pipeline without exhausting our CI
minutes credit.
[1] https://docs.gitlab.com/ci/runners/hosted_runners/linux/#machine-types-available-for-linux---x86-64
[2] https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors
https://docs.gitlab.com/ci/pipelines/compute_minutes/#compute-usage-calculation
https://docs.gitlab.com/ci/pipelines/compute_minutes/#cost-factors-of-hosted-runners-for-gitlabcom
[3] https://gitlab.com/buildroot.org/gitlab-oss
[4] https://docs.gitlab.com/ci/runners/hosted_runners/#gitlabcom-hosted-runner-workflow
[5] https://gitlab.com/buildroot.org/buildroot/-/pipelines/2416603721
Signed-off-by: Romain Naour <romain.naour@smile.fr>
[Arnout:
- simplify parsing of test_file and test_name;
- match the entire test_name instead of substring;
- assume "small" by default;
- remove the "small" tags;
- use "gitlab-runner" instead of "Gitlab-runner".
]
Signed-off-by: Arnout Vandecappelle <arnout@rnout.be>
|
||
|
Bernd Kuhls
|
317260f336 |
package/{mesa3d, mesa3d-headers}: bump version to 25.0.6
Release notes: https://lists.freedesktop.org/archives/mesa-announce/2024-May/000762.html https://lists.freedesktop.org/archives/mesa-announce/2024-June/000763.html https://lists.freedesktop.org/archives/mesa-announce/2024-June/000765.html https://lists.freedesktop.org/archives/mesa-announce/2024-July/000766.html https://lists.freedesktop.org/archives/mesa-announce/2024-July/000767.html https://lists.freedesktop.org/archives/mesa-announce/2024-July/000771.html https://lists.freedesktop.org/archives/mesa-announce/2024-August/000773.html https://lists.freedesktop.org/archives/mesa-announce/2024-August/000776.html https://lists.freedesktop.org/archives/mesa-announce/2024-September/000778.html https://lists.freedesktop.org/archives/mesa-announce/2024-September/000779.html https://lists.freedesktop.org/archives/mesa-announce/2024-October/000780.html https://lists.freedesktop.org/archives/mesa-announce/2024-October/000781.html https://lists.freedesktop.org/archives/mesa-announce/2024-October/000782.html https://lists.freedesktop.org/archives/mesa-announce/2024-November/000784.html https://lists.freedesktop.org/archives/mesa-announce/2024-November/000786.html https://lists.freedesktop.org/archives/mesa-announce/2024-December/000788.html https://docs.mesa3d.org/relnotes/24.3.2.html https://docs.mesa3d.org/relnotes/24.3.3.html https://docs.mesa3d.org/relnotes/24.3.4.html https://lists.freedesktop.org/archives/mesa-announce/2025-February/000793.html https://lists.freedesktop.org/archives/mesa-announce/2025-March/000794.html https://lists.freedesktop.org/archives/mesa-announce/2025-March/000795.html https://lists.freedesktop.org/archives/mesa-announce/2025-April/000796.html https://lists.freedesktop.org/archives/mesa-announce/2025-April/000798.html https://lists.freedesktop.org/archives/mesa-announce/2025-April/000801.html https://lists.freedesktop.org/archives/mesa-announce/2025-May/000803.html ------------------------------------------------------------------------ Changes needed for the bump to 24.1.x: Added dependency to llvm & Co. for iris driver due to upstream commit: https://cgit.freedesktop.org/mesa/mesa/commit/meson.build?h=24.1&id=a512c2a8b572c5da360873320dbbd343c6223cd6 Added host version of mesa tool intel_clc needed for target build of the iris driver. Added dependency to host-python-pycparser for etnaviv driver due to upstream commit: https://cgit.freedesktop.org/mesa/mesa/commit/src/etnaviv/hwdb/meson.build?h=24.1&id=2192e620bb0c68b75ff45165d0b117c7ecb77268 Added dependency to host-python-ply for intel vulkan driver due to upstream commit: https://cgit.freedesktop.org/mesa/mesa/commit/src/intel/vulkan/grl/meson.build?h=24.1&id=dc1aedef2bd054884685ad971a3ef5be07ecd101 Although this dependency exists since mesa3d 22.3 it is only needed when intel-clc is enabled, this dependency is added with this patch so no need to backport this dependency to older buildroot trees. Update configure parameter of glvnd option due to upstream commit: https://cgit.freedesktop.org/mesa/mesa/commit/meson.build?h=24.1&id=4f25b84b2460524d375424a81b42faa4d99c8e60 ------------------------------------------------------------------------ Changes needed for the bump to 24.2.x: Added dependency to host-python-pyyaml to host and target build, needed due to upstream commit |
||
|
Julien Olivain
|
bedc44c073 |
support/testing: weston: fix the weston shutdown test
Commit [1] "support/testing: improve weston test reliability" moved
out the wait time from the emulator (to run on the test controller).
While doing so, the sleep time which was initially _after_ the
"killall weston" invocation to in stop_weston() was incorrectly
moved before the command invocation. In this state, the test can
succeed on fast host computer running the test. But it will most
likely fail on an average computer.
This commit fixes this issue by moving the sleep time after
the command invocation.
[1]
|
||
|
Julien Olivain
|
6561a5d773 |
support/testing: improve weston test reliability
The weston runtime test is unreliable, depending on the execution speed of its runner. Example of failure is [1], and success is [2]. This commit improves the test in several ways, to make it more robust to execution speed variations: - The command started in background (weston, weston-simple-egl) are now started in a subshell. This suppresses the job control messages when they are stopped. Those messages could interfere with the parsing of the output; - Wait time are moved outside the emulator; - The kernel argument vt.global_cursor_default=0 is added, to make sure cursors are globally disabled, since the test use vkms display CRCs; - The memory of the emulator is increased to 512M. This test uses cpio initramfs, and the filesystem size increased; - The vkms driver emulates a "vsync" event, but can generate a warning when the system is too slow. This warning is printed on the console by the klogd daemon in its default configuration. This commit adds the overlay file /etc/default/klogd to limit only kernel emergency messages to be printed on the console. This change fixes the failure seen in [1] ; - Some sleep time values were adjusted to run on a "performant" idle host. Those values are not suitable in all situations. In the meantime a generic retry mechanism is added in the test infra, this commit adds a retry logic inspired from the test_flutter runtime test. Fixes: [1] [1] https://gitlab.com/buildroot.org/buildroot/-/jobs/8562483474 [2] https://gitlab.com/buildroot.org/buildroot/-/jobs/8435236652 Signed-off-by: Julien Olivain <ju.o@free.fr> Signed-off-by: Peter Korsgaard <peter@korsgaard.com> |
||
|
Yann E. MORIN
|
69629bae7c |
support/testing/test/graphics_base: add helper to test graphics rendering
In
|
||
|
Yann E. MORIN
|
0e65515862 |
support/runtime-test: fix weston test
The weston runtime test uses the CRC of the framebuffer to detect that
"something" is being drawned on the framebuffer. This requires that the
sampling of the CRC happens does not happen too early after trigerring
an action, or the rendering may be not be finishe, either:
- weston may not have had time to initialise, or
- the test application may not have started rednering,
The sequence of rendering that has been observed yields this sequence of
CRCs (elided for brevity):
- boot:
- alternating between 0x4c4126bf and 0x5d2f9aa5: console cursor
blinking
- start weston:
- 0x4c4126bf: weston switches to a cleared vt, no blinking cursor
...
- 0xe54b7895: weston is starting
...
- 0xe54b7895: wayland socket appears!
...
- 0x6bf28bdf: weston is ready
...
- start weston-simple-egl:
- 0x6bf28bdf: application is starting
...
- 0xNNNNNNNN: random CRCs while the application renders
...
- stop weston-simple-egl:
- 0xNNNNNNNN: zero, one, or two random CRCs while the application
renders before it handles SIGTERM
- 0x6bf28bdf: application is stopped
...
- stop weston:
- 0x6bf28bdf: a few CRC identical to when weston was started, while
weston is processing SIGTERM
- oscillating between 0x4c4126bf and 0x5d2f9aa5: console cursor
blinking, back to initial vt, weston dead.
So, we need to wait "enough" after each action. Moreover, when the
wayland socket appears, weston may not have stabilised yet, so we also
need to wait after the socket appears.
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Julien Olivain <ju.o@free.fr>
|
||
|
Julien Olivain
|
4edb0e3456 |
support/testing/tests/package/test_weston.py: new runtime test
This test is a followup of the discussion at: https://lists.buildroot.org/pipermail/buildroot/2023-July/671639.html It provides an example of a runtime tests using standard Linux graphic components (Kernel, DRM, Mesa3D, weston). Signed-off-by: Julien Olivain <ju.o@free.fr> [yann.morin.1998@free.fr: - use an overlay rather than create config file at runtime - sleep in python not in target - increase delay to capture DRI CRCs ] Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> |