[Qemu-devel] qemu-system-sparc question?

[Qemu-devel] qemu-system-sparc question?

[Ishwar Rattan]

Is it possible to boot the iso image
   debian-31r3-sparc-netinst.iso

in qemu-system-sparc? What about other
Linux distributions?

-ishwar

Re: [Qemu-devel] qemu-system-sparc question?

[K. Richard Pixley]

Ishwar Rattan wrote:
> Is it possible to boot the iso image
>   debian-31r3-sparc-netinst.iso
>
> in qemu-system-sparc? What about other
> Linux distributions? 
I haven't tried it.  But I'd be curious to hear how it works for you.

--rich

Re: [Qemu-devel] qemu-system-sparc question?

[WaxDragon]

I've booted both aurora sparc linux 2.0-rcsomething and the last
sparc32 gentoo iso available (install-sparc-universal-2004.1.iso).
They both "work" to a certian point.  There are still bugs to be fixed
/ uncovered.

WD

On 10/10/06, K. Richard Pixley <rich.pixley@palmsource.com> wrote:
> Ishwar Rattan wrote:
> > Is it possible to boot the iso image
> >   debian-31r3-sparc-netinst.iso
> >
> > in qemu-system-sparc? What about other
> > Linux distributions?
> I haven't tried it.  But I'd be curious to hear how it works for you.
>
> --rich
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


