On 10/26/2016 12:54 PM, york.sun@nxp.com wrote:

On 10/26/2016 12:47 PM, Stephen Warren wrote:

...

There are two data structures in ARM U-Boot that describe memory layout:

1. A list of RAM memory regions. U-Boot uses these to know where to

relocate itself to (it relocates itself to the top of RAM at boot), and to fill in the /memory node when booting an OS using DT (and other equivalent mechanisms when not using DT.)

2. For AArch64 specifically, there's a memory map table that defines all

RAM and MMIO regions, and the translation table attributes required for those regions.

Judging by your comments later in the original message, it sounds like it'd be fine to read from these structures during any dcache clean routine provided the table has already been cleaned. That makes using the tables much more tractable:-)

I think we need to benchmark walking through the MMU tables. It can map huge amount of memory. For our case, it is more than 16GB. I have been reluctant to do so for the size. I am now back testing to revert _this_ patch, hoping to confirm what I learned from this discussion.

I came back from my testing and I have more questions than answers.

For _this_ patch, I proposed to flush cache before disabling them, noting once the dcache is disabled, the staled data in dirty cache is not visible to the core. My argument was if we flush L1/L2, they could end up in L3 (I don't know for sure). If I want to skip flushing L3, I have to fix it.

During this discussion, I thought I made a mistake by flushing L1/L2 by way/set first, then flushing by VA. Actually I didn't. I flushed by VA first.

With my today's test, the baseline (working in the sense of booting Linux) is

PATCH 1/2 armv8: Fix dcache disable function PATCH 2/2 armv8: Fix flush_dcache_all function

With these two patches, I flush the stack up to top of U-Boot by VA, followed by flush by set/way. L3 is not flushed. Then d-cache is disabled. I know this is not a real "flush all" procedure. With this modified procedure, I can continue to boot Linux.

If I revert patch 1, i.e. to disable dcache before flushing, I can see the data is not visible from the core (debug with JTAG tool). My hope was the staled data should be flushed to main memory if flushed by VA. That's not the case. The main memory doesn't have the correct data. So my new question is, why flushing by VA doesn't flush the data to main memory? Do I need to flush the cache while cache is enabled?

York