[Qemu-devel] a question

[Qemu-devel] a question

[Marian-Nicolae V. Ion]

Hello,

Is is possible to boot qemu not from a disk image but directly from a
partition ? i.e. I am on Linux Fedora, I have a partition with Mandriva
(I use dual-boot and I can boot on it) but I would like to start my
Mandriva system from qemu, not by rebooting the computer.

Would it be possible? if yes, how?

Regards,

Marian

Re: [Qemu-devel] a question

[Jan Marten Simons]

Marian-Nicolae V. Ion schrieb:
> Hello,
>
> Is is possible to boot qemu not from a disk image but directly from a
> partition ? i.e. I am on Linux Fedora, I have a partition with Mandriva
> (I use dual-boot and I can boot on it) but I would like to start my
> Mandriva system from qemu, not by rebooting the computer.
>
> Would it be possible? if yes, how?
>   
Just supply the device name to qemu: qemu -hda /dev/hdc
You can also use a Partition this way, but then that partition has to 
include a mbr and partition table.

This thread will be of interest to you: 
http://lists.gnu.org/archive/html/qemu-devel/2006-05/msg00164.html
I'm not sure, if the patch mentioned there was merged, yet.

with regards,
Jan

[Qemu-devel] A Question

[Zhenkai Zhang]

Hi, guys,

I want to emulate some code for ARM7TDMI. Does Qemu support this ARM type?

Thank you

Zhenkai

Re: [Qemu-devel] A Question

[Peter Maydell]

On 4 May 2011 16:26, Zhenkai Zhang <zhangzhenkai@gmail.com> wrote:
> I want to emulate some code for ARM7TDMI. Does Qemu support this ARM type?

No, we don't emulate an ARM7TDMI. However depending on what your code
does it's possible that you might be able to get away with using the
ARM926 model. If you want to emulate a system image (rather than an
individual Linux application binary) you also need to consider what
SoC/device/peripherals the system image requires and whether QEMU
supports them: that is likely to be a bigger obstacle.

-- PMM

Re: [Qemu-devel] A Question

[Rob Landley]

On 05/04/2011 10:46 AM, Peter Maydell wrote:
> On 4 May 2011 16:26, Zhenkai Zhang <zhangzhenkai@gmail.com> wrote:
>> I want to emulate some code for ARM7TDMI. Does Qemu support this ARM type?
> 
> No, we don't emulate an ARM7TDMI. However depending on what your code
> does it's possible that you might be able to get away with using the
> ARM926 model. If you want to emulate a system image (rather than an
> individual Linux application binary) you also need to consider what
> SoC/device/peripherals the system image requires and whether QEMU
> supports them: that is likely to be a bigger obstacle.
> 
> -- PMM

I note that I have a half-dozen prebuilt system images at
http://landley.net/aboriginal/downloads/binaries and the build scripts
and such are in the directories above that.

FYI.  I'm working on updating them to a current kernel, and fixing the
ones that have bit-rotted (sparc, sh4...)

Rob

Re: [Qemu-devel] A Question

[Peter Maydell]

On 5 May 2011 00:16, Rob Landley <rob@landley.net> wrote:
> I note that I have a half-dozen prebuilt system images at
> http://landley.net/aboriginal/downloads/binaries and the build scripts
> and such are in the directories above that.

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?

Perhaps we should have a wiki page with links to useful
third-party system images? I also know of Aurelien's
images at http://people.debian.org/~aurel32/qemu/
and no doubt there are others.

-- PMM

Re: [Qemu-devel] A Question

[Rob Landley]

On 05/05/2011 02:01 AM, Peter Maydell wrote:
> On 5 May 2011 00:16, Rob Landley <rob@landley.net> wrote:
>> I note that I have a half-dozen prebuilt system images at
>> http://landley.net/aboriginal/downloads/binaries and the build scripts
>> and such are in the directories above that.
> 
> 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.

The point of these system images is to encourage native development
(I.E. building software natively under qemu, optionally using distcc to
call out to a compatible cross compiler on the host).

All it needs to do this is _a_ kernel that qemu is capable of booting
that can run that software with appropriate peripherals (serial I/O,
network card, block device, RTC, etc).  It includes an example kernel
built to do that under qemu, and a shell script to launch qemu.  But
these are not kernels you'd install on the actual hardware, there are
dozens of those for each root filesystem.

