From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 24 Feb 2015 23:43:07 +0100 (CET) Received: from localhost.localdomain ([127.0.0.1]:55842 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S27007158AbbBXWnFeUrGa (ORCPT ); Tue, 24 Feb 2015 23:43:05 +0100 Received: from scotty.linux-mips.net (localhost.localdomain [127.0.0.1]) by scotty.linux-mips.net (8.14.9/8.14.8) with ESMTP id t1OMh1TQ012447; Tue, 24 Feb 2015 23:43:01 +0100 Received: (from ralf@localhost) by scotty.linux-mips.net (8.14.9/8.14.9/Submit) id t1OMgvg2012446; Tue, 24 Feb 2015 23:42:58 +0100 Date: Tue, 24 Feb 2015 23:42:57 +0100 From: Ralf Baechle To: Andrew Bresticker Cc: Arnd Bergmann , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Linux-MIPS , Ezequiel Garcia , James Hartley , James Hogan , Lars-Peter Clausen Subject: Re: [PATCH 2/5] MIPS: Allow platforms to specify the decompressor load address Message-ID: <20150224224257.GB9748@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 45938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ralf Baechle Subject: Re: [PATCH 2/5] MIPS: Allow platforms to specify the decompressor load address Date: Tue, 24 Feb 2015 23:42:57 +0100 Message-ID: <20150224224257.GB9748@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andrew Bresticker Cc: Arnd Bergmann , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Linux-MIPS , Ezequiel Garcia , James Hartley , James Hogan , Lars-Peter Clausen List-Id: devicetree@vger.kernel.org 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 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html