From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:45812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsaBm-0004LF-0k for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:25:34 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsaBi-0003ZL-7O for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:25:29 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:37477) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsaBi-0003ZE-11 for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:25:26 -0500 Received: by pbaa11 with SMTP id a11so1391343pba.4 for ; Wed, 01 Feb 2012 05:25:25 -0800 (PST) Message-ID: <4F293D40.90804@codemonkey.ws> Date: Wed, 01 Feb 2012 07:25:20 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <1328055113-30031-1-git-send-email-grant.likely@secretlab.ca> <201202010135.32078.paul@codesourcery.com> <1CB9FDC2-00A7-45BF-9693-21EB23FB47B1@suse.de> <4F28A554.4090000@codemonkey.ws> <4F29384F.6070404@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] arm: add device tree support List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Alexander Graf , Rob Herring , qemu-devel@nongnu.org, Grant Likely , Paul Brook , "Edgar E. Iglesias" , Jeremy Kerr , John Williams On 02/01/2012 07:10 AM, Peter Maydell wrote: > On 1 February 2012 13:04, Anthony Liguori wrote: >> How does it race? Devices normally never touch memory so a loader device >> will be the only thing mucking with memory. > > The obvious one is "loader reset function wants to set starting PC to > entry point of kernel/etc" vs "CPU device reset wants to set starting > PC to hardware-mandated reset vector". We have this at the moment, of > course, and I think we implicitly rely on reset handlers being called > in order of registration... I'm a bit confused, why can't the kernel loader be implemented in terms of a firmware blob? This is what we do for x86 and it solves this problem robustly. Isn't it just a matter of a few instructions to do a jmp to a known location? Regards, Anthony Liguori > > (The other irritating case is where the CPU device reset wants > to read the starting PC out of memory, like the Cortex-M3, but > really that one is because we don't distinguish "going into reset" > from "coming out of reset".) > > -- PMM >