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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.