hw/arm: Add minimal support for the B-L475E-IOT01A board

This commit adds a new B-L475E-IOT01A board using the STM32L475VG SoC
as well as a dedicated documentation file.
The implementation is derive

hw/arm: Add minimal support for the B-L475E-IOT01A board

This commit adds a new B-L475E-IOT01A board using the STM32L475VG SoC
as well as a dedicated documentation file.
The implementation is derived from the Netduino Plus 2 machine.
There are no peripherals implemented yet, only memory regions.

Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Arnaud Minier <arnaud.minier@telecom-paris.fr>
Signed-off-by: Inès Varhol <ines.varhol@telecom-paris.fr>
Message-id: 20240108135849.351719-3-ines.varhol@telecom-paris.fr
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

show more ...

docs: use "buses" rather than "busses"

If "busses" might be encountered as a plural of "bus" (5 instances),
the correct spelling is "buses" (26 instances). Fixing those 5
instances makes the doc mor

docs: use "buses" rather than "busses"

If "busses" might be encountered as a plural of "bus" (5 instances),
the correct spelling is "buses" (26 instances). Fixing those 5
instances makes the doc more consistent.

Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Pavel Pisa <pisa@cmp.felk.cvut.cz>
Reviewed-by: Zhao Liu <zhao1.liu@intel.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

show more ...

hw: Replace anti-social QOM type names (again)

QOM type names containing ',' result in awful UI. We got rid of them
in v6.0.0 (commit e178113ff64 hw: Replace anti-social QOM type names).
A few have

hw: Replace anti-social QOM type names (again)

QOM type names containing ',' result in awful UI. We got rid of them
in v6.0.0 (commit e178113ff64 hw: Replace anti-social QOM type names).
A few have crept back since:

xlnx,cframe-reg
xlnx,efuse
xlnx,pmc-efuse-cache
xlnx,versal-cfu-apb
xlnx,versal-cfu-fdro
xlnx,versal-cfu-sfr
xlnx,versal-crl
xlnx,versal-efuse
xlnx,zynqmp-efuse

These are all device types. They can't be plugged with -device /
device_add, except for "xlnx,efuse" (I'm not sure that one is
intentional).

They *can* be used with -device / device_add to request help.
Usability is poor, though: you have to double the comma, like this:

$ qemu-system-aarch64 -device xlnx,,pmc-efuse-cache,help

They can also be used with -global, where you must *not* double the
comma:

$ qemu-system-aarch64 -global xlnx,efuse.drive-index=2

Trap for the unwary.

"xlnx,efuse", "xlnx,versal-efuse", "xlnx,pmc-efuse-cache",
"xlnx-zynqmp-efuse" are from v6.2.0, "xlnx,versal-crl" is from v7.1.0,
and the remainder are new.

Rename them all to "xlnx-FOO", like commit e178113ff64 did.

Reported-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Francisco Iglesias <francisco.iglesias@amd.com>
Message-ID: <20231117114457.177308-3-thuth@redhat.com>
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

docs/system/arm: Fix for rename of type "xlnx.bbram-ctrl"

