From: maxime.coquelin@st.com (Maxime Coquelin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: STi: stih407-family: Disable reserved-memory co-processor nodes
Date: Fri, 17 Jun 2016 11:56:54 +0200 [thread overview]
Message-ID: <5763C966.9040907@st.com> (raw)
In-Reply-To: <20160607083724.18599-1-lee.jones@linaro.org>
On 06/07/2016 10:37 AM, Lee Jones wrote:
> This patch fixes a non-booting issue in Mainline.
>
> When booting with a compressed kernel, we need to be careful how we
> populate memory close to DDR start. AUTO_ZRELADDR is enabled by default
> in multi-arch enabled configurations, which place some restrictions on
> where the kernel is placed and where it will be uncompressed to on boot.
>
> AUTO_ZRELADDR takes the decompressor code's start address and masks out
> the bottom 28 bits to obtain an address to uncompress the kernel to
> (thus a load address of 0x42000000 means that the kernel will be
> uncompressed to 0x40000000 i.e. DDR START on this platform).
>
> Even changing the load address to after the co-processor's shared memory
> won't render a booting platform, since the AUTO_ZRELADDR algorithm still
> ensures the kernel is uncompressed into memory shared with the first
> co-processor (0x40000000).
>
> Another option would be to move loading to 0x4A000000, since this will
> mean the decompressor will decompress the kernel to 0x48000000. However,
> this would mean a large chunk (0x44000000 => 0x48000000 (64MB)) of
> memory would essentially be wasted for no good reason.
>
> Until we can work with ST to find a suitable memory location to
> relocate co-processor shared memory, let's disable the shared memory
> nodes. This will ensure a working platform in the mean time.
>
> NB: The more observant of you will notice that we're leaving the DMU
> shared memory node enabled; this is because a) it is the only one in
> active use at the time of this writing and b) it is not affected by
> the current default behaviour which is causing issues.
>
> Fixes: fe135c6 (ARM: dts: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory)
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
>
That sounds reasonable:
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Arnd, Olof, can you pick this patch directly in -rc fixes,
as it prevents STi boards to boot correctly?
Thanks in advance,
Maxime
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Coquelin <maxime.coquelin@st.com>
To: Lee Jones <lee.jones@linaro.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <arnd@arndb.de>,
Olof Johansson <olof@lixom.net>
Cc: <kernel@stlinux.com>, <patrice.chotard@st.com>
Subject: Re: [PATCH] ARM: dts: STi: stih407-family: Disable reserved-memory co-processor nodes
Date: Fri, 17 Jun 2016 11:56:54 +0200 [thread overview]
Message-ID: <5763C966.9040907@st.com> (raw)
In-Reply-To: <20160607083724.18599-1-lee.jones@linaro.org>
On 06/07/2016 10:37 AM, Lee Jones wrote:
> This patch fixes a non-booting issue in Mainline.
>
> When booting with a compressed kernel, we need to be careful how we
> populate memory close to DDR start. AUTO_ZRELADDR is enabled by default
> in multi-arch enabled configurations, which place some restrictions on
> where the kernel is placed and where it will be uncompressed to on boot.
>
> AUTO_ZRELADDR takes the decompressor code's start address and masks out
> the bottom 28 bits to obtain an address to uncompress the kernel to
> (thus a load address of 0x42000000 means that the kernel will be
> uncompressed to 0x40000000 i.e. DDR START on this platform).
>
> Even changing the load address to after the co-processor's shared memory
> won't render a booting platform, since the AUTO_ZRELADDR algorithm still
> ensures the kernel is uncompressed into memory shared with the first
> co-processor (0x40000000).
>
> Another option would be to move loading to 0x4A000000, since this will
> mean the decompressor will decompress the kernel to 0x48000000. However,
> this would mean a large chunk (0x44000000 => 0x48000000 (64MB)) of
> memory would essentially be wasted for no good reason.
>
> Until we can work with ST to find a suitable memory location to
> relocate co-processor shared memory, let's disable the shared memory
> nodes. This will ensure a working platform in the mean time.
>
> NB: The more observant of you will notice that we're leaving the DMU
> shared memory node enabled; this is because a) it is the only one in
> active use at the time of this writing and b) it is not affected by
> the current default behaviour which is causing issues.
>
> Fixes: fe135c6 (ARM: dts: STiH407: Move over to using the 'reserved-memory' API for obtaining DMA memory)
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
> arch/arm/boot/dts/stih407-family.dtsi | 3 +++
> 1 file changed, 3 insertions(+)
>
>
That sounds reasonable:
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Arnd, Olof, can you pick this patch directly in -rc fixes,
as it prevents STi boards to boot correctly?
Thanks in advance,
Maxime
next prev parent reply other threads:[~2016-06-17 9:56 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-07 8:37 [PATCH] ARM: dts: STi: stih407-family: Disable reserved-memory co-processor nodes Lee Jones
2016-06-07 8:37 ` Lee Jones
2016-06-07 8:50 ` [STLinux Kernel] " Peter Griffin
2016-06-07 8:50 ` Peter Griffin
2016-06-17 9:56 ` Maxime Coquelin [this message]
2016-06-17 9:56 ` Maxime Coquelin
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=5763C966.9040907@st.com \
--to=maxime.coquelin@st.com \
--cc=linux-arm-kernel@lists.infradead.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.