qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qemu-system-sh4 broken again.


From: Rob Landley
Subject: Re: [Qemu-devel] qemu-system-sh4 broken again.
Date: Sat, 13 Mar 2010 15:11:03 -0600
User-agent: KMail/1.11.2 (Linux/2.6.28-18-generic; KDE/4.2.2; x86_64; ; )

On Saturday 13 March 2010 04:26:47 Aurelien Jarno wrote:
> On Sat, Mar 13, 2010 at 01:51:35AM -0600, Rob Landley wrote:
> > Using qemu-system-sh4, this commit:
> >
> > e1c09175bc00dd8dfb2ad1b26e1858dcdc109b59 is first bad commit
> > commit e1c09175bc00dd8dfb2ad1b26e1858dcdc109b59
> > Author: Gerd Hoffmann <address@hidden>
> > Date:   Tue Dec 8 13:11:44 2009 +0100
> >
> >     zap serial_monitor_mux
> >
> >     The logic in this code obviously predates the multiple monitor
> >     capability of qemu and looks increasingly silly these days.
> >
> >     I think the intention of this piece of code is to get a reasonable
> >     default for the -nographic case: have monitor and serial line muxed
> >     on stdio.
> >
> >     With the new default_serial and default_monitor variables we have now
> >     doing just that became much easier ;)
> >
> >     Signed-off-by: Gerd Hoffmann <address@hidden>
> >     Signed-off-by: Anthony Liguori <address@hidden>
> >
> > Made "-serial stdio" now do:
> >
> >   chardev: opening backend "stdio" failed
> >   qemu: could not open serial device 'stdio': Inappropriate ioctl for
> > device
> >
> > Am I using it wrong?
> >
> > If I don't override it, I instead get:
> >
> >   long read to SH7750_WCR1_A7 (0x000000001f800008) ignored
> >   long read to SH7750_WCR2_A7 (0x000000001f80000c) ignored
> >   long read to SH7750_WCR3_A7 (0x000000001f800010) ignored
> >   long read to SH7750_MCR_A7 (0x000000001f800014) ignored
> >   long read to SH7750_MCR_A7 (0x000000001f800014) ignored
> >   sh_serial: unsupported read from 0x10
> >   qemu-system-sh4: /home/landley/qemu/git/hw/sh_serial.c:285:
> >     sh_serial_ioport_read: Assertion `0' failed.
> >
> > Is anybody out there actually using the sh4 emulator?  I've gotten it to
> > work several times before on various random git snapshots, but never in a
> > release version...
>
> Would be nice to give that you give the actual command line to try to
> use. I am using the stable-0.12 branch (plus some backporting patches
> for the MMU) to do development on sh4. HEAD still works correctly here.
> I am using the following command line:

Mine's:

And the kernel and root filesystem images to use with it are at:
  http://impactlinux.com/fwl/downloads/binaries/system-image-sh4.tar.bz2

Note the binaries in that tarball used to work, they haven't been rebuilt 
since the last time I had a qemu that could run them.  The problem it was a 
random -git snapshot (no release version has ever worked for me on sh4, that 
I'm aware of) and I don't remember which version.  However, my blog says that 
on November 5, 2009 I had it working with unpatched git, so presumably I could 
grab a qemu from there and bisect...

> ~/git/qemu/sh4-softmmu/qemu-system-sh4 -M r2d -kernel zImage -drive
> file=sh4.img -serial null -serial stdio -usb -append "root=/dev/sda1
> console=tty0 console=ttySC0,115200 noiotrap" -usbdevice keyboard -usbdevice
> mouse

I found my blog entries about getting sh4 to work back in February 2009:

 http://landley.net/notes-2009.html#13-02-2009

Which told me when to look in the archives to find the threads where I learned 
how to make it work in the first place.  This one is where I got the -serial 
null -serial stdio advice:

  http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00825.html

And here's where I got an actual command prompt:

  http://lists.gnu.org/archive/html/qemu-devel/2009-02/msg00961.html

Meaning I've figured out who I should have cc'd in the first place. :)

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds




reply via email to

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