Fixes: b65b4b7ae3c8 (xlnx-bbram: hw/nvram: Use dot in device type name)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[thuth: Use lon

docs/system/arm: Fix for rename of type "xlnx.bbram-ctrl"

Fixes: b65b4b7ae3c8 (xlnx-bbram: hw/nvram: Use dot in device type name)
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[thuth: Use longhand syntax to avoid problems with the "." in the name]
Reviewed-by: Peter Maydell <peter.maydell@linaro.org>
Message-ID: <20231117114457.177308-2-thuth@redhat.com>
Acked-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>

show more ...

docs: clean-up the xenpvh documentation

I noticed the code blocks where not rendering properly so thought I'd
better fix things up. So:

- Use better title for the machine type
- Explain why Xen

docs: clean-up the xenpvh documentation

I noticed the code blocks where not rendering properly so thought I'd
better fix things up. So:

- Use better title for the machine type
- Explain why Xen is a little different
- Add a proper anchor to the tpm-device link
- add newline so code block properly renders
- add some indentation to make continuation clearer

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Message-ID: <20231207130623.360473-1-alex.bennee@linaro.org>

show more ...

docs/system/arm/emulation.rst: spelling fix: Enhacements

Fixes: c7c807f6dd6d "target/arm: Implement FEAT_Pauth2"
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.m

docs/system/arm/emulation.rst: spelling fix: Enhacements

Fixes: c7c807f6dd6d "target/arm: Implement FEAT_Pauth2"
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>

show more ...

hw/arm/vexpress-a9: Remove useless mapping of RAM at address 0

On the vexpress-a9 board we try to map both RAM and flash to address 0,
as seen in "info mtree":

address-space: memory
0000000000000

hw/arm/vexpress-a9: Remove useless mapping of RAM at address 0

On the vexpress-a9 board we try to map both RAM and flash to address 0,
as seen in "info mtree":

address-space: memory
0000000000000000-ffffffffffffffff (prio 0, i/o): system
0000000000000000-0000000003ffffff (prio 0, romd): alias vexpress.flashalias @vexpress.flash0 0000000000000000-0000000003ffffff
0000000000000000-0000000003ffffff (prio 0, ram): alias vexpress.lowmem @vexpress.highmem 0000000000000000-0000000003ffffff
0000000010000000-0000000010000fff (prio 0, i/o): arm-sysctl
0000000010004000-0000000010004fff (prio 0, i/o): pl041
(etc)

The flash "wins" and the RAM mapping is useless (but also harmless).

This happened as a result of commit 6ec1588e in 2014, which changed
"we always map the RAM to the low addresses for vexpress-a9" to "we
always map flash in the low addresses", but forgot to stop mapping
the RAM.

In real hardware, this low part of memory is remappable, both at
runtime by the guest writing to a control register, and configurably
as to what you get out of reset -- you can have the first flash
device, or the second, or the DDR2 RAM, or the external AXI bus
(which for QEMU means "nothing there"). In an ideal world we would
support that remapping both at runtime and via a machine property to
select the out-of-reset behaviour.

Pending anybody caring enough to implement the full remapping
behaviour:
* remove the useless mapped-but-inaccessible lowram MR
* document that QEMU doesn't support remapping of low memory

Fixes: 6ec1588e ("hw/arm/vexpress: Alias NOR flash at 0 for vexpress-a9")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1761
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20231103185602.875849-1-peter.maydell@linaro.org

show more ...

target/arm: Implement Neoverse N2 CPU model

Implement a model of the Neoverse N2 CPU. This is an Armv9.0-A
processor very similar to the Cortex-A710. The differences are:
* no FEAT_EVT
* FEAT_DGH

target/arm: Implement Neoverse N2 CPU model

Implement a model of the Neoverse N2 CPU. This is an Armv9.0-A
processor very similar to the Cortex-A710. The differences are:
* no FEAT_EVT
* FEAT_DGH (data gathering hint)
* FEAT_NV (not yet implemented in QEMU)
* Statistical Profiling Extension (not implemented in QEMU)
* 48 bit physical address range, not 40
* CTR_EL0.DIC = 1 (no explicit icache cleaning needed)
* PMCR_EL0.N = 6 (always 6 PMU counters, not 20)

Because it has 48-bit physical address support, we can use
this CPU in the sbsa-ref board as well as the virt board.

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Tested-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Message-id: 20230915185453.1871167-3-peter.maydell@linaro.org

show more ...

target/arm: Implement FEAT_HPMN0

FEAT_HPMN0 is a small feature which defines that it is valid for
MDCR_EL2.HPMN to be set to 0, meaning "no PMU event counters provided
to an EL1 guest" (previously t

target/arm: Implement FEAT_HPMN0

FEAT_HPMN0 is a small feature which defines that it is valid for
MDCR_EL2.HPMN to be set to 0, meaning "no PMU event counters provided
to an EL1 guest" (previously this setting was reserved). QEMU's
implementation almost gets HPMN == 0 right, but we need to fix
one check in pmevcntr_is_64_bit(). That is enough for us to
advertise the feature in the 'max' CPU.

(We don't need to make the behaviour conditional on feature
presence, because the FEAT_HPMN0 behaviour is within the range
of permitted UNPREDICTABLE behaviour for a non-FEAT_HPMN0
implementation.)

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-id: 20230921185445.3339214-1-peter.maydell@linaro.org

show more ...