+ Cédric for Aspeed
On 12/3/25 11:20, Peter Maydell wrote:
On Wed, 12 Mar 2025 at 09:40, Thomas Huth <th...@redhat.com> wrote:
On 25/02/2025 19.04, Peter Maydell wrote:
From: Bernhard Beschow <shen...@gmail.com>
As a first step, implement the bare minimum: CPUs, RAM, interrupt controller,
serial. All other devices of the A53 memory map are represented as
TYPE_UNIMPLEMENTED_DEVICE, i.e. the whole memory map is provided. This allows
for running Linux without it crashing due to invalid memory accesses.
Signed-off-by: Bernhard Beschow <shen...@gmail.com>
Message-id: 20250223114708.1780-5-shen...@gmail.com
Reviewed-by: Peter Maydell <peter.mayd...@linaro.org>
[PMM: drop 'static const' from serial_table[] definition to avoid
compile failure on GCC 7.5]
Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
---
...
+static const TypeInfo fsl_imx8mp_types[] = {
+ {
+ .name = TYPE_FSL_IMX8MP,
+ .parent = TYPE_DEVICE,
+ .instance_size = sizeof(FslImx8mpState),
+ .instance_init = fsl_imx8mp_init,
+ .class_init = fsl_imx8mp_class_init,
+ },
+};
+
+DEFINE_TYPES(fsl_imx8mp_types)
Hi Bernhard, hi Peter,
this device can be used to crash QEMU quite easily:
$ ./qemu-system-aarch64 -M virt -device fsl-imx8mp
**
ERROR:../../devel/qemu/tcg/tcg.c:1006:tcg_register_thread: assertion failed:
(n < tcg_max_ctxs)
Bail out! ERROR:../../devel/qemu/tcg/tcg.c:1006:tcg_register_thread:
assertion failed: (n < tcg_max_ctxs)
Aborted (core dumped)
Should it maybe be marked with "user_creatable = false" to avoid this?
The bug is that this is directly inheriting from TYPE_DEVICE,
not from TYPE_SYSBUS_DEVICE. Doing the former is almost always
wrong, because it means the device is never reset.
(It looks like we do this wrong for other fsl SoCs too,
but they're marked user_creatable = false.)
IIRC it is deliberately that way for the Aspeed SoCs, because
otherwise there were issue when building the multi-SoC fby35 machines
due to peripherals ending mapped in the same (sys)bus, so developers
took a lot of care to not base anything on sysbus. But maybe I'm
mis-remembering correctly, the peripherals parent could be sysbus
as long as we don't use any sysbus API to map memory regions.
