From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O6QLm-00025f-6W for qemu-devel@nongnu.org; Mon, 26 Apr 2010 11:35:58 -0400 Received: from [140.186.70.92] (port=40831 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O6QLk-000258-Uj for qemu-devel@nongnu.org; Mon, 26 Apr 2010 11:35:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O6QLi-0005Qb-KB for qemu-devel@nongnu.org; Mon, 26 Apr 2010 11:35:56 -0400 Received: from gate.crashing.org ([63.228.1.57]:49910) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O6QLi-0005QO-6q for qemu-devel@nongnu.org; Mon, 26 Apr 2010 11:35:54 -0400 In-Reply-To: <4BCEF15B.7020204@suse.de> References: <1271841716-11582-1-git-send-email-thomas_ml@monjalon.net> <1271841716-11582-3-git-send-email-thomas_ml@monjalon.net> <9658034F-3621-4F6B-BBD7-CFDAF7E8BCDB@suse.de> <201004211407.50369.thomas_ml@monjalon.net> <4BCEF15B.7020204@suse.de> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7193FDBE-AE3E-4597-A8DD-A20F577230A6@kernel.crashing.org> Content-Transfer-Encoding: 7bit From: Segher Boessenkool Subject: Re: [Qemu-devel] [PATCH 2/2] target-ppc: fix interrupt vectors for MPC603 and e300 Date: Mon, 26 Apr 2010 17:02:39 +0200 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org >> It is explained in [e300CORERM] at chapters 5.2.3, 5.5.1.1 and 8.3.3. >> Clearly, the vector offset is 0x100 and the exception prefix can >> be 0 or >> 0xFFF00000, depending of the MSR[IP] bit. >> >> So, yes, I'm sure the value of hreset_vector must be 0x100. >> But hreset_excp_prefix can change. It could be another patch. > > Interesting. That's different from 970. On 970, you can have the same effect (well, more general) by changing HIOR. >> About the prefix initialization, the datasheet says it is >> "determined by >> MSR[IP]". and is "determined by the state of the msrip signal". >> But I don't >> understand what is the msrip signal and how MSR[IP] is changed (is >> it related >> to msrip ?). Do you have an explanation for this part ? Your code can change MSR[IP]; there is also a strapping pin that is sampled on HRESET (and copied to MSR[IP]). Segher