[PATCH 0/5] hw/arm/exynos4210: Add acceptance tests to the SMDKC210 board

[PATCH 0/5] hw/arm/exynos4210: Add acceptance tests to the SMDKC210 board

[Philippe Mathieu-Daudé]

Hi all,

Yesterday Peter Maydell asked on IRC if I had any working Exynos4
image. I looked at some old backuped notes and could boot Guenter
initrd with BusyBox.
I'll use this cover letter to share my notes, they might help to
have this board fully usable again.

This board is listed as "Odd Fixes". Since we have it covered, I
thought it was worthwhile to have it covered by tests to avoid
more regressions.

Frédéric Basse used this board last year:
https://fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html

I'll have a look a these particular commits he added:

- https://github.com/frederic/qemu-exynos-bootrom/commit/9be5c9f2253dbc04ee

   sd: add sd clock support to SDHC_CLKCON

- https://github.com/frederic/qemu-exynos-bootrom/commit/6f045949ee2fdec624

   sd: always reply to ACMD41 (SD_APP_OP_COND)

Guenter also carries on this patch:

- https://github.com/groeck/qemu/commit/0a80543cc910d

  hw/timer/exynos4210_mct: Initialize timer before starting it

  When booting a recent Linux kernel, the qemu message "Timer with period
  zero, disabling" is seen, apparently because a timer is started before
  being initialized.  Fix the problem by initializing the offending timer
  before starting it.

It might also be interesting to use Krzysztof's initramfs image:
https://github.com/krzk/tools/blob/master/run-qemu.sh#L29

The 1st test added works fine, however the 2nd (SD card) is not
reliable so it is disabled. We might need to adapt the ADMA patch
Igor sent once:
https://patchwork.ozlabs.org/patch/181854/

If you want to run the Avocado tests, you need these other patches
pending review:

- https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06439.html
  "tests/boot_linux_console: Extract the gunzip() helper"

- https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06438.html
  "python/qemu/machine: Allow to use other serial consoles than default"
  (only for the 2nd disabled test)

Regards,

Phil.

Based-on: 20190926173428.10713-16-f4bug@amsat.org

Philippe Mathieu-Daudé (5):
  tests/boot_linux_console: Add initrd test for the Exynos4210
  hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions
  hw/sd/sdhci: Add dummy Samsung SDHCI controller
  hw/arm/exynos4210: Use the Samsung s3c SDHCI controller
  tests/boot_linux_console: Add sdcard test for the Exynos4210

 hw/arm/exynos4210.c                    |  2 +-
 hw/sd/sdhci.c                          | 68 +++++++++++++++++++-
 include/hw/sd/sdhci.h                  |  2 +
 tests/acceptance/boot_linux_console.py | 88 ++++++++++++++++++++++++++
 4 files changed, 158 insertions(+), 2 deletions(-)

-- 
2.20.1

[PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Philippe Mathieu-Daudé]

This test boots a Linux kernel on a smdkc210 board and verify
the serial output is working.

The cpio image used comes from the linux-build-test project:
https://github.com/groeck/linux-build-test

If ARM is a target being built, "make check-acceptance" will
automatically include this test by the use of the "arch:arm" tags.