-- 
22:38 <@WaxDragon> false ^ true
22:39 < false> :(
22:39 < false> dont you think you can XOR me and get away with it! I
always return!

Re: [Qemu-devel] qemu-system-sparc question?

[Ishwar Rattan]

On Tue, 10 Oct 2006, WaxDragon wrote:

> I've booted both aurora sparc linux 2.0-rcsomething and the last
> sparc32 gentoo iso available (install-sparc-universal-2004.1.iso).
> They both "work" to a certian point.  There are still bugs to be fixed
> / uncovered.
Can you give some more information on the boot process itself?
Where can I find install-sparc-universal-2004.1.iso (it is not
on the mirrors?

Thanks,
-ishwar

RE: [Qemu-devel] qemu-system-sparc question?

[Blue Swirl]

>Is it possible to boot the iso image
>   debian-31r3-sparc-netinst.iso
>
>in qemu-system-sparc? What about other
>Linux distributions?

In serial console mode it should boot and the install should finish (Qemu 
CVS version), at least on 3.1r1 full CD.

I made some tests a while ago, here are the results:

Aurora 1.0 graphical: X starts
Aurora 2.0 graphical: X starts, partitioning fails
Aurora 2.1 graphical: installer thinks CD is not correct
Debian 3.1 R1 serial: install complete
Gentoo 1.4 RC5 graphical: shell prompt, keyboard fast repeat
Gentoo 2004.1 graphical: shell prompt, keyboard fast repeat, hangs
NetBSD 1.6.1 graphical: loader can't find kernel
NetBSD 2.1 graphical: loader can't find kernel
NetBSD 3.0 graphical: loader can't find kernel
Red Hat 4.2 Zoot graphical: Cannot open /dev/kbd, keyboard doesn't work
SuSE 7.1 graphical: X starts, mouse doesn't work

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: [Qemu-devel] qemu-system-sparc question?

[Ishwar Rattan]

Well here is the situation. Dept had a lab with SPARC
based Solaris machines that were phased out in summer
(over my objections). I needed the environment to teach
first computer archt course with some assembly language
thrown in. Intel processor assembly requires a much
bigger effort (on part of students) which defeats the puprpose
of the course. So, I thought that I could put together
the SPARC back, if I am able to boot a SPARC version of
Linux (with gcc, gas, text-editor and networking) under
qemu. Hence the barrage of questions. GUI is a non-issue.

-ishwar

On Tue, 10 Oct 2006, Blue Swirl wrote:

>> Is it possible to boot the iso image
>>   debian-31r3-sparc-netinst.iso
>> 
>> in qemu-system-sparc? What about other
>> Linux distributions?
>
> In serial console mode it should boot and the install should finish (Qemu CVS 
> version), at least on 3.1r1 full CD.
>
> I made some tests a while ago, here are the results:
>
> Aurora 1.0 graphical: X starts
> Aurora 2.0 graphical: X starts, partitioning fails
> Aurora 2.1 graphical: installer thinks CD is not correct
> Debian 3.1 R1 serial: install complete
> Gentoo 1.4 RC5 graphical: shell prompt, keyboard fast repeat
> Gentoo 2004.1 graphical: shell prompt, keyboard fast repeat, hangs
> NetBSD 1.6.1 graphical: loader can't find kernel
> NetBSD 2.1 graphical: loader can't find kernel
> NetBSD 3.0 graphical: loader can't find kernel
> Red Hat 4.2 Zoot graphical: Cannot open /dev/kbd, keyboard doesn't work
> SuSE 7.1 graphical: X starts, mouse doesn't work
>
> _________________________________________________________________
> Express yourself instantly with MSN Messenger! Download today it's FREE! 
> http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
>

Re: [Qemu-devel] qemu-system-sparc question?

[Marco Matthies]

Ishwar Rattan wrote:
> 
> Well here is the situation. Dept had a lab with SPARC
> based Solaris machines that were phased out in summer
> (over my objections). I needed the environment to teach
> first computer archt course with some assembly language
> thrown in. Intel processor assembly requires a much
> bigger effort (on part of students) which defeats the puprpose
> of the course. So, I thought that I could put together
> the SPARC back, if I am able to boot a SPARC version of
> Linux (with gcc, gas, text-editor and networking) under
> qemu. Hence the barrage of questions. GUI is a non-issue.

Couldn't you just build a crosscompiler and cross-binutils and
then use qemu-sparc instead of qemu-system-sparc, i.e. using
user emulation instead of whole system emulation ?

Marco

Re: [Qemu-devel] qemu-system-sparc question?

[Aurelien Jarno]

On Tue, Oct 10, 2006 at 12:40:53PM -0400, Ishwar Rattan wrote:
> 
> Is it possible to boot the iso image
>   debian-31r3-sparc-netinst.iso
> 
> in qemu-system-sparc? What about other
> Linux distributions?

I haven't tried this one, but the debian-installer from Etch. It is
possible to install a full Debian using it. So my guess is that the
sarge version should also work.

Everything works correctly (I haven't tried X), but after a few hours 
(with few being between around 6 and 20 hours), the esp driver from the
kernel crashes, with the following log:

esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg<a4000211> addr<f004d000>
esp0: SW [sreg<00> sstep<04> ireg<18>]
esp0: HW reread [sreg<83> sstep<00> ireg<10>]
esp0: current command [tgt<00> lun<00> pphase<DATAOUT> cphase<DATAOUT>]
esp0: disconnected
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg<a4000210> addr<f004d000>
esp0: SW [sreg<00> sstep<04> ireg<18>]
esp0: HW reread [sreg<03> sstep<00> ireg<10>]
esp0: current command [tgt<00> lun<00> pphase<UNISSUED> cphase<UNISSUED>]
esp0: disconnected
esp0: Resetting scsi bus
esp0: SCSI bus reset interrupt
Unable to handle kernel NULL pointer dereference
tsk->{mm,active_mm}->context = 00000054
tsk->{mm,active_mm}->pgd = fc036000
              \|/ ____ \|/
              "@'/ ,. \`@"
              /_| \__/ |_\
                 \__U_/
ntpd(2981): Oops [#1]
PSR: 04401fc1 PC: fe61eb14 NPC: fe61eb18 Y: 00000000    Not tainted
PC: <esp_do_data_finale+0x374/0x3c0 [esp]>
%G: f00d3998 ffffffff  00000014 fd01a000  00000000 00000001  f1bf6000 00000001
%O: fe620c00 f021baec  fd011000 00001556  00000000 f0220c88  f1bf7a78 fe61e7f4
RPC: <esp_do_data_finale+0x54/0x3c0 [esp]>
%L: f3027b60 00000000  00000000 f79cd640  00000000 00000000  f1bf6000 00000001
%I: f3049a70 f7a32380  f316b040 fe620a00  f1bf6000 f0218cc4  f1bf7ae0 fe61f4a4
Caller[fe61f4a4]: esp_work_bus+0x5c/0x6c [esp]
Caller[fe61fd04]: esp_intr+0x1dc/0x300 [esp]
Caller[f0013090]: handler_irq+0x78/0xa4
Caller[f0010b20]: patch_handler_irq+0x0/0x24
Caller[f0191474]: here+0x10/0xa0
Caller[f01919c0]: schedule_timeout+0x18/0xbc
Caller[f007c548]: do_select+0x3d0/0x43c
Caller[f007c788]: core_sys_select+0x1d4/0x288
Caller[f007cc54]: sys_select+0xc8/0x1e8
Caller[f001157c]: syscall_is_too_hard+0x34/0x40
Caller[00019c7c]: 0x19c7c
Instruction DUMP: c2242118  8400a014  c4242114 <c200a010> c2242110  c200a00c  c224210c  c20e203a  82086007
Kernel panic - not syncing: Aiee, killing interrupt handler!
 <0>Press Stop-A (L1-A) to return to the boot prom


-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] qemu-system-sparc question?

[Paul Brook]

On Tuesday 10 October 2006 21:44, Ishwar Rattan wrote:
> Well here is the situation. Dept had a lab with SPARC
> based Solaris machines that were phased out in summer
> (over my objections). I needed the environment to teach
> first computer archt course with some assembly language
> thrown in. Intel processor assembly requires a much
> bigger effort (on part of students) which defeats the puprpose
> of the course. So, I thought that I could put together
> the SPARC back, if I am able to boot a SPARC version of
> Linux (with gcc, gas, text-editor and networking) under
> qemu. Hence the barrage of questions. GUI is a non-issue.

Sounds like you just want a bare-metal cross. There's absolutely no reason to 
run the editor, compiler or assembler on the target machine.
Many targets even have gdb simulators (MIPS, ARM and PPC do).

IMHO there's nothing particularly good about sparc for teaching assembly 
(Whoever thought register windows were a good idea!).

Paul

Re: [Qemu-devel] qemu-system-sparc question?

[Ishwar Rattan]

On Wed, 11 Oct 2006, Paul Brook wrote:

> IMHO there's nothing particularly good about sparc for teaching assembly
> (Whoever thought register windows were a good idea!).
The goal is not about assembly but programmer view of
a processor architecture using a mix of C and a little assembly.

-ishwar

Re: [Qemu-devel] qemu-system-sparc question?

[Blue Swirl]

>Sounds like you just want a bare-metal cross. There's absolutely no reason 
>to
>run the editor, compiler or assembler on the target machine.
>Many targets even have gdb simulators (MIPS, ARM and PPC do).

I disagree, it's much easier to use a native compiler than to build a cross 
compiler, even with crosstool. Especially crosstool's Sparc and Spac64 rows 
are disappointing. I don't think other compilers than GCC even support cross 
setups.

>IMHO there's nothing particularly good about sparc for teaching assembly
>(Whoever thought register windows were a good idea!).

Well, the register use is consistent, there are very few instructions and no 
instruction modifiers. I don't like ideas like ASIs, lack of FPU/IU 
connecivity and the delay slot.

BTW, we could easily design and implement an ideal CPU just for Qemu 
purposes. It could be unlike any existing hardware, for example with zero or 
thousands of registers. The problem would be making a compiler for the CPU, 
also porting some OS to it. Any GCC and Linux guru volunteers? CS research 
projects?

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Qemu-devel] qemu-system-sparc question?

[K. Richard Pixley]

Blue Swirl wrote:
> BTW, we could easily design and implement an ideal CPU just for Qemu 
> purposes. It could be unlike any existing hardware, for example with 
> zero or thousands of registers. The problem would be making a compiler 
> for the CPU, also porting some OS to it. Any GCC and Linux guru 
> volunteers? CS research projects? 
This idea has been around for a long time.  When I was in school, one of 
our projects was to build a processor for such an architecture.  The 
idea has been kicked around the gnu development toolchain community for 
some time as well.

Gcc is sexy.  You shouldn't have any trouble finding a student or 
another volunteer who's interested in implementing a simple, relatively 
orthogonal instruction set.

Gas is harder.  It's not so sexy.  Nor is ld, nor gdb.

Porting linux at that point is pretty much just a matter of determining 
cpu start and load addresses.

Note: mmu management would also be a modest task, either to implement or 
to circumvent.

--rich

Re: [Qemu-devel] qemu-system-sparc question?

[Marco Matthies]

Blue Swirl wrote:
> BTW, we could easily design and implement an ideal CPU just for Qemu 
> purposes. It could be unlike any existing hardware, for example with 
> zero or thousands of registers. The problem would be making a compiler 
> for the CPU, also porting some OS to it. Any GCC and Linux guru 
> volunteers? CS research projects?

How about MMIX?
http://en.wikipedia.org/wiki/MMIX

There is already a simulator/assembler here:
http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html

Marco

Re: [Qemu-devel] qemu-system-sparc question?

[Brian Wheeler]

On Wed, 2006-10-11 at 19:32 +0200, Marco Matthies wrote:
> Blue Swirl wrote:
> > BTW, we could easily design and implement an ideal CPU just for Qemu 
> > purposes. It could be unlike any existing hardware, for example with 
> > zero or thousands of registers. The problem would be making a compiler 
> > for the CPU, also porting some OS to it. Any GCC and Linux guru 
> > volunteers? CS research projects?
> 
> How about MMIX?
> http://en.wikipedia.org/wiki/MMIX
> 
> There is already a simulator/assembler here:
> http://www-cs-faculty.stanford.edu/~knuth/mmix-news.html
> 
> Marco
> 

It might not be a bad idea, especially since MMIX is well documented and
fairly simple.  

However, since it doesn't have real devices (Just traps to do OS-like
things), it'd probably be good to have a simple CPU with some simple
devices so newcomers can copy it as a starting point for other projects.


Brian



> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] qemu-system-sparc question?

