sh7785 cache question

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.

[snip]

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.

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.

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

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

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.