From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44683) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJRBr-0006nR-Cn for qemu-devel@nongnu.org; Mon, 09 May 2011 10:12:07 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QJRBm-0001bh-RZ for qemu-devel@nongnu.org; Mon, 09 May 2011 10:12:03 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57740 helo=mx2.suse.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QJRBm-0001bZ-F2 for qemu-devel@nongnu.org; Mon, 09 May 2011 10:11:58 -0400 Message-ID: <4DC7F62C.7030103@suse.de> Date: Mon, 09 May 2011 16:11:56 +0200 From: Alexander Graf 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> In-Reply-To: <4DC6E01D.4060503@landley.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable 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: Rob Landley Cc: Peter Maydell , =?ISO-8859-1?Q?Andreas_F=E4rber?= , qemu-devel@nongnu.org, Ben Leslie On 05/08/2011 08:25 PM, Rob Landley wrote: > On 05/08/2011 09:10 AM, Andreas F=E4rber wrote: >> Am 06.05.2011 um 14:48 schrieb Alexander Graf: >> >>> On 06.05.2011, at 01:50, Rob Landley wrote: >>> >>>> On 05/05/2011 06:26 PM, Alexander Graf wrote: >>>>>> As an aside: I think QEMU should have an option which is "just loa= d >>>>>> a plain ELF or raw binary, with no funny Linux-kernel-specific >>>>>> behaviour" rather than overloading -kernel to mean "if it's a raw >>>>>> image it's Linux and if it's an ELF file it's not". >>>>> Traditionally, -bios has been that one. -kernel is more of a real >>>>> bootloader replacement, including all the weirdness a bootloader do= es >>>>> :). >>>> Except that neither "qemu-system-x86_64 -bios vmlinux" nor >>>> qemu-system-x86_64 -kernel vmlinux" will load an ELF kernel on x86-6= 4. >>>> >>>> The code to do this _exists_ within qemu, it's just not hooked up >>>> consistently on all targets. We have a universal cross-platform ima= ge >>>> format, and we have support in qemu for loading that format, and for >>>> some reason it's only enabled on certain targets. I've never unders= tood >>>> why... >>> Unfortunately, booting isn't that easy :). The kernel needs some more >>> data than just itself and an entry point to properly load. On some >>> architectures, it requires a device tree (and pointer to it in a >>> register), it might require page tables / TLB entries to be set up, i= f >>> you want -initrd and -append to work you also need to tell the kernel >>> where to find those. >>> >>> So while ELF is a nice container for binaries, there are still some >>> pieces missing to actually make it a kernel loader. But that's what >>> multiboot was invented for. I haven't seen too much effort going on >>> around multiboot on non-x86, but it basically fills exactly the gap >>> you're wondering about. It uses ELF and adds a simple boot protocol >>> for all the other fancy stuff a kernel needs. >> I guess Rob meant something different: -bios does not load ELF files f= or >> all machines (raw neither). For example, for raw-only PReP I had poste= d >> a patch that enables loading ELF firmware like OpenBIOS that you turne= d >> down. > I actually wrote a long reply and then save-as-draft rather than sendin= g > it because it boils down to "I need to do the work myself and send you = a > patch". > > What I meant was that the build for every Linux architecture produces a > vmlinux file, which it often then packs into another format but on mips > and powerpc the file I feed to -kernel is the elf vmlinux file. > (Doesn't even have to be stripped.) > > Which is nice, because when I debug stuff with the -s option I need to > feed the vmlinux file to gdb, so just having to keep track of one of th= e > suckers is incredibly convenient. Being able to build 5 architectures > without having to record an arbitrary path to whatever the output file > is called this time is also nice. > > Yes, -kernel is linux-specific: so is vmlinux. Yes -kernel does variou= s > other stuff to boot a linux kernel, but at least half of it is obsolete > things for 2.2 and earlier kernels, as described in the rdev man page. > (And if you want to use such ancient kernels, you can always make a boo= t > floppy image and use rdev, just just make a disk image with a bootloade= r > in it from one of the install cds on > http://archive.download.redhat.com/pub/redhat/linux or something.) > > Pretty much everything the kernel needs is on the command line these > days, including vga settings and the physical starting address of the > initial ram disk ("ramdisk_start=3D", see init/do_mounts_rd.c in the > kernel). On most platforms the one thing it needs is a device tree > pointer (in a register) and then it finds the command line data blob > through that. > > I have no interest in GNU/multiboot, and neither does most of the rest > of the Linux community from what I've seen. The GNU/hurd is welcome to > it, the FSF has nothing to do with Linux. The people porting device > trees to x86 soo the mechanism will be properly universal (that went > into the 2.6.39 development series, by the way) are not referencing > GNU/multiboot. I want to teach -kernel to accept a vmlinux file, not > introduce crazy FSF code dependencies, which don't seem to be supported > on any non-x86 platform yet despite being designed with Solaris in mind= , > into my build. > > What I want to do is actually somewhat straightforward, load_elf() is > already used directly on several platforms like mips_r4k.c, the hard > parts of making it work on x86 are A) properly editing the kernel > command line instead of trying to recreate rdev, B) figuring out where > to splice the kernel command line start address into a vmlinux instead > of a bzImage, and C) starting in the right mode. > > 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. Grub won't=20 just load a vmlinux file and boot it. I'm not even sure how much exactly=20 the early entry code handles in Linux before it jumps to the ELF entry=20 point. Either way, if you get something rolling that also ensures that it fails=20 when it's an ELF file that's not Linux, I'd be very open to it :). > But "-kernel vmlinux" is not currently at the top of my todo list, lemm= e > 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, tha= t >> 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=20 to set up TLB entries, but those are at least defined by the spec :). Alex