From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:60986) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Si4Jp-0007rL-Qu for qemu-devel@nongnu.org; Fri, 22 Jun 2012 09:54:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Si4Jj-0007ob-Jz for qemu-devel@nongnu.org; Fri, 22 Jun 2012 09:54:37 -0400 Received: from mail-bk0-f45.google.com ([209.85.214.45]:34223) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Si4Jj-0007oS-Cs for qemu-devel@nongnu.org; Fri, 22 Jun 2012 09:54:31 -0400 Received: by bkwj10 with SMTP id j10so1696023bkw.4 for ; Fri, 22 Jun 2012 06:54:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <54bd7599198754771c6dc3f658f4cab74ede93b2.1339982763.git.peter.crosthwaite@petalogix.com> Date: Fri, 22 Jun 2012 23:54:28 +1000 Message-ID: From: Peter Crosthwaite Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [PATCH v2 1/2] arm_boot: Assume Linux boot flow when -dtb given List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: edgar.iglesias@gmail.com, qemu-devel@nongnu.org, john.williams@petalogix.com On Fri, Jun 22, 2012 at 11:36 PM, Peter Maydell wrote: > On 22 June 2012 14:27, Peter Crosthwaite > wrote: >> Ping! >> >> Any thoughts Peter? > > Still sounds too specific to your odd use case and hardware to me. > > I'd accept some reasonable way of saying "this ELF file is a Linux kernel", > but magically doing it if you also said -dtb isn't it. I also care about > backcompat with previous command lines and with being consistent about > how -kernel works across architectures where possible. Speaking of other archs, microblaze will accept -dtb with an elf and implement the r2=foo style behviour before loading the elf entry. A provocative thought, how bout always using a Linux style bootloader no matter what? Does it really matter if your elf is bootstrapped by half a dozen instructions? Further to that, can we get rid of the bootloader blob altogether and just setup the cpu->env like other architectures do? 23 /* The worlds second smallest bootloader. Set r0-r2, then jump to kernel. */ 24 static uint32_t bootloader[] = { 25 0xe3a00000, /* mov r0, #0 */ 26 0xe59f1004, /* ldr r1, [pc, #4] */ 27 0xe59f2004, /* ldr r2, [pc, #4] */ 28 0xe59ff004, /* ldr pc, [pc, #4] */ 29 0, /* Board ID */ 30 0, /* Address of kernel args. Set by integratorcp_init. */ 31 0 /* Kernel entry point. Set by integratorcp_init. */ 32 }; All this code does is set registers and an entry point, which several bootloaders do just though cpu->env manipulation. > a somewhat contradictory set of requirements.) > > -- PMM