From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46813) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJf1w-0007PW-Nf for qemu-devel@nongnu.org; Tue, 10 May 2011 00:58:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QJf1v-0004Wq-Do for qemu-devel@nongnu.org; Tue, 10 May 2011 00:58:44 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:35855) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJf1v-0004Wk-BY for qemu-devel@nongnu.org; Tue, 10 May 2011 00:58:43 -0400 Received: by yib19 with SMTP id 19so2425211yib.4 for ; Mon, 09 May 2011 21:58:42 -0700 (PDT) Message-ID: <4DC8C5FB.3010500@landley.net> Date: Mon, 09 May 2011 23:58:35 -0500 From: Rob Landley MIME-Version: 1.0 References: <57FFBBA3-27A2-4362-A6AC-4D48315352EB@suse.de> <4DC337DF.1060100@landley.net> <90784430-8495-4C6C-B40D-BB6A920C24C9@web.de> <4DC6E01D.4060503@landley.net> <4DC7F62C.7030103@suse.de> In-Reply-To: <4DC7F62C.7030103@suse.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Allow ARMv7M to be started without a kernel List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: Peter Maydell , =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org, Ben Leslie On 05/09/2011 09:11 AM, Alexander Graf wrote: >> C) requires more research, because I have to make sure the entry point >> is either doing the 16->32 (or 64) bit startup dance or that it's being >> launched in the right mode (which the bios isn't doing), but vmlinux >> doesn't need to be decompressed and copied so it's just making sure >> we're expecting the right layer of stuff. Which means reading through >> arch/x86/boot to see what the vmlinux->bzImage packaging is adding, I >> suppose. > > The issue is that this is not how it works on real hardware. Real hardware doesn't have the -kernel option. On x86 that option is currently patching the rdev area after loading the blob into DRAM. > Grub won't just load a vmlinux file and boot it. The -kernel option doesn't load grub, it loads a _kernel_. -kernel is a linux-specific bootloader. It doesn't chainload other bootloaders. > I'm not even sure how much exactly > the early entry code handles in Linux before it jumps to the ELF entry > point. > > Either way, if you get something rolling that also ensures that it fails > when it's an ELF file that's not Linux, I'd be very open to it :). If it's an ELF file that's not Linux, I can ensure the result won't boot Linux. It's guaranteed to fail without me doing anything. I don't understand your objection. (The option is called -kernel. It does what it says on the tin. If you feed it something that isn't a kernel, which you can do now, this is pilot error.) By the way, I just did "qemu -kernel qemu-img" an the emulated vga screen was very colorful. Feeding it qemu-io gave a different pattern of vga text mode garbage. It's happily loading an elf file _now_, and spinning its little CPU on the resulting garbage... >> But "-kernel vmlinux" is not currently at the top of my todo list, lemme >> finish studying the v9fs code first... >> >>> Point being, the handling of -bios is board-specific (not even >>> architecture-specific) and thus inconsistent. >> So, currently, is -kernel. Having it accept vmlinux on more platforms >> would make it more consistent. (Having -bios accept that too sounds >> great, but is orthogonal to what I'm trying to do.) >> >>> Your points above - page >>> tables, TLB entries etc. - only apply to -kernel but not to -bios, that >>> should give us a bare-metal machine. >> In 16 bit mode. > > Depends on the machine. On PPC e500 for example, even with -bios we have > to set up TLB entries, but those are at least defined by the spec :). Yes, -kernel has to do setup work before starting the kernel. This is true now, it remains true if the kernel is in a different file format. -kernel is a linux bootloader, which is not the same thing as the -bios option. Rob