This test can be run using:

  $ avocado --show=app,console run -t machine:smdkc210 tests/acceptance/boot_linux_console.py
  console: Booting Linux on physical CPU 0x900
  console: Linux version 4.19.0-6-armmp (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)
  console: CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
  console: CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
  console: OF: fdt: Machine model: Samsung smdkv310 evaluation board based on Exynos4210
  [...]
  console: Samsung CPU ID: 0x43210211
  console: random: get_random_bytes called from start_kernel+0xa0/0x504 with crng_init=0
  console: percpu: Embedded 17 pages/cpu s39756 r8192 d21684 u69632
  console: Built 1 zonelists, mobility grouping on.  Total pages: 249152
  console: Kernel command line: printk.time=0 console=ttySAC0,115200n8 earlyprintk random.trust_cpu=off cryptomgr.notests cpuidle.off=1 panic=-1 noreboot
  [...]
  console: L2C: platform modifies aux control register: 0x02020000 -> 0x3e420001
  console: L2C: platform provided aux values permit register corruption.
  console: L2C: DT/platform modifies aux control register: 0x02020000 -> 0x3e420001
  console: L2C-310 erratum 769419 enabled
  console: L2C-310 enabling early BRESP for Cortex-A9
  console: L2C-310: enabling full line of zeros but not enabled in Cortex-A9
  console: L2C-310 ID prefetch enabled, offset 1 lines
  console: L2C-310 dynamic clock gating disabled, standby mode disabled
  console: L2C-310 cache controller enabled, 8 ways, 128 kB
  console: L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x7e420001
  console: Exynos4210 clocks: sclk_apll = 12000000, sclk_mpll = 12000000
  console: sclk_epll = 12000000, sclk_vpll = 12000000, arm_clk = 12000000
  [...]
  console: s3c-i2c 13860000.i2c: slave address 0x00
  console: s3c-i2c 13860000.i2c: bus frequency set to 93 KHz
  console: s3c-i2c 13860000.i2c: i2c-0: S3C I2C adapter
  [...]
  console: dma-pl330 12680000.pdma: Loaded driver for PL330 DMAC-241330
  console: dma-pl330 12680000.pdma:       DBUFF-256x8bytes Num_Chans-8 Num_Peri-32 Num_Events-16
  console: dma-pl330 12690000.pdma: Loaded driver for PL330 DMAC-241330
  console: dma-pl330 12690000.pdma:       DBUFF-256x8bytes Num_Chans-8 Num_Peri-32 Num_Events-16
  console: dma-pl330 12850000.mdma: Loaded driver for PL330 DMAC-241330
  console: dma-pl330 12850000.mdma:       DBUFF-256x8bytes Num_Chans-8 Num_Peri-1 Num_Events-16
  console: dma-pl330 12850000.mdma: PM domain LCD0 will not be powered off
  console: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
  console: Serial: AMBA driver
  console: 13800000.serial: ttySAC0 at MMIO 0x13800000 (irq = 40, base_baud = 0) is a S3C6400/10
  console: console [ttySAC0] enabled
  console: 13810000.serial: ttySAC1 at MMIO 0x13810000 (irq = 41, base_baud = 0) is a S3C6400/10
  console: 13820000.serial: ttySAC2 at MMIO 0x13820000 (irq = 42, base_baud = 0) is a S3C6400/10
  console: 13830000.serial: ttySAC3 at MMIO 0x13830000 (irq = 43, base_baud = 0) is a S3C6400/10
  [...]
  console: Freeing unused kernel memory: 2048K
  console: Run /init as init process
  console: mount: mounting devtmpfs on /dev failed: Device or resource busy
  console: Starting logging: OK
  console: Initializing random number generator... random: dd: uninitialized urandom read (512 bytes read)
  console: done.
  console: Starting network: OK
  console: Found console ttySAC0
  console: Linux version 4.19.0-6-armmp (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)
  console: Boot successful.
  PASS (37.98 s)

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
serial input is not working :(

I sometime get (not always):

Starting network: OK
[   70.403690] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[   70.423212] rcu:     0-...!: (36 GPs behind) idle=c7a/1/0x40000000 softirq=287/288 fqs=1
[   70.428209] rcu:     (detected by 1, t=2602 jiffies, g=-443, q=2209)
[   70.432826] Sending NMI from CPU 1 to CPUs 0:
[   70.473866] NMI backtrace for cpu 0
[   70.476621] CPU: 0 PID: 112 Comm: cat Not tainted 4.19.0 #1
[   70.476711] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   70.476916] PC is at mntput_no_expire+0x88/0x464
[   70.476996] LR is at rcu_is_watching+0x24/0x78
[   70.477074] pc : [<c02b256c>]    lr : [<c01a2fb4>]    psr: a0000013
[   70.477150] sp : ee2afdb0  ip : 9dff9a2f  fp : ee2aff70
[   70.477225] r10: 00000142  r9 : ee219dc0  r8 : ee2afec0
[   70.477302] r7 : ee2afec0  r6 : c0298d6c  r5 : ef02c400  r4 : ef018200
[   70.477385] r3 : c0f99274  r2 : 00000031  r1 : 2e87c000  r0 : a0000013
[   70.477461] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
[   70.477537] Control: 10c5387d  Table: 6e30806a  DAC: 00000051
[   70.477613] CPU: 0 PID: 112 Comm: cat Not tainted 4.19.0 #1
[   70.477688] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   70.477765] [<c01128f4>] (unwind_backtrace) from [<c010e5b4>] (show_stack+0x10/0x14)
[   70.477847] [<c010e5b4>] (show_stack) from [<c0a36160>] (dump_stack+0x98/0xc4)
[   70.477925] [<c0a36160>] (dump_stack) from [<c0a3cc90>] (nmi_cpu_backtrace+0x6c/0xb4)
[   70.478000] [<c0a3cc90>] (nmi_cpu_backtrace) from [<c0111530>] (handle_IPI+0x108/0x420)
[   70.478076] [<c0111530>] (handle_IPI) from [<c04950a8>] (gic_handle_irq+0x98/0x9c)
[   70.478151] [<c04950a8>] (gic_handle_irq) from [<c01019f0>] (__irq_svc+0x70/0xb0)
[   70.478226] Exception stack(0xee2afd60 to 0xee2afda8)
[   70.478303] fd60: a0000013 2e87c000 00000031 c0f99274 ef018200 ef02c400 c0298d6c ee2afec0
[   70.478378] fd80: ee2afec0 ee219dc0 00000142 ee2aff70 9dff9a2f ee2afdb0 c01a2fb4 c02b256c
[   70.478453] fda0: a0000013 ffffffff
[   70.478529] [<c01019f0>] (__irq_svc) from [<c02b256c>] (mntput_no_expire+0x88/0x464)
[   70.478605] [<c02b256c>] (mntput_no_expire) from [<c0298d6c>] (terminate_walk+0x154/0x160)
[   70.478681] [<c0298d6c>] (terminate_walk) from [<c029ce3c>] (path_openat+0x324/0xfe4)
[   70.478759] [<c029ce3c>] (path_openat) from [<c029ea9c>] (do_filp_open+0x70/0xdc)
[   70.478835] [<c029ea9c>] (do_filp_open) from [<c028b36c>] (do_sys_open+0x134/0x1e4)
[   70.478911] [<c028b36c>] (do_sys_open) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
[   70.478989] Exception stack(0xee2affa8 to 0xee2afff0)
[   70.479064] ffa0:                   b6fc7d6c 0000000a ffffff9c bebbf268 000a0000 00000000
[   70.479139] ffc0: b6fc7d6c 0000000a 00000050 00000142 bebbf268 b6fc6970 b6fc6b28 bebbf254
[   70.479214] ffe0: b6fc6970 bebbf1e0 b6f9dd94 b6fb0c0c
[   70.484892] rcu: rcu_preempt kthread starved for 2600 jiffies! g-443 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
[   70.514943] rcu: RCU grace-period kthread stack dump:
[   70.516687] rcu_preempt     I    0    10      2 0x00000000
[   70.523711] [<c0a4caac>] (__schedule) from [<c0a4d28c>] (schedule+0x4c/0xac)
[   70.525103] [<c0a4d28c>] (schedule) from [<c0a52c34>] (schedule_timeout+0x230/0x564)
[   70.526472] [<c0a52c34>] (schedule_timeout) from [<c01a7818>] (rcu_gp_kthread+0x6e4/0xbf0)
[   70.527784] [<c01a7818>] (rcu_gp_kthread) from [<c014d7f0>] (kthread+0x138/0x168)
[   70.528989] [<c014d7f0>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
[   70.530387] Exception stack(0xef111fb0 to 0xef111ff8)
[   70.532556] 1fa0:                                     00000000 00000000 00000000 00000000
[   70.534904] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[   70.536920] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
Found console ttySAC0

Linux version 4.19.0 (root@591d0a36fd03) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP PREEMPT Fri Oct 4 19:53:43 UTC 2019
Boot successful.
/ #

Also:

[   73.000405] [<c01128f4>] (unwind_backtrace) from [<c010e5b4>] (show_stack+0x10/0x14)
[   73.000537] [<c010e5b4>] (show_stack) from [<c0a36160>] (dump_stack+0x98/0xc4)
[   73.000631] [<c0a36160>] (dump_stack) from [<c0a3cc90>] (nmi_cpu_backtrace+0x6c/0xb4)
[   73.000701] [<c0a3cc90>] (nmi_cpu_backtrace) from [<c0111530>] (handle_IPI+0x108/0x420)
[   73.000823] [<c0111530>] (handle_IPI) from [<c04950a8>] (gic_handle_irq+0x98/0x9c)
[   73.000924] [<c04950a8>] (gic_handle_irq) from [<c01019f0>] (__irq_svc+0x70/0xb0)
[   73.000990] Exception stack(0xef123f80 to 0xef123fc8)
[   73.001064] 3f80: 00000001 00000001 00000000 ef11b300 ef122000 c1007470 c10074b4 00000002
[   73.001131] 3fa0: 4000406a 410fc090 00000000 00000000 00000000 ef123fd0 c018759c c010a4c8
[   73.001196] 3fc0: 20000013 ffffffff
[   73.001262] [<c01019f0>] (__irq_svc) from [<c010a4c8>] (arch_cpu_idle+0x24/0x3c)
[   73.001328] [<c010a4c8>] (arch_cpu_idle) from [<c015f1f0>] (do_idle+0xcc/0x168)
[   73.001394] [<c015f1f0>] (do_idle) from [<c015f60c>] (cpu_startup_entry+0x18/0x1c)
[   73.001462] [<c015f60c>] (cpu_startup_entry) from [<4010276c>] (0x4010276c)

Based-on: 20190926173428.10713-16-f4bug@amsat.org
"tests/boot_linux_console: Extract the gunzip() helper"
---
 tests/acceptance/boot_linux_console.py | 41 ++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

diff --git a/tests/acceptance/boot_linux_console.py b/tests/acceptance/boot_linux_console.py
index 079590f0c8..197358a69c 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -318,6 +318,47 @@ class BootLinuxConsole(Test):
         self.vm.launch()
         self.wait_for_console_pattern('init started: BusyBox')
 
+    def test_arm_exynos4210_initrd(self):
+        """
+        :avocado: tags=arch:arm
+        :avocado: tags=machine:smdkc210
+        """
+        deb_url = ('https://snapshot.debian.org/archive/debian/'
+                   '20190928T224601Z/pool/main/l/linux/'
+                   'linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb')
+        deb_hash = 'fa9df4a0d38936cb50084838f2cb933f570d7d82'
+        deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
+        kernel_path = self.extract_from_deb(deb_path,
+                                            '/boot/vmlinuz-4.19.0-6-armmp')
+        dtb_path = '/usr/lib/linux-image-4.19.0-6-armmp/exynos4210-smdkv310.dtb'
+        dtb_path = self.extract_from_deb(deb_path, dtb_path)
+
+        initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
+                      '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
+                      'arm/rootfs-armv5.cpio.gz')
+        initrd_hash = '2b50f1873e113523967806f4da2afe385462ff9b'
+        initrd_path_gz = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
+        initrd_path = os.path.join(self.workdir, 'rootfs.cpio')
+        gunzip(initrd_path_gz, initrd_path)
+
+        self.vm.set_machine('smdkc210')
+        self.vm.set_console()
+        kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
+                               'earlycon=exynos4210,0x13800000 earlyprintk ' +
+                               'console=ttySAC0,115200n8 ' +
+                               'random.trust_cpu=off cryptomgr.notests ' +
+                               'cpuidle.off=1 panic=-1 noreboot')
+
+        self.vm.add_args('-kernel', kernel_path,
+                         '-dtb', dtb_path,
+                         '-initrd', initrd_path,
+                         '-append', kernel_command_line,
+                         '-no-reboot')
+        self.vm.launch()
+
+        self.wait_for_console_pattern('Boot successful.')
+        # TODO user command, for now the uart is stuck
+
     def test_s390x_s390_ccw_virtio(self):
         """
         :avocado: tags=arch:s390x
-- 
2.20.1

Re: [PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Peter Maydell]

On Sat, 5 Oct 2019 at 16:47, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>
> This test boots a Linux kernel on a smdkc210 board and verify
> the serial output is working.
>
> The cpio image used comes from the linux-build-test project:
> https://github.com/groeck/linux-build-test

Thanks for putting this test case together, very helpful.

> +        initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
> +                      '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> +                      'arm/rootfs-armv5.cpio.gz')

Do our other acceptance tests download random third-party
(ie "not a well-known distro") binaries for the tests ?
It seems a bit hazardous for reproducability and trustability
reasons...

thanks
-- PMM

Re: [PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Cleber Rosa]

On Mon, Oct 07, 2019 at 05:28:49PM +0100, Peter Maydell wrote:
> On Sat, 5 Oct 2019 at 16:47, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> >
> > This test boots a Linux kernel on a smdkc210 board and verify
> > the serial output is working.
> >
> > The cpio image used comes from the linux-build-test project:
> > https://github.com/groeck/linux-build-test
> 
> Thanks for putting this test case together, very helpful.
> 
> > +        initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
> > +                      '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> > +                      'arm/rootfs-armv5.cpio.gz')
> 
> Do our other acceptance tests download random third-party
> (ie "not a well-known distro") binaries for the tests ?
> It seems a bit hazardous for reproducability and trustability
> reasons...
> 
> thanks
> -- PMM

A quick and dirty grep shows (excluding comments and docs):

   boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
   boot_linux_console.py:        deb_url = ('http://snapshot.debian.org/archive/debian/'
   boot_linux_console.py:        deb_url = ('http://snapshot.debian.org/archive/debian/'
   boot_linux_console.py:        deb_url = ('http://snapshot.debian.org/archive/debian/'
   boot_linux_console.py:        initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
   boot_linux_console.py:        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
   boot_linux_console.py:        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
   boot_linux_console.py:        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
   boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
   boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
   boot_linux_console.py:        uboot_url = ('https://raw.githubusercontent.com/'
   boot_linux_console.py:        spi_url = ('https://raw.githubusercontent.com/'
   boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive'
   boot_linux_console.py:        kernel_url = ('http://archive.debian.org/debian/dists/lenny/main/'
   boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive'
   linux_initrd.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora/li'
   linux_initrd.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
   linux_ssh_mips_malta.py:        'be': {'image_url': ('https://people.debian.org/~aurel32/qemu/mips/'
   linux_ssh_mips_malta.py:        'le': {'image_url': ('https://people.debian.org/~aurel32/qemu/mipsel/'
   linux_ssh_mips_malta.py:        kernel_url = ('https://people.debian.org/~aurel32/qemu/mips/'
   linux_ssh_mips_malta.py:        kernel_url = ('https://people.debian.org/~aurel32/qemu/mipsel/'
   linux_ssh_mips_malta.py:        kernel_url = ('https://people.debian.org/~aurel32/qemu/mips/'
   linux_ssh_mips_malta.py:        kernel_url = ('https://people.debian.org/~aurel32/qemu/mipsel/'
   machine_m68k_nextcube.py:        rom_url = ('http://www.nextcomputers.org/NeXTfiles/Software/ROM_Files/'

I find it hard to judge precisely how much of a third-party some of
these are.  I remember Philippe mentioning that one of them, I guess
the images used on linux_ssh_mips_malta.py, were "as official as it
gets" (my words, from my often misleading memory).

Reproducibility is definitely an issue, in the sense given that some
of these can indeed go away, but as long as they're available the hash
recorded in the test should guarantee that we're running the same
images.

Do you think we should do something different here?

Thanks!
- Cleber.

Re: [PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Guenter Roeck]

On Tue, Oct 08, 2019 at 05:49:07PM -0400, Cleber Rosa wrote:
> On Mon, Oct 07, 2019 at 05:28:49PM +0100, Peter Maydell wrote:
> > On Sat, 5 Oct 2019 at 16:47, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
> > >
> > > This test boots a Linux kernel on a smdkc210 board and verify
> > > the serial output is working.
> > >
> > > The cpio image used comes from the linux-build-test project:
> > > https://github.com/groeck/linux-build-test
> > 
> > Thanks for putting this test case together, very helpful.
> > 
> > > +        initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
> > > +                      '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> > > +                      'arm/rootfs-armv5.cpio.gz')
> > 
> > Do our other acceptance tests download random third-party
> > (ie "not a well-known distro") binaries for the tests ?
> > It seems a bit hazardous for reproducability and trustability
> > reasons...
> > 

FWIW, the root file system was generated with buildroot, with
minor modifications. It should be possible to create a clean
root file system from there.

Guenter

Re: [PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Peter Maydell]

On Tue, 8 Oct 2019 at 22:49, Cleber Rosa <crosa@redhat.com> wrote:
> On Mon, Oct 07, 2019 at 05:28:49PM +0100, Peter Maydell wrote:
> > Do our other acceptance tests download random third-party
> > (ie "not a well-known distro") binaries for the tests ?
> > It seems a bit hazardous for reproducability and trustability
> > reasons...

> A quick and dirty grep shows (excluding comments and docs):
>
>    boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
>    boot_linux_console.py:        deb_url = ('http://snapshot.debian.org/archive/debian/'
>    boot_linux_console.py:        deb_url = ('http://snapshot.debian.org/archive/debian/'
>    boot_linux_console.py:        deb_url = ('http://snapshot.debian.org/archive/debian/'
>    boot_linux_console.py:        initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
>    boot_linux_console.py:        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
>    boot_linux_console.py:        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
>    boot_linux_console.py:        kernel_url = ('https://mipsdistros.mips.com/LinuxDistro/nanomips/'
>    boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
>    boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
>    boot_linux_console.py:        uboot_url = ('https://raw.githubusercontent.com/'
>    boot_linux_console.py:        spi_url = ('https://raw.githubusercontent.com/'
>    boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive'
>    boot_linux_console.py:        kernel_url = ('http://archive.debian.org/debian/dists/lenny/main/'
>    boot_linux_console.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive'
>    linux_initrd.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora/li'
>    linux_initrd.py:        kernel_url = ('https://archives.fedoraproject.org/pub/archive/fedora'
>    linux_ssh_mips_malta.py:        'be': {'image_url': ('https://people.debian.org/~aurel32/qemu/mips/'
>    linux_ssh_mips_malta.py:        'le': {'image_url': ('https://people.debian.org/~aurel32/qemu/mipsel/'
>    linux_ssh_mips_malta.py:        kernel_url = ('https://people.debian.org/~aurel32/qemu/mips/'
>    linux_ssh_mips_malta.py:        kernel_url = ('https://people.debian.org/~aurel32/qemu/mipsel/'
>    linux_ssh_mips_malta.py:        kernel_url = ('https://people.debian.org/~aurel32/qemu/mips/'
>    linux_ssh_mips_malta.py:        kernel_url = ('https://people.debian.org/~aurel32/qemu/mipsel/'
>    machine_m68k_nextcube.py:        rom_url = ('http://www.nextcomputers.org/NeXTfiles/Software/ROM_Files/'
>
> I find it hard to judge precisely how much of a third-party some of
> these are.  I remember Philippe mentioning that one of them, I guess
> the images used on linux_ssh_mips_malta.py, were "as official as it
> gets" (my words, from my often misleading memory).
>
> Reproducibility is definitely an issue, in the sense given that some
> of these can indeed go away, but as long as they're available the hash
> recorded in the test should guarantee that we're running the same
> images.
>
> Do you think we should do something different here?

I'm not sure, which is why I asked whether this new test
was in line with what we've done previously. Since these
are just test cases and we don't redistribute them to
other people there's less of a traceability/reproducibility
worry, and if we check hashes on download that cuts off
a lot of "fail to notice if the image changes for some
reason" possible problems.

thanks
-- PMM

Re: [PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Cleber Rosa]

On Wed, Oct 09, 2019 at 02:38:02PM +0100, Peter Maydell wrote:
> On Tue, 8 Oct 2019 at 22:49, Cleber Rosa <crosa@redhat.com> wrote:
> >
> > I find it hard to judge precisely how much of a third-party some of
> > these are.  I remember Philippe mentioning that one of them, I guess
> > the images used on linux_ssh_mips_malta.py, were "as official as it
> > gets" (my words, from my often misleading memory).
> >
> > Reproducibility is definitely an issue, in the sense given that some
> > of these can indeed go away, but as long as they're available the hash
> > recorded in the test should guarantee that we're running the same
> > images.
> >
> > Do you think we should do something different here?
> 
> I'm not sure, which is why I asked whether this new test
> was in line with what we've done previously. Since these
> are just test cases and we don't redistribute them to
> other people there's less of a traceability/reproducibility
> worry, and if we check hashes on download that cuts off
> a lot of "fail to notice if the image changes for some
> reason" possible problems.
> 
> thanks
> -- PMM
> 

Yep, because I have no clue how to do improve on this (redistributing
the binaries is definitely not on the improvement side, and neither
is not testing some machine types), the current approach seems good.

Thanks for checking in and giving feedback!

- Cleber.

Re: [PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Philippe Mathieu-Daudé]

On 10/9/19 9:07 PM, Cleber Rosa wrote:
> On Wed, Oct 09, 2019 at 02:38:02PM +0100, Peter Maydell wrote:
>> On Tue, 8 Oct 2019 at 22:49, Cleber Rosa <crosa@redhat.com> wrote:
>>> On Mon, Oct 07, 2019 at 05:28:49PM +0100, Peter Maydell wrote:
 >>>
 >>>> Do our other acceptance tests download random third-party
 >>>> (ie "not a well-known distro") binaries for the tests ?
 >>>> It seems a bit hazardous for reproducability and trustability
 >>>> reasons...
[...]
>>> I find it hard to judge precisely how much of a third-party some of
>>> these are.  I remember Philippe mentioning that one of them, I guess
>>> the images used on linux_ssh_mips_malta.py, were "as official as it
>>> gets" (my words, from my often misleading memory).
>>>
>>> Reproducibility is definitely an issue, in the sense given that some
>>> of these can indeed go away, but as long as they're available the hash
>>> recorded in the test should guarantee that we're running the same
>>> images.

So this thread is a follow up on:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg546430.html

For Open Source software I can understand we want to be able to rebuild 
them, and should provide a link about how to rebuild.

I don't want to rebuild images myself, I want to focus on testing QEMU. 
I tried once to build a MIPSsim kernel and it was a total nightmare:
https://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg04071.html
(Thomas Huth eventually succeeded using buildroot).

>>> Do you think we should do something different here?
>>
>> I'm not sure, which is why I asked whether this new test
>> was in line with what we've done previously. Since these
>> are just test cases and we don't redistribute them to
>> other people there's less of a traceability/reproducibility
>> worry, and if we check hashes on download that cuts off
>> a lot of "fail to notice if the image changes for some
>> reason" possible problems.
> 
> Yep, because I have no clue how to do improve on this (redistributing
> the binaries is definitely not on the improvement side, and neither
> is not testing some machine types), the current approach seems good.

QEMU machines are not restricted to running Linux or other Open Source 
software. It seems important to be able to test for regressions with 
closed-source code too, because it usually has been well tested on real 
hardware.

I just posted a firmware test:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg651012.html

I could find it stored compressed and uuencoded on the Wayback Machine.
Since I don't want to abuse from this amazing service, and other script 
to decode/uncompress it, I stored it on a new repository with its SHA-1
(the default hash used by Avocado):
https://github.com/philmd/qemu-testing-blob/tree/master/hppa/hp9000/712

Is this acceptable? Incorrect?

Regarding Avocado tests, maybe we can simply add a "untrusted" or 
"closedsource" tag, so people willing to test untrusted binaries could 
still run the tests using 'avocado --tag untrusted_software', and we 
could skip these tests by default.

I am very interested because I already experimented with:

- AIX on PReP/40p
- some RTOS on Canon PowerShot A1100
- VxWorks on MIPS and SPARC
- closed-source bootloader for Raspi3/4

Regards,

Phil.

Re: [PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Philippe Mathieu-Daudé]

On 10/10/19 3:43 PM, Philippe Mathieu-Daudé wrote:
> On 10/9/19 9:07 PM, Cleber Rosa wrote:
>> On Wed, Oct 09, 2019 at 02:38:02PM +0100, Peter Maydell wrote:
>>> On Tue, 8 Oct 2019 at 22:49, Cleber Rosa <crosa@redhat.com> wrote:
>>>> On Mon, Oct 07, 2019 at 05:28:49PM +0100, Peter Maydell wrote:
>  >>>
>  >>>> Do our other acceptance tests download random third-party
>  >>>> (ie "not a well-known distro") binaries for the tests ?
>  >>>> It seems a bit hazardous for reproducability and trustability
>  >>>> reasons...
> [...]
>>>> I find it hard to judge precisely how much of a third-party some of
>>>> these are.  I remember Philippe mentioning that one of them, I guess
>>>> the images used on linux_ssh_mips_malta.py, were "as official as it
>>>> gets" (my words, from my often misleading memory).
>>>>
>>>> Reproducibility is definitely an issue, in the sense given that some
>>>> of these can indeed go away, but as long as they're available the hash
>>>> recorded in the test should guarantee that we're running the same
>>>> images.
> 
> So this thread is a follow up on:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg546430.html
> 
> For Open Source software I can understand we want to be able to rebuild 
> them, and should provide a link about how to rebuild.
> 
> I don't want to rebuild images myself, I want to focus on testing QEMU. 
> I tried once to build a MIPSsim kernel and it was a total nightmare:
> https://lists.nongnu.org/archive/html/qemu-devel/2018-04/msg04071.html
> (Thomas Huth eventually succeeded using buildroot).
> 
>>>> Do you think we should do something different here?
>>>
>>> I'm not sure, which is why I asked whether this new test
>>> was in line with what we've done previously. Since these
>>> are just test cases and we don't redistribute them to
>>> other people there's less of a traceability/reproducibility
>>> worry, and if we check hashes on download that cuts off
>>> a lot of "fail to notice if the image changes for some
>>> reason" possible problems.
>>
>> Yep, because I have no clue how to do improve on this (redistributing
>> the binaries is definitely not on the improvement side, and neither
>> is not testing some machine types), the current approach seems good.
> 
> QEMU machines are not restricted to running Linux or other Open Source 
> software. It seems important to be able to test for regressions with 
> closed-source code too, because it usually has been well tested on real 
> hardware.
> 
> I just posted a firmware test:
> https://www.mail-archive.com/qemu-devel@nongnu.org/msg651012.html
> 
> I could find it stored compressed and uuencoded on the Wayback Machine.
> Since I don't want to abuse from this amazing service, and other script 
> to decode/uncompress it, I stored it on a new repository with its SHA-1
> (the default hash used by Avocado):
> https://github.com/philmd/qemu-testing-blob/tree/master/hppa/hp9000/712
> 
> Is this acceptable? Incorrect?

I'v been wondering about this during the week-end. If this is 
problematic to add the tests in the QEMU repository, we can add the 
tests in another repository. The problem will be to keep it sync with 
QEMU. If we add it as a QEMU submodule, it is the same as continuing 
adding the tests in the main tree.

Avocado don't have problem browsing tests in various directories, the 
problem is we need to import avocado_qemu 
(tests/acceptance/avocado_qemu) which imports QEMUMachine from qemu.machine.

Cleber, we once talked about having the main repository producing 
python-qemu and python-qemu-acceptance-testing packages. How do you want 
to proceed? Extract theses files from the main repo and have it consumes 
the packages? I'm afraid that doesn't scale properly with distributions.
Also, updating them to improve the testing will be slow/painful.

I now realize this is probably not the clever path to continue, but I'm 
currently out of ideas to unblock the testing process.

Peter what do you think, do you think of other alternatives we can 
investigate?

Thanks,

Phil.

> Regarding Avocado tests, maybe we can simply add a "untrusted" or 
> "closedsource" tag, so people willing to test untrusted binaries could 
> still run the tests using 'avocado --tag untrusted_software', and we 
> could skip these tests by default.
> 
> I am very interested because I already experimented with:
> 
> - AIX on PReP/40p
> - some RTOS on Canon PowerShot A1100
> - VxWorks on MIPS and SPARC
> - closed-source bootloader for Raspi3/4
> 
> Regards,
> 
> Phil.

Re: [PATCH 1/5] tests/boot_linux_console: Add initrd test for the Exynos4210

[Cleber Rosa]

On Sat, Oct 05, 2019 at 05:47:44PM +0200, Philippe Mathieu-Daudé wrote:
> This test boots a Linux kernel on a smdkc210 board and verify
> the serial output is working.
> 
> The cpio image used comes from the linux-build-test project:
> https://github.com/groeck/linux-build-test
> 
> If ARM is a target being built, "make check-acceptance" will
> automatically include this test by the use of the "arch:arm" tags.
> 
> This test can be run using:
> 
>   $ avocado --show=app,console run -t machine:smdkc210 tests/acceptance/boot_linux_console.py
>   console: Booting Linux on physical CPU 0x900
>   console: Linux version 4.19.0-6-armmp (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)
>   console: CPU: ARMv7 Processor [410fc090] revision 0 (ARMv7), cr=10c5387d
>   console: CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
>   console: OF: fdt: Machine model: Samsung smdkv310 evaluation board based on Exynos4210
>   [...]
>   console: Samsung CPU ID: 0x43210211
>   console: random: get_random_bytes called from start_kernel+0xa0/0x504 with crng_init=0
>   console: percpu: Embedded 17 pages/cpu s39756 r8192 d21684 u69632
>   console: Built 1 zonelists, mobility grouping on.  Total pages: 249152
>   console: Kernel command line: printk.time=0 console=ttySAC0,115200n8 earlyprintk random.trust_cpu=off cryptomgr.notests cpuidle.off=1 panic=-1 noreboot
>   [...]
>   console: L2C: platform modifies aux control register: 0x02020000 -> 0x3e420001
>   console: L2C: platform provided aux values permit register corruption.
>   console: L2C: DT/platform modifies aux control register: 0x02020000 -> 0x3e420001
>   console: L2C-310 erratum 769419 enabled
>   console: L2C-310 enabling early BRESP for Cortex-A9
>   console: L2C-310: enabling full line of zeros but not enabled in Cortex-A9
>   console: L2C-310 ID prefetch enabled, offset 1 lines
>   console: L2C-310 dynamic clock gating disabled, standby mode disabled
>   console: L2C-310 cache controller enabled, 8 ways, 128 kB
>   console: L2C-310: CACHE_ID 0x410000c8, AUX_CTRL 0x7e420001
>   console: Exynos4210 clocks: sclk_apll = 12000000, sclk_mpll = 12000000
>   console: sclk_epll = 12000000, sclk_vpll = 12000000, arm_clk = 12000000
>   [...]
>   console: s3c-i2c 13860000.i2c: slave address 0x00
>   console: s3c-i2c 13860000.i2c: bus frequency set to 93 KHz
>   console: s3c-i2c 13860000.i2c: i2c-0: S3C I2C adapter
>   [...]
>   console: dma-pl330 12680000.pdma: Loaded driver for PL330 DMAC-241330
>   console: dma-pl330 12680000.pdma:       DBUFF-256x8bytes Num_Chans-8 Num_Peri-32 Num_Events-16
>   console: dma-pl330 12690000.pdma: Loaded driver for PL330 DMAC-241330
>   console: dma-pl330 12690000.pdma:       DBUFF-256x8bytes Num_Chans-8 Num_Peri-32 Num_Events-16
>   console: dma-pl330 12850000.mdma: Loaded driver for PL330 DMAC-241330
>   console: dma-pl330 12850000.mdma:       DBUFF-256x8bytes Num_Chans-8 Num_Peri-1 Num_Events-16
>   console: dma-pl330 12850000.mdma: PM domain LCD0 will not be powered off
>   console: Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
>   console: Serial: AMBA driver
>   console: 13800000.serial: ttySAC0 at MMIO 0x13800000 (irq = 40, base_baud = 0) is a S3C6400/10
>   console: console [ttySAC0] enabled
>   console: 13810000.serial: ttySAC1 at MMIO 0x13810000 (irq = 41, base_baud = 0) is a S3C6400/10
>   console: 13820000.serial: ttySAC2 at MMIO 0x13820000 (irq = 42, base_baud = 0) is a S3C6400/10
>   console: 13830000.serial: ttySAC3 at MMIO 0x13830000 (irq = 43, base_baud = 0) is a S3C6400/10
>   [...]
>   console: Freeing unused kernel memory: 2048K
>   console: Run /init as init process
>   console: mount: mounting devtmpfs on /dev failed: Device or resource busy
>   console: Starting logging: OK
>   console: Initializing random number generator... random: dd: uninitialized urandom read (512 bytes read)
>   console: done.
>   console: Starting network: OK
>   console: Found console ttySAC0
>   console: Linux version 4.19.0-6-armmp (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)
>   console: Boot successful.
>   PASS (37.98 s)
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> serial input is not working :(
> 
> I sometime get (not always):
> 
> Starting network: OK
> [   70.403690] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
> [   70.423212] rcu:     0-...!: (36 GPs behind) idle=c7a/1/0x40000000 softirq=287/288 fqs=1
> [   70.428209] rcu:     (detected by 1, t=2602 jiffies, g=-443, q=2209)
> [   70.432826] Sending NMI from CPU 1 to CPUs 0:
> [   70.473866] NMI backtrace for cpu 0
> [   70.476621] CPU: 0 PID: 112 Comm: cat Not tainted 4.19.0 #1
> [   70.476711] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   70.476916] PC is at mntput_no_expire+0x88/0x464
> [   70.476996] LR is at rcu_is_watching+0x24/0x78
> [   70.477074] pc : [<c02b256c>]    lr : [<c01a2fb4>]    psr: a0000013
> [   70.477150] sp : ee2afdb0  ip : 9dff9a2f  fp : ee2aff70
> [   70.477225] r10: 00000142  r9 : ee219dc0  r8 : ee2afec0
> [   70.477302] r7 : ee2afec0  r6 : c0298d6c  r5 : ef02c400  r4 : ef018200
> [   70.477385] r3 : c0f99274  r2 : 00000031  r1 : 2e87c000  r0 : a0000013
> [   70.477461] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
> [   70.477537] Control: 10c5387d  Table: 6e30806a  DAC: 00000051
> [   70.477613] CPU: 0 PID: 112 Comm: cat Not tainted 4.19.0 #1
> [   70.477688] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
> [   70.477765] [<c01128f4>] (unwind_backtrace) from [<c010e5b4>] (show_stack+0x10/0x14)
> [   70.477847] [<c010e5b4>] (show_stack) from [<c0a36160>] (dump_stack+0x98/0xc4)
> [   70.477925] [<c0a36160>] (dump_stack) from [<c0a3cc90>] (nmi_cpu_backtrace+0x6c/0xb4)
> [   70.478000] [<c0a3cc90>] (nmi_cpu_backtrace) from [<c0111530>] (handle_IPI+0x108/0x420)
> [   70.478076] [<c0111530>] (handle_IPI) from [<c04950a8>] (gic_handle_irq+0x98/0x9c)
> [   70.478151] [<c04950a8>] (gic_handle_irq) from [<c01019f0>] (__irq_svc+0x70/0xb0)
> [   70.478226] Exception stack(0xee2afd60 to 0xee2afda8)
> [   70.478303] fd60: a0000013 2e87c000 00000031 c0f99274 ef018200 ef02c400 c0298d6c ee2afec0
> [   70.478378] fd80: ee2afec0 ee219dc0 00000142 ee2aff70 9dff9a2f ee2afdb0 c01a2fb4 c02b256c
> [   70.478453] fda0: a0000013 ffffffff
> [   70.478529] [<c01019f0>] (__irq_svc) from [<c02b256c>] (mntput_no_expire+0x88/0x464)
> [   70.478605] [<c02b256c>] (mntput_no_expire) from [<c0298d6c>] (terminate_walk+0x154/0x160)
> [   70.478681] [<c0298d6c>] (terminate_walk) from [<c029ce3c>] (path_openat+0x324/0xfe4)
> [   70.478759] [<c029ce3c>] (path_openat) from [<c029ea9c>] (do_filp_open+0x70/0xdc)
> [   70.478835] [<c029ea9c>] (do_filp_open) from [<c028b36c>] (do_sys_open+0x134/0x1e4)
> [   70.478911] [<c028b36c>] (do_sys_open) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
> [   70.478989] Exception stack(0xee2affa8 to 0xee2afff0)
> [   70.479064] ffa0:                   b6fc7d6c 0000000a ffffff9c bebbf268 000a0000 00000000
> [   70.479139] ffc0: b6fc7d6c 0000000a 00000050 00000142 bebbf268 b6fc6970 b6fc6b28 bebbf254
> [   70.479214] ffe0: b6fc6970 bebbf1e0 b6f9dd94 b6fb0c0c
> [   70.484892] rcu: rcu_preempt kthread starved for 2600 jiffies! g-443 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
> [   70.514943] rcu: RCU grace-period kthread stack dump:
> [   70.516687] rcu_preempt     I    0    10      2 0x00000000
> [   70.523711] [<c0a4caac>] (__schedule) from [<c0a4d28c>] (schedule+0x4c/0xac)
> [   70.525103] [<c0a4d28c>] (schedule) from [<c0a52c34>] (schedule_timeout+0x230/0x564)
> [   70.526472] [<c0a52c34>] (schedule_timeout) from [<c01a7818>] (rcu_gp_kthread+0x6e4/0xbf0)
> [   70.527784] [<c01a7818>] (rcu_gp_kthread) from [<c014d7f0>] (kthread+0x138/0x168)
> [   70.528989] [<c014d7f0>] (kthread) from [<c01010b4>] (ret_from_fork+0x14/0x20)
> [   70.530387] Exception stack(0xef111fb0 to 0xef111ff8)
> [   70.532556] 1fa0:                                     00000000 00000000 00000000 00000000
> [   70.534904] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [   70.536920] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> Found console ttySAC0
> 
> Linux version 4.19.0 (root@591d0a36fd03) (gcc version 6.3.0 20170516 (Debian 6.3.0-18)) #1 SMP PREEMPT Fri Oct 4 19:53:43 UTC 2019
> Boot successful.
> / #
> 
> Also:
> 
> [   73.000405] [<c01128f4>] (unwind_backtrace) from [<c010e5b4>] (show_stack+0x10/0x14)
> [   73.000537] [<c010e5b4>] (show_stack) from [<c0a36160>] (dump_stack+0x98/0xc4)
> [   73.000631] [<c0a36160>] (dump_stack) from [<c0a3cc90>] (nmi_cpu_backtrace+0x6c/0xb4)
> [   73.000701] [<c0a3cc90>] (nmi_cpu_backtrace) from [<c0111530>] (handle_IPI+0x108/0x420)
> [   73.000823] [<c0111530>] (handle_IPI) from [<c04950a8>] (gic_handle_irq+0x98/0x9c)
> [   73.000924] [<c04950a8>] (gic_handle_irq) from [<c01019f0>] (__irq_svc+0x70/0xb0)
> [   73.000990] Exception stack(0xef123f80 to 0xef123fc8)
> [   73.001064] 3f80: 00000001 00000001 00000000 ef11b300 ef122000 c1007470 c10074b4 00000002
> [   73.001131] 3fa0: 4000406a 410fc090 00000000 00000000 00000000 ef123fd0 c018759c c010a4c8
> [   73.001196] 3fc0: 20000013 ffffffff
> [   73.001262] [<c01019f0>] (__irq_svc) from [<c010a4c8>] (arch_cpu_idle+0x24/0x3c)
> [   73.001328] [<c010a4c8>] (arch_cpu_idle) from [<c015f1f0>] (do_idle+0xcc/0x168)
> [   73.001394] [<c015f1f0>] (do_idle) from [<c015f60c>] (cpu_startup_entry+0x18/0x1c)
> [   73.001462] [<c015f60c>] (cpu_startup_entry) from [<4010276c>] (0x4010276c)
>

I did not run into this, but I did run into one execution that reached
no further than:

   17:14:18 DEBUG| Power domain MFC disable failed
   17:14:18 DEBUG| Freeing unused kernel memory: 2048K
   17:14:43 DEBUG| random: crng init done

And then Avocado's timeout handler kicked in.  This means that, upon
inclusion, those tests should not run by default.  We've discussed a
few approaches before, but I guess it's time to implement *something*
on that matter, and then refine it later.

> Based-on: 20190926173428.10713-16-f4bug@amsat.org
> "tests/boot_linux_console: Extract the gunzip() helper"

With Avocado 72.0 (which is now pinned in requirements.txt) there
should be no need for this helper.

> ---
>  tests/acceptance/boot_linux_console.py | 41 ++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/tests/acceptance/boot_linux_console.py b/tests/acceptance/boot_linux_console.py
> index 079590f0c8..197358a69c 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -318,6 +318,47 @@ class BootLinuxConsole(Test):
>          self.vm.launch()
>          self.wait_for_console_pattern('init started: BusyBox')
>  
> +    def test_arm_exynos4210_initrd(self):
> +        """
> +        :avocado: tags=arch:arm
> +        :avocado: tags=machine:smdkc210
> +        """
> +        deb_url = ('https://snapshot.debian.org/archive/debian/'
> +                   '20190928T224601Z/pool/main/l/linux/'
> +                   'linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb')
> +        deb_hash = 'fa9df4a0d38936cb50084838f2cb933f570d7d82'
> +        deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> +        kernel_path = self.extract_from_deb(deb_path,
> +                                            '/boot/vmlinuz-4.19.0-6-armmp')
> +        dtb_path = '/usr/lib/linux-image-4.19.0-6-armmp/exynos4210-smdkv310.dtb'
> +        dtb_path = self.extract_from_deb(deb_path, dtb_path)
> +
> +        initrd_url = ('https://github.com/groeck/linux-build-test/raw/'
> +                      '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> +                      'arm/rootfs-armv5.cpio.gz')
> +        initrd_hash = '2b50f1873e113523967806f4da2afe385462ff9b'
> +        initrd_path_gz = self.fetch_asset(initrd_url, asset_hash=initrd_hash)
> +        initrd_path = os.path.join(self.workdir, 'rootfs.cpio')
> +        gunzip(initrd_path_gz, initrd_path)

With Avocado 72.0 you can simply use:

   archive.uncompress(initrd_path_gz, initrd_path)

> +
> +        self.vm.set_machine('smdkc210')

I'm longing for the day where this won't be necessary anymore:

  https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg05634.html

- Cleber.

> +        self.vm.set_console()
> +        kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
> +                               'earlycon=exynos4210,0x13800000 earlyprintk ' +
> +                               'console=ttySAC0,115200n8 ' +
> +                               'random.trust_cpu=off cryptomgr.notests ' +
> +                               'cpuidle.off=1 panic=-1 noreboot')
> +
> +        self.vm.add_args('-kernel', kernel_path,
> +                         '-dtb', dtb_path,
> +                         '-initrd', initrd_path,
> +                         '-append', kernel_command_line,
> +                         '-no-reboot')
> +        self.vm.launch()
> +
> +        self.wait_for_console_pattern('Boot successful.')
> +        # TODO user command, for now the uart is stuck
> +
>      def test_s390x_s390_ccw_virtio(self):
>          """
>          :avocado: tags=arch:s390x
> -- 
> 2.20.1
> 
> 

