[PATCH 11/11] Nokia RX-51: Add automated test for running RX-51 build in qemu

[Tom Rini]

On Tue, Apr 21, 2020 at 11:34:02PM +0200, Pali Rohár wrote:
> On Tuesday 21 April 2020 16:51:23 Tom Rini wrote:
> > On Tue, Apr 21, 2020 at 02:49:05PM -0600, Simon Glass wrote:
> > > Hi Tom,
> > > 
> > > On Tue, 21 Apr 2020 at 14:46, Tom Rini <trini at konsulko.com> wrote:
> > > >
> > > > On Tue, Apr 21, 2020 at 02:37:45PM -0600, Simon Glass wrote:
> > > > > Hi,
> > > > >
> > > > > On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini at konsulko.com> wrote:
> > > > > >
> > > > > > On Tue, Apr 21, 2020 at 11:36:37AM -0600, Simon Glass wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Tue, 21 Apr 2020 at 08:56, Lokesh Vutla <lokeshvutla at ti.com> wrote:
> > > > > > > >
> > > > > > > > Tom,
> > > > > > > >
> > > > > > > > On 14/04/20 4:10 PM, Pali Rohár wrote:
> > > > > > > > > On Wednesday 01 April 2020 00:35:18 Pali Rohár wrote:
> > > > > > > > >> This patch contains a script which automatically download and compile all
> > > > > > > > >> needed tools to build a simple MTD images for booting Maemo kernel image by
> > > > > > > > >> U-Boot from RAM, eMMC and OneNAND. MTD images are then run in virtual n900
> > > > > > > > >> machine provided by qemu-linaro project.
> > > > > > > > >>
> > > > > > > > >> It can be used to check that U-Boot for Nokia N900 is not broken and can be
> > > > > > > > >> successfully booted in emulator.
> > > > > > > > >>
> > > > > > > > >> Script is registered in to .travis.yml so it would be automatically run on
> > > > > > > > >> Travi CI service.
> > > > > > > > >>
> > > > > > > > >> Signed-off-by: Pali Rohár <pali at kernel.org>
> > > > > > > > >
> > > > > > > > > Tom Rini, in past you have asked me for N900 Travis test. So could you
> > > > > > > > > please review this patch (including fixup at the bottom)?
> > > > > > > >
> > > > > > > > Can you ack this patch?
> > > > > > >
> > > > > > > Please use a pytest for this (test/py). We don't use shell scripts anymore.
> > > > > >
> > > > > > Well, this is where it's tricky and I've been debating with myself on
> > > > > > how to move forward here.
> > > > > >
> > > > > > Part of the problem here is that much like a Pi, we could emulate this
> > > > > > board in QEMU but would need not-upstream-QEMU to do it.  But unlike Pi,
> > > > > > there's not a lot of these devices around to test with.  It's not a big
> > > > > > deal that Pi isn't tested by CI via QEMU, my lab as a Pi, Simon's lab
> > > > > > has a Pi and other labs could add one fairly easy.  But adding an N900
> > > > > > to a lab is hard.
> > > > > >
> > > > > > Looking over the script to do it, there's a lot of other stuff required
> > > > > > too, for it all to work.  Looking over the script again, there's enough
> > > > > > stuff going on that I wouldn't want it done in a persistent
> > > > > > image/container.
> > > > > >
> > > > > > The only changes I would ask for I guess are that it should be put in
> > > > > > .travis.yml in the same areas other non-pytest tests, and put in similar
> > > > > > stanzas in .azure-ci.yml and .gitlab-ci.yml.
> > > > >
> > > > > For the existing stuff we use some sort of qemu that is built into the
> > > > > image, so far as I understand it. Is that right?
> > > >
> > > > Right for GitLab/Azure, for Travis we checkout/build/install.
> > > >
> > > > > Could we do something similar here? I actually don't like that though,
> > > > > since there is so much setup needed to run things locally (without
> > > > > docker).
> > > >
> > > > That's what the script does.  The problem is that we need a specific
> > > > (seemingly dead-end, but I'd like to be told I'm wrong!) old commit.  So
> > > > we can't replace the QEMU we use for everyone with one that also
> > > > supports N900.
> > > 
> > > OK I see.
> > > 
> > > >
> > > > > Also, what is to stop me running this script on my machine?
> > > >
> > > > Nothing.  And it does a good job of keeping all of the specific versions
> > > > of stuff it needs local to itself.
> > > 
> > > OK, so you don't think we should add this as a pytest?
> > 
> > No, I don't think wrapping this as a pytest would be valuable.  Re-doing
> > the FS tests is a step towards being able to run them on at least
> > emulated HW too.
> 
> Ok, so is something needed to do with this patch?

Yes, re-order where the .travis.yml hunk is and add a similar part to
.gitlab-ci.yml and .azure-ci.yml.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200421/7e7c4b43/attachment.sig>