[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-commits] [qemu/qemu] e70af2: hw/arm/boot: Don't assume RAM starts
|
From: |
Peter Maydell |
|
Subject: |
[Qemu-commits] [qemu/qemu] e70af2: hw/arm/boot: Don't assume RAM starts at address zero |
|
Date: |
Mon, 17 Jun 2019 08:46:28 -0700 |
Branch: refs/heads/master
Home: https://github.com/qemu/qemu
Commit: e70af24b42190481e19c9adb727b97a0fc794ea8
https://github.com/qemu/qemu/commit/e70af24b42190481e19c9adb727b97a0fc794ea8
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/arm/boot.c
Log Message:
-----------
hw/arm/boot: Don't assume RAM starts at address zero
In the Arm kernel/initrd loading code, in some places we make the
incorrect assumption that info->ram_size can be treated as the
address of the end of RAM, as for instance when we calculate the
available space for the initrd using "info->ram_size - info->initrd_start".
This is wrong, because many Arm boards (including "virt") specify
a non-zero info->loader_start to indicate that their RAM area
starts at a non-zero physical address.
Correct the places which make this incorrect assumption.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Tested-by: Mark Rutland <address@hidden>
Message-id: address@hidden
Commit: 852dc64d665f89d8b54dd9aa7e36c3ff12bef775
https://github.com/qemu/qemu/commit/852dc64d665f89d8b54dd9aa7e36c3ff12bef775
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/arm/boot.c
Log Message:
-----------
hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAM
We calculate the locations in memory where we want to put the
initrd and the DTB based on the size of the kernel, since they
come after it. Add some explicit checks that these aren't off the
end of RAM entirely.
(At the moment the way we calculate the initrd_start means that
it can't ever be off the end of RAM, but that will change with
the next commit.)
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Tested-by: Mark Rutland <address@hidden>
Message-id: address@hidden
Commit: e6b2b20d9735d4ef6a6c2a056b2e1b7798e9cb27
https://github.com/qemu/qemu/commit/e6b2b20d9735d4ef6a6c2a056b2e1b7798e9cb27
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/arm/boot.c
Log Message:
-----------
hw/arm/boot: Avoid placing the initrd on top of the kernel
We currently put the initrd at the smaller of:
* 128MB into RAM
* halfway into the RAM
(with the dtb following it).
However for large kernels this might mean that the kernel
overlaps the initrd. For some kinds of kernel (self-decompressing
32-bit kernels, and ELF images with a BSS section at the end)
we don't know the exact size, but even there we have a
minimum size. Put the initrd at least further into RAM than
that. For image formats that can give us an exact kernel size, this
will mean that we definitely avoid overlaying kernel and initrd.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Tested-by: Mark Rutland <address@hidden>
Message-id: address@hidden
Commit: 5e6dbe1e8cbbe4b6f7407dda2c021cbe80a8ec02
https://github.com/qemu/qemu/commit/5e6dbe1e8cbbe4b6f7407dda2c021cbe80a8ec02
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/arm/boot.c
Log Message:
-----------
hw/arm/boot: Honour image size field in AArch64 Image format kernels
Since Linux v3.17, the kernel's Image header includes a field image_size,
which gives the total size of the kernel including unpopulated data
sections such as the BSS). If this is present, then return it from
load_aarch64_image() as the true size of the kernel rather than
just using the size of the Image file itself. This allows the code
which calculates where to put the initrd to avoid putting it in
the kernel's BSS area.
This means that we should be able to reliably load kernel images
which are larger than 128MB without accidentally putting the
initrd or dtb in locations that clash with the kernel itself.
Fixes: https://bugs.launchpad.net/qemu/+bug/1823998
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Tested-by: Mark Rutland <address@hidden>
Message-id: address@hidden
Commit: 97a28b0eeac14a4a7326d583b745c555fa1f1da6
https://github.com/qemu/qemu/commit/97a28b0eeac14a4a7326d583b745c555fa1f1da6
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/cpu.c
M target/arm/cpu.h
Log Message:
-----------
target/arm: Allow VFP and Neon to be disabled via a CPU property
Allow VFP and neon to be disabled via a CPU property. As with
the "pmu" property, we only allow these features to be removed
from CPUs which have it by default, not added to CPUs which
don't have it.
The primary motivation here is to be able to optionally
create Cortex-M33 CPUs with no FPU, but we provide switches
for both VFP and Neon because the two interact:
* AArch64 can't have one without the other
* Some ID register fields only change if both are disabled
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Message-id: address@hidden
Commit: ea90db0af67aabdf0abb65c418b8857d5359b6ea
https://github.com/qemu/qemu/commit/ea90db0af67aabdf0abb65c418b8857d5359b6ea
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/cpu.c
M target/arm/cpu.h
Log Message:
-----------
target/arm: Allow M-profile CPUs to disable the DSP extension via CPU property
Allow the DSP extension to be disabled via a CPU property for
M-profile CPUs. (A and R-profile CPUs don't have this extension
as a defined separate optional architecture extension, so
they don't need the property.)
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Message-id: address@hidden
Commit: e0cf7b81637a09faf987aca5c20d289a36dc9cf6
https://github.com/qemu/qemu/commit/e0cf7b81637a09faf987aca5c20d289a36dc9cf6
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/arm/armv7m.c
M include/hw/arm/armv7m.h
Log Message:
-----------
hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPU
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 <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Message-id: address@hidden
Commit: a90a862b9ee585bb60683de59524dd06d792ab5d
https://github.com/qemu/qemu/commit/a90a862b9ee585bb60683de59524dd06d792ab5d
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/arm/armsse.c
M hw/arm/musca.c
M include/hw/arm/armsse.h
Log Message:
-----------
hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boards
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 <address@hidden>
Reviewed-by: Alex Bennée <address@hidden>
Message-id: address@hidden
Commit: e40f60730a208338057d51bfc6c98f89af8eab2d
https://github.com/qemu/qemu/commit/e40f60730a208338057d51bfc6c98f89af8eab2d
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/intc/arm_gicv3_dist.c
M hw/intc/arm_gicv3_redist.c
Log Message:
-----------
hw/intc/arm_gicv3: Fix decoding of ID register range
The GIC ID registers cover an area 0x30 bytes in size
(12 registers, 4 bytes each). We were incorrectly decoding
only the first 0x20 bytes.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 0edfcc9ec06fbbcc154cce64748752a5c565a32c
https://github.com/qemu/qemu/commit/0edfcc9ec06fbbcc154cce64748752a5c565a32c
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/intc/arm_gicv3_dist.c
Log Message:
-----------
hw/intc/arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1
The GICv3 specification says that the GICD_TYPER.SecurityExtn bit
is RAZ if GICD_CTLR.DS is 1. We were incorrectly making it RAZ
if the security extension is unsupported. "Security extension
unsupported" always implies GICD_CTLR.DS == 1, but the guest can
also set DS on a GIC which does support the security extension.
Fix the condition to correctly check the GICD_CTLR.DS bit.
Signed-off-by: Peter Maydell <address@hidden>
Message-id: address@hidden
Commit: d6a092d479333b5f20a647a912a31b0102d37335
https://github.com/qemu/qemu/commit/d6a092d479333b5f20a647a912a31b0102d37335
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate-a64.c
M target/arm/translate-a64.h
M target/arm/translate-vfp.inc.c
M target/arm/translate.h
Log Message:
-----------
target/arm: Move vfp_expand_imm() to translate.[ch]
We want to use vfp_expand_imm() in the AArch32 VFP decode;
move it from the a64-only header/source file to the
AArch32 one (which is always compiled even for AArch64).
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 9bee50b498410ed6466018b26464d7384c7879e9
https://github.com/qemu/qemu/commit/9bee50b498410ed6466018b26464d7384c7879e9
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate-vfp.inc.c
M target/arm/vfp.decode
Log Message:
-----------
target/arm: Use vfp_expand_imm() for AArch32 VFP VMOV_imm
The AArch32 VMOV (immediate) instruction uses the same VFP encoded
immediate format we already handle in vfp_expand_imm(). Use that
function rather than hand-decoding it.
Suggested-by: Richard Henderson <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: fd8a68cdcf81d70eebf866a132e9780d4108da9c
https://github.com/qemu/qemu/commit/fd8a68cdcf81d70eebf866a132e9780d4108da9c
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Stop using cpu_F0s for NEON_2RM_VABS_F
Where Neon instructions are floating point operations, we
mostly use the old VFP utility functions like gen_vfp_abs()
which work on the TCG globals cpu_F0s and cpu_F1s. The
Neon for-each-element loop conditionally loads the inputs
into either a plain old TCG temporary for most operations
or into cpu_F0s for float operations, and similarly stores
back either cpu_F0s or the temporary.
Switch NEON_2RM_VABS_F away from using cpu_F0s, and
update neon_2rm_is_float_op() accordingly.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: cedcc96fc7c8e520a190a010ac97dbb53e57d7d2
https://github.com/qemu/qemu/commit/cedcc96fc7c8e520a190a010ac97dbb53e57d7d2
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Stop using cpu_F0s for NEON_2RM_VNEG_F
Switch NEON_2RM_VABS_F away from using cpu_F0s.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 3b52ad1fae804acdc2fdc41b418a65249beae430
https://github.com/qemu/qemu/commit/3b52ad1fae804acdc2fdc41b418a65249beae430
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Stop using cpu_F0s for NEON_2RM_VRINT*
Switch NEON_2RM_VRINT* away from using cpu_F0s.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 30bf0a018f6c706913c8c0ea57b386907f4229be
https://github.com/qemu/qemu/commit/30bf0a018f6c706913c8c0ea57b386907f4229be
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Stop using cpu_F0s for NEON_2RM_VCVT[ANPM][US]
Stop using cpu_F0s for the NEON_2RM_VCVT[ANPM][US] ops.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 9a011fece7201f8e268c982df8c7836f3335bbe6
https://github.com/qemu/qemu/commit/9a011fece7201f8e268c982df8c7836f3335bbe6
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F
Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 60737ed5785b9c1c6f1c85575dfdd1e9eec91878
https://github.com/qemu/qemu/commit/60737ed5785b9c1c6f1c85575dfdd1e9eec91878
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Stop using cpu_F0s for Neon f32/s32 VCVT
Stop using cpu_F0s for the Neon f32/s32 VCVT operations.
Since this is the last user of cpu_F0s in the Neon 2rm-op
loop, we can remove the handling code for it too.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: c253dd7832bc6b4e140a0da56410a9336cce05bc
https://github.com/qemu/qemu/commit/c253dd7832bc6b4e140a0da56410a9336cce05bc
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Stop using cpu_F0s in Neon VCVT fixed-point ops
Stop using cpu_F0s in the Neon VCVT fixed-point operations.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 58f2682eee738e8890f9cfe858e0f4f68b00d45d
https://github.com/qemu/qemu/commit/58f2682eee738e8890f9cfe858e0f4f68b00d45d
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: stop using deprecated functions in NEON_2RM_VCVT_F16_F32
Remove some old constructs from NEON_2RM_VCVT_F16_F32 code:
* don't use cpu_F0s
* don't use tcg_gen_ld_f32
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: b66f6b9981004bbf120b8d17c20f92785179bdf2
https://github.com/qemu/qemu/commit/b66f6b9981004bbf120b8d17c20f92785179bdf2
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Stop using deprecated functions in NEON_2RM_VCVT_F32_F16
Remove some old constructns from NEON_2RM_VCVT_F16_F32 code:
* don't use CPU_F0s
* don't use tcg_gen_st_f32
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: d9eea52c67c04c58ecceba6ffe5a93d1d02051fa
https://github.com/qemu/qemu/commit/d9eea52c67c04c58ecceba6ffe5a93d1d02051fa
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate.c
Log Message:
-----------
target/arm: Remove unused cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d
Remove the now unused TCG globals cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d.
cpu_M0 is still used by the iwmmxt code, and cpu_V0 and
cpu_V1 are used by both iwmmxt and Neon.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Tested-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 83655223ac6143a563e981906ce13fd6f2cfbefd
https://github.com/qemu/qemu/commit/83655223ac6143a563e981906ce13fd6f2cfbefd
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/translate-vfp.inc.c
Log Message:
-----------
target/arm: Fix typos in trans function prototypes
In several places cut and paste errors meant we were using the wrong
type for the 'arg' struct in trans_ functions called by the
decodetree decoder, because we were using the _sp version of the
struct in the _dp function. These were harmless, because the two
structs were identical and so decodetree made them typedefs of the
same underlying structure (and we'd have had a compile error if they
were not harmless), but we should clean them up anyway.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden
Commit: 1120827fa182f0e76226df7ffe7a86598d1df54f
https://github.com/qemu/qemu/commit/1120827fa182f0e76226df7ffe7a86598d1df54f
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M target/arm/cpu.h
M target/arm/translate-vfp.inc.c
Log Message:
-----------
target/arm: Only implement doubles if the FPU supports them
The architecture permits FPUs which have only single-precision
support, not double-precision; Cortex-M4 and Cortex-M33 are
both like that. Add the necessary checks on the MVFR0 FPDP
field so that we UNDEF any double-precision instructions on
CPUs like this.
Note that even if FPDP==0 the insns like VMOV-to/from-gpreg,
VLDM/VSTM, VLDR/VSTR which take double precision registers
still exist.
Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Richard Henderson <address@hidden>
Message-id: address@hidden
Commit: 144ecc7f1a12504e8a134d1cb6d88764f75ae36c
https://github.com/qemu/qemu/commit/144ecc7f1a12504e8a134d1cb6d88764f75ae36c
Author: Peter Maydell <address@hidden>
Date: 2019-06-17 (Mon, 17 Jun 2019)
Changed paths:
M hw/arm/armsse.c
M hw/arm/armv7m.c
M hw/arm/boot.c
M hw/arm/musca.c
M hw/intc/arm_gicv3_dist.c
M hw/intc/arm_gicv3_redist.c
M include/hw/arm/armsse.h
M include/hw/arm/armv7m.h
M target/arm/cpu.c
M target/arm/cpu.h
M target/arm/translate-a64.c
M target/arm/translate-a64.h
M target/arm/translate-vfp.inc.c
M target/arm/translate.c
M target/arm/translate.h
M target/arm/vfp.decode
Log Message:
-----------
Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190617'
into staging
target-arm queue:
* support large kernel images in bootloader (by avoiding
putting the initrd over the top of them)
* correctly disable FPU/DSP in the CPU for the mps2-an521, musca-a boards
* arm_gicv3: Fix decoding of ID register range
* arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1
* some code cleanups following on from the VFP decodetree conversion
* Only implement doubles if the FPU supports them
(so we now correctly model Cortex-M4, -M33 as single precision only)
# gpg: Signature made Mon 17 Jun 2019 15:33:01 BST
# gpg: using RSA key E1A5C593CD419DE28E8315CF3C2525ED14360CDE
# gpg: issuer "address@hidden"
# gpg: Good signature from "Peter Maydell <address@hidden>" [ultimate]
# gpg: aka "Peter Maydell <address@hidden>" [ultimate]
# gpg: aka "Peter Maydell <address@hidden>" [ultimate]
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83 15CF 3C25 25ED 1436 0CDE
* remotes/pmaydell/tags/pull-target-arm-20190617: (24 commits)
target/arm: Only implement doubles if the FPU supports them
target/arm: Fix typos in trans function prototypes
target/arm: Remove unused cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d
target/arm: Stop using deprecated functions in NEON_2RM_VCVT_F32_F16
target/arm: stop using deprecated functions in NEON_2RM_VCVT_F16_F32
target/arm: Stop using cpu_F0s in Neon VCVT fixed-point ops
target/arm: Stop using cpu_F0s for Neon f32/s32 VCVT
target/arm: Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F
target/arm: Stop using cpu_F0s for NEON_2RM_VCVT[ANPM][US]
target/arm: Stop using cpu_F0s for NEON_2RM_VRINT*
target/arm: Stop using cpu_F0s for NEON_2RM_VNEG_F
target/arm: Stop using cpu_F0s for NEON_2RM_VABS_F
target/arm: Use vfp_expand_imm() for AArch32 VFP VMOV_imm
target/arm: Move vfp_expand_imm() to translate.[ch]
hw/intc/arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1
hw/intc/arm_gicv3: Fix decoding of ID register range
hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boards
hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPU
target/arm: Allow M-profile CPUs to disable the DSP extension via CPU property
target/arm: Allow VFP and Neon to be disabled via a CPU property
...
Signed-off-by: Peter Maydell <address@hidden>
Compare: https://github.com/qemu/qemu/compare/5d0e5694470d...144ecc7f1a12
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Qemu-commits] [qemu/qemu] e70af2: hw/arm/boot: Don't assume RAM starts at address zero,
Peter Maydell <=