qemu-stable
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] tests/avocado: update sunxi kernel from armbian to 6.6.16


From: Peter Maydell
Subject: Re: [PATCH] tests/avocado: update sunxi kernel from armbian to 6.6.16
Date: Tue, 30 Apr 2024 15:12:19 +0100

On Mon, 29 Apr 2024 at 21:40, Niek Linnenbank <nieklinnenbank@gmail.com> wrote:
>
> Hi Peter, Strahinja,
>
> I can confirm that the orangepi-pc and cubieboard based tests are working OK 
> using the newer kernel 6.6.16:
>
>   $ ARMBIAN_ARTIFACTS_CACHED=yes AVOCADO_ALLOW_LARGE_STORAGE=yes 
> ./build/pyvenv/bin/avocado --show=app,console run -t machine:orangepi-pc -t 
> machine:cubieboard tests/avocado/boot_linux_console.py
>   ...
>   RESULTS    : PASS 7 | ERROR 0 | FAIL 0 | SKIP 0 | WARN 0 | INTERRUPT 0 | 
> CANCEL 1
>   JOB TIME   : 177.65 s
>
> So for this patch:
> Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com>
> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com>

Great, thanks. (I'll put this patch into an upcoming arm pullreq.)

> About the BootLinuxConsole.test_arm_orangepi_bionic_20_08 test, I'd be happy 
> to provide a patch to revive that test.
> Since that test is no longer working without having the image available, this 
> could also be a good moment to re-consider if armbian is really the best 
> input for testing
> the orangepi-pc board. The image is relatively larger and slower compared to 
> other images, like the two openwrt based tests for cubieboard and bpim2u.
>
> After some searching I've found that Openwrt also has orangepi-pc support:
>   https://openwrt.org/toh/xunlong/orange_pi_pc
>
> That image works fine with our emulated orangepi-pc board:
>
> $ qemu-system-arm -M orangepi-pc -sd 
> openwrt-23.05.0-sunxi-cortexa7-xunlong_orangepi-pc-ext4-sdcard.img -nographic

> Using openwrt also for the orangepi-pc test instead of armbian also gives 
> some consistency between the various tests, to some degree. What are you 
> opinions on this?

Yeah, seems reasonable. My main thing to think about would be
that to understand what extra coverage this gives us that we
don't already have (there's no point running a ton of tests
which all amount to "boot a Linux kernel to a shell prompt").
It looks like what we get from this one is that we are testing
the "boot off an SD card image via u-boot" flow -- is that right?

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]