> Perhaps we should have a wiki page with links to useful
> third-party system images? I also know of Aurelien's
> images at http://people.debian.org/~aurel32/qemu/
> and no doubt there are others.

There used to be one, but it's impossible to be complete.

Rob

Re: [Qemu-devel] A Question

[Peter Maydell]

On 5 May 2011 23:13, Rob Landley <rob@landley.net> 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
usually take "system image" to mean "complete disk image
including bootloader, kernel and initrd as well as rootfs",
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.
(ARM kernels having alas not yet got to the point where you
can build a single kernel that will boot on everything.)

-- PMM

Re: [Qemu-devel] A Question

[Rob Landley]

On 05/05/2011 05:32 PM, Peter Maydell wrote:
> On 5 May 2011 23:13, Rob Landley <rob@landley.net> 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

Re: [Qemu-devel] A Question

[Peter Maydell]

On 6 May 2011 00:20, Rob Landley <rob@landley.net> wrote:
> On 05/05/2011 05:32 PM, Peter Maydell wrote:
>> (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

Yes. Making sure ARM QEMU plays nicely with device tree is on
Linaro's todo list for the upcoming six-month cycle.

-- PMM

[Qemu-devel] a question

[Michael Rolnik]

Hi all,

I want to partially implement AT STK500
<http://www.atmel.com/tools/STK500.aspx?tab=documents> board  in order to
run FreeRTOS AVR / ATMegaAVR <http://www.freertos.org/a00090.html#ATMEL>
demo.
if you look into ATmega32 <http://www.atmel.com/images/doc2503.pdf>
documentation you will see that, for example, Timer/Countet1 registers are
held together at memory addresses [0x46 .. 0xff], but interrupt masks and
enable bits are at some other place, actually 0x58 .. 0x59. Every board has
its own interrupt masks and enable registers, because number of devices and
their types may vary.

what is the right solution?

A:

   1. create every device as a true memory mapped QEMU device, which will
   expose all its interrupts as gpio lines
   2. create architecture specific "interrupt controller", which will
   consume all interrupts and aggregate them.


unless there is no device with registers/bits scattered between different
locations.


B:

   1. create non memory mapped devices. Each device will export the
   following functions
   1. avr_<device>_init
      2. avr_<device>_read_<register>
      3. avr_<device>_write_<register>
   2. create "big" memory mapped device, which will cover the whole IO
   space and it will call _read_/_write_ functions of the devices when there
   is an access to specific address in the IO memory space.




-- 
Best Regards,
Michael Rolnik

Re: [Qemu-devel] a question

[Peter Maydell]

On 26 August 2016 at 10:31, Michael Rolnik <mrolnik@gmail.com> wrote:
> I want to partially implement AT STK500 board  in order to run FreeRTOS AVR
> / ATMegaAVR demo.
> if you look into ATmega32 documentation you will see that, for example,
> Timer/Countet1 registers are held together at memory addresses [0x46 ..
> 0xff], but interrupt masks and enable bits are at some other place, actually
> 0x58 .. 0x59.

(0x58..0x59 is a subset of 0x46..0xff -- I think from the docs
that you meant 0x46..0x4f.)

I think I would treat this set of timers as a single device that
implements all the timers, and which implements also the timer
interrupt mask/enable registers. Where there are multiple disjoint
register sets you can do this by having the device provide multiple
MemoryRegions, which the SoC container device then maps into the
memory space at the right places.

If you plan to support multiple CPUs which reuse some of the
individual timer modules but not all of them, you can structure
the code to allow convenient reuse, but that is an internal
detail of the overall "timers" device.

> create non memory mapped devices. Each device will export the following
> functions
>
> avr_<device>_init
> avr_<device>_read_<register>
> avr_<device>_write_<register>
>
> create "big" memory mapped device, which will cover the whole IO space and
> it will call _read_/_write_ functions of the devices when there is an access
> to specific address in the IO memory space.

You can do all this with the memory region API. Your various
devices can provide multiple memory regions (implementing the bits
of memory space that they care about), and then a higher level
SoC container device can map those into the right places in a
container memory region which it then exports to the board level.
You don't need to invent a new API for having devices provide registers.

thanks
-- PMM