e33ee3097f
The kernel image and DeviceTree blob are built by the Armbian project (based on Debian): https://docs.armbian.com/Developer-Guide_Build-Preparation/ 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. Alternatively, this test can be run using: $ avocado --show=console run -t machine:cubieboard tests/acceptance/boot_linux_console.py console: Uncompressing Linux... done, booting the kernel. console: Booting Linux on physical CPU 0x0 console: Linux version 4.20.7-sunxi (root@armbian.com) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #5.75 SMP Fri Feb 8 09:02:10 CET 2019 [...] console: ahci-sunxi 1c18000.sata: Linked as a consumer to regulator.4 console: ahci-sunxi 1c18000.sata: controller can't do 64bit DMA, forcing 32bit console: ahci-sunxi 1c18000.sata: AHCI 0001.0000 32 slots 1 ports 1.5 Gbps 0x1 impl platform mode console: ahci-sunxi 1c18000.sata: flags: ncq only console: scsi host0: ahci-sunxi console: ata1: SATA max UDMA/133 mmio [mem 0x01c18000-0x01c18fff] port 0x100 irq 27 console: of_cfs_init console: of_cfs_init: OK console: vcc3v0: disabling console: vcc5v0: disabling console: usb1-vbus: disabling console: usb2-vbus: disabling console: ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) console: ata1.00: ATA-7: QEMU HARDDISK, 2.5+, max UDMA/100 console: ata1.00: 40960 sectors, multi 16: LBA48 NCQ (depth 32) console: ata1.00: applying bridge limits console: ata1.00: configured for UDMA/100 console: scsi 0:0:0:0: Direct-Access ATA QEMU HARDDISK 2.5+ PQ: 0 ANSI: 5 console: sd 0:0:0:0: Attached scsi generic sg0 type 0 console: sd 0:0:0:0: [sda] 40960 512-byte logical blocks: (21.0 MB/20.0 MiB) console: sd 0:0:0:0: [sda] Write Protect is off console: sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA console: sd 0:0:0:0: [sda] Attached SCSI disk console: EXT4-fs (sda): mounting ext2 file system using the ext4 subsystem console: EXT4-fs (sda): mounted filesystem without journal. Opts: (null) console: VFS: Mounted root (ext2 filesystem) readonly on device 8:0. [...] console: cat /proc/partitions console: / # cat /proc/partitions console: major minor #blocks name console: 1 0 4096 ram0 console: 1 1 4096 ram1 console: 1 2 4096 ram2 console: 1 3 4096 ram3 console: 8 0 20480 sda console: reboot console: / # reboot [...] console: sd 0:0:0:0: [sda] Synchronizing SCSI cache console: reboot: Restarting system PASS (48.39 s) Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20191230110953.25496-3-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> |
||
---|---|---|
.. | ||
avocado_qemu | ||
boot_linux_console.py | ||
cpu_queries.py | ||
empty_cpu_model.py | ||
linux_initrd.py | ||
linux_ssh_mips_malta.py | ||
machine_m68k_nextcube.py | ||
machine_sparc_leon3.py | ||
migration.py | ||
pc_cpu_hotplug_props.py | ||
ppc_prep_40p.py | ||
README.rst | ||
version.py | ||
virtio_seg_max_adjust.py | ||
virtio_version.py | ||
vnc.py | ||
x86_cpu_model_versions.py |
============================================ Acceptance tests using the Avocado Framework ============================================ This directory contains functional tests, also known as acceptance level tests. They're usually higher level, and may interact with external resources and with various guest operating systems. For more information, please refer to ``docs/devel/testing.rst``, section "Acceptance tests using the Avocado Framework".