On 11/07/2016 06:12 AM, Mark Rutland wrote:
> On Fri, Oct 28, 2016 at 09:35:37PM +, york sun wrote:
>> I am struggling on the dcache_disable() which implies all dcache is
>> flushed. I don't have a reasonable way to flush all if I want to skip
>> L3. I tried to benchmark flushing by VA to cover
On Fri, Oct 28, 2016 at 09:35:37PM +, york sun wrote:
> I am struggling on the dcache_disable() which implies all dcache is
> flushed. I don't have a reasonable way to flush all if I want to skip
> L3. I tried to benchmark flushing by VA to cover my entire 16GB memory.
> It took 30+ seconds.
On Fri, Oct 28, 2016 at 12:32:36PM -0600, Stephen Warren wrote:
> Related, consider the following from the Linux kernel's
> Documentation/arm64/booting.txt:
>
> >- Caches, MMUs
> > The MMU must be off.
> > Instruction cache may be on or off.
> > The address range corresponding to the loaded ker
On 10/28/2016 11:32 AM, Stephen Warren wrote:
> On 10/28/2016 12:17 PM, york sun wrote:
>> On 10/28/2016 10:57 AM, Stephen Warren wrote:
>>> On 10/28/2016 11:38 AM, york sun wrote:
On 10/26/2016 02:02 PM, york@nxp.com wrote:
>
> I came back from my testing and I have more questions
On 10/26/2016 02:02 PM, york@nxp.com wrote:
>
> 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 argume
On 10/28/2016 10:57 AM, Stephen Warren wrote:
> On 10/28/2016 11:38 AM, york sun wrote:
>> On 10/26/2016 02:02 PM, york@nxp.com wrote:
>>>
>>> I came back from my testing and I have more questions than answers.
>>>
>>> For _this_ patch, I proposed to flush cache before disabling them,
>>> notin
On 10/28/2016 12:17 PM, york sun wrote:
On 10/28/2016 10:57 AM, Stephen Warren wrote:
On 10/28/2016 11:38 AM, york sun wrote:
On 10/26/2016 02:02 PM, york@nxp.com wrote:
I came back from my testing and I have more questions than answers.
For _this_ patch, I proposed to flush cache before
On 10/28/2016 11:38 AM, york sun wrote:
On 10/26/2016 02:02 PM, york@nxp.com wrote:
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
n
On 10/26/2016 02:00 PM, Stephen Warren wrote:
> On 10/26/2016 02:29 PM, york sun wrote:
>> On 10/26/2016 01:12 PM, Stephen Warren wrote:
>>> On 10/26/2016 01:54 PM, york sun wrote:
On 10/26/2016 12:47 PM, Stephen Warren wrote:
>
> There are two data structures in ARM U-Boot that descri
On 10/26/2016 12:54 PM, york@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
On 10/26/2016 02:29 PM, york sun wrote:
On 10/26/2016 01:12 PM, Stephen Warren wrote:
On 10/26/2016 01:54 PM, york sun 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 th
On 10/26/2016 01:12 PM, Stephen Warren wrote:
> On 10/26/2016 01:54 PM, york sun 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
>>> r
On 10/26/2016 01:54 PM, york sun 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),
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
On 10/24/2016 04:59 AM, Mark Rutland wrote:
On Fri, Oct 21, 2016 at 07:31:52PM +, york sun wrote:
On 10/20/2016 01:34 PM, Stephen Warren wrote:
On 10/19/2016 11:06 PM, york sun wrote:
I understand the data in dirty cache is not lost when the dcache is
disabled. It is just not accessible. I
On 10/24/2016 04:44 AM, Mark Rutland wrote:
Hi,
Sorry for joining this a bit late; apologies if the below re-treads
ground already covered.
On Wed, Oct 19, 2016 at 09:25:02AM -0600, Stephen Warren wrote:
On 10/14/2016 02:17 PM, York Sun wrote:
Current code turns off d-cache first, then flush
On Fri, Oct 21, 2016 at 07:31:52PM +, york sun wrote:
> On 10/20/2016 01:34 PM, Stephen Warren wrote:
> > On 10/19/2016 11:06 PM, york sun wrote:
> >> I understand the data in dirty cache is not lost when the dcache is
> >> disabled. It is just not accessible. In my case, after flushing L1/L2 b
Hi,
Sorry for joining this a bit late; apologies if the below re-treads
ground already covered.
On Wed, Oct 19, 2016 at 09:25:02AM -0600, Stephen Warren wrote:
> On 10/14/2016 02:17 PM, York Sun wrote:
> >Current code turns off d-cache first, then flush all levels of cache.
> >This results data l
On 10/20/2016 01:34 PM, Stephen Warren wrote:
> On 10/19/2016 11:06 PM, york sun wrote:
>> On 10/19/2016 06:01 PM, Stephen Warren wrote:
>>> On 10/19/2016 04:32 PM, york sun wrote:
On 10/19/2016 12:18 PM, Stephen Warren wrote:
> On 10/19/2016 09:25 AM, Stephen Warren wrote:
>> On 10/14
On 10/19/2016 11:06 PM, york sun wrote:
On 10/19/2016 06:01 PM, Stephen Warren wrote:
On 10/19/2016 04:32 PM, york sun wrote:
On 10/19/2016 12:18 PM, Stephen Warren wrote:
On 10/19/2016 09:25 AM, Stephen Warren wrote:
On 10/14/2016 02:17 PM, York Sun wrote:
Current code turns off d-cache fir
On 10/19/2016 06:01 PM, Stephen Warren wrote:
> On 10/19/2016 04:32 PM, york sun wrote:
>> On 10/19/2016 12:18 PM, Stephen Warren wrote:
>>> On 10/19/2016 09:25 AM, Stephen Warren wrote:
On 10/14/2016 02:17 PM, York Sun wrote:
> Current code turns off d-cache first, then flush all levels o
On 10/19/2016 04:32 PM, york sun wrote:
On 10/19/2016 12:18 PM, Stephen Warren wrote:
On 10/19/2016 09:25 AM, Stephen Warren wrote:
On 10/14/2016 02:17 PM, York Sun wrote:
Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, t
On 10/19/2016 12:18 PM, Stephen Warren wrote:
> On 10/19/2016 09:25 AM, Stephen Warren wrote:
>> On 10/14/2016 02:17 PM, York Sun wrote:
>>> Current code turns off d-cache first, then flush all levels of cache.
>>> This results data loss. As soon as d-cache is off, the dirty cache
>>> is discarded
On 10/19/2016 09:25 AM, Stephen Warren wrote:
On 10/14/2016 02:17 PM, York Sun wrote:
Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, the dirty cache
is discarded according to the test on LS2080A. This issue was not
seen as
On 10/14/2016 02:17 PM, York Sun wrote:
Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, the dirty cache
is discarded according to the test on LS2080A. This issue was not
seen as long as external L3 cache was flushed to push
On 10/14/2016 02:17 PM, York Sun wrote:
Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, the dirty cache
is discarded according to the test on LS2080A. This issue was not
seen as long as external L3 cache was flushed to push
On 10/14/2016 02:17 PM, York Sun wrote:
Current code turns off d-cache first, then flush all levels of cache.
This results data loss. As soon as d-cache is off, the dirty cache
is discarded according to the test on LS2080A. This issue was not
seen as long as external L3 cache was flushed to push
27 matches
Mail list logo
