#
f503bc4b |
| 04-Jan-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/arm: Add missing QOM parent for v7-M SoCs
QDev objects created with qdev_new() need to manually add their parent relationship with object_property_add_child().
Signed-off-by: Philippe Mathieu-Da
hw/arm: Add missing QOM parent for v7-M SoCs
QDev objects created with qdev_new() need to manually add their parent relationship with object_property_add_child().
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20240104141159.53883-1-philmd@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
#
f503bc4b |
| 04-Jan-2024 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/arm: Add missing QOM parent for v7-M SoCs
QDev objects created with qdev_new() need to manually add their parent relationship with object_property_add_child().
Signed-off-by: Philippe Mathieu-Da
hw/arm: Add missing QOM parent for v7-M SoCs
QDev objects created with qdev_new() need to manually add their parent relationship with object_property_add_child().
Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20240104141159.53883-1-philmd@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
Revision tags: v8.1.4, v7.2.8, v8.2.0, v8.2.0-rc4, v8.2.0-rc3, v8.2.0-rc2, v8.2.0-rc1, v7.2.7, v8.1.3 |
|
#
d6528660 |
| 17-Nov-2023 |
Philippe Mathieu-Daudé <philmd@linaro.org> |
hw/arm/stm32f100: Report error when incorrect CPU is used
The 'stm32vldiscovery' machine ignores the CPU type requested by the command line. This might confuse users, since the following will create
hw/arm/stm32f100: Report error when incorrect CPU is used
The 'stm32vldiscovery' machine ignores the CPU type requested by the command line. This might confuse users, since the following will create a machine with a Cortex-M3 CPU:
$ qemu-system-aarch64 -M stm32vldiscovery -cpu neoverse-n1
Set the MachineClass::valid_cpu_types field (introduced in commit c9cf636d48 "machine: Add a valid_cpu_types property"). Remove the now unused MachineClass::default_cpu_type field.
We now get:
$ qemu-system-aarch64 -M stm32vldiscovery -cpu neoverse-n1 qemu-system-aarch64: Invalid CPU type: neoverse-n1-arm-cpu The valid types are: cortex-m3-arm-cpu
Since the SoC family can only use Cortex-M3 CPUs, hard-code the CPU type name at the SoC level, removing the QOM property entirely.
Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org> Reviewed-by: Gavin Shan <gshan@redhat.com> Message-id: 20231117071704.35040-5-philmd@linaro.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|
Revision tags: v8.2.0-rc0, v8.1.2, v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0, v8.0.3, v7.2.4, v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4 |
|
#
761c532a |
| 23-Aug-2022 |
Peter Maydell <peter.maydell@linaro.org> |
target/arm: Make boards pass base address to armv7m_load_kernel()
Currently armv7m_load_kernel() takes the size of the block of memory where it should load the initial guest image, but assumes that
target/arm: Make boards pass base address to armv7m_load_kernel()
Currently armv7m_load_kernel() takes the size of the block of memory where it should load the initial guest image, but assumes that it should always load it at address 0. This happens to be true of all our M-profile boards at the moment, but it isn't guaranteed to always be so: M-profile CPUs can be configured (via init-svtor and init-nsvtor, which match equivalent hardware configuration signals) to have the initial vector table at any address, not just zero. (For instance the Teeny board has the boot ROM at address 0x0200_0000.)
Add a base address argument to armv7m_load_kernel(), so that callers now pass in both base address and size. All the current callers pass 0, so this is not a behaviour change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220823160417.3858216-3-peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
Revision tags: v8.2.0-rc0, v8.1.2, v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0, v8.0.3, v7.2.4, v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4 |
|
#
761c532a |
| 23-Aug-2022 |
Peter Maydell <peter.maydell@linaro.org> |
target/arm: Make boards pass base address to armv7m_load_kernel()
Currently armv7m_load_kernel() takes the size of the block of memory where it should load the initial guest image, but assumes that
target/arm: Make boards pass base address to armv7m_load_kernel()
Currently armv7m_load_kernel() takes the size of the block of memory where it should load the initial guest image, but assumes that it should always load it at address 0. This happens to be true of all our M-profile boards at the moment, but it isn't guaranteed to always be so: M-profile CPUs can be configured (via init-svtor and init-nsvtor, which match equivalent hardware configuration signals) to have the initial vector table at any address, not just zero. (For instance the Teeny board has the boot ROM at address 0x0200_0000.)
Add a base address argument to armv7m_load_kernel(), so that callers now pass in both base address and size. All the current callers pass 0, so this is not a behaviour change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220823160417.3858216-3-peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
Revision tags: v8.2.0-rc0, v8.1.2, v8.1.1, v7.2.6, v8.0.5, v8.1.0, v8.1.0-rc4, v8.1.0-rc3, v7.2.5, v8.0.4, v8.1.0-rc2, v8.1.0-rc1, v8.1.0-rc0, v8.0.3, v7.2.4, v8.0.2, v8.0.1, v7.2.3, v7.2.2, v8.0.0, v8.0.0-rc4, v8.0.0-rc3, v7.2.1, v8.0.0-rc2, v8.0.0-rc1, v8.0.0-rc0, v7.2.0, v7.2.0-rc4, v7.2.0-rc3, v7.2.0-rc2, v7.2.0-rc1, v7.2.0-rc0, v7.1.0, v7.1.0-rc4 |
|
#
761c532a |
| 23-Aug-2022 |
Peter Maydell <peter.maydell@linaro.org> |
target/arm: Make boards pass base address to armv7m_load_kernel()
Currently armv7m_load_kernel() takes the size of the block of memory where it should load the initial guest image, but assumes that
target/arm: Make boards pass base address to armv7m_load_kernel()
Currently armv7m_load_kernel() takes the size of the block of memory where it should load the initial guest image, but assumes that it should always load it at address 0. This happens to be true of all our M-profile boards at the moment, but it isn't guaranteed to always be so: M-profile CPUs can be configured (via init-svtor and init-nsvtor, which match equivalent hardware configuration signals) to have the initial vector table at any address, not just zero. (For instance the Teeny board has the boot ROM at address 0x0200_0000.)
Add a base address argument to armv7m_load_kernel(), so that callers now pass in both base address and size. All the current callers pass 0, so this is not a behaviour change.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20220823160417.3858216-3-peter.maydell@linaro.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
show more ...
|
Revision tags: v7.1.0-rc3, v7.1.0-rc2, v7.1.0-rc1, v7.1.0-rc0, v7.0.0, v7.0.0-rc4, v7.0.0-rc3, v7.0.0-rc2, v7.0.0-rc1, v7.0.0-rc0, v6.1.1, v6.2.0, v6.2.0-rc4, v6.2.0-rc3, v6.2.0-rc2, v6.2.0-rc1, v6.2.0-rc0, v6.0.1, v6.1.0, v6.1.0-rc4 |
|
#
683754c7 |
| 12-Aug-2021 |
Peter Maydell <peter.maydell@linaro.org> |
arm: Remove system_clock_scale global
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 th
arm: Remove system_clock_scale global
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
show more ...
|
#
7580384b |
| 12-Aug-2021 |
Peter Maydell <peter.maydell@linaro.org> |
hw/arm/stm32vldiscovery: Delete trailing blank line
Delete the trailing blank line at the end of the source file.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alexandre Ioos
hw/arm/stm32vldiscovery: Delete trailing blank line
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
show more ...
|
#
b5ff0c61 |
| 12-Aug-2021 |
Peter Maydell <peter.maydell@linaro.org> |
hw/arm/stm32f100: Wire up sysclk and refclk
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 cod
hw/arm/stm32f100: Wire up sysclk and refclk
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
show more ...
|
Revision tags: v6.1.0-rc3, v6.1.0-rc2, v6.1.0-rc1, v6.1.0-rc0 |
|
#
2ac2410c |
| 17-Jun-2021 |
Alexandre Iooss <erdnaxe@crans.org> |
stm32vldiscovery: Add the STM32VLDISCOVERY Machine
This is a Cortex-M3 based machine. Information can be found at: https://www.st.com/en/evaluation-tools/stm32vldiscovery.html
Signed-off-by: Alexan
stm32vldiscovery: Add the STM32VLDISCOVERY Machine
This is a Cortex-M3 based machine. Information can be found at: https://www.st.com/en/evaluation-tools/stm32vldiscovery.html
Signed-off-by: Alexandre Iooss <erdnaxe@crans.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-id: 20210617165647.2575955-3-erdnaxe@crans.org Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
show more ...
|