[Johannes Schindelin]

Hi,

On Wed, 11 Oct 2006, Blue Swirl wrote:

> BTW, we could easily design and implement an ideal CPU just for Qemu 
> purposes.

This soooo reminds me of Java.

Ciao,
Dscho

Re: [Qemu-devel] qemu-system-sparc question?

[Blue Swirl]

> > BTW, we could easily design and implement an ideal CPU just for Qemu
> > purposes.
>
>This soooo reminds me of Java.

Except that Java VM is not suitable target for all classes of programming 
languages, like C.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: [Qemu-devel] qemu-system-sparc question?

[K. Richard Pixley]

Johannes Schindelin wrote:
> This soooo reminds me of Java.
Or lisp.

:-).

--rich

Re: [Qemu-devel] qemu-system-sparc question?

[Ben Taylor]

---- Blue Swirl <blueswir1@hotmail.com> wrote: 
> > > BTW, we could easily design and implement an ideal CPU just for Qemu
> > > purposes.
> >
> >This soooo reminds me of Java.
> 
> Except that Java VM is not suitable target for all classes of programming 
> languages, like C.

I wondered if you could use the host's native java as an extension inside
the qemu host to improve java runtime performance in the qemu guest.

But that sounds way to convoluted to work. :-)

Re: [Qemu-devel] qemu-system-sparc question?

