sh7785 cache question

sh7785 cache question

[Valentin R Sitsikov]

Hello All!

Sh-7785 hw manual section 5 (Caches), chapter 5.3 (Operation of 
Instructions for Operand Cache Manipulation.) says:
OCBI
OCBWB
OCBP

Formerly, this instruction was treated as an NOP if Rn indicated an 
address in a non-cacheable
area. In the case of the LSI with the SH-4A extended functions, the 
operand cache line indicated
by way = Rn[14:13] and entry = Rn[12:5] is affected.
This operation is only valid in privileged mode, and the instruction 
generates an
address error exception in user mode. In addition, TLB-related 
exceptions do not occur.
Do not execute this instruction with Rn[31:24] containing a value other 
than H'F4, i.e. a value that
indicates the memory-mapped array area, control register area, or a 
reserved area (H'F0 to H'F3,
H'F5 to H'FF).

So my question is why still all cache related code for the sh-7785 in 
these instructions have effective address
as operand instead of 0xF4XXXXXX ?

Also It is interesting if there any plans for remove associative write 
operation to memory mapped OC address array?
The manual says:
5.4       Memory-Mapped Associative Write Operation
Associative writing to the IC and OC address arrays may not be supported 
in future SuperH-
family products. The use of instructions ICBI, OCBI, OCBP, and OCBWB is 
recommended.
These instructions handle ITLB misses, and notify instruction TLB miss 
exceptions and data TLB
miss exceptions, thus providing a sure way of controlling the IC and OC. 
As a transitional
measure, the SH-4A generates address errors when this function is used. 
If compatibility with
previous products is a crucial consideration, on the other hand, the 
MMCAW bit in EXPMASK
(H'FF2F 0004) can be set to 1 to enable this function. However, 
instructions ICBI, OCBI, OCBP,
and OCBWB should be used to guarantee compatibility with future 
SuperH-family products.


Thanks in advance.

Re: sh7785 cache question

[Paul Mundt]

On Thu, Aug 06, 2009 at 01:03:47PM +0400, Valentin R Sitsikov wrote:
> So my question is why still all cache related code for the sh-7785 in 
> these instructions have effective address as operand instead of
> 0xF4XXXXXX ?
> 
[snip]

> Also It is interesting if there any plans for remove associative write 
> operation to memory mapped OC address array?
> 
This has mostly been a compatibility thing, as these new methods do not
work on older parts while at the same time the associated write still
works with current parts, even though it's less than optimal and will
likely go away in the future.

Currently there are a few cases that need to be handled:

	- icbi based I-cache flushing, especially for SMP parts where
	  broadcast invalidation is not handled by hardware.

	- decoupled I-cache and D-cache flushing, mostly for parts with
	  D-cache coherency that still need to maintain the I-cache bits.

	- D-cache flushing overloads for platforms that prefer using more
	  optimized routines.

These are things that I am presently working on in the sh/cachetlb topic
branch getting things tidied up for highmem and variable SH-X3 cache
configurations, which in turn will also benefit SH-X2 cores when
everything is done. It's a bit slow going due to the amount of heavy
testing and benchmarking that needs to be done every step of the way, but
it's slowly getting there.

Feel free to poke around at the topic branch if this is an area you are
interested in playing with, otherwise it should see a 2.6.32 merge.

Re: sh7785 cache question

[Valentin R Sitsikov]

Hello Paul!

Thanks a lot for your answer.
I still can`t understand the situation with ocbi, ocbp, ocbwb on sh4-a.
It is written what they should be used only with address starting from 
0xf4000000 (Rn[31:24] = 0xF4 - memory mapped OC address area)  .
But there are some functions in the kerenl which use virtual address of 
zero page to manipulate with cache.
I made some experiments and has a feeling what cache still can be 
controlled by ocbi... by using
not only 0xf4000000 but any virtual address (which is not permitted by 
spec).
So i am in doubts .
May be You have some ideas if sh7785 could still use ocbi with virtual 
addresses?

Best regards,
Valentin.


Paul Mundt wrote:
> On Thu, Aug 06, 2009 at 01:03:47PM +0400, Valentin R Sitsikov wrote:
>   
>> So my question is why still all cache related code for the sh-7785 in 
>> these instructions have effective address as operand instead of
>> 0xF4XXXXXX ?
>>
>>     
> [snip]
>
>   
>> Also It is interesting if there any plans for remove associative write 
>> operation to memory mapped OC address array?
>>
>>     
> This has mostly been a compatibility thing, as these new methods do not
> work on older parts while at the same time the associated write still
> works with current parts, even though it's less than optimal and will
> likely go away in the future.
>
> Currently there are a few cases that need to be handled:
>
> 	- icbi based I-cache flushing, especially for SMP parts where
> 	  broadcast invalidation is not handled by hardware.
>
> 	- decoupled I-cache and D-cache flushing, mostly for parts with
> 	  D-cache coherency that still need to maintain the I-cache bits.
>
> 	- D-cache flushing overloads for platforms that prefer using more
> 	  optimized routines.
>
> These are things that I am presently working on in the sh/cachetlb topic
> branch getting things tidied up for highmem and variable SH-X3 cache
> configurations, which in turn will also benefit SH-X2 cores when
> everything is done. It's a bit slow going due to the amount of heavy
> testing and benchmarking that needs to be done every step of the way, but
> it's slowly getting there.
>
> Feel free to poke around at the topic branch if this is an area you are
> interested in playing with, otherwise it should see a 2.6.32 merge.
>   

Re: sh7785 cache question

[yoshii.takashi]

I think this answer solves your question better than paul's...
A: You have the question because the manual's description is insufficient.
# I'm a software engineer, and this is never an official speaking of renesas's semiconductor division.

Actually, you can use 00000000-EFFFFFFF and  F4xxxxxxxx for SH4A's cache insns.
# only F4xxxxxx is valid for SH4. 00000000-EFFFFFFF is SH4A extension.

SH7785 Hardware Manual (rej09b0261) says
> Do not execute this instruction to invalidate the memory-mapped array areas and control
> register areas for which Rn[31:24] is not H'F4, and their reserved areas (H'F0 to H'F3, H'F5 to
> H'FF).

Mmm. Perhaps two sentences has been crashed into one? I guess what they wanted to say was
Do not use this instructions onto
  the memory-mapped array areas and control register areas  for which Rn[31:24] is not H'F4.
# According to "Figure 7.4 P4 Area"  of the manual,
#  memory-mapped array areas is H'F3-H'F7,  control register areas is H'FC-H'FF
# Anyway, this does not care about lower space (H'00-H'EF), that is valid area.

And later part is additional, somewhat duplicated area assignment, as a result this is the answer
 Don't use them onto H'F0 to H'F3 and H'F5 to H'FF.

Only the condition (F0-F3,F5-FF) is clearly described in  Software manual for SH4A extensions
(rjj09b0235 written in Japanese, No English version found).
Sorry for inconvenient.

Hope this helps,
/yoshii

Re: sh7785 cache question

[Paul Mundt]

On Tue, Sep 01, 2009 at 11:19:37AM +0900, yoshii.takashi@renesas.com wrote:
> I think this answer solves your question better than paul's...
> A: You have the question because the manual's description is insufficient.
> # I'm a software engineer, and this is never an official speaking of renesas's semiconductor division.
> 
> Actually, you can use 00000000-EFFFFFFF and  F4xxxxxxxx for SH4A's cache insns.
> # only F4xxxxxx is valid for SH4. 00000000-EFFFFFFF is SH4A extension.
> 
> SH7785 Hardware Manual (rej09b0261) says
> > Do not execute this instruction to invalidate the memory-mapped array areas and control
> > register areas for which Rn[31:24] is not H'F4, and their reserved areas (H'F0 to H'F3, H'F5 to
> > H'FF).
> 
> Mmm. Perhaps two sentences has been crashed into one? I guess what they wanted to say was
> Do not use this instructions onto
>   the memory-mapped array areas and control register areas  for which Rn[31:24] is not H'F4.
> # According to "Figure 7.4 P4 Area"  of the manual,
> #  memory-mapped array areas is H'F3-H'F7,  control register areas is H'FC-H'FF
> # Anyway, this does not care about lower space (H'00-H'EF), that is valid area.
> 
> And later part is additional, somewhat duplicated area assignment, as a result this is the answer
>  Don't use them onto H'F0 to H'F3 and H'F5 to H'FF.
> 
> Only the condition (F0-F3,F5-FF) is clearly described in  Software manual for SH4A extensions
> (rjj09b0235 written in Japanese, No English version found).
> Sorry for inconvenient.
> 
I think part of the confusion comes from the fact we are still using
associative writes, which we should ultimately move away from given the
fact they can silently turn in to nops under the right conditions on
current hardware. With the transition off of associative accesses, none
of this should be an issue.