[PATCH 2/5] hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions

[Philippe Mathieu-Daudé]

This file keeps the various QDev blocks separated by comments.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/sd/sdhci.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index e08ec3e398..82ec5c1b4a 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1532,6 +1532,8 @@ static const TypeInfo sdhci_bus_info = {
     .class_init = sdhci_bus_class_init,
 };
 
+/* --- qdev i.MX eSDHC --- */
+
 static uint64_t usdhc_read(void *opaque, hwaddr offset, unsigned size)
 {
     SDHCIState *s = SYSBUS_SDHCI(opaque);
@@ -1734,7 +1736,6 @@ usdhc_write(void *opaque, hwaddr offset, uint64_t val, unsigned size)
     }
 }
 
-
 static const MemoryRegionOps usdhc_mmio_ops = {
     .read = usdhc_read,
     .write = usdhc_write,
-- 
2.20.1

Re: [PATCH 2/5] hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions

[Cleber Rosa]

On Sat, Oct 05, 2019 at 05:47:45PM +0200, Philippe Mathieu-Daudé wrote:
> This file keeps the various QDev blocks separated by comments.
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/sd/sdhci.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index e08ec3e398..82ec5c1b4a 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -1532,6 +1532,8 @@ static const TypeInfo sdhci_bus_info = {
>      .class_init = sdhci_bus_class_init,
>  };
>  
> +/* --- qdev i.MX eSDHC --- */
> +
>  static uint64_t usdhc_read(void *opaque, hwaddr offset, unsigned size)
>  {
>      SDHCIState *s = SYSBUS_SDHCI(opaque);
> @@ -1734,7 +1736,6 @@ usdhc_write(void *opaque, hwaddr offset, uint64_t val, unsigned size)
>      }
>  }
>  
> -
>  static const MemoryRegionOps usdhc_mmio_ops = {
>      .read = usdhc_read,
>      .write = usdhc_write,
> -- 
> 2.20.1
> 
> 

Reviewed-by: Cleber Rosa <crosa@redhat.com>

[PATCH 3/5] hw/sd/sdhci: Add dummy Samsung SDHCI controller

[Philippe Mathieu-Daudé]

The Linux kernel access few S3C-specific registers [1] to set some
clock. We don't care about this part for device emulation [2]. Add
a dummy device to properly ignore these accesses, so we can focus
on the important registers missing.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/sdhci-s3c-regs.h?h=cc014f3
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/sdhci-s3c.c?h=v5.3#n263

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
Eventually we should add the ADMA changes Igor sent in this patch:
https://patchwork.ozlabs.org/patch/181854/
They might solve the boot timing issues when using SD cards.
---
 hw/sd/sdhci.c         | 65 +++++++++++++++++++++++++++++++++++++++++++
 include/hw/sd/sdhci.h |  2 ++
 2 files changed, 67 insertions(+)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 82ec5c1b4a..88404d0e9d 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1761,11 +1761,76 @@ static const TypeInfo imx_usdhc_info = {
     .instance_init = imx_usdhc_init,
 };
 
+/* --- qdev Samsung s3c --- */
+
+#define S3C_SDHCI_CONTROL2      0x80
+#define S3C_SDHCI_CONTROL3      0x84
+#define S3C_SDHCI_CONTROL4      0x8c
+
+static uint64_t sdhci_s3c_read(void *opaque, hwaddr offset, unsigned size)
+{
+    uint64_t ret;
+
+    switch (offset) {
+    case S3C_SDHCI_CONTROL2:
+    case S3C_SDHCI_CONTROL3:
+    case S3C_SDHCI_CONTROL4:
+        /* ignore */
+        ret = 0;
+        break;
+    default:
+        ret = sdhci_read(opaque, offset, size);
+        break;
+    }
+
+    return ret;
+}
+
+static void sdhci_s3c_write(void *opaque, hwaddr offset, uint64_t val,
+                            unsigned size)
+{
+    switch (offset) {
+    case S3C_SDHCI_CONTROL2:
+    case S3C_SDHCI_CONTROL3:
+    case S3C_SDHCI_CONTROL4:
+        /* ignore */
+        break;
+    default:
+        sdhci_write(opaque, offset, val, size);
+        break;
+    }
+}
+
+static const MemoryRegionOps sdhci_s3c_mmio_ops = {
+    .read = sdhci_s3c_read,
+    .write = sdhci_s3c_write,
+    .valid = {
+        .min_access_size = 1,
+        .max_access_size = 4,
+        .unaligned = false
+    },
+    .endianness = DEVICE_LITTLE_ENDIAN,
+};
+
+static void sdhci_s3c_init(Object *obj)
+{
+    SDHCIState *s = SYSBUS_SDHCI(obj);
+
+    s->io_ops = &sdhci_s3c_mmio_ops;
+}
+
+static const TypeInfo sdhci_s3c_info = {
+    .name = TYPE_S3C_SDHCI  ,
+    .parent = TYPE_SYSBUS_SDHCI,
+    .instance_init = sdhci_s3c_init,
+};
+
 static void sdhci_register_types(void)
 {
     type_register_static(&sdhci_sysbus_info);
     type_register_static(&sdhci_bus_info);
     type_register_static(&imx_usdhc_info);
+    type_register_static(&sdhci_s3c_info);
 }
 
 type_init(sdhci_register_types)
diff --git a/include/hw/sd/sdhci.h b/include/hw/sd/sdhci.h
index cbf415e43a..c6868c9699 100644
--- a/include/hw/sd/sdhci.h
+++ b/include/hw/sd/sdhci.h
@@ -116,4 +116,6 @@ typedef struct SDHCIState {
 
 #define TYPE_IMX_USDHC "imx-usdhc"
 
+#define TYPE_S3C_SDHCI "s3c-sdhci"
+
 #endif /* SDHCI_H */
-- 
2.20.1

Re: [PATCH 3/5] hw/sd/sdhci: Add dummy Samsung SDHCI controller

[Krzysztof Kozlowski]

On Sat, Oct 05, 2019 at 05:47:46PM +0200, Philippe Mathieu-Daudé wrote:
> The Linux kernel access few S3C-specific registers [1] to set some
> clock. We don't care about this part for device emulation [2]. Add
> a dummy device to properly ignore these accesses, so we can focus
> on the important registers missing.

The CONTROL2  has also few other settings, not clock related, but they
can be skipped as well.

Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>

Best regards,
Krzysztof

> 
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/sdhci-s3c-regs.h?h=cc014f3
> [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/mmc/host/sdhci-s3c.c?h=v5.3#n263
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
> Eventually we should add the ADMA changes Igor sent in this patch:
> https://patchwork.ozlabs.org/patch/181854/
> They might solve the boot timing issues when using SD cards.
> ---
>  hw/sd/sdhci.c         | 65 +++++++++++++++++++++++++++++++++++++++++++
>  include/hw/sd/sdhci.h |  2 ++
>  2 files changed, 67 insertions(+)
> 

[PATCH 4/5] hw/arm/exynos4210: Use the Samsung s3c SDHCI controller

[Philippe Mathieu-Daudé]

The Exynos SoC has specific SDHCI registers. Use the s3c SDHCI
model which handle these specific registers.

This silents the following "SDHC ... not implemented" warnings so
we can focus on the important registers missing:

  $ qemu-system-arm ... -d unimp \
    -append "... root=/dev/mmcblk0 rootfstype=ext4 rw rootwait" \
    -drive file=linux-build-test/rootfs/arm/rootfs-armv5.ext2,if=sd,format=raw
  [...]
  [   25.744858] sdhci: Secure Digital Host Controller Interface driver
  [   25.745862] sdhci: Copyright(c) Pierre Ossman
  [   25.783188] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2 (12000000 Hz)
  SDHC rd_4b @0x80 not implemented
  SDHC wr_4b @0x80 <- 0x00000020 not implemented
  SDHC wr_4b @0x8c <- 0x00030000 not implemented
  SDHC rd_4b @0x80 not implemented
  SDHC wr_4b @0x80 <- 0xc0004100 not implemented
  SDHC wr_4b @0x84 <- 0x80808080 not implemented
  [   26.013318] mmc0: SDHCI controller on samsung-hsmmc [12530000.sdhci] using ADMA
  [   26.032318] Synopsys Designware Multimedia Card Interface Driver
  [   42.024885] Waiting for root device /dev/mmcblk0...

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 hw/arm/exynos4210.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hw/arm/exynos4210.c b/hw/arm/exynos4210.c
index a9f8a5c868..77fbe1baab 100644
--- a/hw/arm/exynos4210.c
+++ b/hw/arm/exynos4210.c
@@ -405,7 +405,7 @@ static void exynos4210_realize(DeviceState *socdev, Error **errp)
          * public datasheet which is very similar (implementing
          * MMC Specification Version 4.0 being the only difference noted)
          */
-        dev = qdev_create(NULL, TYPE_SYSBUS_SDHCI);
+        dev = qdev_create(NULL, TYPE_S3C_SDHCI);
         qdev_prop_set_uint64(dev, "capareg", EXYNOS4210_SDHCI_CAPABILITIES);
         qdev_init_nofail(dev);
 
-- 
2.20.1

Re: [PATCH 4/5] hw/arm/exynos4210: Use the Samsung s3c SDHCI controller

[Krzysztof Kozlowski]

On Sat, Oct 05, 2019 at 05:47:47PM +0200, Philippe Mathieu-Daudé wrote:
> The Exynos SoC has specific SDHCI registers. Use the s3c SDHCI
> model which handle these specific registers.
> 
> This silents the following "SDHC ... not implemented" warnings so
> we can focus on the important registers missing:
> 
>   $ qemu-system-arm ... -d unimp \
>     -append "... root=/dev/mmcblk0 rootfstype=ext4 rw rootwait" \
>     -drive file=linux-build-test/rootfs/arm/rootfs-armv5.ext2,if=sd,format=raw
>   [...]
>   [   25.744858] sdhci: Secure Digital Host Controller Interface driver
>   [   25.745862] sdhci: Copyright(c) Pierre Ossman
>   [   25.783188] s3c-sdhci 12530000.sdhci: clock source 2: mmc_busclk.2 (12000000 Hz)
>   SDHC rd_4b @0x80 not implemented
>   SDHC wr_4b @0x80 <- 0x00000020 not implemented
>   SDHC wr_4b @0x8c <- 0x00030000 not implemented
>   SDHC rd_4b @0x80 not implemented
>   SDHC wr_4b @0x80 <- 0xc0004100 not implemented
>   SDHC wr_4b @0x84 <- 0x80808080 not implemented
>   [   26.013318] mmc0: SDHCI controller on samsung-hsmmc [12530000.sdhci] using ADMA
>   [   26.032318] Synopsys Designware Multimedia Card Interface Driver
>   [   42.024885] Waiting for root device /dev/mmcblk0...
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  hw/arm/exynos4210.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>

Best regards,
Krzysztof

[PATCH 5/5] tests/boot_linux_console: Add sdcard test for the Exynos4210

[Philippe Mathieu-Daudé]

This test boots a Linux kernel on a smdkc210 board and verify
the serial output is working.

The cpio image used comes from the linux-build-test project:
https://github.com/groeck/linux-build-test

Since this test is not reliable due to clock timing issues,
it is disabled with the 'skip' property.

Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 tests/acceptance/boot_linux_console.py | 47 ++++++++++++++++++++++++++
 1 file changed, 47 insertions(+)

diff --git a/tests/acceptance/boot_linux_console.py b/tests/acceptance/boot_linux_console.py
index 197358a69c..2d0d82b013 100644
--- a/tests/acceptance/boot_linux_console.py
+++ b/tests/acceptance/boot_linux_console.py
@@ -14,6 +14,7 @@ import lzma
 import gzip
 import shutil
 
+from avocado import skip
 from avocado_qemu import Test
 from avocado.utils import process
 from avocado.utils import archive
@@ -359,6 +360,52 @@ class BootLinuxConsole(Test):
         self.wait_for_console_pattern('Boot successful.')
         # TODO user command, for now the uart is stuck
 
+    @skip("unstable clock timings")
+    def test_arm_exynos4210_sdcard(self):
+        """
+        :avocado: tags=arch:arm
+        :avocado: tags=machine:smdkc210
+        """
+        deb_url = ('https://snapshot.debian.org/archive/debian/'
+                   '20190928T224601Z/pool/main/l/linux/'
+                   'linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb')
+        deb_hash = 'fa9df4a0d38936cb50084838f2cb933f570d7d82'
+        deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
+        kernel_path = self.extract_from_deb(deb_path,
+                                            '/boot/vmlinuz-4.19.0-6-armmp')
+        dtb_path = '/usr/lib/linux-image-4.19.0-6-armmp/exynos4210-smdkv310.dtb'
+        dtb_path = self.extract_from_deb(deb_path, dtb_path)
+
+        rootfs_url = ('https://github.com/groeck/linux-build-test/raw/'
+                      '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
+                      'arm/rootfs-armv5.ext2.gz')
+        rootfs_hash = '093e89d2b4d982234bf528bc9fb2f2f17a9d1f93'
+        rootfs_path_gz = self.fetch_asset(rootfs_url, asset_hash=rootfs_hash)
+        rootfs_path = os.path.join(self.workdir, 'rootfs.ext2')
+        gunzip(rootfs_path_gz, rootfs_path)
+
+        self.vm.set_machine('smdkc210')
+        self.vm.set_console(console_id=1)
+        kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
+                               'earlycon=exynos4210,0x13810000 earlyprintk ' +
+                               'console=ttySAC1,115200n8 ' +
+                               'random.trust_cpu=off cryptomgr.notests ' +
+                               'root=/dev/mmcblk0 rootwait rw ' +
+                               'cpuidle.off=1 panic=-1 noreboot')
+
+        self.vm.add_args('-kernel', kernel_path,
+                         '-dtb', dtb_path,
+                         '-append', kernel_command_line,
+                         # The external MMC is on the 3rd slot
+                         '-drive', 'if=sd,driver=null-co',
+                         '-drive', 'if=sd,driver=null-co',
+                         '-drive', 'if=sd,file=' + rootfs_path + ',format=raw',
+                         '-no-reboot')
+        self.vm.launch()
+
+        self.wait_for_console_pattern('Boot successful.')
+        # TODO user command, for now the uart is stuck
+
     def test_s390x_s390_ccw_virtio(self):
         """
         :avocado: tags=arch:s390x
-- 
2.20.1

Re: [PATCH 5/5] tests/boot_linux_console: Add sdcard test for the Exynos4210

[Cleber Rosa]

On Sat, Oct 05, 2019 at 05:47:48PM +0200, Philippe Mathieu-Daudé wrote:
> This test boots a Linux kernel on a smdkc210 board and verify
> the serial output is working.
> 
> The cpio image used comes from the linux-build-test project:
> https://github.com/groeck/linux-build-test
> 
> Since this test is not reliable due to clock timing issues,
> it is disabled with the 'skip' property.
> 
> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  tests/acceptance/boot_linux_console.py | 47 ++++++++++++++++++++++++++
>  1 file changed, 47 insertions(+)
> 
> diff --git a/tests/acceptance/boot_linux_console.py b/tests/acceptance/boot_linux_console.py
> index 197358a69c..2d0d82b013 100644
> --- a/tests/acceptance/boot_linux_console.py
> +++ b/tests/acceptance/boot_linux_console.py
> @@ -14,6 +14,7 @@ import lzma
>  import gzip
>  import shutil
>  
> +from avocado import skip
>  from avocado_qemu import Test
>  from avocado.utils import process
>  from avocado.utils import archive
> @@ -359,6 +360,52 @@ class BootLinuxConsole(Test):
>          self.wait_for_console_pattern('Boot successful.')
>          # TODO user command, for now the uart is stuck
>  
> +    @skip("unstable clock timings")

On the topic of skipping unstable tests, don't you think this is
something that should check for some type of flag?

Just for the sake of brainstorming, other possiblity is to build on
Avocado's "WARN" test status, and instead of failing a test (and
affecting the overall job execution), simply warn the user.  A
decorator such as "@warn_on" could be implemented similar to the
existing "@fail_on" and "@cancel_on".

> +    def test_arm_exynos4210_sdcard(self):
> +        """
> +        :avocado: tags=arch:arm
> +        :avocado: tags=machine:smdkc210
> +        """
> +        deb_url = ('https://snapshot.debian.org/archive/debian/'
> +                   '20190928T224601Z/pool/main/l/linux/'
> +                   'linux-image-4.19.0-6-armmp_4.19.67-2+deb10u1_armhf.deb')
> +        deb_hash = 'fa9df4a0d38936cb50084838f2cb933f570d7d82'
> +        deb_path = self.fetch_asset(deb_url, asset_hash=deb_hash)
> +        kernel_path = self.extract_from_deb(deb_path,
> +                                            '/boot/vmlinuz-4.19.0-6-armmp')
> +        dtb_path = '/usr/lib/linux-image-4.19.0-6-armmp/exynos4210-smdkv310.dtb'
> +        dtb_path = self.extract_from_deb(deb_path, dtb_path)
> +
> +        rootfs_url = ('https://github.com/groeck/linux-build-test/raw/'
> +                      '2eb0a73b5d5a28df3170c546ddaaa9757e1e0848/rootfs/'
> +                      'arm/rootfs-armv5.ext2.gz')
> +        rootfs_hash = '093e89d2b4d982234bf528bc9fb2f2f17a9d1f93'
> +        rootfs_path_gz = self.fetch_asset(rootfs_url, asset_hash=rootfs_hash)
> +        rootfs_path = os.path.join(self.workdir, 'rootfs.ext2')
> +        gunzip(rootfs_path_gz, rootfs_path)

I was going to suggest the same thing as the previous patch, but this
turned out to be quite interesting.  Basically, both compressed and
uncompressed verions of this file seems to disguise themselves pretty
well as a tar file:

 $ tar vtf rootfs-armv5.ext2.gz
 $ gzip -dc rootfs-armv5.ext2.gz | tar vtf -
 $ python3 -m tarfile -l rootfs-armv5.ext2.gz
 $ python3 -m tarfile -l rootfs-armv5.ext2

Even though it is not.  This affects how "avocado.utils.uncompress"
detects the file, and consequently how it tries to uncompress it.
So, here, you could instead use:

  archive.gzip_uncompress(rootfs_path_gz, rootfs_path)

To avoid relying on the broken tar file detection.

- Cleber.

> +
> +        self.vm.set_machine('smdkc210')
> +        self.vm.set_console(console_id=1)
> +        kernel_command_line = (self.KERNEL_COMMON_COMMAND_LINE +
> +                               'earlycon=exynos4210,0x13810000 earlyprintk ' +
> +                               'console=ttySAC1,115200n8 ' +
> +                               'random.trust_cpu=off cryptomgr.notests ' +
> +                               'root=/dev/mmcblk0 rootwait rw ' +
> +                               'cpuidle.off=1 panic=-1 noreboot')
> +
> +        self.vm.add_args('-kernel', kernel_path,
> +                         '-dtb', dtb_path,
> +                         '-append', kernel_command_line,
> +                         # The external MMC is on the 3rd slot
> +                         '-drive', 'if=sd,driver=null-co',
> +                         '-drive', 'if=sd,driver=null-co',
> +                         '-drive', 'if=sd,file=' + rootfs_path + ',format=raw',
> +                         '-no-reboot')
> +        self.vm.launch()
> +
> +        self.wait_for_console_pattern('Boot successful.')
> +        # TODO user command, for now the uart is stuck
> +
>      def test_s390x_s390_ccw_virtio(self):
>          """
>          :avocado: tags=arch:s390x
> -- 
> 2.20.1
> 
> 

Re: [PATCH 0/5] hw/arm/exynos4210: Add acceptance tests to the SMDKC210 board

[Krzysztof Kozlowski]

On Sat, Oct 05, 2019 at 05:47:43PM +0200, Philippe Mathieu-Daudé wrote:
> Hi all,
> 
> Yesterday Peter Maydell asked on IRC if I had any working Exynos4
> image. I looked at some old backuped notes and could boot Guenter
> initrd with BusyBox.
> I'll use this cover letter to share my notes, they might help to
> have this board fully usable again.
> 
> This board is listed as "Odd Fixes". Since we have it covered, I
> thought it was worthwhile to have it covered by tests to avoid
> more regressions.
> 
> Frédéric Basse used this board last year:
> https://fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html
> 
> I'll have a look a these particular commits he added:
> 
> - https://github.com/frederic/qemu-exynos-bootrom/commit/9be5c9f2253dbc04ee
> 
>    sd: add sd clock support to SDHC_CLKCON
> 
> - https://github.com/frederic/qemu-exynos-bootrom/commit/6f045949ee2fdec624
> 
>    sd: always reply to ACMD41 (SD_APP_OP_COND)
> 
> Guenter also carries on this patch:
> 
> - https://github.com/groeck/qemu/commit/0a80543cc910d
> 
>   hw/timer/exynos4210_mct: Initialize timer before starting it
> 
>   When booting a recent Linux kernel, the qemu message "Timer with period
>   zero, disabling" is seen, apparently because a timer is started before
>   being initialized.  Fix the problem by initializing the offending timer
>   before starting it.
> 
> It might also be interesting to use Krzysztof's initramfs image:
> https://github.com/krzk/tools/blob/master/run-qemu.sh#L29

I haven't been working on QEMU since 2 years but I can try to find that
initramfs image.

The recent initramfs I create, is for testing kernel under my Buildbot.
I take standard initramfs from Arch ARM and then I add some more stuff:
Source/instruction is here:
https://github.com/krzk/tools/tree/master/buildbot/initramfs
and the script making it for each boot is here:
https://github.com/krzk/tools/blob/master/buildbot/build-slave-deploy.sh#L50
https://github.com/krzk/tools/blob/master/pi/make-initramfs.sh

Best regards,
Krzysztof


> 
> The 1st test added works fine, however the 2nd (SD card) is not
> reliable so it is disabled. We might need to adapt the ADMA patch
> Igor sent once:
> https://patchwork.ozlabs.org/patch/181854/
> 
> If you want to run the Avocado tests, you need these other patches
> pending review:
> 
> - https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06439.html
>   "tests/boot_linux_console: Extract the gunzip() helper"
> 
> - https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06438.html
>   "python/qemu/machine: Allow to use other serial consoles than default"
>   (only for the 2nd disabled test)
> 
> Regards,
> 
> Phil.
> 
> Based-on: 20190926173428.10713-16-f4bug@amsat.org
> 
> Philippe Mathieu-Daudé (5):
>   tests/boot_linux_console: Add initrd test for the Exynos4210
>   hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions
>   hw/sd/sdhci: Add dummy Samsung SDHCI controller
>   hw/arm/exynos4210: Use the Samsung s3c SDHCI controller
>   tests/boot_linux_console: Add sdcard test for the Exynos4210
> 
>  hw/arm/exynos4210.c                    |  2 +-
>  hw/sd/sdhci.c                          | 68 +++++++++++++++++++-
>  include/hw/sd/sdhci.h                  |  2 +
>  tests/acceptance/boot_linux_console.py | 88 ++++++++++++++++++++++++++
>  4 files changed, 158 insertions(+), 2 deletions(-)
> 
> -- 
> 2.20.1
> 

Re: [PATCH 0/5] hw/arm/exynos4210: Add acceptance tests to the SMDKC210 board

[Krzysztof Kozlowski]

On Mon, Oct 07, 2019 at 11:10:24AM +0200, Krzysztof Kozlowski wrote:
> On Sat, Oct 05, 2019 at 05:47:43PM +0200, Philippe Mathieu-Daudé wrote:
> > Hi all,
> > 
> > Yesterday Peter Maydell asked on IRC if I had any working Exynos4
> > image. I looked at some old backuped notes and could boot Guenter
> > initrd with BusyBox.
> > I'll use this cover letter to share my notes, they might help to
> > have this board fully usable again.
> > 
> > This board is listed as "Odd Fixes". Since we have it covered, I
> > thought it was worthwhile to have it covered by tests to avoid
> > more regressions.
> > 
> > Frédéric Basse used this board last year:
> > https://fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html
> > 
> > I'll have a look a these particular commits he added:
> > 
> > - https://github.com/frederic/qemu-exynos-bootrom/commit/9be5c9f2253dbc04ee
> > 
> >    sd: add sd clock support to SDHC_CLKCON
> > 
> > - https://github.com/frederic/qemu-exynos-bootrom/commit/6f045949ee2fdec624
> > 
> >    sd: always reply to ACMD41 (SD_APP_OP_COND)
> > 
> > Guenter also carries on this patch:
> > 
> > - https://github.com/groeck/qemu/commit/0a80543cc910d
> > 
> >   hw/timer/exynos4210_mct: Initialize timer before starting it
> > 
> >   When booting a recent Linux kernel, the qemu message "Timer with period
> >   zero, disabling" is seen, apparently because a timer is started before
> >   being initialized.  Fix the problem by initializing the offending timer
> >   before starting it.
> > 
> > It might also be interesting to use Krzysztof's initramfs image:
> > https://github.com/krzk/tools/blob/master/run-qemu.sh#L29
> 
> I haven't been working on QEMU since 2 years but I can try to find that
> initramfs image.
> 
> The recent initramfs I create, is for testing kernel under my Buildbot.
> I take standard initramfs from Arch ARM and then I add some more stuff:
> Source/instruction is here:
> https://github.com/krzk/tools/tree/master/buildbot/initramfs
> and the script making it for each boot is here:
> https://github.com/krzk/tools/blob/master/buildbot/build-slave-deploy.sh#L50
> https://github.com/krzk/tools/blob/master/pi/make-initramfs.sh
>

I checked my initramfs. I created it simply from a running Arch ARM
    instance with `fakeroot mkinitcpio -g file.cpio.gz`

You could automatize the process by:
1. Downloading and extracting
   http://os.archlinuxarm.org/os/ArchLinuxARM-odroid-latest.tar.gz,
2. Running mkinitcpio or creating initramfs manually (e.g. my script
   above).

Best regards,
Krzysztof

Re: [PATCH 0/5] hw/arm/exynos4210: Add acceptance tests to the SMDKC210 board

[Philippe Mathieu-Daudé]

Hi Peter,

On 10/5/19 5:47 PM, Philippe Mathieu-Daudé wrote:
> Hi all,
> 
> Yesterday Peter Maydell asked on IRC if I had any working Exynos4
> image. I looked at some old backuped notes and could boot Guenter
> initrd with BusyBox.
> I'll use this cover letter to share my notes, they might help to
> have this board fully usable again.
> 
> This board is listed as "Odd Fixes". Since we have it covered, I
> thought it was worthwhile to have it covered by tests to avoid
> more regressions.
> 
> Frédéric Basse used this board last year:
> https://fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html
> 
> I'll have a look a these particular commits he added:
> 
> - https://github.com/frederic/qemu-exynos-bootrom/commit/9be5c9f2253dbc04ee
> 
>     sd: add sd clock support to SDHC_CLKCON
> 
> - https://github.com/frederic/qemu-exynos-bootrom/commit/6f045949ee2fdec624
> 
>     sd: always reply to ACMD41 (SD_APP_OP_COND)
> 
> Guenter also carries on this patch:
> 
> - https://github.com/groeck/qemu/commit/0a80543cc910d
> 
>    hw/timer/exynos4210_mct: Initialize timer before starting it
> 
>    When booting a recent Linux kernel, the qemu message "Timer with period
>    zero, disabling" is seen, apparently because a timer is started before
>    being initialized.  Fix the problem by initializing the offending timer
>    before starting it.
> 
> It might also be interesting to use Krzysztof's initramfs image:
> https://github.com/krzk/tools/blob/master/run-qemu.sh#L29
> 
> The 1st test added works fine, however the 2nd (SD card) is not
> reliable so it is disabled. We might need to adapt the ADMA patch
> Igor sent once:
> https://patchwork.ozlabs.org/patch/181854/
> 
> If you want to run the Avocado tests, you need these other patches
> pending review:
> 
> - https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06439.html
>    "tests/boot_linux_console: Extract the gunzip() helper"
> 
> - https://lists.gnu.org/archive/html/qemu-devel/2019-09/msg06438.html
>    "python/qemu/machine: Allow to use other serial consoles than default"
>    (only for the 2nd disabled test)
> 
> Regards,
> 
> Phil.
> 
> Based-on: 20190926173428.10713-16-f4bug@amsat.org
> 
> Philippe Mathieu-Daudé (5):
>    tests/boot_linux_console: Add initrd test for the Exynos4210
>    hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions
>    hw/sd/sdhci: Add dummy Samsung SDHCI controller
>    hw/arm/exynos4210: Use the Samsung s3c SDHCI controller
>    tests/boot_linux_console: Add sdcard test for the Exynos4210

Can you take patches 2-4 from this series? (C part, not Python).
All these patches have been reviewed.

Thanks,

Phil.

Re: [PATCH 0/5] hw/arm/exynos4210: Add acceptance tests to the SMDKC210 board

[Peter Maydell]

On Fri, 18 Oct 2019 at 15:48, Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
>
> Hi Peter,
>
> On 10/5/19 5:47 PM, Philippe Mathieu-Daudé wrote:
> > Philippe Mathieu-Daudé (5):
> >    tests/boot_linux_console: Add initrd test for the Exynos4210
> >    hw/sd/sdhci: Add a comment to distinct the i.MX eSDHC functions
> >    hw/sd/sdhci: Add dummy Samsung SDHCI controller
> >    hw/arm/exynos4210: Use the Samsung s3c SDHCI controller
> >    tests/boot_linux_console: Add sdcard test for the Exynos4210
>
> Can you take patches 2-4 from this series? (C part, not Python).
> All these patches have been reviewed.

Sure, I've done that. I assume we'll get the test in via
some other path.

thanks
-- PMM