[Johannes Schindelin]

Hi,

On Wed, 11 Oct 2006, Ben Taylor wrote:

> 
> ---- Blue Swirl <blueswir1@hotmail.com> wrote: 
> > > > BTW, we could easily design and implement an ideal CPU just for Qemu
> > > > purposes.
> > >
> > >This soooo reminds me of Java.
> > 
> > Except that Java VM is not suitable target for all classes of programming 
> > languages, like C.
> 
> I wondered if you could use the host's native java as an extension inside
> the qemu host to improve java runtime performance in the qemu guest.
> 
> But that sounds way to convoluted to work. :-)

I doubt it. For one, if you use a GUI, the host's VM just cannot access 
the client's graphics, and in many cases would be unprepared to do so, 
too: a Linux VM wants to talk to X11, while a Windows VM wants to talk to 
the Windows equivalent.

However, you could just redirect the DISPLAY if your host _and_ guest have 
X11-targeted Javas. But then, why would you need to start QEmu at all?

Ciao,
Dscho

Re: [Qemu-devel] qemu-system-sparc question?

[Paul Brook]

On Wednesday 11 October 2006 18:20, Blue Swirl wrote:
> >Sounds like you just want a bare-metal cross. There's absolutely no reason
> >to
> >run the editor, compiler or assembler on the target machine.
> >Many targets even have gdb simulators (MIPS, ARM and PPC do).
>
> I disagree, it's much easier to use a native compiler than to build a cross
> compiler, even with crosstool. 

