xtensa: hikey960: Add initial qemu support for Hikey 960 DSP #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add initial support for Hikey 960. Offiacial XAF firmware boots and sends some data to the UART. Not sure if XAF FW completes boot, but code does run. Signed-off-by: John Gunn <jgunn0262@gmail.com>
jgunn0262
changed the title
lgirdwood
approved these changes
Jan 14, 2019
ymdatta
pushed a commit
to ymdatta/qemu
that referenced
this pull request
Jun 2, 2020
This test boots a Linux kernel on a Quadra 800 board and verify the serial is working. Example: $ avocado --show=app,console run -t machine:q800 tests/acceptance/boot_linux_console.py console: ABCFGHIJK console: Linux version 5.2.0-2-m68k (debian-kernel@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-21)) thesofproject#1 Debian 5.2.9-2 (2019-08-21) console: Detected Macintosh model: 35 console: Apple Macintosh Quadra 800 console: Built 1 zonelists, mobility grouping on. Total pages: 32448 console: Kernel command line: printk.time=0 console=ttyS0 vga=off [...] console: Calibrating delay loop... 1236.99 BogoMIPS (lpj=6184960) [...] console: NuBus: Scanning NuBus slots. console: Slot 9: Board resource not found! console: SCSI subsystem initialized console: clocksource: Switched to clocksource via1 [...] console: macfb: framebuffer at 0xf9001000, mapped to 0x(ptrval), size 468k console: macfb: mode is 800x600x8, linelength=800 console: Console: switching to colour frame buffer device 100x37 console: fb0: DAFB frame buffer device console: pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>) console: scc.0: ttyS0 at MMIO 0x50f0c022 (irq = 4, base_baud = 230400) is a Z85c30 ESCC - Serial port console: scc.1: ttyS1 at MMIO 0x50f0c020 (irq = 4, base_baud = 230400) is a Z85c30 ESCC - Serial port console: Non-volatile memory driver v1.3 console: adb: Mac II ADB Driver v1.0 for Unified ADB console: mousedev: PS/2 mouse device common for all mice console: random: fast init done console: Detected ADB keyboard, type <unknown>. console: input: ADB keyboard as /devices/virtual/input/input0 console: input: ADB mouse as /devices/virtual/input/input1 console: rtc-generic rtc-generic: registered as rtc0 console: ledtrig-cpu: registered to indicate activity on CPUs [...] console: rtc-generic rtc-generic: setting system clock to 2019-09-10T16:20:25 UTC (1568132425) console: List of all partitions: console: No filesystem could mount root, tried: JOB TIME : 2.91 s Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Laurent Vivier <laurent@vivier.eu> Tested-by: Cleber Rosa <crosa@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Message-Id: <20190910163430.11326-1-f4bug@amsat.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu> Message-Id: <20191026164546.30020-12-laurent@vivier.eu> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
ymdatta
pushed a commit
to ymdatta/qemu
that referenced
this pull request
Jun 2, 2020
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: $ IGNORE_AVOCADO_CONSOLE_BUG=yes \ 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)) thesofproject#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: 1381000.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)) thesofproject#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> Message-Id: <20191028073441.6448-25-philmd@redhat.com> Reviewed-by: Cleber Rosa <crosa@redhat.com> Tested-by: Cleber Rosa <crosa@redhat.com> [Cleber: removed conditional to skip test] Signed-off-by: Cleber Rosa <crosa@redhat.com>
ymdatta
pushed a commit
to ymdatta/qemu
that referenced
this pull request
Jun 2, 2020
Currently offloads disabled by guest via the VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET command are not preserved on VM migration. Instead all offloads reported by guest features (via VIRTIO_PCI_GUEST_FEATURES) get enabled. What happens is: first the VirtIONet::curr_guest_offloads gets restored and offloads are getting set correctly: #0 qemu_set_offload (nc=0x555556a11400, csum=1, tso4=0, tso6=0, ecn=0, ufo=0) at net/net.c:474 thesofproject#1 virtio_net_apply_guest_offloads (n=0x555557701ca0) at hw/net/virtio-net.c:720 thesofproject#2 virtio_net_post_load_device (opaque=0x555557701ca0, version_id=11) at hw/net/virtio-net.c:2334 thesofproject#3 vmstate_load_state (f=0x5555569dc010, vmsd=0x555556577c80 <vmstate_virtio_net_device>, opaque=0x555557701ca0, version_id=11) at migration/vmstate.c:168 thesofproject#4 virtio_load (vdev=0x555557701ca0, f=0x5555569dc010, version_id=11) at hw/virtio/virtio.c:2197 thesofproject#5 virtio_device_get (f=0x5555569dc010, opaque=0x555557701ca0, size=0, field=0x55555668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036 thesofproject#6 vmstate_load_state (f=0x5555569dc010, vmsd=0x555556577ce0 <vmstate_virtio_net>, opaque=0x555557701ca0, version_id=11) at migration/vmstate.c:143 thesofproject#7 vmstate_load (f=0x5555569dc010, se=0x5555578189e0) at migration/savevm.c:829 thesofproject#8 qemu_loadvm_section_start_full (f=0x5555569dc010, mis=0x5555569eee20) at migration/savevm.c:2211 thesofproject#9 qemu_loadvm_state_main (f=0x5555569dc010, mis=0x5555569eee20) at migration/savevm.c:2395 thesofproject#10 qemu_loadvm_state (f=0x5555569dc010) at migration/savevm.c:2467 thesofproject#11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449 However later on the features are getting restored, and offloads get reset to everything supported by features: #0 qemu_set_offload (nc=0x555556a11400, csum=1, tso4=1, tso6=1, ecn=0, ufo=0) at net/net.c:474 thesofproject#1 virtio_net_apply_guest_offloads (n=0x555557701ca0) at hw/net/virtio-net.c:720 thesofproject#2 virtio_net_set_features (vdev=0x555557701ca0, features=5104441767) at hw/net/virtio-net.c:773 thesofproject#3 virtio_set_features_nocheck (vdev=0x555557701ca0, val=5104441767) at hw/virtio/virtio.c:2052 thesofproject#4 virtio_load (vdev=0x555557701ca0, f=0x5555569dc010, version_id=11) at hw/virtio/virtio.c:2220 thesofproject#5 virtio_device_get (f=0x5555569dc010, opaque=0x555557701ca0, size=0, field=0x55555668cd00 <__compound_literal.5>) at hw/virtio/virtio.c:2036 thesofproject#6 vmstate_load_state (f=0x5555569dc010, vmsd=0x555556577ce0 <vmstate_virtio_net>, opaque=0x555557701ca0, version_id=11) at migration/vmstate.c:143 thesofproject#7 vmstate_load (f=0x5555569dc010, se=0x5555578189e0) at migration/savevm.c:829 thesofproject#8 qemu_loadvm_section_start_full (f=0x5555569dc010, mis=0x5555569eee20) at migration/savevm.c:2211 thesofproject#9 qemu_loadvm_state_main (f=0x5555569dc010, mis=0x5555569eee20) at migration/savevm.c:2395 thesofproject#10 qemu_loadvm_state (f=0x5555569dc010) at migration/savevm.c:2467 thesofproject#11 process_incoming_migration_co (opaque=0x0) at migration/migration.c:449 Fix this by preserving the state in saved_guest_offloads field and pushing out offload initialization to the new post load hook. Cc: qemu-stable@nongnu.org Signed-off-by: Mikhail Sennikovsky <mikhail.sennikovskii@cloud.ionos.com> Signed-off-by: Jason Wang <jasowang@redhat.com>
ymdatta
pushed a commit
to ymdatta/qemu
that referenced
this pull request
Jun 2, 2020
Guests can crash QEMU when writting to PnP registers: $ echo 'writeb 0x800ff042 69' | qemu-system-sparc -M leon3_generic -S -bios /etc/magic -qtest stdio [I 1571938309.932255] OPENED [R +0.063474] writeb 0x800ff042 69 Segmentation fault (core dumped) (gdb) bt #0 0x0000000000000000 in () thesofproject#1 0x0000555f4bcdf0bc in memory_region_write_with_attrs_accessor (mr=0x555f4d7be8c0, addr=66, value=0x7fff07d00f08, size=1, shift=0, mask=255, attrs=...) at memory.c:503 thesofproject#2 0x0000555f4bcdf185 in access_with_adjusted_size (addr=66, value=0x7fff07d00f08, size=1, access_size_min=1, access_size_max=4, access_fn=0x555f4bcdeff4 <memory_region_write_with_attrs_accessor>, mr=0x555f4d7be8c0, attrs=...) at memory.c:539 thesofproject#3 0x0000555f4bce2243 in memory_region_dispatch_write (mr=0x555f4d7be8c0, addr=66, data=69, op=MO_8, attrs=...) at memory.c:1489 thesofproject#4 0x0000555f4bc80b20 in flatview_write_continue (fv=0x555f4d92c400, addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, addr1=66, l=1, mr=0x555f4d7be8c0) at exec.c:3161 thesofproject#5 0x0000555f4bc80c65 in flatview_write (fv=0x555f4d92c400, addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3201 thesofproject#6 0x0000555f4bc80fb0 in address_space_write (as=0x555f4d7aa460, addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1) at exec.c:3291 thesofproject#7 0x0000555f4bc8101d in address_space_rw (as=0x555f4d7aa460, addr=2148528194, attrs=..., buf=0x7fff07d01120 "E", len=1, is_write=true) at exec.c:3301 thesofproject#8 0x0000555f4bcdb388 in qtest_process_command (chr=0x555f4c2ed7e0 <qtest_chr>, words=0x555f4db0c5d0) at qtest.c:432 Instead of crashing, log the access as unimplemented. Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com> Message-Id: <20191025110114.27091-2-philmd@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add initial support for Hikey 960. Official XAF firmware boots and
sends some data to the UART. Not sure if XAF FW completes boot, but code
does run.
Signed-off-by: John Gunn jgunn0262@gmail.com