From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: yalin wang <yalin.wang2010@gmail.com>
Cc: nico@linaro.org, keescook@chromium.org, robh@kernel.org,
stefan@agner.ch, rabin@rab.in, msalter@redhat.com,
ard.biesheuvel@linaro.org, will.deacon@arm.com,
ssantosh@kernel.org, yamada.m@jp.panasonic.com,
sboyd@codeaurora.org, contact@paulk.fr, pavel@ucw.cz,
slash.tmp@free.fr, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] arm: add relocate initrd support
Date: Fri, 9 Oct 2015 17:10:34 +0100 [thread overview]
Message-ID: <20151009161033.GA32532@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <1444406109-28354-1-git-send-email-yalin.wang2010@gmail.com>
On Fri, Oct 09, 2015 at 11:55:09PM +0800, yalin wang wrote:
> Add support for initrd on ARM arch, in case
> mem= boot option change the memory size or the initrd are
> not placed in low memory region, we need copy the initrd
> to low memory region.
>
> Signed-off-by: yalin wang <yalin.wang2010@gmail.com>
> ---
> arch/arm/include/asm/fixmap.h | 1 +
> arch/arm/kernel/setup.c | 72 +++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 73 insertions(+)
>
> diff --git a/arch/arm/include/asm/fixmap.h b/arch/arm/include/asm/fixmap.h
> index 58cfe9f..18ad90f 100644
> --- a/arch/arm/include/asm/fixmap.h
> +++ b/arch/arm/include/asm/fixmap.h
> @@ -10,6 +10,7 @@
>
> enum fixed_addresses {
> FIX_EARLYCON_MEM_BASE,
> + FIX_RELOCATE_INITRD,
> __end_of_permanent_fixed_addresses,
>
> FIX_KMAP_BEGIN = __end_of_permanent_fixed_addresses,
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 20edd34..4260d59 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -811,6 +811,77 @@ static void __init request_standard_resources(const struct machine_desc *mdesc)
> request_resource(&ioport_resource, &lp2);
> }
>
> +#if defined(CONFIG_BLK_DEV_INITRD) && defined(CONFIG_MMU)
> +/*
> + * Relocate initrd if it is not completely within the linear mapping.
> + * This would be the case if mem= cuts out all or part of it
> + * or the initrd are not in low mem region place.
> + */
> +static void __init relocate_initrd(void)
> +{
> + phys_addr_t orig_start = __virt_to_phys(initrd_start);
> + phys_addr_t orig_end = __virt_to_phys(initrd_end);
If initrd_start or initrd_end are outside of the lowmem region, it's
quite possible for these to return incorrect physical addresses.
The generic kernel's idea of using virtual addresses for the initrd
stuff is painfully wrong IMHO.
The unfortunate thing is that the DT code propagates this stuff:
initrd_start = (unsigned long)__va(start);
initrd_end = (unsigned long)__va(end);
and even this can give wrong results for the virtual address when the
physical is outside of lowmem. For addresses outside of lowmem,
__virt_to_phys(__va(start)) is not guaranteed to return 'start'.
This is why I've said that if we want to support ramdisks outside of
the lowmem mapping, we need to get rid of the initrd_start/initrd_end
virtual addresses.
I'm sorry, but we need much wider code changes before we can cope with
this.
> + phys_addr_t ram_end = memblock_end_of_DRAM();
> + phys_addr_t new_start;
> + phys_addr_t src;
> + unsigned long size, to_free = 0;
> + unsigned long slop, clen, p;
> + void *dest;
> +
> + if (orig_end <= memblock_get_current_limit())
> + return;
> +
> + /*
> + * Any of the original initrd which overlaps the linear map should
> + * be freed after relocating.
How does this work? The code in arm_memblock_init() will have already
reserved the physical addresses for the ramdisk:
memblock_reserve(phys_initrd_start, phys_initrd_size);
So any new allocation shouldn't overlap the existing ramdisk - unless
this is wrong.
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2015-10-09 16:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-09 15:55 yalin wang
2015-10-09 16:10 ` Russell King - ARM Linux [this message]
2015-10-10 2:03 ` yalin wang
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=20151009161033.GA32532@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=ard.biesheuvel@linaro.org \
--cc=contact@paulk.fr \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=msalter@redhat.com \
--cc=nico@linaro.org \
--cc=pavel@ucw.cz \
--cc=rabin@rab.in \
--cc=robh@kernel.org \
--cc=sboyd@codeaurora.org \
--cc=slash.tmp@free.fr \
--cc=ssantosh@kernel.org \
--cc=stefan@agner.ch \
--cc=will.deacon@arm.com \
--cc=yalin.wang2010@gmail.com \
--cc=yamada.m@jp.panasonic.com \
/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
Powered by JetHome