History log of /qemu/configs/targets/arm-softmmu.mak (Results 1 – 10 of 10)
Revision Date Author Comments
# a3d40b5e 05-Apr-2025 Philippe Mathieu-Daudé <philmd@linaro.org>

tcg: Convert TARGET_SUPPORTS_MTTCG to TCGCPUOps::mttcg_supported field

Instead of having a compile-time TARGET_SUPPORTS_MTTCG definition,
have each target set the 'mttcg_supported' field in the TCGC

tcg: Convert TARGET_SUPPORTS_MTTCG to TCGCPUOps::mttcg_supported field

Instead of having a compile-time TARGET_SUPPORTS_MTTCG definition,
have each target set the 'mttcg_supported' field in the TCGCPUOps
structure.

Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Anton Johansson <anjo@rev.ng>
Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-ID: <20250405161320.76854-17-philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

show more ...


# 537600df 31-Jan-2025 Richard Henderson <richard.henderson@linaro.org>

configure: Define TARGET_LONG_BITS in configs/targets/*.mak

Define TARGET_LONG_BITS in each target's configure fragment.
Do this without removing the define in target/*/cpu-param.h
so that errors ar

configure: Define TARGET_LONG_BITS in configs/targets/*.mak

Define TARGET_LONG_BITS in each target's configure fragment.
Do this without removing the define in target/*/cpu-param.h
so that errors are caught like so:

In file included from .../src/include/exec/cpu-defs.h:26,
from ../src/target/hppa/cpu.h:24,
from ../src/linux-user/qemu.h:4,
from ../src/linux-user/hppa/cpu_loop.c:21:
../src/target/hppa/cpu-param.h:11: error: "TARGET_LONG_BITS" redefined [-Werror]
11 | #define TARGET_LONG_BITS 64
|
In file included from .../src/include/qemu/osdep.h:36,
from ../src/linux-user/hppa/cpu_loop.c:20:
./hppa-linux-user-config-target.h:32: note: this is the location of the previous definition
32 | #define TARGET_LONG_BITS 32
|
cc1: all warnings being treated as errors

Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

show more ...


# 9b089d25 08-May-2024 Paolo Bonzini <pbonzini@redhat.com>

configs: disable emulators that require it if libfdt is not found

Since boards can express their dependency on libfdt and
system/device_tree.c, only leave TARGET_NEED_FDT if the target has a
hard de

configs: disable emulators that require it if libfdt is not found

Since boards can express their dependency on libfdt and
system/device_tree.c, only leave TARGET_NEED_FDT if the target has a
hard dependency.

Those emulators will be skipped if libfdt is disabled, or if it
is "auto" and not found and --disable-download is passed; unless
the target is mentioned explicitly in --target-list, in which case
the build will fail.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...


# dbd9e084 01-Nov-2021 Peter Maydell <peter.maydell@linaro.org>

target/arm: Advertise MVE to gdb when present

Cortex-M CPUs with MVE should advertise this fact to gdb, using the
org.gnu.gdb.arm.m-profile-mve XML feature, which defines the VPR
register. Presence

target/arm: Advertise MVE to gdb when present

Cortex-M CPUs with MVE should advertise this fact to gdb, using the
org.gnu.gdb.arm.m-profile-mve XML feature, which defines the VPR
register. Presence of this feature also tells gdb to create
pseudo-registers Q0..Q7, so we do not need to tell gdb about them
separately.

Note that unless you have a very recent GDB that includes this fix:
http://patches-tcwg.linaro.org/patch/58133/ gdb will mis-print the
individual fields of the VPR register as zero (but showing the whole
thing as hex, eg with "print /x $vpr" will give the correct value).

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20211101160814.5103-1-peter.maydell@linaro.org>
Signed-off-by: Richard Henderson <richard.henderson@linaro.org>

show more ...


# b355f08a 21-Sep-2021 Peter Maydell <peter.maydell@linaro.org>

target/arm: Don't put FPEXC and FPSID in org.gnu.gdb.arm.vfp XML

Currently we send VFP XML which includes D0..D15 or D0..D31, plus
FPSID, FPSCR and FPEXC. The upstream GDB tolerates this, but its
d

target/arm: Don't put FPEXC and FPSID in org.gnu.gdb.arm.vfp XML

Currently we send VFP XML which includes D0..D15 or D0..D31, plus
FPSID, FPSCR and FPEXC. The upstream GDB tolerates this, but its
definition of this XML feature does not include FPSID or FPEXC. In
particular, for M-profile cores there are no FPSID or FPEXC
registers, so advertising those is wrong.

Move FPSID and FPEXC into their own bit of XML which we only send for
A and R profile cores. This brings our definition of the XML
org.gnu.gdb.arm.vfp feature into line with GDB's own (at least for
non-Neon cores...) and means we don't claim to have FPSID and FPEXC
on M-profile.

(It seems unlikely to me that any gdbstub users really care about
being able to look at FPEXC and FPSID; but we've supplied them to gdb
for a decade and it's not hard to keep doing so.)

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

show more ...


# 812b31d3 07-Jul-2021 Alex Bennée <alex.bennee@linaro.org>

configs: rename default-configs to configs and reorganise

In preparation for offering variation to our build configurations lets
move everything and rename it to default. Common included base config

configs: rename default-configs to configs and reorganise

In preparation for offering variation to our build configurations lets
move everything and rename it to default. Common included base configs
are also renamed.

During the cleanup the stale usb.mak and pci.mak references were
removed from MAINTAINERS.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Message-Id: <20210707131744.26027-5-alex.bennee@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...


# fbb4121d 05-Oct-2020 Paolo Bonzini <pbonzini@redhat.com>

dtc: Convert Makefile bits to meson bits

Build the library via the main meson.build just like for capstone.
This improves the current state of affairs in that we will re-link
the qemu executables ag

dtc: Convert Makefile bits to meson bits

Build the library via the main meson.build just like for capstone.
This improves the current state of affairs in that we will re-link
the qemu executables against a changed libfdt.a, which we wouldn't
do before-hand, and lets us remove the whole recursive make machinery.

Tested-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...


# fa73168b 21-Sep-2020 Paolo Bonzini <pbonzini@redhat.com>

default-configs: remove redundant keys

TARGET_BASE_ARCH and TARGET_ABI_DIR are 99% of the time the same
as TARGET_ARCH, remove them if so.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


# a9a74907 21-Sep-2020 Paolo Bonzini <pbonzini@redhat.com>

default-configs: use TARGET_ARCH key

Replace the individual TARGET_*=y lines with TARGET_ARCH,
similar to how TARGET_BASE_ARCH is handled already.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>


# fdb75aef 21-Sep-2020 Paolo Bonzini <pbonzini@redhat.com>

configure: remove target configuration

The config-target.mak files are small constant, we can therefore just
write them down explicitly.

This removes a pretty large part of the configure script, in

configure: remove target configuration

The config-target.mak files are small constant, we can therefore just
write them down explicitly.

This removes a pretty large part of the configure script, including the
whole logic to detect which accelerators are supported by each target.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

show more ...