[PATCH v1] armv8: MMU: Fix the memory map for RAM

[Tom Rini]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200904/a7732d28/attachment.sig>