From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33046) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsaUN-0003e4-Qw for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:44:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RsaUE-0000Hm-SY for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:44:43 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:47621) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RsaUE-0000Fo-N1 for qemu-devel@nongnu.org; Wed, 01 Feb 2012 08:44:34 -0500 Received: by pbaa11 with SMTP id a11so1409731pba.4 for ; Wed, 01 Feb 2012 05:44:32 -0800 (PST) Message-ID: <4F2941BB.9010406@codemonkey.ws> Date: Wed, 01 Feb 2012 07:44:27 -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> <4F293D40.90804@codemonkey.ws> <514AF576-4462-40FD-B6EA-F98C6AD4A915@suse.de> In-Reply-To: <514AF576-4462-40FD-B6EA-F98C6AD4A915@suse.de> Content-Type: text/plain; charset=ISO-8859-1; 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: Alexander Graf Cc: Peter Maydell , qemu-devel@nongnu.org, Rob Herring , Grant Likely , Paul Brook , "Edgar E. Iglesias" , Jeremy Kerr , John Williams On 02/01/2012 07:32 AM, Alexander Graf wrote: > > On 01.02.2012, at 14:25, Anthony Liguori wrote: > >> 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? > > Only if you have non-semi-hosted modes. For e500 for example, we don't have a bios flash region mapped through mmio available. So we would have to write the "jump to kernel" code into ram. But where in RAM? Linux starts at address 0, so that one's taken. The processor has to have a defined sequence where IP is fixed to a specific value, no? How else would the real hardware bootstrap software? Regards, Anthony Liguori > > Alex > >