qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Anitha Boyapati <anitha.boyapati@gmail.com>
To: Robin Randhawa <robin.randhawa@gmail.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Qemu as Instruction Set Simulator without any OS
Date: Wed, 1 Sep 2010 20:29:34 +0530	[thread overview]
Message-ID: <AANLkTimi_T92mHdexSW0Pkg5yBRu3sNpWUPFKLNeBz2g@mail.gmail.com> (raw)
In-Reply-To: <20100901135216.GD22311@gmail.com>

On 1 September 2010 19:22, Robin Randhawa <robin.randhawa@gmail.com> wrote:
[...]
>> My exact requirement is to test a gcc cross-compiler using DejaGnu for
>> a given target (AVR32). While the cross-compiler is ready, there is no
>> simulator. Since there is not much of OS support, I am trying to
>> evaluate if Qemu can still be considered for this purpose.
>
> I see. That makes sense. I thought that AVR32 support never made it to
> the mainline. Has that changed ?
>

Not yet. Maybe sooner :-)

>> The usage scenario probably goes like this:
>>
>> 1. Qemu-target should be invoked with the application (yes,
>> bare-metal) waiting for some gdb connection.  2. target-gdb is invoked
>> with the same application
>>
>> I am referring to the example given in
>> http://wiki.qemu.org/download/qemu-doc.html#gdb_005fusage :
>>
>> > qemu -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img -append
>> > "root=/dev/hda"
>>
>> However, in my case kernel image doesn't exist.
>
> Got that. Note that your system mode emulation would have to cater for
> loading the bare-metal image (qemu has well defined APIs for this). Some
> emulations add some intelligence over and above the bare-metal image
> loading, such as the ARM Realview emulation which checks to see if the
> image passed to the "-kernel" argument is a Linux image in which case
> some special case initialisation is done (instead of a 'raw' load).
>

I was thinking along similar lines. Little more source code probing
should give me better overview.

>> As to the requirement
>> of bootloader, I need to investigate further as various types of
>> memories (FLASH & SRAM for program and data sections) exist.
>
> Most of that can be easily faked as simple RAM at the appropriate
> offsets in your platform description to start off with.
>

Yep, I hope so. Thanks for the help :-)

Best Regards
Anitha

      reply	other threads:[~2010-09-01 14:59 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-31  3:22 [Qemu-devel] Qemu as Instruction Set Simulator without any OS Anitha Boyapati
2010-09-01 12:27 ` Robin Randhawa
2010-09-01 12:54   ` Anitha Boyapati
2010-09-01 13:37     ` Jan-Simon Möller
2010-09-01 15:20       ` Anitha Boyapati
2010-09-01 13:52     ` Robin Randhawa
2010-09-01 14:59       ` Anitha Boyapati [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=AANLkTimi_T92mHdexSW0Pkg5yBRu3sNpWUPFKLNeBz2g@mail.gmail.com \
    --to=anitha.boyapati@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=robin.randhawa@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).