From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:48537)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1RsZxh-00009X-U7
	for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:11:04 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1RsZxb-0008QT-H8
	for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:10:57 -0500
Received: from mail-qw0-f45.google.com ([209.85.216.45]:54573)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <peter.maydell@linaro.org>) id 1RsZxb-0008QM-Eu
	for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:10:51 -0500
Received: by qabg40 with SMTP id g40so3202361qab.4
	for <qemu-devel@nongnu.org>; Wed, 01 Feb 2012 05:10:50 -0800 (PST)
MIME-Version: 1.0
In-Reply-To: <4F29384F.6070404@codemonkey.ws>
References: <1328055113-30031-1-git-send-email-grant.likely@secretlab.ca>
	<FD7610EE-454F-4E88-9CC5-0EA7D2CEEF41@suse.de>
	<201202010135.32078.paul@codesourcery.com>
	<1CB9FDC2-00A7-45BF-9693-21EB23FB47B1@suse.de>
	<4F28A554.4090000@codemonkey.ws>
	<CACPZLaVNZPUx6FBg3LvHKBiNx_2s1g-fEE7Ef46QTu+hD7jfMQ@mail.gmail.com>
	<4F29384F.6070404@codemonkey.ws>
Date: Wed, 1 Feb 2012 13:10:50 +0000
Message-ID: <CAFEAcA89A1SBezb2DEbMWL5qD+Me3_uXufmneHyxwz4Kj8dBeA@mail.gmail.com>
From: Peter Maydell <peter.maydell@linaro.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Qemu-devel] [PATCH v2] arm: add device tree support
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Alexander Graf <agraf@suse.de>, Rob Herring <rob.herring@calxeda.com>, qemu-devel@nongnu.org, Grant Likely <grant.likely@secretlab.ca>, Paul Brook <paul@codesourcery.com>, "Edgar E. Iglesias" <edgar.iglesias@gmail.com>, Jeremy Kerr <jeremy.kerr@canonical.com>, John Williams <john.williams@petalogix.com>

On 1 February 2012 13:04, Anthony Liguori <anthony@codemonkey.ws> wrote:
> How does it race? =C2=A0Devices normally never touch memory so a loader d=
evice
> 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...

(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