Lines Matching +full:linux +full:- +full:kernel
1 Upreving Linux Kernel
4 Occasionally, the GitLab CI needs a Linux Kernel update to enable new kernel
6 Kernel uprevs in GitLab CI are relatively simple, but prone to lots of
7 side-effects since many devices from different platforms are involved in the
10 Kernel repository
11 -----------------
13 The Linux Kernel used in the GitLab CI is stored at the following repository:
14 https://gitlab.freedesktop.org/gfx-ci/linux
16 It is common that Mesa kernel brings some patches that were not merged on the
17 Linux mainline, that is why Mesa has its own kernel version which should be used
20 So, one should base the kernel uprev from the last tag used in the Mesa CI,
21 please refer to ``.gitlab-ci/image-tags.yml`` ``KERNEL_TAG`` variable.
22 Every tag has a standard naming: ``vX.YZ-for-mesa-ci-<commit_short_SHA>``, which
25 :code:`git tag vX.YZ-for-mesa-ci-$(git rev-parse --short HEAD)`
27 Building Kernel
28 ---------------
30 The kernel files are loaded from the artifacts uploaded to S3 from gfx-ci/linux.
35 When a Kernel uprev happens, it is worth compiling and cross-compiling the
36 Kernel locally, in order to update the Kconfigs accordingly. Remember that the
37 resulting Kconfig is a merge between *Mesa CI Kconfig* and *Linux tree
38 defconfig* made via ``merge_config.sh`` script located at Linux Kernel tree.
43 +------------+------------------------------------------------------+------------------------------…
44 | Platform | Mesa CI Kconfig location | Linux tree defconfig …
46 | arm | kernel/configs/mesa3d-ci_arm.config\@gfx-ci/linux | arch/arm/configs/multi_v7_def…
47 +------------+------------------------------------------------------+------------------------------…
48 | arm64 | kernel/configs/mesa3d-ci_arm64.config\@gfx-ci/linux | arch/arm64/configs/defconfig …
49 +------------+------------------------------------------------------+------------------------------…
50 | x86-64 | kernel/configs/mesa3d-ci_x86_64.config\@gfx-ci/linux | arch/x86/configs/x86_64_defco…
51 +------------+------------------------------------------------------+------------------------------…
54 -------------------
56 Every kernel uprev should update 3 image tags, located at two files.
58 :code:`.gitlab-ci/container/gitlab-ci.yml` tag
60 - **KERNEL_URL** for the location of the new kernel
62 :code:`.gitlab-ci/image-tags.yml` tags
64 - **KERNEL_ROOTFS_TAG** to rebuild rootfs with the new kernel
65 - **DEBIAN_X86_TEST_GL_TAG** to ensure that the new rootfs is being used by the GitLab x86 jobs
68 -------------------
70 1. Compile the newer kernel locally for each platform.
73 4. Push a new development branch to `Kernel repository`_ based on the latest kernel tag used in Git…
74 5. Hack ``build-kernel.sh`` script to clone kernel from your development branch
78 When the Kernel uprev is stable
81 1. Push a new tag to Mesa CI `Kernel repository`_
82 2. Update KERNEL_URL ``debian/x86_test-gl`` job definition
86 ---------------
91 To have the most confidence that a kernel uprev does not break anything in Mesa,
94 Step-by-step
97 …branch in the same git ref (should be the main branch) before branching to the kernel uprev kernel.
100 4. Now do the same for the kernel uprev branch
101 5. Compare the job results. If a CI job turned red on your uprev branch, it means that the kernel u…
103 Bare-metal custom kernels
106 Some CI jobs have support to plug in a custom kernel by simply changing a variable.
107 This is great, since rebuilding the kernel and rootfs may takes dozens of minutes.
110 ``BM_KERNEL``. If one puts a gz-compressed kernel URL there, the job will use that
111 kernel to boot the Freedreno bare-metal devices. The same works for ``BM_DTB`` in
117 Sometimes a job may turn to red for reasons unrelated to the kernel update, e.g.