[Top] [All Lists]

Re: kexec - not happening on mipsel?

To: Nicolas Schichan <>
Subject: Re: kexec - not happening on mipsel?
From: Ralf Baechle <>
Date: Mon, 20 Aug 2007 17:28:40 +0100
Cc: Andrew Sharp <>,
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: Mutt/1.5.14 (2007-02-12)
On Mon, Aug 20, 2007 at 03:57:38PM +0200, Nicolas Schichan wrote:

> The updated patch only uses __flush_cache_all().

Applied, thanks.

> > There is a hazard barrier missing here.
> Just for my culture, could you please specify which kind of barrier macro 
> should I use here ? should it be a back_to_back_c0_hazard() ?

According to the MIPS architecture, a mfc0 instruction that is immediately
following a mtc0 instruction where both are accessing the same cp0
register, has undefined operation.  Not all processors have this hazard and
for those those which have it the resolution before version 2 of the
architecture did differ between MIPS implementation.
back_to_back_c0_hazard() will solve this problem.  For example:

        write_c0_status(read_c0_status() & ~ ST0_BEV);
        write_c0_status(read_c0_status() | ST0_IE);

could possibly be compiled into such a mtc0 mfc0 sequence.  Throwing in a
back_to_back_c0_hazard() line will fix that.

        write_c0_status(read_c0_status() & ~ ST0_BEV);
        write_c0_status(read_c0_status() | ST0_IE);

On a modern processor back_to_back_c0_hazard() will expand into a EHB,
on an antique to whatever serves the equivalent job.

Changing Config.K0 also creates an "instruction hazard".  Even when the
mtc0 has been graduated in the pipeline it needs to be ensured that no
instructions are being fetched and executed based on the old value.

My description is somewhat to short to be accurate, I suggest you read
up on it in the MIPS R2 architecture specification, See MIPS Run and of
course in the manual for your specific processor.

> Hoewever I so feel a bit unsafe now because D-Cache is not wrote-back and 
> I-Cache is not invalidated in relocate_kernel.S, before jumping to the new 
> kernel. This happens to work on my board, but I think that it is mostly 
> because of luck. Maybe using KSEG1 or XKPHYS (not sure about this one, I am 
> not familiar with 64bit mips) when fixing the indirection list addresses 
> should be safer.

KSEG1 would have the same issues as KSEG0 configured to uncached.

But really, why making things more complicated than required.  A flush
should do the trick.

Another open end in your patch would be SMP; normally Linux expects that
on bootup all processors are under firmware control but that is not the
case when a new kernel is initializing after being kexeced.


<Prev in Thread] Current Thread [Next in Thread>