From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?VmluY2VudCBTdGVobMOp?= Date: Tue, 8 Jan 2013 13:27:56 +0100 Subject: [U-Boot] [PATCH v4 3/3] ARM: OMAP5: redefine arm_setup_identity_mapping In-Reply-To: <50EBFFAE.1090402@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> Message-ID: <50EC10CC.3030609@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: Tested-by: Vincent Stehl? Best regards, V.