Date: Thu, 29 Jun 2017 20:28:08 +0530
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Rafael Wysocki <rjw@rjwysocki.net>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Rob Herring <robh@kernel.org>, Stephen Boyd <sboyd@codeaurora.org>,
        linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>,
        rnayak@codeaurora.org, Shiraz Hashim <shashim@codeaurora.org>,
        linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC 0/5] drivers: Add boot constraints core
Message-ID: <20170629145808.GQ29665@vireshk-i7>
References: <cover.1498642745.git.viresh.kumar@linaro.org>
 <20170629124908.GV4902@n2100.armlinux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170629124908.GV4902@n2100.armlinux.org.uk>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1922
Lines: 43

On 29-06-17, 13:49, Russell King - ARM Linux wrote:
> The thing that concerns me most about this is that typically the LCD
> controller will be performing DMA to system RAM.
> 
> The location of the frame buffer is unknown to the decompressor - and
> as the decompressor self-relocates itself (using purely assembly code),
> it could relocate itself on top of the frame buffer, causing the "nice"
> image to become very colourful.
> 
> The decompressor doesn't have the information from DT at that point to
> know what are safe locations, so it's up to the boot loader to place
> the frame buffer somewhere out of the way.  (If people want to write
> a DT parser in position independent ARM assembly code that may change.)
> 
> As long as people realise this, then it's not a problem, but given the
> number of problems that we've already encountered with boot loaders and
> memory space layout, I don't trust them to get this right.
> 
> Right now, the ARM kernel booting document requires:
> 
> - Quiesce all DMA capable devices so that memory does not get
>   corrupted by bogus network packets or disk data. This will save
>   you many hours of debug.
> 
> so we would need to modify that to make an exception for LCD controllers.
> However, we definitely can't have devices left enabled which are capable
> of writing to system memory, or which changing system memory is likely
> to cause bad effects (eg, packet ring buffers, USB buffers etc, which is
> really what the above requirement is about.)

Well, LCD was just an example here. But yeah, it is one of the most
probable case we have.

So, this thing is already working for sure, of course with some out of
tree hacks. Every smart phone shows their company's logo (some kind of
flash) while the phone boots. How do they get around such issues?

@Stephen: Any idea how Qcom does it ? :)

Must be fixing some area in RAM for this purpose, isn't it ?

-- 
viresh