aboutsummaryrefslogtreecommitdiff
path: root/include/hw/arm
AgeCommit message (Collapse)Author
2019-07-22hw/arm/fsl-imx6ul.c: Remove dead SMP-related codePeter Maydell
The i.MX6UL always has a single Cortex-A7 CPU (we set FSL_IMX6UL_NUM_CPUS to 1 in line with this). This means that all the code in fsl-imx6ul.c to handle multiple CPUs is dead code, and Coverity is now complaining that it is unreachable (CID 1403008, 1403011). Remove the unreachable code and the only-executes-once loops, and replace the single-entry cpu[] array in the FSLIMX6ULState with a simple cpu member. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190712115030.26895-1-peter.maydell@linaro.org
2019-07-01hw/misc/aspeed_xdma: New deviceEddie James
The XDMA engine embedded in the Aspeed SOCs performs PCI DMA operations between the SOC (acting as a BMC) and a host processor in a server. The XDMA engine exists on the AST2400, AST2500, and AST2600 SOCs, so enable it for all of those. Add trace events on the important register writes in the XDMA engine. Signed-off-by: Eddie James <eajames@linux.ibm.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Cédric Le Goater <clg@kaod.org> Message-id: 20190618165311.27066-21-clg@kaod.org [clg: - changed title ] Signed-off-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: add support for multiple NICsCédric Le Goater
The Aspeed SoCs have two MACs. Extend the Aspeed model to support a second NIC. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-7-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: introduce a configurable number of CPU per machineCédric Le Goater
The current models of the Aspeed SoCs only have one CPU but future ones will support SMP. Introduce a new num_cpus field at the SoC class level to define the number of available CPUs per SoC and also introduce a 'num-cpus' property to activate the CPUs configured for the machine. The max_cpus limit of the machine should depend on the SoC definition but, unfortunately, these values are not available when the machine class is initialized. This is the reason why we add a check on num_cpus in the AspeedSoC realize handler. SMP support will be activated when models for such SoCs are implemented. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-6-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01hw/arm/aspeed: Add RTC to SoCJoel Stanley
All systems have an RTC. The IRQ is hooked up but the model does not use it at this stage. There is no guest code that uses it, so this limitation is acceptable. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190618165311.27066-5-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: add a per SoC mapping for the memory spaceCédric Le Goater
This will simplify the definition of new SoCs, like the AST2600 which should use a slightly different address space and have a different set of controllers. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-3-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01aspeed: add a per SoC mapping for the interrupt spaceCédric Le Goater
This will simplify the definition of new SoCs, like the AST2600 which should use a different CPU and a different IRQ number layout. Signed-off-by: Cédric Le Goater <clg@kaod.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Joel Stanley <joel@jms.id.au> Message-id: 20190618165311.27066-2-clg@kaod.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01i.mx7d: pci: Update PCI IRQ mapping to match HWAndrey Smirnov
Datasheet for i.MX7 is incorrect and i.MX7's PCI IRQ mapping matches that of i.MX6: * INTD/MSI 122 * INTC 123 * INTB 124 * INTA 125 Fix all of the relevant code to reflect that fact. Needed by latest Linux kernels. (Reference: Linux kernel commit 538d6e9d597584e80 from an NXP employee confirming that the datasheet is incorrect and with a report of a test against hardware.) Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: added ref to kernel commit confirming the datasheet error] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01i.mx7d: Add no-op/unimplemented PCIE PHY IP blockAndrey Smirnov
Add no-op/unimplemented PCIE PHY IP block. Needed by new kernels to use PCIE. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-07-01i.mx7d: Add no-op/unimplemented APBH DMA moduleAndrey Smirnov
Instantiate no-op APBH DMA module. Needed to boot latest Linux kernel. Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Peter Maydell <peter.maydell@linaro.org> Cc: Michael S. Tsirkin <mst@redhat.com> Cc: qemu-devel@nongnu.org Cc: qemu-arm@nongnu.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
2019-06-17hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boardsPeter Maydell
The SSE-200 hardware has configurable integration settings which determine whether its two CPUs have the FPU and DSP: * CPU0_FPU (default 0) * CPU0_DSP (default 0) * CPU1_FPU (default 1) * CPU1_DSP (default 1) Similarly, the IoTKit has settings for its single CPU: * CPU0_FPU (default 1) * CPU0_DSP (default 1) Of our four boards that use either the IoTKit or the SSE-200: * mps2-an505, mps2-an521 and musca-a use the default settings * musca-b1 enables FPU and DSP on both CPUs Currently QEMU models all these boards using CPUs with both FPU and DSP enabled. This means that we are incorrect for mps2-an521 and musca-a, which should not have FPU or DSP on CPU0. Create QOM properties on the ARMSSE devices corresponding to the default h/w integration settings, and make the Musca-B1 board enable FPU and DSP on both CPUs. This fixes the mps2-an521 and musca-a behaviour, and leaves the musca-b1 and mps2-an505 behaviour unchanged. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190517174046.11146-5-peter.maydell@linaro.org
2019-06-17hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPUPeter Maydell
Create "vfp" and "dsp" properties on the armv7m container object which will be forwarded to its CPU object, so that SoCs can configure whether the CPU has these features. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Message-id: 20190517174046.11146-4-peter.maydell@linaro.org
2019-06-12Supply missing header guardsMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190604181618.19980-5-armbru@redhat.com>
2019-06-12Normalize position of header guardMarkus Armbruster
This is the common header guard idiom: /* * File comment */ #ifndef GUARD_SYMBOL_H #define GUARD_SYMBOL_H ... actual contents ... #endif A few of our headers have some #include before the guard. target/tilegx/spr_def_64.h has #ifndef __DOXYGEN__ outside the guard. A few more have the #define elsewhere. Change them to match the common idiom. For spr_def_64.h, that means dropping #ifndef __DOXYGEN__. While there, rename guard symbols to make scripts/clean-header-guards.pl happy. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190604181618.19980-2-armbru@redhat.com> [Rebased with conflicts resolved automatically]
2019-06-12Include qemu-common.h exactly where neededMarkus Armbruster
No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]
2019-05-24hw/arm/bcm2835: Use object_initialize() on PL011StatePhilippe Mathieu-Daudé
To be coherent with the other peripherals contained in the BCM2835PeripheralState structure, directly allocate the PL011State (instead of using the pl011 uart as a pointer to a SysBusDevice). Initialize the PL011State with object_initialize() instead of object_new(). Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190507163416.24647-6-philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-05-24hw/arm/bcm2835: Use TYPE_PL011 instead of hardcoded stringPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-Id: <20190507163416.24647-5-philmd@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-05-23hw/arm/exynos4210: QOM'ify the Exynos4210 SoCPhilippe Mathieu-Daudé
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20190520214342.13709-5-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-05-23arm: Rename hw/arm/arm.h to hw/arm/boot.hPeter Maydell
The header file hw/arm/arm.h now includes only declarations relating to hw/arm/boot.c functionality. Rename it accordingly, and adjust its header comment. The bulk of this commit was created via perl -pi -e 's|hw/arm/arm.h|hw/arm/boot.h|' hw/arm/*.c include/hw/arm/*.h In a few cases we can just delete the #include: hw/arm/msf2-soc.c, include/hw/arm/aspeed_soc.h and include/hw/arm/bcm2836.h did not require it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190516163857.6430-4-peter.maydell@linaro.org
2019-05-23arm: Move system_clock_scale to armv7m_systick.hPeter Maydell
The system_clock_scale global is used only by the armv7m systick device; move the extern declaration to the armv7m_systick.h header, and expand the comment to explain what it is and that it should ideally be replaced with a different approach. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190516163857.6430-2-peter.maydell@linaro.org
2019-05-13Clean up decorations and whitespace around header guardsMarkus Armbruster
Cleaned up with scripts/clean-header-guards.pl. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190315145123.28030-9-armbru@redhat.com>
2019-05-07arm: aspeed: Set SDRAM sizeJoel Stanley
We currently use Qemu's default of 128MB. As we know how much ram each machine ships with, make it easier on users by setting a default. It can still be overridden with -m on the command line. Signed-off-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190503022958.1394-1-joel@jms.id.au Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-05-07hw/arm/virt: Support firmware configuration with -blockdevMarkus Armbruster
The ARM virt machines put firmware in flash memory. To configure it, you use -drive if=pflash,unit=0,... and optionally -drive if=pflash,unit=1,... Why two -drive? This permits setting up one part of the flash memory read-only, and the other part read/write. It also makes upgrading firmware on the host easier. Below the hood, we get two separate flash devices, because we were too lazy to improve our flash device models to support sector protection. The problem at hand is to do the same with -blockdev somehow, as one more step towards deprecating -drive. We recently solved this problem for x86 PC machines, in commit ebc29e1beab. See the commit message for design rationale. This commit solves it for ARM virt basically the same way: new machine properties pflash0, pflash1 forward to the onboard flash devices' properties. Requires creating the onboard devices in the .instance_init() method virt_instance_init(). The existing code to pick up drives defined with -drive if=pflash is replaced by code to desugar into the machine properties. There are a few behavioral differences, though: * The flash devices are always present (x86: only present if configured) * Flash base addresses and sizes are fixed (x86: sizes depend on images, mapped back to back below a fixed address) * -bios configures contents of first pflash (x86: -bios configures ROM contents) * -bios is rejected when first pflash is also configured with -machine pflash0=... (x86: bios is silently ignored then) * -machine pflash1=... does not require -machine pflash0=... (x86: it does). The actual code is a bit simpler than for x86 mostly due to the first two differences. Before the patch, all the action is in create_flash(), called from the machine's .init() method machvirt_init(): main() machine_run_board_init() machvirt_init() create_flash() create_one_flash() for flash[0] create configure includes obeying -drive if=pflash,unit=0 realize map fall back to -bios create_one_flash() for flash[1] create configure includes obeying -drive if=pflash,unit=1 realize map update FDT To make the machine properties work, we need to move device creation to its .instance_init() method virt_instance_init(). Another complication is machvirt_init()'s computation of @firmware_loaded: it predicts what create_flash() will do. Instead of predicting what create_flash()'s replacement virt_firmware_init() will do, I decided to have virt_firmware_init() return what it did. Requires calling it a bit earlier. Resulting call tree: main() current_machine = object_new() ... virt_instance_init() virt_flash_create() virt_flash_create1() for flash[0] create configure: set defaults become child of machine [NEW] add machine prop pflash0 as alias for drive [NEW] virt_flash_create1() for flash[1] create configure: set defaults become child of machine [NEW] add machine prop pflash1 as alias for drive [NEW] for all machine props from the command line: machine_set_property() ... property_set_alias() for machine props pflash0, pflash1 ... set_drive() for cfi.pflash01 prop drive this is how -machine pflash0=... etc set machine_run_board_init(current_machine); virt_firmware_init() pflash_cfi01_legacy_drive() legacy -drive if=pflash,unit=0 and =1 [NEW] virt_flash_map() virt_flash_map1() for flash[0] configure: num-blocks realize map virt_flash_map1() for flash[1] configure: num-blocks realize map fall back to -bios virt_flash_fdt() update FDT You have László to thank for making me explain this in detail. Signed-off-by: Markus Armbruster <armbru@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-id: 20190416091348.26075-4-armbru@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-29hw/devices: Move TI touchscreen declarations into a new headerPhilippe Mathieu-Daudé
Since uWireSlave is only used in this new header, there is no need to expose it via "qemu/typedefs.h". Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190412165416.7977-9-philmd@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-04-29hw/arm/smmuv3: Remove SMMUNotifierNodeEric Auger
The SMMUNotifierNode struct is not necessary and brings extra complexity so let's remove it. We now directly track the SMMUDevices which have registered IOMMU MR notifiers. This is inspired from the same transformation on intel-iommu done in commit b4a4ba0d68f50f218ee3957b6638dbee32a5eeef ("intel-iommu: remove IntelIOMMUNotifierNode") Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Message-id: 20190409160219.19026-1-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-05hw/arm/virt: Dynamic memory map depending on RAM requirementsEric Auger
Up to now the memory map has been static and the high IO region base has always been 256GiB. This patch modifies the virt_set_memmap() function, which freezes the memory map, so that the high IO range base becomes floating, located after the initial RAM and the device memory. The function computes - the base of the device memory, - the size of the device memory, - the high IO region base - the highest GPA used in the memory map. Entries of the high IO region are assigned a base address. The device memory is initialized. The highest GPA used in the memory map will be used at VM creation to choose the requested IPA size. Setting all the existing highmem IO regions beyond the RAM allows to have a single contiguous RAM region (initial RAM and possible hotpluggable device memory). That way we do not need to do invasive changes in the EDK2 FW to support a dynamic RAM base. Still the user cannot request an initial RAM size greater than 255GB. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190304101339.25970-8-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-05hw/arm/virt: Split the memory map descriptionEric Auger
In the prospect to introduce an extended memory map supporting more RAM, let's split the memory map array into two parts: - the former a15memmap, renamed base_memmap, contains regions below and including the RAM. MemMapEntries initialized in this array have a static size and base address. - extended_memmap, only initialized with entries located after the RAM. MemMapEntries initialized in this array only get their size initialized. Their base address is dynamically computed depending on the the top of the RAM, with same alignment as their size. Eventually base_memmap entries are copied into the extended_memmap array. Using two separate arrays however clarifies which entries are statically allocated and those which are dynamically allocated. This new split will allow to grow the RAM size without changing the description of the high IO entries. We introduce a new virt_set_memmap() helper function which "freezes" the memory map. We call it in machvirt_init as memory attributes of the machine are not yet set when virt_instance_init() gets called. The memory map is unchanged (the top of the initial RAM still is 256GiB). Then come the high IO regions with same layout as before. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190304101339.25970-4-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-03-05hw/arm/virt: Rename highmem IO regionsEric Auger
In preparation for a split of the memory map into a static part and a dynamic part floating after the RAM, let's rename the regions located after the RAM Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-id: 20190304101339.25970-3-eric.auger@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-28hw/arm/armsse: Wire up the MHUsPeter Maydell
Create and connect the MHUs in the SSE-200. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190219125808.25174-3-peter.maydell@linaro.org
2019-02-21hw/arm/armsse: Make 0x5... alias region work for per-CPU devicesPeter Maydell
The region 0x40010000 .. 0x4001ffff and its secure-only alias at 0x50010000... are for per-CPU devices. We implement this by giving each CPU its own container memory region, where the per-CPU devices live. Unfortunately, the alias region which makes devices mapped at 0x4... addresses also appear at 0x5... is only implemented in the overall "all CPUs" container. The effect of this bug is that the CPU_IDENTITY register block appears only at 0x4001f000, but not at the 0x5001f000 alias where it should also appear. Guests (like very recent Arm Trusted Firmware-M) which try to access it at 0x5001f000 will crash. Fix this by moving the handling for this alias from the "all CPUs" container to the per-CPU container. (We leave the aliases for 0x1... and 0x3... in the overall container, because there are no per-CPU devices there.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20190215180500.6906-1-peter.maydell@linaro.org Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
2019-02-21hw/arm/armsse: Allow boards to specify init-svtorPeter Maydell
The Musca boards have DAPLink firmware that sets the initial secure VTOR value (the location of the vector table) differently depending on the boot mode (from flash, from RAM, etc). Export the init-svtor as a QOM property of the ARMSSE object so that the board can change it. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-21hw/arm/armsse: Document SRAM_ADDR_WIDTH property in header commentPeter Maydell
In commit 4b635cf7a95e501211 we added a QOM property to the ARMSSE object, but forgot to add it to the documentation comment in the header. Correct the omission. Fixes: 4b635cf7a95e501211 ("hw/arm/armsse: Make SRAM bank size configurable") Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
2019-02-01arm: Instantiate NRF51 special NVM's and NVMCSteffen Görtz
Instantiates UICR, FICR, FLASH and NVMC in nRF51 SOC. Signed-off-by: Steffen Görtz <contrib@steffen-goertz.de> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20190201023357.22596-3-stefanha@redhat.com Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-02-01hw/arm/armsse: Add SSE-200 modelPeter Maydell
Add a model of the SSE-200, now we have put in all the code that lets us make it different from the IoTKit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-22-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Add CPU_IDENTITY block to SSE-200Peter Maydell
Instantiate a copy of the CPU_IDENTITY register block for each CPU in an SSE-200. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-21-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Add unimplemented-device stub for CPU local control registersPeter Maydell
The SSE-200 has a "CPU local security control" register bank; add an unimplemented-device stub for it. (The register bank has only one interesting register, which allows the guest to lock down changes to various CPU registers so they cannot be modified further. We don't support that in our Cortex-M33 model anyway.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-19-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Add unimplemented-device stub for cache control registersPeter Maydell
The SSE-200 gives each CPU a register bank to use to control its L1 instruction cache. Put in an unimplemented-device stub for this. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-18-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Add unimplemented-device stubs for PPUsPeter Maydell
Add unimplemented-device stubs for the various Power Policy Unit devices that the SSE-200 has. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-17-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Add unimplemented-device stubs for MHUsPeter Maydell
The SSE-200 has two Message Handling Units (MHUs), which sit behind the APB PPC0. Wire up some unimplemented-device stubs for these, since we don't yet implement a real model of this device. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-16-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Put each CPU in its own cluster objectPeter Maydell
Create a cluster object to hold each CPU in the SSE. They are logically distinct and may be configured differently (for instance one may not have an FPU where the other does). Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-14-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Give each CPU its own view of memoryPeter Maydell
Give each CPU its own container memory region. This is necessary for two reasons: * some devices are instantiated one per CPU and the CPU sees only its own device * since a memory region can only be put into one container, we must give each armv7m object a different MemoryRegion as its 'memory' property, or a dual-CPU configuration will assert on realize when the second armv7m object tries to put the MR into a container when it is already in the first armv7m object's container Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-13-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Support dual-CPU configurationPeter Maydell
The SSE-200 has two Cortex-M33 CPUs. These see the same view of memory, with the exception of the "private CPU region" which has per-CPU devices. Internal device interrupts for SSE-200 devices are mostly wired up to both CPUs, with the exception of a few per-CPU devices. External GPIO inputs on the SSE-200 device are provided for the second CPU's interrupts above 32, as is already the case for the first CPU. Refactor the code to support creation of multiple CPUs. For the moment we leave all CPUs with the same view of memory: this will not work in the multiple-CPU case, but we will fix this in the following commit. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-12-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Make SRAM bank size configurablePeter Maydell
For the IoTKit the SRAM bank size is always 32K (15 bits); for the SSE-200 this is a configurable parameter, which defaults to 32K but can be changed when it is built into a particular SoC. For instance the Musca-B1 board sets it to 128K (17 bits). Make the bank size a QOM property. We follow the SSE-200 hardware in naming the parameter SRAM_ADDR_WIDTH, which specifies the number of address bits of a single SRAM bank. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-11-peter.maydell@linaro.org
2019-02-01hw/arm/armsse: Make number of SRAM banks parameterisedPeter Maydell
The SSE-200 has four banks of SRAM, each with its own Memory Protection Controller, where the IoTKit has only one. Make the number of SRAM banks a field in ARMSSEInfo. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-10-peter.maydell@linaro.org
2019-02-01hw/arm/iotkit: Rename files to hw/arm/armsse.[ch]Peter Maydell
Rename the files that used to be iotkit.[ch] to armsse.[ch] to reflect the fact they new cover multiple Arm subsystems for embedded. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-8-peter.maydell@linaro.org
2019-02-01hw/arm/iotkit: Refactor into abstract base class and subclassPeter Maydell
The Arm SSE-200 Subsystem for Embedded is a revised and extended version of the older IoTKit SoC. Prepare for adding a model of it by refactoring the IoTKit code into an abstract base class which contains the functionality, driven by a class data block specific to each subclass. (This is the same approach used by the existing bcm283x SoC family implementation.) Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-6-peter.maydell@linaro.org
2019-02-01hw/arm/iotkit: Rename IoTKit to ARMSSEPeter Maydell
The Arm IoTKit was effectively the forerunner of a series of subsystems for embedded SoCs, named the SSE-050, SSE-100 and SSE-200: https://developer.arm.com/products/system-design/subsystems These are generally quite similar, though later iterations have extra devices that earlier ones do not. We want to add a model of the SSE-200, which means refactoring the IoTKit code into an abstract base class and subclasses (using the same design that the bcm283x SoC and Aspeed SoC family implementations do). As a first step, rename the IoTKit struct and QOM macros to ARMSSE, which is what we're going to name the base class. We temporarily retain TYPE_IOTKIT to avoid changing the code that instantiates a TYPE_IOTKIT device here and then changing it back again when it is re-introduced as a subclass. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-5-peter.maydell@linaro.org
2019-02-01armv7m: Pass through start-powered-off CPU propertyPeter Maydell
Expose "start-powered-off" as a property of the ARMv7M container, which we just pass through to the CPU object in the same way that we do for "init-svtor" and "idau". (We want this for the SSE-200, which powers up only the first CPU at reset and leaves the second powered down.) As with the other CPU properties here, we can't just use alias properties, because the CPU QOM object is not created until armv7m realize time. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20190121185118.18550-4-peter.maydell@linaro.org
2019-01-29arm: Stub out NRF51 TWI magnetometer/accelerometer detectionSteffen Görtz
Recent microbit firmwares panic if the TWI magnetometer/accelerometer devices are not detected during startup. We don't implement TWI (I2C) so let's stub out these devices just to let the firmware boot. Signed-off by: Steffen Görtz <contrib@steffen-goertz.de> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Message-id: 20190110094020.18354-2-stefanha@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> [PMM: fixed comment style] Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-01-22hw/pcmcia: Remove PCMCIACardState from "qemu/typedefs.h"Philippe Mathieu-Daudé
There is only one header file requiring this typedef (hw/arm/pxa.h), let it include "hw/pcmcia.h" directly to simplify "qemu/typedefs.h". To clean "qemu/typedefs.h", move the declaration to "hw/pcmcia.h" (removing the forward declaration). Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> [thuth: slightly tweaked commit message] Signed-off-by: Thomas Huth <thuth@redhat.com>
generated by cgit v1.2.3 (git 2.26.2) at 2025-03-16 11:01:14 +0000