aboutsummaryrefslogtreecommitdiff
path: root/hw/arm
AgeCommit message (Collapse)AuthorFilesLines
2021-10-05acpi: arm/virt: convert build_iort() to endian agnostic build_append_FOO() APIIgor Mammedov1-71/+93
Drop usage of packed structures and explicit endian conversions when building IORT table use endian agnostic build_append_int_noprefix() API to build it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20210924122802.1455362-30-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com>
2021-10-05acpi: arm: virt: build_iort: use acpi_table_begin()/acpi_table_end() instead ↵Igor Mammedov1-26/+18
of build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Tested-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-29-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: arm: virt: build_dsdt: use acpi_table_begin()/acpi_table_end() instead ↵Igor Mammedov1-7/+6
of build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-28-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: arm/virt: madt: use build_append_int_noprefix() API to compose MADT tableIgor Mammedov1-60/+90
Drop usage of packed structures and explicit endian conversions when building MADT table for arm/x86 and use endian agnostic build_append_int_noprefix() API to build it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-26-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: madt: arm/x86: use acpi_table_begin()/acpi_table_end() instead of ↵Igor Mammedov1-8/+11
build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-22-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: use build_append_int_noprefix() API to compose SRAT tableIgor Mammedov1-12/+17
Drop usage of packed structures and explicit endian conversions when building SRAT tables for arm/x86 and use endian agnostic build_append_int_noprefix() API to build it. Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-18-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-05acpi: arm/x86: build_srat: use acpi_table_begin()/acpi_table_end() instead ↵Igor Mammedov1-8/+7
of build_header() it replaces error-prone pointer arithmetic for build_header() API, with 2 calls to start and finish table creation, which hides offsets magic from API user. While at it switch to build_append_int_noprefix() to build table entries (which also removes some manual offset calculations) Signed-off-by: Igor Mammedov <imammedo@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Message-Id: <20210924122802.1455362-17-imammedo@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2021-10-01machine: Move smp_prefer_sockets to struct SMPCompatPropsYanan Wang1-1/+1
Now we have a common structure SMPCompatProps used to store information about SMP compatibility stuff, so we can also move smp_prefer_sockets there for cleaner code. No functional change intended. Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-15-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-01machine: Prefer cores over sockets in smp parsing since 6.2Yanan Wang1-0/+1
In the real SMP hardware topology world, it's much more likely that we have high cores-per-socket counts and few sockets totally. While the current preference of sockets over cores in smp parsing results in a virtual cpu topology with low cores-per-sockets counts and a large number of sockets, which is just contrary to the real world. Given that it is better to make the virtual cpu topology be more reflective of the real world and also for the sake of compatibility, we start to prefer cores over sockets over threads in smp parsing since machine type 6.2 for different arches. In this patch, a boolean "smp_prefer_sockets" is added, and we only enable the old preference on older machines and enable the new one since type 6.2 for all arches by using the machine compat mechanism. Suggested-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Yanan Wang <wangyanan55@huawei.com> Acked-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@ionos.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20210929025816.21076-10-wangyanan55@huawei.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-09-30hw/arm: sabrelite: Connect SPI flash CS line to GPIO3_19Xuzhou Cheng1-1/+1
The Linux spi-imx driver does not work on QEMU. The reason is that the state of m25p80 loops in STATE_READING_DATA state after receiving RDSR command, the new command is ignored. Before sending a new command, CS line should be pulled high to make the state of m25p80 back to IDLE. Currently the SPI flash CS line is connected to the SPI controller, but on the real board, it's connected to GPIO3_19. This matches the ecspi1 device node in the board dts. ecspi1 node in imx6qdl-sabrelite.dtsi: &ecspi1 { cs-gpios = <&gpio3 19 GPIO_ACTIVE_LOW>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ecspi1>; status = "okay"; flash: m25p80@0 { compatible = "sst,sst25vf016b", "jedec,spi-nor"; spi-max-frequency = <20000000>; reg = <0>; }; }; Should connect the SSI_GPIO_CS to GPIO3_19 when adding a spi-nor to spi1 on sabrelite machine. Verified this patch on Linux v5.14. Logs: # echo "01234567899876543210" > test # mtd_debug erase /dev/mtd0 0x0 0x1000 Erased 4096 bytes from address 0x00000000 in flash # mtd_debug write /dev/mtdblock0 0x0 20 test Copied 20 bytes from test to address 0x00000000 in flash # mtd_debug read /dev/mtdblock0 0x0 20 test_out Copied 20 bytes from address 0x00000000 in flash to test_out # cat test_out 01234567899876543210# Signed-off-by: Xuzhou Cheng <xuzhou.cheng@windriver.com> Reported-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-id: 20210927142825.491-1-xchengl.cn@gmail.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30hw/arm: xlnx-zcu102: Add Xilinx eFUSE deviceTong Ho2-0/+44
Connect the support for ZynqMP eFUSE one-time field-programmable bit array. The command argument: -drive if=pflash,index=3,... Can be used to optionally connect the bit array to a backend storage, such that field-programmed values in one invocation can be made available to next invocation. The backend storage must be a seekable binary file, and its size must be 768 bytes or larger. A file with all binary 0's is a 'blank'. Signed-off-by: Tong Ho <tong.ho@xilinx.com> Message-id: 20210917052400.1249094-9-tong.ho@xilinx.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30hw/arm: xlnx-zcu102: Add Xilinx BBRAM deviceTong Ho2-0/+35
Connect the support for Xilinx ZynqMP Battery-Backed RAM (BBRAM) The command argument: -drive if=pflash,index=2,... Can be used to optionally connect the bbram to a backend storage, such that field-programmed values in one invocation can be made available to next invocation. The backend storage must be a seekable binary file, and its size must be 36 bytes or larger. A file with all binary 0's is a 'blank'. Signed-off-by: Tong Ho <tong.ho@xilinx.com> Message-id: 20210917052400.1249094-8-tong.ho@xilinx.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30hw/arm: xlnx-versal-virt: Add Xilinx eFUSE deviceTong Ho3-0/+92
Connect the support for Versal eFUSE one-time field-programmable bit array. The command argument: -drive if=pflash,index=1,... Can be used to optionally connect the bit array to a backend storage, such that field-programmed values in one invocation can be made available to next invocation. The backend storage must be a seekable binary file, and its size must be 3072 bytes or larger. A file with all binary 0's is a 'blank'. Signed-off-by: Tong Ho <tong.ho@xilinx.com> Message-id: 20210917052400.1249094-7-tong.ho@xilinx.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30hw/arm: xlnx-versal-virt: Add Xilinx BBRAM deviceTong Ho3-0/+55
Connect the support for Versal Battery-Backed RAM (BBRAM) The command argument: -drive if=pflash,index=0,... Can be used to optionally connect the bbram to a backend storage, such that field-programmed values in one invocation can be made available to next invocation. The backend storage must be a seekable binary file, and its size must be 36 bytes or larger. A file with all binary 0's is a 'blank'. Signed-off-by: Tong Ho <tong.ho@xilinx.com> Message-id: 20210917052400.1249094-6-tong.ho@xilinx.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-30allwinner-h3: Switch to SMC as PSCI conduitAlexander Graf1-1/+1
The Allwinner H3 SoC uses Cortex-A7 cores which support virtualization. However, today we are configuring QEMU to use HVC as PSCI conduit. That means HVC calls get trapped into QEMU instead of the guest's own emulated CPU and thus break the guest's ability to execute virtualization. Fix this by moving to SMC as conduit, freeing up HYP completely to the VM. Signed-off-by: Alexander Graf <agraf@csgraf.de> Message-id: 20210920203931.66527-1-agraf@csgraf.de Fixes: 740dafc0ba0 ("hw/arm: add Allwinner H3 System-on-Chip") Reviewed-by: Niek Linnenbank <nieklinnenbank@gmail.com> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.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>
2021-09-20hw/arm/aspeed: Add Fuji machine typePeter Delevoryas1-0/+120
This adds a new machine type "fuji-bmc" based on the following device tree: https://github.com/torvalds/linux/blob/40cb6373b46/arch/arm/boot/dts/aspeed-bmc-facebook-fuji.dts Most of the i2c devices are not there, they're added here: https://github.com/facebook/openbmc/blob/fb2ed12002fb/meta-facebook/meta-fuji/recipes-utils/openbmc-utils/files/setup_i2c.sh I tested this by building a Fuji image from Facebook's OpenBMC repo, booting, and ssh'ing from host-to-guest. Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Joel Stanley <joel@jms.id.au> [ clg: On 32-bit hosts, lower RAM to 1G because of 2047 MB limit ] Message-Id: <20210906133124.3674661-1-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20hw/arm/aspeed: Allow machine to set UART defaultPeter Delevoryas3-7/+12
When you run QEMU with an Aspeed machine and a single serial device using stdio like this: qemu -machine ast2600-evb -drive ... -serial stdio The guest OS can read and write to the UART5 registers at 0x1E784000 and it will receive from stdin and write to stdout. The Aspeed SoC's have a lot more UART's though (AST2500 has 5, AST2600 has 13) and depending on the board design, may be using any of them as the serial console. (See "stdout-path" in a DTS to check which one is chosen). Most boards, including all of those currently defined in hw/arm/aspeed.c, just use UART5, but some use UART1. This change adds some flexibility for different boards without requiring users to change their command-line invocation of QEMU. I tested this doesn't break existing code by booting an AST2500 OpenBMC image and an AST2600 OpenBMC image, each using UART5 as the console. Then I tested switching the default to UART1 and booting an AST2600 OpenBMC image that uses UART1, and that worked too. Signed-off-by: Peter Delevoryas <pdel@fb.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210901153615.2746885-2-pdel@fb.com> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20arm/aspeed: Add DPS310 to Witherspoon and RainierJoel Stanley1-2/+2
Witherspoon uses the DPS310 as a temperature sensor. Rainier uses it as a temperature and humidity sensor. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210629142336.750058-5-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20hw/misc: Add Infineon DPS310 sensor modelJoel Stanley1-0/+1
This contains some hardcoded register values that were obtained from the hardware after reading the temperature. It does enough to test the Linux kernel driver. The FIFO mode, IRQs and operation modes other than the default as used by Linux are not modelled. Signed-off-by: Joel Stanley <joel@jms.id.au> Message-Id: <20210616073358.750472-2-joel@jms.id.au> [ clg: - Fixed sequential reading - Reworked regs_reset_state array - Moved model under hw/sensor/ ] Message-Id: <20210629142336.750058-4-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20aspeed: Emulate the AST2600A3Joel Stanley2-6/+6
This is the latest revision of the ASPEED 2600 SoC. As there is no need to model multiple revisions of the same SoC for the moment, update the SCU AST2600 to model the A3 revision instead of the A1 and adapt the AST2600 SoC and machines. Reset values are taken from v8 of the datasheet. Signed-off-by: Joel Stanley <joel@jms.id.au> [ clg: - Introduced an Aspeed "ast2600-a3" SoC class - Commit log update ] Message-Id: <20210629142336.750058-3-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20arm/aspeed: rainier: Add i2c eeproms and muxesJoel Stanley1-0/+44
These are the devices documented by the Rainier device tree. With this we can see the guest discovering the multiplexers and probing the eeprom devices: i2c i2c-2: Added multiplexed i2c bus 16 i2c i2c-2: Added multiplexed i2c bus 17 i2c i2c-2: Added multiplexed i2c bus 18 i2c i2c-2: Added multiplexed i2c bus 19 i2c-mux-gpio i2cmux: 4 port mux on 1e78a180.i2c-bus adapter at24 20-0050: 8192 byte 24c64 EEPROM, writable, 1 bytes/write i2c i2c-4: Added multiplexed i2c bus 20 at24 21-0051: 8192 byte 24c64 EEPROM, writable, 1 bytes/write i2c i2c-4: Added multiplexed i2c bus 21 at24 22-0052: 8192 byte 24c64 EEPROM, writable, 1 bytes/write Signed-off-by: Joel Stanley <joel@jms.id.au> [ clg: Introduced aspeed_eeprom_init ] Message-Id: <20210629142336.750058-2-clg@kaod.org> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20hw: arm: aspeed: Enable mac0/1 instead of mac1/2 for g220aGuenter Roeck1-1/+1
According to its dts file in the Linux kernel, we need mac0 and mac1 enabled instead of mac1 and mac2. Also, g220a is based on aspeed-g5 (ast2500) which doesn't even have the third interface. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210810035742.550391-1-linux@roeck-us.net> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-20hw: arm: aspeed: Enable eth0 interface for aspeed-ast2600-evbGuenter Roeck1-1/+2
Commit 7582591ae7 ("aspeed: Support AST2600A1 silicon revision") switched the silicon revision for AST2600 to revision A1. On revision A1, the first Ethernet interface is operational. Enable it. Signed-off-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Cédric Le Goater <clg@kaod.org> Message-Id: <20210808200457.889955-1-linux@roeck-us.net> Signed-off-by: Cédric Le Goater <clg@kaod.org>
2021-09-13hw/arm/mps2.c: Mark internal-only I2C buses as 'full'Peter Maydell1-1/+11
The various MPS2 boards implemented in mps2.c have multiple I2C buses: a bus dedicated to the audio configuration, one for the LCD touchscreen controller, and two which are connected to the external Shield expansion connector. Mark the buses which are used only for board-internal devices as 'full' so that if the user creates i2c devices on the commandline without specifying a bus name then they will be connected to the I2C controller used for the Shield connector, where guest software will expect them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210903151435.22379-5-peter.maydell@linaro.org
2021-09-13hw/arm/mps2-tz.c: Mark internal-only I2C buses as 'full'Peter Maydell1-14/+43
The various MPS2 boards have multiple I2C buses: typically a bus dedicated to the audio configuration, one for the LCD touchscreen controller, one for a DDR4 EEPROM, and two which are connected to the external Shield expansion connector. Mark the buses which are used only for board-internal devices as 'full' so that if the user creates i2c devices on the commandline without specifying a bus name then they will be connected to the I2C controller used for the Shield connector, where guest software will expect them. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210903151435.22379-4-peter.maydell@linaro.org
2021-09-13hw/arm/mps2-tz.c: Add extra data parameter to MakeDevFnPeter Maydell1-13/+22
The mps2-tz boards use a data-driven structure to create the devices that sit behind peripheral protection controllers. Currently the functions which create these devices are passed an 'opaque' pointer which is always the address within the machine struct of the device to create, and some "all devices need this" information like irqs and addresses. If a specific device needs more information than this, it is currently not possible to pass that through from the PPCInfo data structure. Add support for passing an extra data parameter, so that we can more flexibly handle the needs of specific device types. To provide some type-safety we make this extra parameter a pointer to a union (which initially has no members). In particular, we would like to be able to indicate which of the i2c controllers are for on-board devices only and which are connected to the external 'shield' expansion port; a subsequent patch will use this mechanism for that purpose. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20210903151435.22379-3-peter.maydell@linaro.org
2021-09-13hw/arm/virt: add ITS support in virt GICShashi Mallela1-2/+27
Included creation of ITS as part of virt platform GIC initialization. This Emulated ITS model now co-exists with kvm ITS and is enabled in absence of kvm irq kernel support in a platform. Signed-off-by: Shashi Mallela <shashi.mallela@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20210910143951.92242-9-shashi.mallela@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-13hw/arm: Add support for kudo-bmc board.Chris Rauer1-0/+34
kudo-bmc is a board supported by OpenBMC. https://github.com/openbmc/openbmc/tree/master/meta-fii/meta-kudo Since v1: - hyphenated Cortex-A9 Tested: Booted kudo firmware. Signed-off-by: Chris Rauer <crauer@google.com> Reviewed-by: Patrick Venture <venture@google.com> Message-id: 20210907223234.1165705-1-crauer@google.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-09-01arm: Remove system_clock_scale globalPeter Maydell8-31/+5
All the devices that used to use system_clock_scale have now been converted to use Clock inputs instead, so the global is no longer needed; remove it and all the code that sets it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210812093356.1946-26-peter.maydell@linaro.org
2021-09-01hw/timer/stellaris-gptm: Use Clock input instead of system_clock_scalePeter Maydell1-3/+9
The stellaris-gptm timer currently uses system_clock_scale for one of its timer modes where the timer runs at the CPU clock rate. Make it use a Clock input instead. We don't try to make the timer handle changes in the clock frequency while the downcounter is running. This is not a change in behaviour from the previous system_clock_scale implementation -- we will pick up the new frequency only when the downcounter hits zero. Handling dynamic clock changes when the counter is running would require state that the current gptm implementation doesn't have. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-id: 20210812093356.1946-25-peter.maydell@linaro.org
2021-09-01hw/arm/stellaris: Split stellaris-gptm into its own filePeter Maydell2-320/+2
The implementation of the Stellaris general purpose timer module device stellaris-gptm is currently in the same source file as the board model. Split it out into its own source file in hw/timer. Apart from the new file comment headers and the Kconfig and meson.build changes, this is just code movement. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-id: 20210812093356.1946-24-peter.maydell@linaro.org
2021-09-01hw/arm/stellaris: Fix code style issues in GPTM codePeter Maydell1-5/+8
Fix the code style issues in the Stellaris general purpose timer module code, so that when we move it to a different file in a following patch checkpatch doesn't complain. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Message-id: 20210812093356.1946-23-peter.maydell@linaro.org
2021-09-01hw/arm/msf2-soc: Wire up refclkPeter Maydell1-0/+23
Wire up the refclk for the msf2 SoC. This SoC runs the refclk at a frequency which is programmably either /4, /8, /16 or /32 of the main CPU clock. We don't currently model the register which allows the guest to set the divisor, so implement the refclk as a fixed /32 of the CPU clock (which is the value of the divisor at reset). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-id: 20210812093356.1946-21-peter.maydell@linaro.org
2021-09-01hw/arm/msf2: Use Clock input to MSF2_SOC instead of m3clk propertyPeter Maydell2-12/+23
Instead of passing the MSF2 SoC an integer property specifying the CPU clock rate, pass it a Clock instead. This lets us wire that clock up to the armv7m object. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Message-id: 20210812093356.1946-20-peter.maydell@linaro.org
2021-09-01hw/arm/msf2_soc: Don't allocate separate MemoryRegionsPeter Maydell1-10/+7
In the realize method of the msf2-soc SoC object, we call g_new() to create new MemoryRegion objects for the nvm, nvm_alias, and sram. This is unnecessary; make these MemoryRegions member fields of the device state struct instead. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Message-id: 20210812093356.1946-19-peter.maydell@linaro.org
2021-09-01hw/arm/stellaris: Wire sysclk up to armv7mPeter Maydell1-1/+4
Connect the sysclk to the armv7m object. This board's SoC does not connect up the systick reference clock, so we don't need to connect a refclk. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Message-id: 20210812093356.1946-18-peter.maydell@linaro.org
2021-09-01hw/arm/stellaris: split stellaris_sys_init()Peter Maydell1-31/+25
Currently the stellaris_sys_init() function creates the TYPE_STELLARIS_SYS object, sets its properties, realizes it, maps its MMIO region and connects its IRQ. In order to support wiring the sysclk up to the armv7m object, we need to split this function apart, because to connect the clock output of the STELLARIS_SYS object to the armv7m object we need to create the STELLARIS_SYS object before the armv7m object, but we can't wire up the IRQ until after we've created the armv7m object. Remove the stellaris_sys_init() function, and instead put the create/configure/realize parts before we create the armv7m object and the mmio/irq connection parts afterwards. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Message-id: 20210812093356.1946-17-peter.maydell@linaro.org
2021-09-01hw/arm/nrf51: Wire up sysclkPeter Maydell1-0/+20
Wire up the sysclk input to the armv7m object. Strictly this SoC should not have a systick device at all, but our armv7m container object doesn't currently support disabling the systick device. For the moment, add a TODO comment, but note that this is why we aren't wiring up a refclk (no need for one). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Message-id: 20210812093356.1946-16-peter.maydell@linaro.org
2021-09-01hw/arm/stm32vldiscovery: Delete trailing blank linePeter Maydell1-1/+0
Delete the trailing blank line at the end of the source file. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-15-peter.maydell@linaro.org
2021-09-01hw/arm/stm32f405: Wire up sysclk and refclkPeter Maydell2-5/+37
Wire up the sysclk and refclk for the stm32f405 SoC. This SoC always runs the systick refclk at 1/8 the frequency of the main CPU clock, so the board code only needs to provide a single sysclk clock. Because there is only one board using this SoC, we convert the SoC and the board together, rather than splitting it into "add clock to SoC; connect clock in board; add error check in SoC code that clock is wired up". When the systick device starts honouring its clock inputs, this will fix an emulation inaccuracy in the netduinoplus2 board where the systick reference clock was running at 1MHz rather than 21MHz. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-14-peter.maydell@linaro.org
2021-09-01hw/arm/stm32f205: Wire up sysclk and refclkPeter Maydell2-5/+37
Wire up the sysclk and refclk for the stm32f205 SoC. This SoC always runs the systick refclk at 1/8 the frequency of the main CPU clock, so the board code only needs to provide a single sysclk clock. Because there is only one board using this SoC, we convert the SoC and the board together, rather than splitting it into "add clock to SoC; connect clock in board; add error check in SoC code that clock is wired up". When the systick device starts honouring its clock inputs, this will fix an emulation inaccuracy in the netduino2 board where the systick reference clock was running at 1MHz rather than 15MHz. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-13-peter.maydell@linaro.org
2021-09-01hw/arm/stm32f100: Wire up sysclk and refclkPeter Maydell2-5/+37
Wire up the sysclk and refclk for the stm32f100 SoC. This SoC always runs the systick refclk at 1/8 the frequency of the main CPU clock, so the board code only needs to provide a single sysclk clock. Because there is only one board using this SoC, we convert the SoC and the board together, rather than splitting it into "add clock to SoC; connect clock in board; add error check in SoC code that clock is wired up". When the systick device starts honouring its clock inputs, this will fix an emulation inaccuracy in the stm32vldiscovery board where the systick reference clock was running at 1MHz rather than 3MHz. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-12-peter.maydell@linaro.org
2021-09-01hw/arm: Don't allocate separate MemoryRegions in stm32 SoC realizePeter Maydell2-20/+14
In the realize methods of the stm32f100 and stm32f205 SoC objects, we call g_new() to create new MemoryRegion objects for the sram, flash, and flash_alias. This is unnecessary (and leaves open the possibility of leaking the allocations if we exit from realize with an error). Make these MemoryRegions member fields of the device state struct instead, as stm32f405 already does. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-11-peter.maydell@linaro.org
2021-09-01hw/arm/mps2.c: Connect up armv7m clocksPeter Maydell1-0/+15
Connect up the armv7m clocks on the mps2-an385/386/500/511. Connect up the armv7m object's clocks on the MPS boards defined in mps2.c. The documentation for these FPGA images doesn't specify what systick reference clock is used (if any), so for the moment we provide a 1MHz refclock, which will result in no behavioural change from the current hardwired 1MHz clock implemented in armv7m_systick.c:systick_scale(). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-9-peter.maydell@linaro.org
2021-09-01armsse: Wire up systick cpuclk clockPeter Maydell1-0/+3
Wire up the cpuclk for the systick devices to the SSE object's existing mainclk clock. We do not wire up the refclk because the SSE subsystems do not provide a refclk. (This is documented in the IoTKit and SSE-200 TRMs; the SSE-300 TRM doesn't mention it but we assume it follows the same approach.) When we update the systick device later to honour "no refclk connected" this will fix a minor emulation inaccuracy for the SSE-based boards. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-8-peter.maydell@linaro.org
2021-09-01hw/arm/armv7m: Create input clocksPeter Maydell1-0/+23
Create input clocks on the armv7m container object which pass through to the systick timers, so that users of the armv7m object can specify the clocks being used. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-7-peter.maydell@linaro.org
2021-09-01arm: Move system PPB container handling to armv7mPeter Maydell1-1/+99
Instead of having the NVIC device provide a single sysbus memory region covering the whole of the "System PPB" space, which implements the default behaviour for unimplemented ranges and provides the NS alias window to the sysregs as well as the main sysreg MR, move this handling to the container armv7m device. The NVIC now provides a single memory region which just implements the system registers. This consolidates all the handling of "map various devices in the PPB" into the armv7m container where it belongs. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-4-peter.maydell@linaro.org
2021-09-01arm: Move systick device creation from NVIC to ARMv7M objectPeter Maydell1-0/+125
There's no particular reason why the NVIC should be owning the SysTick device objects; move them into the ARMv7M container object instead, as part of consolidating the "create the devices which are built into an M-profile CPU and map them into their architected locations in the address space" work into one place. This involves temporarily creating a duplicate copy of the nvic_sysreg_ns_ops struct and its read/write functions (renamed as v7m_sysreg_ns_*), but we will delete the NVIC's copy of this code in a subsequent patch. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Luc Michel <luc@lmichel.fr> Message-id: 20210812093356.1946-3-peter.maydell@linaro.org
2021-09-01arm: Move M-profile RAS register block into its own devicePeter Maydell1-0/+12
Currently we implement the RAS register block within the NVIC device. It isn't really very tightly coupled with the NVIC proper, so instead move it out into a sysbus device of its own and have the top level ARMv7M container create it and map it into memory at the right address. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Luc Michel <luc@lmichel.fr> Reviewed-by: Damien Hedde <damien.hedde@greensocs.com> Message-id: 20210812093356.1946-2-peter.maydell@linaro.org
2021-09-01hw/arm/virt: target-arm: Add A64FX processor support to virt machineShuuichirou Ishii1-0/+1
Add -cpu a64fx to use A64FX processor when -machine virt option is specified. In addition, add a64fx to the Supported guest CPU types in the virt.rst document. Signed-off-by: Shuuichirou Ishii <ishii.shuuichir@fujitsu.com> Reviewed-by: Andrew Jones <drjones@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>