[Qemu-devel] Qemu as Instruction Set Simulator without any OS

[Qemu-devel] Qemu as Instruction Set Simulator without any OS

[Anitha Boyapati]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

Hi All,

Having gone through the documentation (developers) and source code, I couple
of questions:

1. For a microcontroller which doesn't have any OS support, can QEMU be
ported without any OS ?
2. Can QEMU be used as a simple instruction set simulator with probably gdb
support for remote debugging? My guess is this would require a bootloader to
load the application to run the application program (full system emulation
mode or just machine emulation if there is something like that). If yes,
what else can be the blocker to have gdb support?

It would be great if someone can share their experiences in this regard.
Essentially I am trying to see if qemu can be of any use in non-os
cases.(Please Cc me)

Thanks
Anitha

[-- Attachment #2: Type: text/html, Size: 768 bytes --]

Re: [Qemu-devel] Qemu as Instruction Set Simulator without any OS

[Robin Randhawa]

Hi Anitha.

Anitha Boyapati wrote:
> Hi All,
>
> Having gone through the documentation (developers) and source code, I
> couple of questions:
>
> 1. For a microcontroller which doesn't have any OS support, can QEMU be
> ported without any OS ?

Not sure I understand. If you want to run qemu natively on the 
microcontroller (in order to dynamically translate code _on_ the 
microcontroller) than that would be a daunting task in the absence of a 
rich execution environment on the microcontroller.

On the other hand, if your question could be rephrased as 'I want to add 
support for a new microcontroller to qemu but I only want to run 
"bare-metal" (not an OS or an application under an OS) software on the 
model', I think that is certainly possible.

> 2. Can QEMU be used as a simple instruction set simulator with probably
> gdb support for remote debugging? My guess is this would require a
> bootloader to load the application to run the application program (full
> system emulation mode or just machine emulation if there is something
> like that). If yes, what else can be the blocker to have gdb support?

IMHO, gdb support if available, is available irrespective of the type 
and nature of the software being run on qemu. For example, you can 
create a bare-metal application that executes from the reset vector for 
say, the ARM or the MIPS models and have gdb support right from the 
outset. There is no explicit need for running boot firmware and/or a 
loader to load an application program. Not sure if that's what you were 
after.

This does require system-mode emulation support as opposed to user-mode 
emulation for your microcontroller to be implemented.

HTH,
Robin

Re: [Qemu-devel] Qemu as Instruction Set Simulator without any OS

[Anitha Boyapati]

Hello Robin,

>> 1. For a microcontroller which doesn't have any OS support, can QEMU be
>> ported without any OS ?
>

> On the other hand, if your question could be rephrased as 'I want to add support for a new microcontroller to qemu but I only want to run "bare-metal" (not an OS or an application under an OS) software on the model', I think that is certainly possible.
>


Yes,  this is what I have been looking for. Adding support for a new
micro-controller which doesn't support any OS yet.

>> 2. Can QEMU be used as a simple instruction set simulator with probably
>> gdb support for remote debugging? My guess is this would require a
>> bootloader to load the application to run the application program (full
>> system emulation mode or just machine emulation if there is something
>> like that). If yes, what else can be the blocker to have gdb support?
>
> IMHO, gdb support if available, is available irrespective of the type and nature of the software being run on qemu. For example, you can create a bare-metal application that executes from the reset vector for say, the ARM or the MIPS models and have gdb support right from the outset. There is no explicit need for running boot firmware and/or a loader to load an application program. Not sure if that's what you were after.
>

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.

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. As to the requirement
of bootloader, I need to investigate further as various types of
memories (FLASH & SRAM for program and data sections) exist.

> This does require system-mode emulation support as opposed to user-mode emulation for your microcontroller to be implemented.

Agreed. System-mode emulation is what is required.

Thanks
Anitha

Re: [Qemu-devel] Qemu as Instruction Set Simulator without any OS

[Jan-Simon Möller]

Am Mittwoch, 1. September 2010, 14:54:41 schrieb Anitha Boyapati:
[...]
> 
> 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.


You should ask Bradley Smith (http://brad-smith.co.uk/ , http://brad-smith.co.uk/emul ) . 
He did experiment creating "qemu-avr32".


Best,
Jan-Simon

Re: [Qemu-devel] Qemu as Instruction Set Simulator without any OS

[Anitha Boyapati]

Hello Jan-Simon,

2010/9/1 Jan-Simon Möller <dl9pf@gmx.de>:
> Am Mittwoch, 1. September 2010, 14:54:41 schrieb Anitha Boyapati:
> [...]
>>
>> 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.
>
>
> You should ask Bradley Smith (http://brad-smith.co.uk/ , http://brad-smith.co.uk/emul ) .

AVR32 emulator...wow! Emulator with llvm jit is indeed more interesting.

> He did experiment creating "qemu-avr32".
>

I did a quick search. Looks like the emulator for avr32 is probably
not Qemu... Also, most of the support has gone for AP7 series.
Support for UC3 series is what I am looking for.

With regarding to qemu-avr32, Rabin Vincent created an experimental
port for AVR32 (link below). Here again, only  AP7 has been supported.
http://lists.gnu.org/archive/html/qemu-devel/2009-10/msg02322.html

Thanks for the links. I will contact Bradley Smith for more details.

Best Regards
Anitha

Re: [Qemu-devel] Qemu as Instruction Set Simulator without any OS

[Robin Randhawa]

Hi again.

On Wed, Sep 01, 2010 at 06:24:41pm +0530, Anitha Boyapati wrote:
> Hello Robin,
[...]
> 
> >> 2. Can QEMU be used as a simple instruction set simulator with
> >> probably gdb support for remote debugging? My guess is this would
> >> require a bootloader to load the application to run the application
> >> program (full system emulation mode or just machine emulation if
> >> there is something like that). If yes, what else can be the blocker
> >> to have gdb support?
> >
> > IMHO, gdb support if available, is available irrespective of the
> > type and nature of the software being run on qemu. For example, you
> > can create a bare-metal application that executes from the reset
> > vector for say, the ARM or the MIPS models and have gdb support
> > right from the outset. There is no explicit need for running boot
> > firmware and/or a loader to load an application program. Not sure if
> > that's what you were after.
> 
> 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 ?
 
> 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).

> 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.
 
> > This does require system-mode emulation support as opposed to
> > user-mode emulation for your microcontroller to be implemented.
> 
> Agreed. System-mode emulation is what is required.

Cheers,
Robin

Re: [Qemu-devel] Qemu as Instruction Set Simulator without any OS

[Anitha Boyapati]

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