aboutsummaryrefslogtreecommitdiffstats
path: root/.gitlab-ci/create-rootfs.sh
Commit message (Collapse)AuthorAgeFilesLines
* ci: Enable testing GLES2-3 on a530 (Dragonboard 820c).Eric Anholt2020-03-171-2/+6
| | | | | | | | | Following on from the db410c conversion to baremetal testing, reuse the same scripts in the same rack to run 7 db820c boards (#4/8 is failing in the bootloader for unknown reasons). Reviewed-by: Kristian H. Kristensen <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4177>
* ci: Make a simple little bare-metal fastboot mode for db410c.Eric Anholt2020-03-111-0/+1
| | | | | | | | | | | | | | | | | This supports powering up the device (using an external tool you provide based on your particular lab), talking over serial to wait for the fastboot prompt, and then booting a fastboot image on a target device. I was previously relying on LAVA for this, but that ran afoul of corporate policies related to the AGPL. However, LAVA wasn't doing too much for us, given that gitlab already has a job scheduler and tagging and runners. We were spending a lot of engineering on making the two systems match up, when we can just have gitlab do it directly. Lightly-reviewed-by: Kristian H. Kristensen <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4076> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4076>
* ci: Fix installation of firmware for db410c's nic.Eric Anholt2020-03-111-1/+3
| | | | | | | | The debian firmware package doesn't actually contain it, costing us a minute of boot time waiting for it to show up. Lightly-reviewed-by: Kristian H. Kristensen <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4076>
* ci: Include db410c support in the ARM container.Eric Anholt2020-02-271-3/+8
| | | | | | | | | | | | | | | | | | | | | | I'm working on moving the db410c CI from docker to LAVA, which means we get to boot a custom kernel. To do that, we need to enable ARCH_QCOM in the kernel, save the dtb around, and include abootimg in our container so that we can generate combined kernel/dtb/ramdisk images for fastboot. LAVA's fastboot support is unable to pack the overlay into an abootimg image, just a cpio rootfs. We could flash the cpio rootfs after overlay addition, but that takes 2 minutes to do, and causes wear on the devices. Instead, we'll bring up the network at boot and use wget to fetch the overlay. We'll want network support anyway, so that we can transfer the failure xmls back to the gitlab job's artifacts at some point. Since the msm GPU and realtek network firmware increase our payload by 3MB, add in firmware compression so that it doesn't waste as much RAM on devices not using it. Reviewed-by: Tomeu Vizoso <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3928> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3928>
* ci: Remove LLVM from ARM test drivers.Eric Anholt2020-02-271-8/+0
| | | | | | | | | | | | | The LLVM libraries were a significant fraction of the entire payload (55M/250M uncompressed) into the initramfs of the test boards, but LLVM is only used for the draw module used in select/feedback (which isn't even tested in CI on ARM yet). Assume that llvmpipe draw is safe enough for ARM given the coverage on x86, and disable LLVM for these jobs. Reviewed-by: Tomeu Vizoso <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3928>
* ci: Make sure that we have a proper shell prompt for LAVA.Eric Anholt2020-02-211-1/+7
| | | | | | | | | | | | | LAVA finds a '#' early in boot and races to emit its shell commands. Apparently for the current boards those serial commands end up getting buffered such that things work out, but for db410c and db820c, the buffer is lost and LAVA gets stuck waiting for the prompt. By setting a prompt, we can delay our commands until we're actually supposed to emit them (and suppress a complaint from the lava dispatcher that we're using a risky prompt!) Reviewed-by: Tomeu Vizoso <[email protected]> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3883>
* gitlab-ci: Consolidate container and build stages for LAVATomeu Vizoso2020-01-141-7/+17
| | | | | | | | | | | | | | | | Use the normal build job to also prepare the artifacts for LAVA jobs. For that, the build container needs to also build the test suites, kernel, ramdisk, etc. Then the build job will place the just-built Mesa in the ramdisk and the test job can generate a LAVA job and point to those artifacts. Signed-off-by: Tomeu Vizoso <[email protected]> Acked-by: Alyssa Rosenzweig <[email protected]> Reviewed-by: Daniel Stone <[email protected]> Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3295>
* gitlab-ci: Move LAVA-related files into top-level ci dirTomeu Vizoso2019-10-061-0/+185
In preparation for testing drivers other than Panfrost in LAVA labs. Signed-off-by: Tomeu Vizoso <[email protected]> Reviewed-by: Eric Anholt <[email protected]>