SH2a Write-back cache issue

SH2a Write-back cache issue

[Andrea Baldini]

Hi,

I'm working on a sh7203 board and I'm currently using a 2.6.28 kernel with a 
write-back cache mode configuration.
When this configuration is set I got some issues when the flush_icache_range is 
involved.

/* O-Cache writeback */
for (way = 0; way < 4; way++) {
unsigned long data =  ctrl_inl(CACHE_OC_ADDRESS_ARRAY | addr | (way << 11));
	if ((data & CACHE_PHYSADDR_MASK) = (v & CACHE_PHYSADDR_MASK)) {
		data &= ~SH_CACHE_UPDATED;
		ctrl_outl(data, CACHE_OC_ADDRESS_ARRAY | addr | (way << 11));
	}
}

When the O-cache writeback is performed all system interrupts are missed, 
including the timer one.
This occurs, for instance, when a flat binary is loaded in memory ( 
load_flat_file() ) or when a signal is handled ( when setting up a frame ).

This is an unacceptable behaviour for the system. 
A workaround is setting a write-through configuration to the kernel and flushing 
just the instruction cache entries.

I've seen the recent kernel releases but it seems this part hasn't been 
modified yet.
Anyway i tried a 2.6.35 kernel version some time ago and i got the same 
problems.

Is anybody here working on this issue?
Is it possible to use the write-back configuration?

Regards

Andrea

Re: SH2a Write-back cache issue

[Fabio Giovagnini]

Hi Federico, I think you could help Andrea about this issue.
Regard

Il giorno mar, 22/11/2011 alle 14.15 +0100, Andrea Baldini ha scritto:
> Hi,
> 
> I'm working on a sh7203 board and I'm currently using a 2.6.28 kernel with a 
> write-back cache mode configuration.
> When this configuration is set I got some issues when the flush_icache_range is 
> involved.
> 
> /* O-Cache writeback */
> for (way = 0; way < 4; way++) {
> unsigned long data =  ctrl_inl(CACHE_OC_ADDRESS_ARRAY | addr | (way << 11));
> 	if ((data & CACHE_PHYSADDR_MASK) = (v & CACHE_PHYSADDR_MASK)) {
> 		data &= ~SH_CACHE_UPDATED;
> 		ctrl_outl(data, CACHE_OC_ADDRESS_ARRAY | addr | (way << 11));
> 	}
> }
> 
> When the O-cache writeback is performed all system interrupts are missed, 
> including the timer one.
> This occurs, for instance, when a flat binary is loaded in memory ( 
> load_flat_file() ) or when a signal is handled ( when setting up a frame ).
> 
> This is an unacceptable behaviour for the system. 
> A workaround is setting a write-through configuration to the kernel and flushing 
> just the instruction cache entries.
> 
> I've seen the recent kernel releases but it seems this part hasn't been 
> modified yet.
> Anyway i tried a 2.6.35 kernel version some time ago and i got the same 
> problems.
> 
> Is anybody here working on this issue?
> Is it possible to use the write-back configuration?
> 
> Regards
> 
> Andrea
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Fabio Giovagnini

Aurion s.r.l.
P.iva 00885711200
cell. +39.335.8350919
Tel. +39 051.082.69.65
Fax. +39 051.082.14.49
skype: aurion.giovagnini

Re: SH2a Write-back cache issue

[Andrea Baldini]

> Hi Federico, I think you could help Andrea about this issue.
> Regard
> 

Thanks Fabio.

I have just successfully booted the lastest git kernel (thanks to Phil for the 
ioread/iowrite big endian fix) but it seems that the write back cache problem 
occurs in the 3.2.0-rc2 too.


-- 
Andrea Baldini

Elettronica di Processo

 

SPES. S.c.p.a
Via  Lamberto Corsi, 43
60044 Fabriano (AN)
tel. +39 0732 25291
fax +39 0732 2529441

 <mailto:andrea.baldini@spesonline.com> andrea.baldini@spesonline.com

 <http://www.spesonline.com> www.spesonline.com

Re: SH2a Write-back cache issue

[Federico Fuga]

Hi Andrea,

I've been working with Fabio on a similar issue.

Il giorno 23/nov/2011, alle ore 11.52, Andrea Baldini ha scritto:
> I have just successfully booted the lastest git kernel (thanks to Phil for the 
> ioread/iowrite big endian fix) but it seems that the write back cache problem 
> occurs in the 3.2.0-rc2 too.

In our setup, the problem seems related to an LCD flickering, when the cache is setup in read-back mode we had an heavy flickering on the LCD, when in write-through it seems much less present, even though not completely absent. 
We tried many different setup for cache and DRAM, but found no solutions for it.
Of course the problem is present in 2.6.17, 2.6.37-38, 3.0 and 3.1 kernels.
We found just one situation where the flickering is nearly invisible, while reserving 2Mb of frame buffer - so placing the fb and the other kernel/code memory far each other.
What is your problem and setup?

Federico

Re: SH2a Write-back cache issue

[Andrea Baldini]

> In our setup, the problem seems related to an LCD flickering, when the
> cache is setup in read-back mode we had an heavy flickering on the LCD,
> when in write-through it seems much less present, even though not
> completely absent. We tried many different setup for cache and DRAM, but
> found no solutions for it. Of course the problem is present in 2.6.17,
> 2.6.37-38, 3.0 and 3.1 kernels. We found just one situation where the
> flickering is nearly invisible, while reserving 2Mb of frame buffer - so
> placing the fb and the other kernel/code memory far each other. What is
> your problem and setup?
> 
> Federico

Hi Federico,

Currently I'm working with a framebuffer on my custom board but the problem I 
described occurs in a basic setup too (without frambuffer support and other not  
essential stuff).

I found this problem when I was working with the Renesas demo board rsk7203.
I tried some kernels compiled with the board defconfig and a busybox built with 
a basic configuration (using a toolchain which creates flat binaries).

With this setup I found that the timer interrupts were missed when executing 
the busybox applets and it was very clear especially in shell loop scripts.
With some debug work I saw that the problem was located in the function i 
mentioned in the first mail, that is flush_icache_range (you can find it in 
cache-sh2a.c) which caused interrupts to be missed during its execution.

The flush_icache_range is called in some points of the kernel and one of them 
is in the load_flat_file() which, in my case, is heavy used (having a flat 
busybox).

Hope this helps to better understand the issue.

Andrea

-- 
Andrea Baldini

Elettronica di Processo

 

SPES. S.c.p.a
Via  Lamberto Corsi, 43
60044 Fabriano (AN)
tel. +39 0732 25291
fax +39 0732 2529441

 <mailto:andrea.baldini@spesonline.com> andrea.baldini@spesonline.com

 <http://www.spesonline.com> www.spesonline.com