From: Peter Maydell <peter.maydell@linaro.org>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [PULL 01/24] hw/arm/boot: Don't assume RAM starts at address zero
Date: Mon, 17 Jun 2019 15:33:49 +0100 [thread overview]
Message-ID: <20190617143412.5734-2-peter.maydell@linaro.org> (raw)
In-Reply-To: <20190617143412.5734-1-peter.maydell@linaro.org>
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 <peter.maydell@linaro.org>
Reviewed-by: Alex Bennée <alex.bennee@linaro.org>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Message-id: 20190516144733.32399-2-peter.maydell@linaro.org
---
hw/arm/boot.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/hw/arm/boot.c b/hw/arm/boot.c
index 0261fdabab0..bb37a9383f3 100644
--- a/hw/arm/boot.c
+++ b/hw/arm/boot.c
@@ -977,6 +977,7 @@ static void arm_setup_direct_kernel_boot(ARMCPU *cpu,
int elf_machine;
hwaddr entry;
static const ARMInsnFixup *primary_loader;
+ uint64_t ram_end = info->loader_start + info->ram_size;
if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) {
primary_loader = bootloader_aarch64;
@@ -1048,8 +1049,7 @@ static void arm_setup_direct_kernel_boot(ARMCPU *cpu,
/* 32-bit ARM */
entry = info->loader_start + KERNEL_LOAD_ADDR;
kernel_size = load_image_targphys_as(info->kernel_filename, entry,
- info->ram_size - KERNEL_LOAD_ADDR,
- as);
+ ram_end - KERNEL_LOAD_ADDR, as);
is_linux = 1;
}
if (kernel_size < 0) {
@@ -1063,12 +1063,11 @@ static void arm_setup_direct_kernel_boot(ARMCPU *cpu,
if (info->initrd_filename) {
initrd_size = load_ramdisk_as(info->initrd_filename,
info->initrd_start,
- info->ram_size - info->initrd_start,
- as);
+ ram_end - info->initrd_start, as);
if (initrd_size < 0) {
initrd_size = load_image_targphys_as(info->initrd_filename,
info->initrd_start,
- info->ram_size -
+ ram_end -
info->initrd_start,
as);
}
--
2.20.1
next prev parent reply other threads:[~2019-06-17 15:03 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 14:33 [Qemu-devel] [PULL 00/24] target-arm queue Peter Maydell
2019-06-17 14:33 ` Peter Maydell [this message]
2019-06-17 14:33 ` [Qemu-devel] [PULL 02/24] hw/arm/boot: Diagnose layouts that put initrd or DTB off the end of RAM Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 03/24] hw/arm/boot: Avoid placing the initrd on top of the kernel Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 04/24] hw/arm/boot: Honour image size field in AArch64 Image format kernels Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 05/24] target/arm: Allow VFP and Neon to be disabled via a CPU property Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 06/24] target/arm: Allow M-profile CPUs to disable the DSP extension via " Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 07/24] hw/arm/armv7m: Forward "vfp" and "dsp" properties to CPU Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 08/24] hw/arm: Correctly disable FPU/DSP for some ARMSSE-based boards Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 09/24] hw/intc/arm_gicv3: Fix decoding of ID register range Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 10/24] hw/intc/arm_gicv3: GICD_TYPER.SecurityExtn is RAZ if GICD_CTLR.DS == 1 Peter Maydell
2019-06-17 14:33 ` [Qemu-devel] [PULL 11/24] target/arm: Move vfp_expand_imm() to translate.[ch] Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 12/24] target/arm: Use vfp_expand_imm() for AArch32 VFP VMOV_imm Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 13/24] target/arm: Stop using cpu_F0s for NEON_2RM_VABS_F Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 14/24] target/arm: Stop using cpu_F0s for NEON_2RM_VNEG_F Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 15/24] target/arm: Stop using cpu_F0s for NEON_2RM_VRINT* Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 16/24] target/arm: Stop using cpu_F0s for NEON_2RM_VCVT[ANPM][US] Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 17/24] target/arm: Stop using cpu_F0s for NEON_2RM_VRECPE_F and NEON_2RM_VRSQRTE_F Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 18/24] target/arm: Stop using cpu_F0s for Neon f32/s32 VCVT Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 19/24] target/arm: Stop using cpu_F0s in Neon VCVT fixed-point ops Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 20/24] target/arm: stop using deprecated functions in NEON_2RM_VCVT_F16_F32 Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 21/24] target/arm: Stop using deprecated functions in NEON_2RM_VCVT_F32_F16 Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 22/24] target/arm: Remove unused cpu_F0s, cpu_F0d, cpu_F1s, cpu_F1d Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 23/24] target/arm: Fix typos in trans function prototypes Peter Maydell
2019-06-17 14:34 ` [Qemu-devel] [PULL 24/24] target/arm: Only implement doubles if the FPU supports them Peter Maydell
2019-06-17 15:41 ` [Qemu-devel] [PULL 00/24] target-arm queue Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190617143412.5734-2-peter.maydell@linaro.org \
--to=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).