From mboxrd@z Thu Jan  1 00:00:00 1970
From: R Sricharan <r.sricharan@ti.com>
Date: Tue, 8 Jan 2013 18:35:59 +0530
Subject: [U-Boot] [PATCH v4 3/3] ARM: OMAP5: redefine
	arm_setup_identity_mapping
In-Reply-To: <50EC10CC.3030609@ti.com>
References: <92476020c6e1ef888207ca6f661c48068050efbf>
	<1357569880-10067-1-git-send-email-v-stehle@ti.com>
	<1357569880-10067-4-git-send-email-v-stehle@ti.com>
	<50EBFFAE.1090402@ti.com> <50EC10CC.3030609@ti.com>
Message-ID: <50EC19B7.6040503@ti.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Hi Vincent,

On Tuesday 08 January 2013 05:57 PM, Vincent Stehl? wrote:
> On 01/08/2013 12:14 PM, R Sricharan wrote:
> (..)
>>   We had this problem of speculative aborts in the kernel uncompress code
>>   as well, which maps all of 4GB address space. It was solved by setting
>>   the non-DRAM region as non-executable(XN) and with client permissions
>>   to the domain in the DACR register.
>>
>>   This way speculative prefetches are avoided not only to the page 0,
>>   but also to other read sensitive I/O regions.
>>
>>   I have created a similar patch in u-boot and posted a RFC now.
>>   I was using your first patch [1] and rest from me.
> (..)
>>
>>   Please let me know your take on that.
>
> Hi Sricharan,
>
> Your solution to this issue looks more elegant to me than my unmapping
> page 0 completely.
>    I tested your patches and they work for me on both GP (without
> security) and EMU (with security) OMAP5 ES1.0 devices. I'll keep them,
> thanks :) You can add my 'Tested-by' if you want:
>
  Thanks for the testing and confirming.
  Will add your <Tested-by> in the re post.

Regards,
  Sricharan