qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] A Question


From: Rob Landley
Subject: Re: [Qemu-devel] A Question
Date: Thu, 05 May 2011 18:20:04 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Thunderbird/3.1.8

On 05/05/2011 05:32 PM, Peter Maydell wrote:
> On 5 May 2011 23:13, Rob Landley <address@hidden> wrote:
>> On 05/05/2011 02:01 AM, Peter Maydell wrote:
>>> I'm afraid I don't entirely understand your file naming
>>> system there -- it seems to say which architecture the
>>> system images are for but not what board?
>>
>> Exactly.  An armv5l root filesystem will run on dozens of boards.  You
>> need to rebuild the kernel for a specific board, but not the root
>> filesystem or toolchain.
> 
> Doh, I should have read the readme a bit more carefully.

I'm working on documentation but every time I sit down and properly
document everything it turns into a giant BOOK ala

  http://landley.net/aboriginal/downloads/presentation.pdf

I've tried it as a faq, I've tried it as both tutorial and reference, I
need to do... I dunno, podcasts or something.

> I
> usually take "system image" to mean "complete disk image
> including bootloader, kernel and initrd as well as rootfs",

In this case qemu's "-kernel" option is the bootloader.  I have it load
an init script out of the final root filesystem instead of using an
initrd (although the build scripts have an initrd packging option so the
root filesystem can _be_ an initrd, either as a cpio image or bundled
into a kernel, but that imposes size limitations and requires the
emulated system to allocate more physical memory, which is a pain on
mips and such).

> which obviously does include the board-specific bits. On the
> other hand the readme does say the tarball includes "a kernel"
> so in that sense it is board-specific, presumably.

Yes, but it's just some random board qemu is capable of emulating.  It
doesn't matter WHICH, it matters that ./run-emulator.sh can boot qemu to
a shell prompt and get reasonable performance with the required I/O
device feature list.

I'm actually trying to get it more generic with device trees and virtio
and such, but those really aren't baked yet.  (And armv6l bit-rotted
recently because I was patching the kernel to stick an armv6l cpu
emulation into a Versatile board, which doesn't happen in nature and
stopped working with my patch around 2.6.33 or so.  I need to swap in a
real armv6l board emulation there.  It's a todo item.)

> (ARM kernels having alas not yet got to the point where you
> can build a single kernel that will boot on everything.)

Grant Likely's working on making it happen via device trees. Here's my
bookmark out of my todo list on the current status of using qemu with that:

http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-March/005112.html

Haven't had a chance to play with it yet, though...

It still won't be a _single_ kernel because you'll still need armv4tl,
armv5l, armv6l, armv7l, thumb2, and a couple of "not quite floating
point, not quite mmx" extensions ala neon...

(Well, ok, armv4tl will boot on everything but it'd be slow which means
poor battery life.  Good enough for doing native compiles, of course...)

Rob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]