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

["Pali Rohár" <pali@kernel.org>]

On Tuesday 21 April 2020 14:37:45 Simon Glass wrote:
> Hi,
> 
> On Tue, 21 Apr 2020 at 14:12, Tom Rini <trini@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@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@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?
> 
> 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 script run u-boot in n900 qemu machine and test that u-boot can
correctly boot Maemo kernel (from RAM, eMMC and OneNAND) with simple
rootfs. So it is full u-boot test for n900. And basically simulates
whole bootloader process for Maemo. In this case I'm sure that
everything is fine and I can replace new u-boot binary without
introducing any regressions. 

It downloads all needed stuff to construct images and filesystems.

> Also, what is to stop me running this script on my machine?

In script is "sudo mknod rootfs/dev/console c 5 1" call as in rootfs is
needed /dev/console character device. Otherwise everything is called
under normal user and all stuff is put into current directory.

And because on travis we can use 'sudo' I chosen this solution.

Alternative way to avoid usage of sudo, is to run whole script under
"fakeroot" utility. It use LD_PRELOAD with own library to fake mknod and
stat functions, so process can mknod (in memory) character device and
then mkfs.ubifs which reads (via stat) all files can properly put
character devices into rootfs image -- without any root privilege
escalation.

So if you want to run it on your machine, you needs be aware of that
sudo call.

Or if you want I can change script to use fakeroot utility (e.g Debian
is using it for building any DEB package) and then you can run it safely
under "nobody" user locally on your machine (if you do not like that
sudo call).

> Regards,
> Simon