aboutsummaryrefslogtreecommitdiff
path: root/hw
AgeCommit message (Collapse)Author
2021-01-08hw/arm: sabrelite: Connect the Ethernet PHY at address 6Bin Meng
At present, when booting U-Boot on QEMU sabrelite, we see: Net: Board Net Initialization Failed No ethernet found. U-Boot scans PHY at address 4/5/6/7 (see board_eth_init() in the U-Boot source: board/boundary/nitrogen6x/nitrogen6x.c). On the real board, the Ethernet PHY is at address 6. Adjust this by updating the "fec-phy-num" property of the fsl_imx6 SoC object. With this change, U-Boot sees the PHY but complains MAC address: Net: using phy at 6 FEC [PRIME] Error: FEC address not set. This is due to U-Boot tries to read the MAC address from the fuse, which QEMU does not have any valid content filled in. However this does not prevent the Ethernet from working in QEMU. We just need to set up the MAC address later in the U-Boot command shell, by: => setenv ethaddr 00:11:22:33:44:55 Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20210106063504.10841-4-bmeng.cn@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08hw/msic: imx6_ccm: Correct register value for silicon typeBin Meng
Currently when U-Boot boots, it prints "??" for i.MX processor: CPU: Freescale i.MX?? rev1.0 at 792 MHz The register that was used to determine the silicon type is undocumented in the latest IMX6DQRM (Rev. 6, 05/2020), but we can refer to get_cpu_rev() in arch/arm/mach-imx/mx6/soc.c in the U-Boot source codes that USB_ANALOG_DIGPROG is used. Update its reset value to indicate i.MX6Q. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20210106063504.10841-3-bmeng.cn@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08hw/misc: imx6_ccm: Update PMU_MISC0 reset valueBin Meng
U-Boot expects PMU_MISC0 register bit 7 is set (see init_bandgap() in arch/arm/mach-imx/mx6/soc.c) during boot. This bit indicates the bandgap has stabilized. With this change, the latest upstream U-Boot (v2021.01-rc3) for imx6 sabrelite board (mx6qsabrelite_defconfig), with a slight change made by switching CONFIG_OF_SEPARATE to CONFIG_OF_EMBED, boots to U-Boot shell on QEMU with the following command: $ qemu-system-arm -M sabrelite -smp 4 -m 1G -kernel u-boot \ -display none -serial null -serial stdio Boot log below: U-Boot 2021.01-rc3 (Dec 12 2020 - 17:40:02 +0800) CPU: Freescale i.MX?? rev1.0 at 792 MHz Reset cause: POR Model: Freescale i.MX6 Quad SABRE Lite Board Board: SABRE Lite I2C: ready DRAM: 1 GiB force_idle_bus: sda=0 scl=0 sda.gp=0x5c scl.gp=0x55 force_idle_bus: failed to clear bus, sda=0 scl=0 force_idle_bus: sda=0 scl=0 sda.gp=0x6d scl.gp=0x6c force_idle_bus: failed to clear bus, sda=0 scl=0 force_idle_bus: sda=0 scl=0 sda.gp=0xcb scl.gp=0x5 force_idle_bus: failed to clear bus, sda=0 scl=0 MMC: FSL_SDHC: 0, FSL_SDHC: 1 Loading Environment from MMC... *** Warning - No block device, using default environment In: serial Out: serial Err: serial Net: Board Net Initialization Failed No ethernet found. starting USB... Bus usb@2184000: usb dr_mode not found USB EHCI 1.00 Bus usb@2184200: USB EHCI 1.00 scanning bus usb@2184000 for devices... 1 USB Device(s) found scanning bus usb@2184200 for devices... 1 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found Hit any key to stop autoboot: 0 => Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20210106063504.10841-2-bmeng.cn@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08exynos4210_mct: Use ptimer_free() in the finalize function to avoid memleaksGan Qixin
When running device-introspect-test, a memory leak occurred in the exynos4210_mct_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 #3 0xaaabf56b01a0 in exynos4210_mct_init /qemu/hw/timer/exynos4210_mct.c:1505 #4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 #9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 #10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164 #11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381 #12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08musicpal: Use ptimer_free() in the finalize function to avoid memleaksGan Qixin
When running device-introspect-test, a memory leak occurred in the mv88w8618_pit_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 192 byte(s) in 4 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 #3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 #4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 #5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 #6 0xaaabf5bb2290 in mv88w8618_timer_init /qemu/hw/arm/musicpal.c:862 #7 0xaaabf5bb2290 in mv88w8618_pit_init /qemu/hw/arm/musicpal.c:954 #8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #11 0xaaabf5a95540 in qdev_device_help /qemu/softmmu/qdev-monitor.c:283 #12 0xaaabf5a96940 in qmp_device_add /qemu/softmmu/qdev-monitor.c:801 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08mss-timer: Use ptimer_free() in the finalize function to avoid memleaksGan Qixin
When running device-introspect-test, a memory leak occurred in the mss_timer_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 192 byte(s) in 2 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 #3 0xaaabf58a0010 in mss_timer_init /qemu/hw/timer/mss-timer.c:235 #4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 #6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 #7 0xaaabf5b8316c in m2sxxx_soc_initfn /qemu/hw/arm/msf2-soc.c:70 #8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08exynos4210_pwm: Use ptimer_free() in the finalize function to avoid memleaksGan Qixin
When running device-introspect-test, a memory leak occurred in the exynos4210_pwm_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 240 byte(s) in 5 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 #3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 #4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 #5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 #6 0xaaabf56a36cc in exynos4210_pwm_init /qemu/hw/timer/exynos4210_pwm.c:401 #7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #8 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #9 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #10 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #11 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 #12 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08exynos4210_rtc: Use ptimer_free() in the finalize function to avoid memleaksGan Qixin
When running device-introspect-test, a memory leak occurred in the exynos4210_rtc_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 96 byte(s) in 1 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 #3 0xaaabf57b3934 in exynos4210_rtc_init /qemu/hw/rtc/exynos4210_rtc.c:567 #4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #5 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #6 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #7 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #8 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 #9 0xaaabf6552708 in aio_bh_call /qemu/util/async.c:136 #10 0xaaabf6552708 in aio_bh_poll /qemu/util/async.c:164 #11 0xaaabf655f19c in aio_dispatch /qemu/util/aio-posix.c:381 #12 0xaaabf65523f4 in aio_ctx_dispatch /qemu/util/async.c:306 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08allwinner-a10-pit: Use ptimer_free() in the finalize function to avoid memleaksGan Qixin
When running device-introspect-test, a memory leak occurred in the a10_pit_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 288 byte(s) in 6 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db84 in timer_new_full /qemu/include/qemu/timer.h:523 #3 0xaaabf555db84 in timer_new /qemu/include/qemu/timer.h:544 #4 0xaaabf555db84 in timer_new_ns /qemu/include/qemu/timer.h:562 #5 0xaaabf555db84 in ptimer_init /qemu/hw/core/ptimer.c:433 #6 0xaaabf57415e8 in a10_pit_init /qemu/hw/timer/allwinner-a10-pit.c:278 #7 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #8 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 #9 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 #10 0xaaabf5b94680 in aw_a10_init /qemu/hw/arm/allwinner-a10.c:49 #11 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #12 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08digic-timer: Use ptimer_free() in the finalize function to avoid memleaksGan Qixin
When running device-introspect-test, a memory leak occurred in the digic_timer_init function, so use ptimer_free() in the finalize function to avoid it. ASAN shows memory leak stack: Indirect leak of 288 byte(s) in 3 object(s) allocated from: #0 0xffffab97e1f0 in __interceptor_calloc (/lib64/libasan.so.5+0xee1f0) #1 0xffffab256800 in g_malloc0 (/lib64/libglib-2.0.so.0+0x56800) #2 0xaaabf555db78 in ptimer_init /qemu/hw/core/ptimer.c:432 #3 0xaaabf5b04084 in digic_timer_init /qemu/hw/timer/digic-timer.c:142 #4 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #5 0xaaabf633ca04 in object_initialize_child_with_propsv /qemu/qom/object.c:564 #6 0xaaabf633cc08 in object_initialize_child_with_props /qemu/qom/object.c:547 #7 0xaaabf5b40e84 in digic_init /qemu/hw/arm/digic.c:46 #8 0xaaabf6339f6c in object_initialize_with_type /qemu/qom/object.c:515 #9 0xaaabf633a1e0 in object_new_with_type /qemu/qom/object.c:729 #10 0xaaabf6375e40 in qmp_device_list_properties /qemu/qom/qom-qmp-cmds.c:153 #11 0xaaabf653d8ec in qmp_marshal_device_list_properties /qemu/qapi/qapi-commands-qdev.c:59 #12 0xaaabf6587d08 in do_qmp_dispatch_bh /qemu/qapi/qmp-dispatch.c:110 Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Gan Qixin <ganqixin@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08Remove superfluous timer_del() callsPeter Maydell
This commit is the result of running the timer-del-timer-free.cocci script on the whole source tree. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20201215154107.3255-4-peter.maydell@linaro.org
2021-01-08hw/arm/highbank: Drop dead KVM support codePeter Maydell
Support for running KVM on 32-bit Arm hosts was removed in commit 82bf7ae84ce739e. You can still run a 32-bit guest on a 64-bit Arm host CPU, but because Arm KVM requires the host and guest CPU types to match, it is not possible to run a guest that requires a Cortex-A9 or Cortex-A15 CPU there. That means that the code in the highbank/midway board models to support KVM is no longer used, and we can delete it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20201215144215.28482-1-peter.maydell@linaro.org
2021-01-08hw/intc/armv7m_nvic: Correct handling of CCR.BFHFNMIGNPeter Maydell
The CCR is a register most of whose bits are banked between security states but where BFHFNMIGN is not, and we keep it in the non-secure entry of the v7m.ccr[] array. The logic which tries to handle this bit fails to implement the "RAZ/WI from Nonsecure if AIRCR.BFHFNMINS is zero" requirement; correct the omission. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20201210201433.26262-2-peter.maydell@linaro.org
2021-01-08hw/arm/virt: Remove virt machine state 'smp_cpus'Andrew Jones
virt machine's 'smp_cpus' and machine->smp.cpus must always have the same value. And, anywhere we have virt machine state we have machine state. So let's remove the redundancy. Also, to make it easier to see that machine->smp is the true source for "smp_cpus" and "max_cpus", avoid passing them in function parameters, preferring instead to get them from the state. No functional change intended. Signed-off-by: Andrew Jones <drjones@redhat.com> Reviewed-by: David Edmondson <david.edmondson@oracle.com> Reviewed-by: Ying Fang <fangying1@huawei.com> Message-id: 20201215174815.51520-1-drjones@redhat.com [PMM: minor formatting tweak to smp_cpus variable declaration] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-08intc/arm_gic: Fix gic_irq_signaling_enabled() for vCPUsEdgar E. Iglesias
Correct the indexing into s->cpu_ctlr for vCPUs. Signed-off-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Luc Michel <luc.michel@greensocs.com> Message-id: 20201214222154.3480243-2-edgar.iglesias@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-06Merge remote-tracking branch 'remotes/bonzini-gitlab/tags/for-upstream' into ↵Peter Maydell
staging From Alex's pull request: * improve cross-build KVM coverage * new --without-default-features configure flag * add __repr__ for ConsoleSocket for debugging * build tcg tests with -Werror * test 32 bit builds with fedora * remove last traces of debian9 * hotfix for centos8 powertools repo * Move lots of feature detection code to meson (Alex, myself) * CFI and LTO support (Daniele) * test-char dangling pointer (Eduardo) * Build system and win32 fixes (Marc-André) * Initialization fixes (myself) * TCG include cleanup (Richard, myself) * x86 'int N' fix (Peter) # gpg: Signature made Wed 06 Jan 2021 09:21:25 GMT # gpg: using RSA key F13338574B662389866C7682BFFBD25F78C7AE83 # gpg: issuer "pbonzini@redhat.com" # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini-gitlab/tags/for-upstream: (52 commits) win32: drop fd registration to the main-loop on setting non-block configure: move tests/qemu-iotests/common.env generation to meson meson.build: convert --with-default-devices to meson libattr: convert to meson cap_ng: convert to meson virtfs: convert to meson seccomp: convert to meson zstd: convert to meson lzfse: convert to meson snappy: convert to meson lzo: convert to meson rbd: convert to meson libnfs: convert to meson libiscsi: convert to meson bzip2: convert to meson glusterfs: convert to meson curl: convert to meson curl: remove compatibility code, require 7.29.0 brlapi: convert to meson configure: remove CONFIG_FILEVERSION and CONFIG_PRODUCTVERSION ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # trace/meson.build
2021-01-06Merge remote-tracking branch 'remotes/mcayland/tags/qemu-sparc-20210106' ↵Peter Maydell
into staging qemu-sparc queue # gpg: Signature made Wed 06 Jan 2021 11:43:02 GMT # gpg: using RSA key CC621AB98E82200D915CC9C45BC2C56FAE0F321F # gpg: issuer "mark.cave-ayland@ilande.co.uk" # gpg: Good signature from "Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>" [full] # Primary key fingerprint: CC62 1AB9 8E82 200D 915C C9C4 5BC2 C56F AE0F 321F * remotes/mcayland/tags/qemu-sparc-20210106: sun4m: don't connect two qemu_irqs directly to the same input include/hw/sparc/grlib.h: Remove unused set_pil_in_fn typedef hw/sparc: Make grlib-irqmp device handle its own inbound IRQ lines hw/timer/slavio_timer: Allow 64-bit accesses Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-06sun4m: don't connect two qemu_irqs directly to the same inputMark Cave-Ayland
The sun4m board code connects both of the IRQ outputs of each ESCC to the same slavio input qemu_irq. Connecting two qemu_irqs outputs directly to the same input is not valid as it produces subtly wrong behaviour (for instance if both the IRQ lines are high, and then one goes low, the PIC input will see this as a high-to-low transition even though the second IRQ line should still be holding it high). This kind of wiring needs an explicitly created OR gate; add one. Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> Message-Id: <20201219111934.5540-1-mark.cave-ayland@ilande.co.uk> Reviewed-by: Artyom Tarasenko <atar4qemu@gmail.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-01-06hw/sparc: Make grlib-irqmp device handle its own inbound IRQ linesPeter Maydell
Currently the GRLIB_IRQMP device is used in one place (the leon3 board), but instead of the device providing inbound gpio lines for the board to wire up, the board code itself calls qemu_allocate_irqs() with the handler function being a set_irq function defined in the code for the device. Refactor this into the standard setup of a device having input gpio lines. This fixes a trivial Coverity memory leak report (the leon3 board code leaks the IRQ array returned from qemu_allocate_irqs()). Fixes: Coverity CID 1421922 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20201212144134.29594-2-peter.maydell@linaro.org> Reviewed-by: KONRAD Frederic <frederic.konrad@adacore.com> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-01-06hw/timer/slavio_timer: Allow 64-bit accessesPhilippe Mathieu-Daudé
Per the "NCR89C105 Chip Specification" referenced in the header: Chip-level Address Map ------------------------------------------------------------------ | 1D0 0000 -> | Counter/Timers | W,D | | 1DF FFFF | | | ... The address map indicated the allowed accesses at each address. [...] W indicates a word access, and D indicates a double-word access. The SLAVIO timer controller is implemented expecting 32-bit accesses. Commit a3d12d073e1 restricted the memory accesses to 32-bit, while the device allows 64-bit accesses. This was not an issue until commit 5d971f9e67 which reverted ("memory: accept mismatching sizes in memory_region_access_valid"). Fix by renaming .valid MemoryRegionOps as .impl, and add the valid access range (W -> 4, D -> 8). Since commit 21786c7e598 ("memory: Log invalid memory accesses") this class of bug can be quickly debugged displaying 'guest_errors' accesses, as: $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -serial stdio -d guest_errors Power-ON Reset Invalid access at addr 0x0, size 8, region 'timer-1', reason: invalid size (min:4 max:4) $ qemu-system-sparc -M SS-20 -m 256 -bios ss20_v2.25_rom -monitor stdio -S (qemu) info mtree address-space: memory 0000000000000000-ffffffffffffffff (prio 0, i/o): system ... 0000000ff1300000-0000000ff130000f (prio 0, i/o): timer-1 ^^^^^^^^^ ^^^^^^^ \ memory region base address and name / (qemu) info qtree bus: main-system-bus dev: slavio_timer, id "" <-- device type name gpio-out "sysbus-irq" 17 num_cpus = 1 (0x1) mmio 0000000ff1310000/0000000000000014 mmio 0000000ff1300000/0000000000000010 <--- base address mmio 0000000ff1301000/0000000000000010 mmio 0000000ff1302000/0000000000000010 ... Reported-by: Yap KV <yapkv@yahoo.com> Buglink: https://bugs.launchpad.net/bugs/1906905 Fixes: a3d12d073e1 ("slavio_timer: convert to memory API") CC: qemu-stable@nongnu.org Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201205150903.3062711-1-f4bug@amsat.org> Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
2021-01-06Merge remote-tracking branch 'remotes/dg-gitlab/tags/ppc-for-6.0-20210106' ↵Peter Maydell
into staging ppc patch queue 2021-01-06 First pull request for 2021, which has a bunch of things accumulated over the holidays. Includes: * A number of cleanups to sam460ex and ppc440 code from BALATON Zoltan * Several fixes for builds with --without-default-devices from Greg Kurz * Fixes for some DRC reset problems from Greg Kurz * QOM conversion of the PPC 4xx UIC devices from Peter Maydell * Some other assorted fixes and cleanups # gpg: Signature made Wed 06 Jan 2021 03:33:19 GMT # gpg: using RSA key 75F46586AE61A66CC44E87DC6C38CACA20D9B392 # gpg: Good signature from "David Gibson <david@gibson.dropbear.id.au>" [full] # gpg: aka "David Gibson (Red Hat) <dgibson@redhat.com>" [full] # gpg: aka "David Gibson (ozlabs.org) <dgibson@ozlabs.org>" [full] # gpg: aka "David Gibson (kernel.org) <dwg@kernel.org>" [unknown] # Primary key fingerprint: 75F4 6586 AE61 A66C C44E 87DC 6C38 CACA 20D9 B392 * remotes/dg-gitlab/tags/ppc-for-6.0-20210106: (22 commits) ppc440_pcix: Fix up pci config access ppc440_pcix: Fix register write trace event ppc440_pcix: Improve comment for IRQ mapping sam460ex: Remove FDT_PPC dependency from KConfig ppc4xx: Move common dependency on serial to common option pnv: Fix reverse dependency on PCI express root ports ppc: Simplify reverse dependencies of POWERNV and PSERIES on XICS and XIVE ppc: Fix build with --without-default-devices spapr: Add drc_ prefix to the DRC realize and unrealize functions spapr: Use spapr_drc_reset_all() at machine reset spapr: Introduce spapr_drc_reset_all() spapr: Fix reset of transient DR connectors spapr: Call spapr_drc_reset() for all DRCs at CAS spapr: Fix buffer overflow in spapr_numa_associativity_init() spapr: Allow memory unplug to always succeed spapr: Fix DR properties of the root node spapr/xive: Make spapr_xive_pic_print_info() static spapr: DRC lookup cannot fail hw/ppc/ppc440_bamboo: Drop use of ppcuic_init() hw/ppc/virtex_ml507: Drop use of ppcuic_init() ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-01-06ppc440_pcix: Fix up pci config accessBALATON Zoltan via
This fixes a long standing issue with MorphOS booting on sam460ex which turns out to be because of suspicious values written to PCI config address that apparently works on real machine but caused wrong access on this device model. This replaces a previous work around for this with a better fix that makes it work. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <6fd215ab2bc5f8d4455cd20ed1a2f059e4415fe5.1609636173.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06ppc440_pcix: Fix register write trace eventBALATON Zoltan via
The trace event for pci_host_config_write() was also using the trace event for read. Add corresponding trace and correct this. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <a6c7dcf7153cc537123ed8ceac060f2f64a883cb.1609636173.git.balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06ppc440_pcix: Improve comment for IRQ mappingBALATON Zoltan via
The code mapping all PCI interrupts to a single CPU IRQ works but is not trivial so document it in a comment. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <c25c0310510672b58466e795fd701e65e8f1ff97.1609636173.git.balaton@eik.bme.hu> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06sam460ex: Remove FDT_PPC dependency from KConfigBALATON Zoltan via
Dependency on FDT_PPC was added in commit b0048f76095 ("hw/ppc/Kconfig: Only select FDT helper for machines using it") but it does not seem to be really necessary so remove it again. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <7461a20b129a912aeacdb9ad115a55f0b84c8726.1609636173.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06ppc4xx: Move common dependency on serial to common optionBALATON Zoltan via
All machines that select SERIAL also select PPC4XX so we can just add this common dependency there once. Signed-off-by: BALATON Zoltan <balaton@eik.bme.hu> Message-Id: <94f1eb7cfb7f315bd883d825f3ce7e0cfc2f2b69.1609636173.git.balaton@eik.bme.hu> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06pnv: Fix reverse dependency on PCI express root portsGreg Kurz
qemu-system-ppc64 built with --without-default-devices crashes: Type 'pnv-phb4-root-port' is missing its parent 'pcie-root-port-base' Aborted (core dumped) Have POWERNV to select PCIE_PORT. This is done through a new PCI_POWERNV config in hw/pci-host/Kconfig since POWERNV doesn't have a direct dependency on PCI. For this reason, PCI_EXPRESS and MSI_NONBROKEN are also moved under PCI_POWERNV. Signed-off-by: Greg Kurz <groug@kaod.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <160883058299.253005.342913177952681375.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06ppc: Simplify reverse dependencies of POWERNV and PSERIES on XICS and XIVEGreg Kurz
Have PSERIES to select XICS and XIVE, and directly check PSERIES in hw/intc/meson.build to enable build of the XICS and XIVE sPAPR backends, like POWERNV already does. This allows to get rid of the intermediate XICS_SPAPR and XIVE_SPAPR. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <160883057560.253005.4206568349917633920.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06ppc: Fix build with --without-default-devicesGreg Kurz
Linking of the qemu-system-ppc64 fails on a POWER9 host when --without-default-devices is passed to configure: $ ./configure --without-default-devices \ --target-list=ppc64-softmmu && make ... libqemu-ppc64-softmmu.fa.p/hw_ppc_e500.c.o: In function `ppce500_init_mpic_kvm': /home/greg/Work/qemu/qemu-ppc/build/../hw/ppc/e500.c:777: undefined reference to `kvm_openpic_connect_vcpu' libqemu-ppc64-softmmu.fa.p/hw_ppc_spapr_irq.c.o: In function `spapr_irq_check': /home/greg/Work/qemu/qemu-ppc/build/../hw/ppc/spapr_irq.c:189: undefined reference to `xics_kvm_has_broken_disconnect' libqemu-ppc64-softmmu.fa.p/hw_intc_spapr_xive.c.o: In function `spapr_xive_post_load': /home/greg/Work/qemu/qemu-ppc/build/../hw/intc/spapr_xive.c:530: undefined reference to `kvmppc_xive_post_load' ... and tons of other symbols belonging to the KVM backend of the openpic, XICS and XIVE interrupt controllers. It turns out that OPENPIC_KVM, XICS_KVM and XIVE_KVM are marked to depend on KVM but this has no effect when minikconf runs in allnoconfig mode. Such reverse dependencies should rather be handled with a 'select' statement, eg. config OPENPIC select OPENPIC_KVM if KVM or even better by getting rid of the intermediate _KVM config and directly checking CONFIG_KVM in the meson.build file: specific_ss.add(when: ['CONFIG_KVM', 'CONFIG_OPENPIC'], if_true: files('openpic_kvm.c')) Go for the latter with OPENPIC, XICS and XIVE. This went unnoticed so far because CI doesn't test the build with --without-default-devices and KVM enabled on a POWER host. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <160883056791.253005.14924294027763955653.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr: Add drc_ prefix to the DRC realize and unrealize functionsGreg Kurz
Use a less generic name for an easier experience with tools such as cscope or grep. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20201218103400.689660-6-groug@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr: Use spapr_drc_reset_all() at machine resetGreg Kurz
Documentation of object_child_foreach_recursive() clearly stipulates that "it is forbidden to add or remove children from @obj from the @fn callback". But this is exactly what we do during machine reset. The call to spapr_drc_reset() can finalize the hot-unplug sequence of a PHB or a PCI bridge, both of which will then in turn destroy their PCI DRCs. This could potentially invalidate the iterator used by do_object_child_foreach(). It is pure luck that this haven't caused any issues so far. Use spapr_drc_reset_all() since it can cope with DRC removal. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20201218103400.689660-5-groug@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr: Introduce spapr_drc_reset_all()Greg Kurz
No need to expose the way DRCs are traversed outside of spapr_drc.c. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20201218103400.689660-4-groug@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr: Fix reset of transient DR connectorsGreg Kurz
Documentation of object_property_iter_init() clearly stipulates that "it is forbidden to modify the property list while iterating". But this is exactly what we do when resetting transient DR connectors during CAS. The call to spapr_drc_reset() can finalize the hot-unplug sequence of a PHB or a PCI bridge, both of which will then in turn destroy their PCI DRCs. This could potentially invalidate the iterator. It is pure luck that this haven't caused any issues so far. Change spapr_drc_reset() to return true if it caused a device to be removed. Restart from scratch in this case. This can potentially increase the overall DRC reset time, especially with a high maxmem which generates a lot of LMB DRCs. But this kind of setup is rare, and so is the use case of rebooting a guest while doing hot-unplug. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20201218103400.689660-3-groug@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr: Call spapr_drc_reset() for all DRCs at CASGreg Kurz
Non-transient DRCs are either in the empty or the ready state, which means spapr_drc_reset() doesn't change their state. It is thus not needed to do any checking. Call spapr_drc_reset() unconditionally and squash spapr_drc_transient() into its only user, spapr_drc_needed(). Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <20201218103400.689660-2-groug@kaod.org> Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com> Tested-by: Daniel Henrique Barboza <danielhb413@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr: Allow memory unplug to always succeedGreg Kurz
It is currently impossible to hot-unplug a memory device between machine reset and CAS. (qemu) device_del dimm1 Error: Memory hot unplug not supported for this guest This limitation was introduced in order to provide an explicit error path for older guests that didn't support hot-plug event sources (and thus memory hot-unplug). The linux kernel has been supporting these since 4.11. All recent enough guests are thus capable of handling the removal of a memory device at all time, including during early boot. Lift the limitation for the latest machine type. This means that trying to unplug memory from a guest that doesn't support it will likely just do nothing and the memory will only get removed at next reboot. Such older guests can still get the existing behavior by using an older machine type. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <160794035064.23292.17560963281911312439.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr: Fix DR properties of the root nodeGreg Kurz
Section 13.5.2 of LoPAPR mandates various DR related indentifiers for all hot-pluggable entities to be exposed in the "ibm,drc-indexes", "ibm,drc-power-domains", "ibm,drc-names" and "ibm,drc-types" properties of their parent node. These properties are created with spapr_dt_drc(). PHBs and LMBs are both children of the machine. Their DR identifiers are thus supposed to be exposed in the afore mentioned properties of the root node. When PHB hot-plug support was added, an extra call to spapr_dt_drc() was introduced: this overwrites the existing properties, previously populated with the LMB identifiers, and they end up containing only PHB identifiers. This went unseen so far because linux doesn't care, but this is still not conformant with LoPAPR. Fortunately spapr_dt_drc() is able to handle multiple DR entity types at the same time. Use that to handle DR indentifiers for PHBs and LMBs with a single call to spapr_dt_drc(). While here also account for PMEM DR identifiers, which were forgotten when NVDIMM hot-plug support was added. Also add an assert to prevent further misuse of spapr_dt_drc(). With -m 1G,maxmem=2G,slots=8 passed on the QEMU command line we get: Without this patch: /proc/device-tree/ibm,drc-indexes 0000001f 20000001 20000002 20000003 20000000 20000005 20000006 20000007 20000004 20000009 20000008 20000010 20000011 20000012 20000013 20000014 20000015 20000016 20000017 20000018 20000019 2000000a 2000000b 2000000c 2000000d 2000000e 2000000f 2000001a 2000001b 2000001c 2000001d 2000001e These are the DRC indexes for the 31 possible PHBs. With this patch: /proc/device-tree/ibm,drc-indexes 0000002b 90000000 90000001 90000002 90000003 90000004 90000005 90000006 90000007 20000001 20000002 20000003 20000000 20000005 20000006 20000007 20000004 20000009 20000008 20000010 20000011 20000012 20000013 20000014 20000015 20000016 20000017 20000018 20000019 2000000a 2000000b 2000000c 2000000d 2000000e 2000000f 2000001a 2000001b 2000001c 2000001d 2000001e 80000004 80000005 80000006 80000007 And now we also have the 4 ((2G - 1G) / 256M) LMBs and the 8 (slots) PMEMs. Fixes: 3998ccd09298 ("spapr: populate PHB DRC entries for root DT node") Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <160794479566.35245.17809158217760761558.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr/xive: Make spapr_xive_pic_print_info() staticCédric Le Goater
Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20201215174025.2636824-1-clg@kaod.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06spapr: DRC lookup cannot failGreg Kurz
All memory DRC objects are created during machine init. It is thus safe to assume spapr_drc_by_id() cannot return NULL when hot-plug/unplugging memory. Make this clear with an assertion, like the code already does a few lines above when looping over memory DRCs. This fixes Coverity reports 1437757 and 1437758. Signed-off-by: Greg Kurz <groug@kaod.org> Message-Id: <160805381160.228955.5388294067094240175.stgit@bahia.lan> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06hw/ppc/ppc440_bamboo: Drop use of ppcuic_init()Peter Maydell
Switch the bamboo board to directly creating and configuring the UIC, rather than doing it via the old ppcuic_init() helper function. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20201212001537.24520-5-peter.maydell@linaro.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06hw/ppc/virtex_ml507: Drop use of ppcuic_init()Peter Maydell
Switch the virtex_ml507 board to directly creating and configuring the UIC, rather than doing it via the old ppcuic_init() helper function. This fixes a trivial Coverity-detected memory leak where we were leaking the array of IRQs returned by ppcuic_init(). Fixes: Coverity CID 1421992 Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20201212001537.24520-4-peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06ppc: Convert PPC UIC to a QOM devicePeter Maydell
Currently the PPC UIC ("Universal Interrupt Controller") is implemented as a non-QOM device in ppc4xx_devs.c. Convert it to a proper QOM device in hw/intc. The ppcuic_init() function is retained for the moment with its current interface; in subsequent commits this will be tidied up to avoid the allocation of an irq array. This conversion adds VMState support. It leaves the LOG_UIC() macro as-is to maximise the extent to which this is simply code-movement rather than a rewrite (in new code it would be better to use tracepoints). The default property values for dcr-base and use-vectors are set to match those use by most of our boards with a UIC. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20201212001537.24520-3-peter.maydell@linaro.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-06hw/ppc/ppc4xx_devs: Make code style fixes to UIC codePeter Maydell
In a following commit we will move the PPC UIC implementation to its own file in hw/intc. To prevent checkpatch complaining about that code-motion, fix up the minor style issues first. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20201212001537.24520-2-peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Tested-by: Edgar E. Iglesias <edgar.iglesias@xilinx.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
2021-01-04hw/mips/fuloong2e: Correct cpuclock in PROM environmentJiaxun Yang
Missed in 3ca7639ff00 ("hw/mips/fuloong2e: Set CPU frequency to 533 MHz"), we need to tell the kernel the correct clock. Fixes: 3ca7639ff00 ("hw/mips/fuloong2e: Set CPU frequency to 533 MHz"). Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201224031750.52146-7-jiaxun.yang@flygoat.com> [PMD: Reworded] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-04hw/mips/fuloong2e: Remove unused env entryJiaxun Yang
modetty is not handled by kernel and the parameter here seems unreasonable. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Message-Id: <20201224031750.52146-6-jiaxun.yang@flygoat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> [PMD: Do not remove busclock] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-04hw/mips/fuloong2e: Replace faulty documentation linksJiaxun Yang
Websites are downing, but GitHub may last forever. Loongson even doesn't recogonize 2E as their products nowadays.. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201224031750.52146-3-jiaxun.yang@flygoat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-04hw/mips/fuloong2e: Remove define DEBUG_FULOONG2E_INITJiaxun Yang
Seems useless.... Fixes: 051c190bce5 ("MIPS: Initial support of fulong mini pc (machine construction)") Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Huacai Chen <chenhuacai@kernel.org> Message-Id: <20201224031750.52146-2-jiaxun.yang@flygoat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-04hw/mips: Use address translation helper to handle ENVP_ADDRJiaxun Yang
It will signed extend vaddr properly. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201215064200.28751-4-jiaxun.yang@flygoat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-04hw/mips/malta: Use address translation helper to calculate bootloader_run_addrJiaxun Yang
So it will sign extend adresses properly. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201215064200.28751-3-jiaxun.yang@flygoat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-04hw/mips: Make bootloader addresses unsignedJiaxun Yang
Address should be unsigned anyway, otherwise it may carry calculations wrongly. Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201215064200.28751-2-jiaxun.yang@flygoat.com> [PMD: Fixed typo and convert hw/mips/mipssim.c too] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-04hw/mips: Add Loongson-3 machine supportHuacai Chen
Add Loongson-3 based machine support, it use liointc as the interrupt controler and use GPEX as the pci controller. Currently it can work with both TCG and KVM. As the machine model is not based on any exiting physical hardware, the name of the machine is "loongson3-virt". It may be superseded in future by a real machine model. If this happens, then a regular deprecation procedure shall occur for "loongson3-virt" machine. We now already have a full functional Linux kernel (based on Linux-5.4.x LTS) here: https://github.com/chenhuacai/linux Of course the upstream kernel is also usable (the kvm host side and guest side have both been upstream in Linux-5.9): https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git How to use QEMU/Loongson-3? 1, Download kernel source from the above URL; 2, Build a kernel with arch/mips/configs/loongson3_defconfig; 3, Boot a Loongson-3A4000 host with this kernel (for KVM mode); 4, Build QEMU-master with this patchset; 5, modprobe kvm (only necessary for KVM mode); 6, Use QEMU with TCG: qemu-system-mips64el -M loongson3-virt,accel=tcg -cpu Loongson-3A1000 -kernel <path_to_kernel> -append ... Use QEMU with KVM: qemu-system-mips64el -M loongson3-virt,accel=kvm -cpu Loongson-3A4000 -kernel <path_to_kernel> -append ... The "-cpu" parameter is optional here and QEMU will use the correct type for TCG/KVM automatically. Co-developed-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Huacai Chen <chenhuacai@kernel.org> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Message-Id: <20201221110538.3186646-5-chenhuacai@kernel.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> [PMD: Set TYPE_LOONGSON_MACHINE instance_size in TypeInfo, select FW_CFG_MIPS in Kconfig] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
generated by cgit v1.2.3 (git 2.26.2) at 2024-11-27 00:17:24 +0000