aboutsummaryrefslogtreecommitdiff
path: root/hw/arm
AgeCommit message (Collapse)Author
2018-04-26Remove checks on MAX_SERIAL_PORTS that are just bounds checksPeter Maydell
Remove checks on MAX_SERIAL_PORTS that were just checking whether they were within bounds for the serial_hds[] array and falling back to NULL if not. This isn't needed with the serial_hd() function, which returns NULL for all indexes beyond what the user set up. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180420145249.32435-9-peter.maydell@linaro.org
2018-04-26Change references to serial_hds[] to serial_hd()Peter Maydell
Change all the uses of serial_hds[] to go via the new serial_hd() function. Code change produced with: find hw -name '*.[ch]' | xargs sed -i -e 's/serial_hds\[\([^]]*\)\]/serial_hd(\1)/g' Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20180420145249.32435-8-peter.maydell@linaro.org
2018-04-26hw/arm/fsl-imx*: Don't create "null" chardevs for serial devicesPeter Maydell
Following commit 12051d82f004024, UART devices should handle being passed a NULL pointer chardev, so we don't need to create "null" backends in board code. Remove the code that does this and updates serial_hds[]. (fsl-imx7.c was already written this way.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Thomas Huth <thuth@redhat.com> Message-id: 20180420145249.32435-3-peter.maydell@linaro.org
2018-04-26hw/arm/aspeed_soc: don't use vmstate_register_ram_global for SRAMPeter Maydell
Currently we use vmstate_register_ram_global() for the SRAM; this is not a good idea for devices, because it means that you can only ever create one instance of the device, as the second instance would get a RAM block name clash. Instead, use memory_region_init_ram(), which automatically registers the RAM block with a local-to-the-device name. Note that this would be a cross-version migration compatibility break for the "palmetto-bmc", "ast2500-evb" and "romulus-bmc" machines, but migration is currently broken for them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Message-id: 20180420124835.7268-4-peter.maydell@linaro.org
2018-04-26hw/arm/aspeed: don't make 'boot_rom' region 'nomigrate'Peter Maydell
Currently we use memory_region_init_ram_nomigrate() to create the "aspeed.boot_rom" memory region, and we don't manually register it with vmstate_register_ram(). This currently means that its contents are migrated but as a ram block whose name is the empty string; in future it may mean they are not migrated at all. Use memory_region_init_ram() instead. Note that would be a cross-version migration compatibility break for the "palmetto-bmc", "ast2500-evb" and "romulus-bmc" machines, but migration is currently broken for them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Tested-by: Cédric Le Goater <clg@kaod.org> Message-id: 20180420124835.7268-3-peter.maydell@linaro.org
2018-04-26hw/arm/highbank: don't make sysram 'nomigrate'Peter Maydell
Currently we use memory_region_init_ram_nomigrate() to create the "highbank.sysram" memory region, and we don't manually register it with vmstate_register_ram(). This currently means that its contents are migrated but as a ram block whose name is the empty string; in future it may mean they are not migrated at all. Use memory_region_init_ram() instead. Note that this is a cross-version migration compatibility break for the "highbank" and "midway" machines. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20180420124835.7268-2-peter.maydell@linaro.org
2018-04-26hw/arm/raspi: Don't bother setting default_cpu_typePeter Maydell
In commit 210f47840dd62, we changed the bcm2836 SoC object to always create a CPU of the correct type for that SoC model. This makes the default_cpu_type settings in the MachineClass structs for the raspi2 and raspi3 boards redundant. We didn't change those at the time because it would have meant a temporary regression in a corner case of error handling if the user requested a non-existing CPU type. The -cpu parse handling changes in 2278b93941d42c3 mean that it no longer implicitly depends on default_cpu_type for this to work, so we can now delete the redundant default_cpu_type fields. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180420155547.9497-1-peter.maydell@linaro.org
2018-04-26arm: always start from first_cpu when registering loader cpu reset callbackIgor Mammedov
if arm_load_kernel() were passed non first_cpu, QEMU would end up with partially set do_cpu_reset() callback leaving some CPUs without it. Make sure that do_cpu_reset() is registered for all CPUs by enumerating CPUs from first_cpu. (In practice every board that we have was passing us the first CPU as the boot CPU, either directly or indirectly, so this wasn't causing incorrect behaviour.) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added a note that this isn't a behaviour change] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-04-10hw/arm/fsl-imx: Fix introspection problem with fsl-imx6 and fsl-imx7Thomas Huth
QEMU currently exits unexpectedly when trying to introspect the fsl-imx6 and fsl-imx7 devices on systems with many SMP CPUs: $ echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ " 'arguments':{'typename':'fsl,imx6'}}" \ | arm-softmmu/qemu-system-arm -M virt,accel=qtest -qmp stdio -smp 8 {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} fsl,imx6: Only 4 CPUs are supported (8 requested) And: $ echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ " 'arguments':{'typename':'fsl,imx7'}}" \ | arm-softmmu/qemu-system-arm -M raspi2,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} fsl,imx7: Only 2 CPUs are supported (4 requested) This happens because these devices are doing an exit() from their instance_init function - which should never be done since instance_init can be called at any time for device introspection! Fix it by moving the deadly check into the realize() function instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-id: 1522908551-14885-1-git-send-email-thuth@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-04-10hw/arm/allwinner-a10: Do not use nd_table in instance_init functionThomas Huth
The instance_init function of a device can be called at any time, even if the device is not going to be used (i.e. not going to be realized). So a instance_init function must not do things that could cause QEMU to exit, like calling qemu_check_nic_model(&nd_table[0], ...) for example. But this is what the instance_init function of the allwinner-a10 device is currently doing - and this causes QEMU to quit unexpectedly when you run the 'device-list-properties' QMP command for example: $ echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ " 'arguments':{'typename':'allwinner-a10'}}" \ | arm-softmmu/qemu-system-arm -M mps2-an505,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} Unsupported NIC model: lan9118 ... and QEMU quits after printing the last line (which should not happen just because of running 'device-list-properties' here). And with the cubieboard, this even causes QEMU to abort(): $ echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ " 'arguments':{'typename':'allwinner-a10'}}" \ | arm-softmmu/qemu-system-arm -M cubieboard,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} Unexpected error in error_set_from_qdev_prop_error() at hw/core/qdev-properties.c:1095: Property 'allwinner-emac.netdev' can't take value 'hub0port0', it's in use Aborted (core dumped) To fix the problem we've got to move the offending code to the realize function instead. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-id: 1522862420-7484-1-git-send-email-thuth@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-04-10hw/arm/integratorcp: Don't do things that could be fatal in the instance_initThomas Huth
An instance_init function must not fail - and might be called multiple times, e.g. during device introspection with the 'device-list-properties' QMP command. Since the integratorcm device ignores this rule, QEMU currently aborts in this case (though it really should not): echo "{'execute':'qmp_capabilities'}"\ "{'execute':'device-list-properties',"\ "'arguments':{'typename':'integrator_core'}}" \ | arm-softmmu/qemu-system-arm -M integratorcp,accel=qtest -qmp stdio {"QMP": {"version": {"qemu": {"micro": 91, "minor": 11, "major": 2}, "package": "build-all"}, "capabilities": []}} {"return": {}} RAMBlock "integrator.flash" already registered, abort! Aborted (core dumped) Move the problematic code to the realize() function instead to fix this problem. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Thomas Huth <thuth@redhat.com> Message-id: 1522906473-11252-1-git-send-email-thuth@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-04-10hw/arm: Allow manually specified /psci nodeAndrey Smirnov
Change the code to avoid exiting QEMU if user provided DTB contains manually specified /psci node and skip any /psci related fixups instead. Fixes: 4cbca7d9b4 ("hw/arm: Move virt's PSCI DT fixup code to arm/boot.c") Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Reported-by: Marc Zyngier <marc.zyngier@arm.com> Tested-by: Marc Zyngier <marc.zyngier@arm.com> Message-id: 20180402205654.14572-1-andrew.smirnov@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-23mach-virt: Set VM's SMBIOS system version to mc->nameWei Huang
Instead of using "1.0" as the system version of SMBIOS, we should use mc->name for mach-virt machine type to be consistent other architectures. With this patch, "dmidecode -t 1" (e.g., "-M virt-2.12,accel=kvm") will show: Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: QEMU Product Name: KVM Virtual Machine Version: virt-2.12 Serial Number: Not Specified ... instead of: Handle 0x0100, DMI type 1, 27 bytes System Information Manufacturer: QEMU Product Name: KVM Virtual Machine Version: 1.0 Serial Number: Not Specified ... For backward compatibility, we allow older machine types to keep "1.0" as the default system version. Signed-off-by: Wei Huang <wei@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Message-id: 20180322212318.7182-1-wei@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-23hw/arm/bcm2836: Use the Cortex-A7 instead of Cortex-A15Peter Maydell
The BCM2836 uses a Cortex-A7, not a Cortex-A15. Update the device to use the correct CPU. https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2836/QA7_rev3.4.pdf When the BCM2836 was introduced (bad5623690b) the Cortex-A7 was not available, so the very similar Cortex-A15 was used. Since dcf578ed8ce we can model the correct core. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair@alistair23.me> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180319110215.16755-1-peter.maydell@linaro.org
2018-03-20Merge remote-tracking branch 'remotes/mst/tags/for_upstream' into stagingPeter Maydell
virtio,vhost,pci,pc: features, cleanups SRAT tables for DIMM devices new virtio net flags for speed/duplex post-copy migration support in vhost cleanups in pci Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Tue 20 Mar 2018 14:40:43 GMT # gpg: using RSA key 281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * remotes/mst/tags/for_upstream: (51 commits) postcopy shared docs libvhost-user: Claim support for postcopy postcopy: Allow shared memory vhost: Huge page align and merge vhost+postcopy: Wire up POSTCOPY_END notify vhost-user: Add VHOST_USER_POSTCOPY_END message libvhost-user: mprotect & madvises for postcopy vhost+postcopy: Call wakeups vhost+postcopy: Add vhost waker postcopy: postcopy_notify_shared_wake postcopy: helper for waking shared vhost+postcopy: Resolve client address postcopy-ram: add a stub for postcopy_request_shared_page vhost+postcopy: Helper to send requests to source for shared pages vhost+postcopy: Stash RAMBlock and offset vhost+postcopy: Send address back to qemu libvhost-user+postcopy: Register new regions with the ufd migration/ram: ramblock_recv_bitmap_test_byte_offset postcopy+vhost-user: Split set_mem_table for postcopy vhost+postcopy: Transmit 'listen' to slave ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org> # Conflicts: # scripts/update-linux-headers.sh
2018-03-19hw/arm/raspi: Provide spin-loop code for AArch64 CPUsPeter Maydell
The raspi3 has AArch64 CPUs, which means that our smpboot code for keeping the secondary CPUs in a pen needs to have a version for A64 as well as A32. Without this, the secondary CPUs go into an infinite loop of taking undefined instruction exceptions. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-10-peter.maydell@linaro.org
2018-03-19hw/arm/bcm2836: Hardcode correct CPU typePeter Maydell
Now we have separate types for BCM2386 and BCM2387, we might as well just hard-code the CPU type they use rather than having it passed through as an object property. This then lets us put the initialization of the CPU object in init rather than realize. Note that this change means that it's no longer possible on the command line to use -cpu to ask for a different kind of CPU than the SoC supports. This was never a supported thing to do anyway; we were just not sanity-checking the command line. This does require us to only build the bcm2837 object on TARGET_AARCH64 configs, since otherwise it won't instantiate due to the missing cortex-a53 device and "make check" will fail. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-9-peter.maydell@linaro.org
2018-03-19hw/arm/bcm2836: Use correct affinity values for BCM2837Peter Maydell
The BCM2837 sets the Aff1 field of the MPIDR affinity values for the CPUs to 0, whereas the BCM2836 uses 0xf. Set this correctly, as it is required for Linux to boot. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-8-peter.maydell@linaro.org
2018-03-19hw/arm/bcm2836: Create proper bcm2837 devicePeter Maydell
The bcm2837 is pretty similar to the bcm2836, but it does have some differences. Notably, the MPIDR affinity aff1 values it sets for the CPUs are 0x0, rather than the 0xf that the bcm2836 uses, and if this is wrong Linux will not boot. Rather than trying to have one device with properties that configure it differently for the two cases, create two separate QOM devices for the two SoCs. We use the same approach as hw/arm/aspeed_soc.c and share code and have a data table that might differ per-SoC. For the moment the two types don't actually have different behaviour. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-7-peter.maydell@linaro.org
2018-03-19hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283xPeter Maydell
Our BCM2836 type is really a generic one that can be any of the bcm283x family. Rename it accordingly. We change only the names which are visible via the header file to the rest of the QEMU code, leaving private function names in bcm2836.c as they are. This is a preliminary to making bcm283x be an abstract parent class to specific types for the bcm2836 and bcm2837. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-6-peter.maydell@linaro.org
2018-03-19hw/arm/bcm2386: Fix parent type of bcm2386Peter Maydell
The TypeInfo and state struct for bcm2386 disagree about what the parent class is -- the TypeInfo says it's TYPE_SYS_BUS_DEVICE, but the BCM2386State struct only defines the parent_obj field as DeviceState. This would have caused problems if anything actually tried to treat the object as a TYPE_SYS_BUS_DEVICE. Fix the TypeInfo to use TYPE_DEVICE as the parent, since we don't need any of the additional functionality TYPE_SYS_BUS_DEVICE provides. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-5-peter.maydell@linaro.org
2018-03-19hw/arm/boot: If booting a kernel in EL2, set SCR_EL3.HCEPeter Maydell
If we're directly booting a Linux kernel and the CPU supports both EL3 and EL2, we start the kernel in EL2, as it expects. We must also set the SCR_EL3.HCE bit in this situation, so that the HVC instruction is enabled rather than UNDEFing. Otherwise at least some kernels will panic when trying to initialize KVM in the guest. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20180313153458.26822-4-peter.maydell@linaro.org
2018-03-19hw/arm/boot: assert that secure_boot and secure_board_setup are false for ↵Peter Maydell
AArch64 Add some assertions that if we're about to boot an AArch64 kernel, the board code has not mistakenly set either secure_boot or secure_board_setup. It doesn't make sense to set secure_boot, because all AArch64 kernels must be booted in non-secure mode. It might in theory make sense to set secure_board_setup, but we don't currently support that, because only the AArch32 bootloader[] code calls this hook; bootloader_aarch64[] does not. Since we don't have a current need for this functionality, just assert that we don't try to use it. If it's needed we'll add it later. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-3-peter.maydell@linaro.org
2018-03-19hw/arm/raspi: Don't do board-setup or secure-boot for raspi3Peter Maydell
For the rpi1 and 2 we want to boot the Linux kernel via some custom setup code that makes sure that the SMC instruction acts as a no-op, because it's used for cache maintenance. The rpi3 boots AArch64 kernels, which don't need SMC for cache maintenance and always expect to be booted non-secure. Don't fill in the aarch32-specific parts of the binfo struct. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Andrew Baumann <Andrew.Baumann@microsoft.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20180313153458.26822-2-peter.maydell@linaro.org
2018-03-13virt_arm: acpi: reuse common build_fadt()Igor Mammedov
Extend generic build_fadt() to support rev5.1 FADT and reuse it for 'virt' board, it would allow to phase out usage of AcpiFadtDescriptorRev5_1 and later ACPI_FADT_COMMON_DEF. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-13acpi: move build_fadt() from i386 specific to generic ACPI sourceIgor Mammedov
It will be extended and reused by follow up patch for ARM target. PS: Since it's generic function now, don't patch FIRMWARE_CTRL, DSDT fields if they don't point to tables since platform might not provide them and use X_ variants instead if applicable. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2018-03-12hw: Do not include "sysemu/block-backend.h" if it is not necessaryThomas Huth
After reviewing a patch from Philippe that removes block-backend.h from hw/lm32/milkymist.c, I noticed that this header is included unnecessarily in a lot of other files, too. Remove those unneeded includes to speed up the compilation process a little bit. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-Id: <1518684912-31637-1-git-send-email-thuth@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2018-03-09hw/arm/virt: Support -machine gic-version=maxPeter Maydell
Add support for passing 'max' to -machine gic-version. By analogy with the -cpu max option, this picks the "best available" GIC version whether you're using KVM or TCG, so it behaves like 'host' when using KVM, and gives you GICv3 when using TCG. Also like '-cpu host', using -machine gic-version=max' means there is no guarantee of migration compatibility between QEMU versions; in future 'max' might mean '4'. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20180308130626.12393-7-peter.maydell@linaro.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2018-03-09hw/arm/virt: Add "max" to the list of CPU types "virt" supportsPeter Maydell
Allow the virt board to support '-cpu max' in the same way it already handles '-cpu host'. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20180308130626.12393-6-peter.maydell@linaro.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2018-03-09arm: avoid heap-buffer-overflow in load_aarch64_imageMarc-André Lureau
Spotted by ASAN: elmarco@boraha:~/src/qemu/build (master *%)$ QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 tests/boot-serial-test /aarch64/boot-serial/virt: ** (process:19740): DEBUG: 18:39:30.275: foo /tmp/qtest-boot-serial-cXaS94D ================================================================= ==19740==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000069648 at pc 0x7f1d2201cc54 bp 0x7fff331f6a40 sp 0x7fff331f61e8 READ of size 4 at 0x603000069648 thread T0 #0 0x7f1d2201cc53 (/lib64/libasan.so.4+0xafc53) #1 0x55bc86685ee3 in load_aarch64_image /home/elmarco/src/qemu/hw/arm/boot.c:894 #2 0x55bc86687217 in arm_load_kernel_notify /home/elmarco/src/qemu/hw/arm/boot.c:1047 #3 0x55bc877363b5 in notifier_list_notify /home/elmarco/src/qemu/util/notify.c:40 #4 0x55bc869331ea in qemu_run_machine_init_done_notifiers /home/elmarco/src/qemu/vl.c:2716 #5 0x55bc8693bc39 in main /home/elmarco/src/qemu/vl.c:4679 #6 0x7f1d1652c009 in __libc_start_main (/lib64/libc.so.6+0x21009) #7 0x55bc86255cc9 in _start (/home/elmarco/src/qemu/build/aarch64-softmmu/qemu-system-aarch64+0x1ae5cc9) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-09arm: fix load ELF error leakMarc-André Lureau
Spotted by ASAN: QTEST_QEMU_BINARY=aarch64-softmmu/qemu-system-aarch64 tests/boot-serial-test Direct leak of 48 byte(s) in 1 object(s) allocated from: #0 0x7ff8a9b0ca38 in __interceptor_calloc (/lib64/libasan.so.4+0xdea38) #1 0x7ff8a8ea7f75 in g_malloc0 ../glib/gmem.c:124 #2 0x55fef3d99129 in error_setv /home/elmarco/src/qemu/util/error.c:59 #3 0x55fef3d99738 in error_setg_internal /home/elmarco/src/qemu/util/error.c:95 #4 0x55fef323acb2 in load_elf_hdr /home/elmarco/src/qemu/hw/core/loader.c:393 #5 0x55fef2d15776 in arm_load_elf /home/elmarco/src/qemu/hw/arm/boot.c:830 #6 0x55fef2d16d39 in arm_load_kernel_notify /home/elmarco/src/qemu/hw/arm/boot.c:1022 #7 0x55fef3dc634d in notifier_list_notify /home/elmarco/src/qemu/util/notify.c:40 #8 0x55fef2fc3182 in qemu_run_machine_init_done_notifiers /home/elmarco/src/qemu/vl.c:2716 #9 0x55fef2fcbbd1 in main /home/elmarco/src/qemu/vl.c:4679 #10 0x7ff89dfed009 in __libc_start_main (/lib64/libc.so.6+0x21009) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-09hw/arm: Use more CONFIG switches for the object filesThomas Huth
A lot of ARM object files are linked into the executable unconditionally, even though we have corresponding CONFIG switches like CONFIG_PXA2XX or CONFIG_OMAP. We should make sure to use these switches in the Makefile so that the users can disable certain unwanted boards and devices more easily. While we're at it, also add some new switches for the boards that do not have a CONFIG option yet. Signed-off-by: Thomas Huth <thuth@redhat.com> Message-id: 1520266949-29817-1-git-send-email-thuth@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-09Implement support for i.MX7 Sabre boardAndrey Smirnov
Implement code needed to set up emulation of MCIMX7SABRE board from NXP. For more info about the HW see: https://www.nxp.com/support/developer-resources/hardware-development-tools/sabre-development-system/sabre-board-for-smart-devices-based-on-the-i.mx-7dual-applications-processors:MCIMX7SABRE Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Jason Wang <jasowang@redhat.com> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Marcel Apfelbaum <marcel.apfelbaum@zoho.com> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Cc: yurovsky@gmail.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-09i.MX: Add i.MX7 SOC implementation.Andrey Smirnov
The following interfaces are partially or fully emulated: * up to 2 Cortex A9 cores (SMP works with PSCI) * A7 MPCORE (identical to A15 MPCORE) * 4 GPTs modules * 7 GPIO controllers * 2 IOMUXC controllers * 1 CCM module * 1 SVNS module * 1 SRC module * 1 GPCv2 controller * 4 eCSPI controllers * 4 I2C controllers * 7 i.MX UART controllers * 2 FlexCAN controllers * 2 Ethernet controllers (FEC) * 3 SD controllers (USDHC) * 4 WDT modules * 1 SDMA module * 1 GPR module * 2 USBMISC modules * 2 ADC modules * 1 PCIe controller Tested to boot and work with upstream Linux (4.13+) guest. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> [PMM: folded a couple of long lines] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-09hw/arm: Set the core count for Xilinx's ZynqMPAlistair Francis
Set the ARM CPU core count property for the A53's attached to the Xilnx ZynqMP machine. Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: fe0dd90b85ac73f9fc9548c253bededa70a07006.1520018138.git.alistair.francis@xilinx.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-02mps2-an505: New board model: MPS2 with AN505 Cortex-M33 FPGA imagePeter Maydell
Define a new board model for the MPS2 with an AN505 FPGA image containing a Cortex-M33. Since the FPGA images for TrustZone cores (AN505, and the similar AN519 for Cortex-M23) have a significantly different layout of devices to the non-TrustZone images, we use a new source file rather than shoehorning them into the existing mps2.c. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180220180325.29818-20-peter.maydell@linaro.org
2018-03-02hw/arm/iotkit: Model Arm IOT KitPeter Maydell
Model the Arm IoT Kit documented in http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ecm0601256/index.html The Arm IoT Kit is a subsystem which includes a CPU and some devices, and is intended be extended by adding extra devices to form a complete system. It is used in the MPS2 board's AN505 image for the Cortex-M33. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180220180325.29818-19-peter.maydell@linaro.org
2018-03-02armv7m: Forward init-svtor property to CPU objectPeter Maydell
Create an "init-svtor" property on the armv7m container object which we can forward to the CPU object. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180220180325.29818-8-peter.maydell@linaro.org
2018-03-02armv7m: Forward idau property to CPU objectPeter Maydell
Create an "idau" property on the armv7m container object which we can forward to the CPU object. Annoyingly, we can't use object_property_add_alias() because the CPU object we want to forward to doesn't exist until the armv7m container is realized. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180220180325.29818-6-peter.maydell@linaro.org
2018-03-02hw/arm/armv7m: Honour CPU's address space for image loadsPeter Maydell
Instead of loading guest images to the system address space, use the CPU's address space. This is important if we're trying to load the file to memory or via an alias memory region that is provided by an SoC object and thus not mapped into the system address space. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180220180325.29818-4-peter.maydell@linaro.org
2018-03-02hw/arm/boot: Honour CPU's address space for image loadsPeter Maydell
Instead of loading kernels, device trees, and the like to the system address space, use the CPU's address space. This is important if we're trying to load the file to memory or via an alias memory region that is provided by an SoC object and thus not mapped into the system address space. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20180220180325.29818-3-peter.maydell@linaro.org
2018-03-02xlnx-zynqmp: Connect the RTC deviceAlistair Francis
Signed-off-by: Alistair Francis <alistair.francis@xilinx.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-03-01arm/vexpress: Add proper display connector emulationLinus Walleij
This adds the SiI9022 (and implicitly EDID I2C) device to the ARM Versatile Express machine, and selects the two I2C devices necessary in the arm-softmmu.mak configuration so everything will build smoothly. I am implementing proper handling of the graphics in the Linux kernel and adding proper emulation of SiI9022 and EDID makes the driver probe as nicely as before, retrieving the resolutions supported by the "QEMU monitor" and overall just working nice. Cc: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Message-id: 20180227104903.21353-6-linus.walleij@linaro.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-02-22raspi: Add "raspi3" machine typePekka Enberg
This patch adds a "raspi3" machine type, which can now be selected as the machine to run on by users via the "-M" command line option to QEMU. The machine type does *not* ignore memory transaction failures so we likely need to add some dummy devices later when people run something more complicated than what I'm using for testing. Signed-off-by: Pekka Enberg <penberg@iki.fi> [PMM: added #ifdef TARGET_AARCH64 so we don't provide the 64-bit board in the 32-bit only arm-softmmu build.] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-02-15raspi: Raspberry Pi 3 supportPekka Enberg
This patch adds Raspberry Pi 3 support to hw/arm/raspi.c. The differences to Pi 2 are: - Firmware address - Board ID - Board revision The CPU is different too, but that's going to be configured as part of the machine default CPU when we introduce a new machine type. The patch was written from scratch by me but the logic is similar to Zoltán Baldaszti's previous work, which I used as a reference (with permission from the author): https://github.com/bztsrc/qemu-raspi3 Signed-off-by: Pekka Enberg <penberg@iki.fi> [PMM: fixed trailing whitespace on one line] Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-02-15bcm2836: Make CPU type configurablePekka Enberg
This patch adds a "cpu-type" property to BCM2836 SoC in preparation for reusing the code for the Raspberry Pi 3, which has a different processor model. Signed-off-by: Pekka Enberg <penberg@iki.fi> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-02-15hw/arm/aspeed: simplify using the 'unimplemented device' for aspeed_soc.ioPhilippe Mathieu-Daudé
(qemu) info mtree address-space: cpu-memory-0 0000000000000000-ffffffffffffffff (prio 0, i/o): system 0000000000000000-0000000007ffffff (prio 0, rom): aspeed.boot_rom - 000000001e600000-000000001e7fffff (prio -1, i/o): aspeed_soc.io + 000000001e600000-000000001e7fffff (prio -1000, i/o): aspeed_soc.io 000000001e620000-000000001e6200ff (prio 0, i/o): aspeed.smc.ast2500-fmc 000000001e630000-000000001e6300ff (prio 0, i/o): aspeed.smc.ast2500-spi1 000000001e631000-000000001e6310ff (prio 0, i/o): aspeed.smc.ast2500-spi2 Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 20180209085755.30414-3-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-02-15hw/arm/aspeed: directly map the serial device to the system address spacePhilippe Mathieu-Daudé
(qemu) info mtree address-space: cpu-memory-0 0000000000000000-ffffffffffffffff (prio 0, i/o): system 0000000000000000-0000000007ffffff (prio 0, rom): aspeed.boot_rom 000000001e600000-000000001e7fffff (prio -1, i/o): aspeed_soc.io - 000000001e784000-000000001e78401f (prio 0, i/o): serial 000000001e620000-000000001e6200ff (prio 0, i/o): aspeed.smc.ast2500-fmc 000000001e630000-000000001e6300ff (prio 0, i/o): aspeed.smc.ast2500-spi1 [...] 000000001e720000-000000001e728fff (prio 0, ram): aspeed.sram 000000001e782000-000000001e782fff (prio 0, i/o): aspeed.timer + 000000001e784000-000000001e78401f (prio 0, i/o): serial 000000001e785000-000000001e78501f (prio 0, i/o): aspeed.wdt 000000001e785020-000000001e78503f (prio 0, i/o): aspeed.wdt Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Message-id: 20180209085755.30414-2-f4bug@amsat.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2018-02-13hw/arm/xilinx_zynqmp: enable the UHS-I modePhilippe Mathieu-Daudé
see the Xilinx datasheet "UG1085" (v1.7) Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Message-Id: <20180208164818.7961-28-f4bug@amsat.org>
2018-02-13hw/arm/xilinx_zynqmp: fix the capabilities/spec version to match the datasheetPhilippe Mathieu-Daudé
checking Xilinx datasheet "UG1085" (v1.7) Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@xilinx.com> Message-Id: <20180208164818.7961-27-f4bug@amsat.org>