I-cache flushing on the 7400

I-cache flushing on the 7400

[Samuel Rydh]

I recently discovered that the following sequence

	LI_PHYS( r2,split_store_patch )
	stw     r4,0(r2)			// store instruction
	dcbst   0,r2				// Flush cache
	sync
	icbi    0,r2
	isync

	.... some instructions and then a rfi to split_store_patch ....
	rfi

split_store_patch:
	nop

did not work properly on a G4s (but it did work flawlessly on my G3).
To make the i-cache flush effective, I had to insert an extra
'sync' before the last isync. Consulting my Motorola manuals,
the recommended sequence for the 7400 (but not for the 750) did have
that extra sync. Looking at the 2.4.3-pre8 BK source, I discovered
the 'sync' was sometimes missing (in flush_icache_range and in a
few places in head.S). Shouldn't the sync really be added?

/Samuel


----------------------------------------------------------
 E-mail <samuel@ibrium.se>  WWW: <http://www.ibrium.se>
  Phone/fax: (home) +46 8 4418431, (work) +46 8 7908470
----------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I-cache flushing on the 7400

[Benjamin Herrenschmidt]

>did not work properly on a G4s (but it did work flawlessly on my G3).
>To make the i-cache flush effective, I had to insert an extra
>'sync' before the last isync. Consulting my Motorola manuals,
>the recommended sequence for the 7400 (but not for the 750) did have
>that extra sync. Looking at the 2.4.3-pre8 BK source, I discovered
>the 'sync' was sometimes missing (in flush_icache_range and in a
>few places in head.S). Shouldn't the sync really be added?

Well, if you had a problem without it and if moto says it's needed, then
I'd go for it, especially since it's not much overhead since this routine
is not used very often.

I'll push that to my tree asap and to bk soon.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I-cache flushing on the 7400

[Gabriel Paubert]

On Sat, 31 Mar 2001, Samuel Rydh wrote:

>
> I recently discovered that the following sequence
>
> 	LI_PHYS( r2,split_store_patch )
> 	stw     r4,0(r2)			// store instruction
> 	dcbst   0,r2				// Flush cache
> 	sync
> 	icbi    0,r2
> 	isync
>
> 	.... some instructions and then a rfi to split_store_patch ....
> 	rfi
>
> split_store_patch:
> 	nop
>
> did not work properly on a G4s (but it did work flawlessly on my G3).
> To make the i-cache flush effective, I had to insert an extra
> 'sync' before the last isync. Consulting my Motorola manuals,
> the recommended sequence for the 7400 (but not for the 750) did have
> that extra sync. Looking at the 2.4.3-pre8 BK source, I discovered
> the 'sync' was sometimes missing (in flush_icache_range and in a
> few places in head.S). Shouldn't the sync really be added?

It should, while actually the isync does not seem necessary since rfi
is a context synchronizing instruction (rfi and sc include implicitly the
equivalent of an isync).

As a side note, this or something similar might have been the cause of a
recently reported problem with 7450 which crash when enabling MaxBUS but
work in traditional 60x bus mode. The reordering of bus operations which
takes place with maxbus makes this kind of bug much more likely to become
visible.

	Regards,
	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I-cache flushing on the 7400

[Samuel Rydh]

On Sat, Mar 31, 2001 at 07:51:55PM +0200, Gabriel Paubert wrote:

> > 	LI_PHYS( r2,split_store_patch )
> > 	stw     r4,0(r2)			// store instruction
> > 	dcbst   0,r2				// Flush cache
> > 	sync
> > 	icbi    0,r2
> > 	isync
> >
> > 	.... some instructions and then a rfi to split_store_patch ....
> > 	rfi
> >
> > split_store_patch:
> > 	nop
> >
>
> It should, while actually the isync does not seem necessary since rfi
> is a context synchronizing instruction (rfi and sc include implicitly the
> equivalent of an isync).

Yes, but in this case the rfi instruction is within the same cache-line
as the nop. I think I need the extra isync to make sure the cache
line in question is not touched before the invalidation is completed.

/Samuel


----------------------------------------------------------
 E-mail <samuel@ibrium.se>  WWW: <http://www.ibrium.se>
  Phone/fax: (home) +46 8 4418431, (work) +46 8 7908470
----------------------------------------------------------

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: I-cache flushing on the 7400

[Gabriel Paubert]

On Sat, 31 Mar 2001, Samuel Rydh wrote:

>
> On Sat, Mar 31, 2001 at 07:51:55PM +0200, Gabriel Paubert wrote:
>
> > > 	LI_PHYS( r2,split_store_patch )
> > > 	stw     r4,0(r2)			// store instruction
> > > 	dcbst   0,r2				// Flush cache
> > > 	sync
> > > 	icbi    0,r2
> > > 	isync
> > >
> > > 	.... some instructions and then a rfi to split_store_patch ....
> > > 	rfi
> > >
> > > split_store_patch:
> > > 	nop
> > >
> >
> > It should, while actually the isync does not seem necessary since rfi
> > is a context synchronizing instruction (rfi and sc include implicitly the
> > equivalent of an isync).
>
> Yes, but in this case the rfi instruction is within the same cache-line
> as the nop. I think I need the extra isync to make sure the cache
> line in question is not touched before the invalidation is completed.

As I understand the doc, you should not need it. The rfi is executed
before the patched instruction, therefore the isync is redundant. It is
the sync instruction that guarantees that the invalidation is completed.
Even if the instructions up to the rfi and the patched instruction are in
the prefetch queue, they will be flushed by the rfi and loaded again into
the instruction cache after the context synchronization due to rfi.

	Gabriel.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/