Well, with native toolchains you get prebuilt binaries from your system 
vendor, so building them is a non-issue.

I don't believe that they're much easier to use in this context. If you're 
building prepackaged worktation software you might hit problems with crappy 
configure scripts. For a teaching environment I wouldn't expect it to be a 
problem, especially given the alternative is probably running on embedded dev 
boards.

> I don't think other compilers than GCC even support 
> cross setups.

That's definitely not true. Certainly anything targeting embedded systems are 
cross compilers (the target too small/slow to consider compiling natively), 
and I'd guess the same is true for many HPC systems (You don't want the 
clutter on your compute machines, esp. if they're used via batch jobs).
In my experience pretty much all development is done with cross compilers from 
workstations or commodity compile farms. This means windows/x86-linux, or 
maybe a few crufty old solaris boxes left over from when sparc was fast :-)

> BTW, we could easily design and implement an ideal CPU just for Qemu
> purposes. It could be unlike any existing hardware, for example with zero
> or thousands of registers. The problem would be making a compiler for the
> CPU, also porting some OS to it. Any GCC and Linux guru volunteers? CS
> research projects?

There's no such think as an Ideal cpu. It's like picking the right 
religion :-) If you want a toy cpu, there are things like mmix.
While arm, ppc, mips, sparc, etc each have their own peculiarities, they're 
all reasonably clean architectures. 

Paul

Re: [Qemu-devel] qemu-system-sparc question?

[Blue Swirl]

>There's no such think as an Ideal cpu. It's like picking the right
>religion :-) If you want a toy cpu, there are things like mmix.

In general true. But the real and toy CPUs are designed with the hardware 
construction in mind, whereas the limitations deriving from HW (number of 
registers, number of instructions, instruction complexity) may be less 
relevant in the Qemu case. Also Qemu could benefit from getting information 
analysed from the source code that no real HW needs. For example, perhaps 
the TB state could be managed explicitly by the compiler.

Though I doubt the near native speed performance with kqemu can ever be 
exceeded with a translator even with all compiler assistance tricks. For 
other goals (like enhancing security), different methods could be tried, for 
example it's hard for virus writers to target a dynamic or even encrypted 
instruction set. Or make stack exploits difficult by giving the CPU separate 
stack pointers for function arguments, return addresses and local variables.

_________________________________________________________________
Don't just search. Find. Check out the new MSN Search! 
http://search.msn.com/

Re: [Qemu-devel] qemu-system-sparc question?

[Paul Brook]

On Saturday 14 October 2006 09:14, Blue Swirl wrote:
> >There's no such think as an Ideal cpu. It's like picking the right
> >religion :-) If you want a toy cpu, there are things like mmix.
>
> In general true. But the real and toy CPUs are designed with the hardware
> construction in mind, whereas the limitations deriving from HW (number of
> registers, number of instructions, instruction complexity) may be less
> relevant in the Qemu case. Also Qemu could benefit from getting information
> analysed from the source code that no real HW needs. For example, perhaps
> the TB state could be managed explicitly by the compiler.

There are plenty of pre-existing dynamic compilation targets, pretty much all 
of which have JIT compilers. eg. JVM, CIL and parrot. IMHO qemu probably 
isn't a particularly good base for this sort of thing, as it's more oriented 
towards emulating conventional CPUs.

Paul