On Fri, Sep 04, 2020 at 09:05:51PM +0200, Marek Bykowski wrote:
Hi Patrick,
First of all thanks for your feedback...
-----------------| | | Read-Only Cacheable | Code | Not-ExecutableCode is executable I think...
Good catch, copy/paste error from a rectangle above.
If all DDR is " Not-Executable", excepted code of U-boot himself and EFI, I think that the standalone application can't be more execute except if the MMU configuration change before to execute it.
Yes, that's why I referred that any new use of memory, except already remapped by this patch should take account of attributing properly Instruction and Data regions. Maybe I should re-phrase that part.
The current situation in which the whole RAM is RW, XN=0 (Executable) advocates the improper CPU uses. CPU (fetch logic) really behaves differently whether interacting with a Code or Data region. Situation in which it is generic (but wrong) and working for 99% cases doesn't justify.
I really think we should impose on users/developers the proper use of the CPU.
See do_bootm_standalone().
PS: it is done for Linux in do_bootm_linux/ do_bootm_linux/ announce_and_cleanup..... caches ans MMU are deactivated
Will check but after MMU is turned off the pages are no matter anymore so should be good. With MMU off for armv8 all data accesses are Device_nGnRnE, all instruction fetches are cacheable, all addresses are RW, XN=1 (Executable).
For information I have the same issue on armV7 platform stm32mp1: speculative access on memory, used by OP-TEE, protected by firewall.
The fault/faults I'm observing on Cortex-A57 is the System Memory Controller gets violated and raises an error interrupt. The error is out-of-order, an attempt to read from an out-of-range address with sample details below:
out_of_range_addr 0x702200200 -> faulting address out_of_range_length 0x40 -> burst size out_of_range_type 0x5 -> stands for a wrapped read command out_of_range_source_id 0x0 -> source indicates it is coming from CPU0
Burst size 64 bytes (a cache line size) and wrapped read (AXI4) may suggest the data side memory system hit into the cache loaded by mispredited instruction fetch, all due to improper MMU programming.
I propose a other solution [1]: no more map the reserved memory region with the property "no-map", bt only for cache-cp15.
It is based lmb library so it could done also in armv8 cache functions.
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=199486
If there is another (better) solution I'm in for it as we *should really* fix it this or that way. The link copied doesn't work with me. Can you resend?
The full link is http://patchwork.ozlabs.org/project/uboot/list/?series=199486&state=* as patchwork "hides" stuff by default when it's in some states such as RFC.