[U-Boot] [Resend RFC PATCH 1/2] armv8: Fix dcache disable function

york sun york.sun at nxp.com
Wed Oct 26 23:02:02 CEST 2016


On 10/26/2016 12:54 PM, york.sun at 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


More information about the U-Boot mailing list