From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:44405) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ULW5j-00082Y-KQ for qemu-devel@nongnu.org; Fri, 29 Mar 2013 05:59:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ULW5i-0006Dj-BG for qemu-devel@nongnu.org; Fri, 29 Mar 2013 05:59:23 -0400 Message-ID: <515565F7.3070907@adacore.com> Date: Fri, 29 Mar 2013 10:59:19 +0100 From: Fabien Chouteau MIME-Version: 1.0 References: <51542CA2.3070204@adacore.com> <10917A2E-638D-4DA3-A1F7-4C89F03B65D3@suse.de> <51545D49.2010900@adacore.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] PPC: Which instruction to fetch at Power-On? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-ppc@nongnu.org" , "qemu-devel@nongnu.org" On 03/28/2013 05:04 PM, Alexander Graf wrote: > > On 28.03.2013, at 16:10, Fabien Chouteau wrote: > >> On 03/28/2013 12:46 PM, Alexander Graf wrote: >>> >>> On 28.03.2013, at 12:42, Fabien Chouteau wrote: >>> >>>> >>>> While working on a patch to remove env->hreset_excp_prefix, I'm looking >>>> at which instruction should be the fetched first at power-on. I'm lost >>>> in all the PPC version and configuration, can anyone (Alex :) can help >>>> me with this mess? >>> >>> Phew - I'd say just keep the targets you don't know exactly as they are :). That way you at least don't break anything that wasn't broken before. >>> >>> For the targets where you do know better (like 7x0), change its behavior to be correct according to the respective spec. >>> >> >> Here's what I found in the UM of almost all the cores supported by QEMU: >> >> Every CPU should start at the hreset address (i.e. excp_prefix + 0x100). >> >> However, some cores don't have a hreset exception (4xx and Book E (e200, >> e500)), those cores start at 0xFFFF_FFFC. > > At least the G5 and I think also more recent POWER CPUs have either a small command stream or a full blown service processor that initialize initial CPU state like the PC. So there, the CPU starts at a board defined address. > You're right, if the start address doesn't follow core's specification, it's up to the board. > I don't think we need to worry too much about that for now though. > The problem is that my patch may break support of some platforms, we will have to fix the boards later on. -- Fabien Chouteau