From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 20 Jan 2021 13:57:19 -0500 Subject: [PATCH 1/1] Dockerfile: compile QEMU for Nokia N900 emulation In-Reply-To: <20200713225608.GF6227@bill-the-cat> References: <20200713171046.230013-1-xypron.glpk@gmx.de> <20200713172034.GB6246@bill-the-cat> <00fbe2dd-c8a2-211d-3fd1-8d44de158d81@gmx.de> <20200713225608.GF6227@bill-the-cat> Message-ID: <20210120185719.GZ9782@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Mon, Jul 13, 2020 at 06:56:08PM -0400, Tom Rini wrote: > On Mon, Jul 13, 2020 at 11:27:40PM +0200, Heinrich Schuchardt wrote: > > On 13.07.20 19:20, Tom Rini wrote: > > > On Mon, Jul 13, 2020 at 07:10:46PM +0200, Heinrich Schuchardt wrote: > > > > > >> For the Nokia N900 emulation we need a special QEMU version. Up to now we > > >> compile it in the Gitlab runner. By compiling it in Docker we can reduce > > >> the Gitlab job duration. > > >> > > >> To avoid naming conflicts the QEMU binary is stored as > > >> /opt/qemu/bin/qemu-system-n900. > > >> > > >> Signed-off-by: Heinrich Schuchardt > > >> --- > > >> Dockerfile | 10 ++++++++++ > > >> 1 file changed, 10 insertions(+) > > >> > > >> diff --git a/Dockerfile b/Dockerfile > > >> index 209e008..bc3cdee 100644 > > >> --- a/Dockerfile > > >> +++ b/Dockerfile > > >> @@ -171,6 +171,16 @@ RUN git clone git://git.qemu.org/qemu.git /tmp/qemu && \ > > >> make -j$(nproc) all install && \ > > >> rm -rf /tmp/qemu > > >> > > >> +# Compile QEMU for Nokia N900 emulation > > >> +# Last working commit is 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1 > > >> +RUN git clone https://git.linaro.org/qemu/qemu-linaro.git /tmp/qemu && \ > > >> + cd /tmp/qemu && \ > > >> + git checkout 8f8d8e0796efe1a6f34cdd83fb798f3c41217ec1 && \ > > >> + ./configure --enable-system --target-list=arm-softmmu --disable-sdl --disable-gtk --disable-curses --audio-drv-list= --audio-card-list= --disable-werror --disable-xen --disable-xen-pci-passthrough --disable-brlapi --disable-vnc --disable-curl --disable-slirp --disable-kvm --disable-user --disable-linux-user --disable-bsd-user --disable-guest-base --disable-uuid --disable-vde --disable-linux-aio --disable-cap-ng --disable-attr --disable-blobs --disable-docs --disable-spice --disable-libiscsi --disable-smartcard-nss --disable-usb-redir --disable-guest-agent --disable-seccomp --disable-glusterfs --disable-nptl --disable-fdt && \ > > >> + make -j$(nproc) && \ > > >> + cp arm-softmmu/qemu-system-arm /opt/qemu/bin/qemu-system-n900 && \ > > >> + rm -rf /tmp/qemu > > >> + > > >> # Create our user/group > > >> RUN echo uboot ALL=NOPASSWD: ALL > /etc/sudoers.d/uboot > > >> RUN useradd -m -U uboot > > > > > > Azure and GitLab will pick this up, if we modify the job to link the > > > binary in. Travis will not, of course. But this feels like a bit of a > > > micro-optimization. The test job is 3-4 minutes currently. If we want > > > > Yes, time I am waiting for the tests that interest me. And sometimes it > > fails because the source repository is not available. > > Right. But I assume you're doing unit testing locally and not via CI. > I would be quite open to moving this test to the rest of the QEMU based > group, in GitLab as that might result in the overall run completing > quicker. > > > > to reduce that, I think switching the test script to use $(nproc) rather > > > than 4 for all make jobs would be a bit better. Keeping all 3 CI > > > > This depends on the number of cores you have on Travis CI. Is this more > > than one? > > I think so, yes. > > > > scripts as close as possible is a goal we have to have I believe to > > > reduce the likelyhood of one CI failing when another passes and it being > > > the CI at fault rather than exposing a race condition in our code. > > > > > > > https://docs.travis-ci.com/user/docker/a > > says that you can use Docker images in Travis CI too. > > > > https://docs.travis-ci.com/user/build-stages/share-docker-image/ > > shows how to trigger tests inside a Docker image. > > > > I think the Docker route is the only way to minimize differences between > > the build systems. > > I was under the impression that it would result in a fetch of the Docker > image every time and thus probably take much longer overall and possibly > require further splitting up of the Travis job. > > Honestly and off-topic for this particular thread, at this point I'd > almost rather just drop Travis support and as much as I like the control > we have in GitLab the fact that every runner has occasional bouts of > random bad luck (DNS failures or jobs get stuck) means I wouldn't get > overly upset if we just used Azure as it's still quicker than Travis, > only a little slower than GitLab when it's fast and can be triggered by > anyone. It would however require custodians to setup yet another > account somewhere and that is a fairly big drawback (as I do expect > custodians to CI their tree before sending a PR and in turn that > blocking on the general Azure queue would be a big bottleneck I fear). So, I'm bringing this old patch up. Now that we have dropped Travis, GitLab and Azure use the same environment. Re-introducing this patch and a follow-up to modify the test script to use this prebuilt QEMU would be something we could do, at this point. Thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: