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-Executable > > > > Code 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. -- Tom
signature.asc
Description: PGP signature
