linux-mips
[Top] [All Lists]

Re: [PATCH 2/5] MIPS: Allow platforms to specify the decompressor load a

To: Andrew Bresticker <abrestic@chromium.org>
Subject: Re: [PATCH 2/5] MIPS: Allow platforms to specify the decompressor load address
From: Ralf Baechle <ralf@linux-mips.org>
Date: Tue, 24 Feb 2015 23:42:57 +0100
Cc: Arnd Bergmann <arnd@arndb.de>, "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Linux-MIPS <linux-mips@linux-mips.org>, Ezequiel Garcia <ezequiel.garcia@imgtec.com>, James Hartley <james.hartley@imgtec.com>, James Hogan <james.hogan@imgtec.com>, Lars-Peter Clausen <lars@metafoo.de>
In-reply-to: <CAL1qeaHSErgc=W4mGhDAm7cu_J4wrOik27joB0Rd-2P7dk=QuA@mail.gmail.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <1424741507-8882-1-git-send-email-abrestic@chromium.org> <1424741507-8882-3-git-send-email-abrestic@chromium.org> <7814815.Q6KYv1fjo1@wuerfel> <CAL1qeaHSErgc=W4mGhDAm7cu_J4wrOik27joB0Rd-2P7dk=QuA@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.23 (2014-03-12)
On Tue, Feb 24, 2015 at 01:39:03PM -0800, Andrew Bresticker wrote:

> It is the same sort of issue, though I think the only way to solve it
> on MIPS would be to copy the image to the address it was linked at,
> which could be problematic if there's overlap.  There's also the cache
> maintenance we'd have to do, which varies from CPU to CPU (and more so
> the ARM I believe).

On MIPS it's significantly less complex to implement than the in-kernel
cache maintenance code because only one flush operation needs to be
implemented that will be invoked only once so performance is less of
an issue.  Also oddball hardware such as the S-caches controlled by
an external controller can be ignored for purpose of kernel decomporession.
That pretty much leaves to treat the standard R4000 style of caches
and a few oddballs like R2000 class processors.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>