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

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

[Rob Landley]

Using qemu-system-sh4, this commit:

e1c09175bc00dd8dfb2ad1b26e1858dcdc109b59 is first bad commit
commit e1c09175bc00dd8dfb2ad1b26e1858dcdc109b59
Author: Gerd Hoffmann <kraxel@redhat.com>
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 <kraxel@redhat.com>
    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>

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...

I'd point to the original message that told me to use -serial stdio for qemu-
system-sh4, but unfortunately your mailing list archive is on lists.gnu.org 
and their robots.txt tells Google not to index them, so your mailing list 
archives aren't googleable.  In fact, there's exactly one hit on the whole of 
lists.gnu.org for "qemu":

  http://www.google.com/#q=site%3Alists.gnu.org+qemu

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

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

[Roy Tam]

2010/3/13 Rob Landley <rob@landley.net>:
> Using qemu-system-sh4, this commit:
>
> e1c09175bc00dd8dfb2ad1b26e1858dcdc109b59 is first bad commit
> commit e1c09175bc00dd8dfb2ad1b26e1858dcdc109b59
> Author: Gerd Hoffmann <kraxel@redhat.com>
> 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 <kraxel@redhat.com>
>    Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>
> 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...
>
> I'd point to the original message that told me to use -serial stdio for qemu-
> system-sh4, but unfortunately your mailing list archive is on lists.gnu.org
> and their robots.txt tells Google not to index them, so your mailing list
> archives aren't googleable.  In fact, there's exactly one hit on the whole of
> lists.gnu.org for "qemu":
>
>  http://www.google.com/#q=site%3Alists.gnu.org+qemu
>

instead of searching in list.gnu.org you can search in gmane:
http://dir.gmane.org/gmane.comp.emulators.qemu

or googling with other mail archives, for example:
site:mail-archive.com
site:marc.info

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

[Aurelien Jarno]

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 <kraxel@redhat.com>
> 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 <kraxel@redhat.com>
>     Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> 
> 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:

~/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


-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

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

[Rob Landley]

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 <kraxel@redhat.com>
> > 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 <kraxel@redhat.com>
> >     Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> >
> > 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

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

[Rob Landley]

On Saturday 13 March 2010 15:11:03 Rob Landley wrote:
> 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 <kraxel@redhat.com>
> > > 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 <kraxel@redhat.com>
> > >     Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> > >
> > > 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

I found out that "-serial stdio" is apparently trying to open /dev/stdio, 
which Ubuntu 9.04 hasn't got.  If I say -serial /dev/tty it works from the 
command line (but not in scripts).

Before the zap_serial_monitor_mux commit above, -serial stdio was being 
recognized as a builtin or some such, and didn't depend on /dev/stdio.

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

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

[Aurelien Jarno]

On Sat, Mar 13, 2010 at 05:11:43PM -0600, Rob Landley wrote:
> On Saturday 13 March 2010 15:11:03 Rob Landley wrote:
> > 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 <kraxel@redhat.com>
> > > > 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 <kraxel@redhat.com>
> > > >     Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> > > >
> > > > 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
> 
> I found out that "-serial stdio" is apparently trying to open /dev/stdio, 
> which Ubuntu 9.04 hasn't got.  If I say -serial /dev/tty it works from the 
> command line (but not in scripts).
> 

This is actually not specific at all to sh4. See this thread:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg20920.html

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

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

[Rob Landley]

On Sunday 14 March 2010 16:28:32 Aurelien Jarno wrote:
> On Sat, Mar 13, 2010 at 05:11:43PM -0600, Rob Landley wrote:
> > I found out that "-serial stdio" is apparently trying to open /dev/stdio,
> > which Ubuntu 9.04 hasn't got.  If I say -serial /dev/tty it works from
> > the command line (but not in scripts).
>
> This is actually not specific at all to sh4. See this thread:
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg20920.html

http://www.mail-archive.com/qemu-devel@nongnu.org/msg22763.html

> This is redundant.  -nographic implies -serial stdio.

Trying with just -nographic and no -serial lines, I get:

$ qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage-sh4 -hda image-
sh4.sqf -append "root=/dev/sda rw init=/usr/sbin/init.sh panic=1 PATH=/usr/bin 
console=ttySC0 noiotrap HOST=sh4"
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

And it hangs.  No output from any of the kernel serial writes.

http://www.mail-archive.com/qemu-devel@nongnu.org/msg22775.html

> >    eg this should work as you'd expect it
> >
> >      qemu -nodefaults -nographic -serial stdio
>
> -nographic is basically equivalent to -serial mon:stdio,signal=on -vga none
> except it operates on defaults. Your invocation actually ends up being very
> different as it doesn't multiplex the monitor and it doesn't disable ctrl-c.
> Basically, your invocation is equivalent to qemu -vga none -serial stdio

http://www.mail-archive.com/qemu-devel@nongnu.org/msg22775.html

$ qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage-sh4 -hda image-
sh4.sqf -append "root=/dev/sda rw init=/usr/sbin/init.sh panic=1 PATH=/usr/bin 
console=ttySC0 noiotrap HOST=sh4"  -vga none -serial stdio
chardev: opening backend "stdio" failed
qemu: could not open serial device 'stdio': Inappropriate ioctl for device

http://www.mail-archive.com/qemu-devel@nongnu.org/msg22777.html

$ qemu-system-sh4 -M r2d -nodefaults -nographic -serial stdio -no-reboot -
kernel zImage-sh4 -hda image-sh4.sqf -append "root=/dev/sda rw 
init=/usr/sbin/init.sh panic=1 PATH=/usr/bin console=ttySC0 noiotrap HOST=sh4"
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

And the hang's back, no output...

Ok, this seems to work:

qemu-system-sh4 -M r2d -nodefaults -nographic -serial null -serial stdio -no-
reboot -kernel zImage-sh4 -hda image-sh4.sqf -append "root=/dev/sda rw 
init=/usr/sbin/init.sh panic=1 PATH=/usr/bin console=ttySC0 noiotrap HOST=sh4"

I no longer even pretend to know why...

Do I have to say "-nodefaults" on every other target as well to disable the 
unwanted monitor I never knew was there?

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

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

[Shin-ichiro KAWASAKI]

Hello, Rob,

This mail might be too late, but I want to report you that I
encountered similar trouble.

Using the linux kernel after the following commit, the qemu-sh
serial console shows no output.

   cd5f107628ab89c5dec5ad923f1c27f4cba41972

This trouble was discussed in sh-linux ML.

   http://marc.info/?l=linux-sh&m=127183863325672&w=2

To avoid this,

   - add "earlyprintk=sh-sci.1" to kernel command line, and
   - modify CONFIG_SERIAL_SH_SCI_NR_UARTS valud from 1 to 2,

in kernel configuration menu.

I hope that this is the trouble you see.

Regards,
Shin-ichiro KAWASAKI


(2010/03/15 9:08), Rob Landley wrote:
> On Sunday 14 March 2010 16:28:32 Aurelien Jarno wrote:
>> On Sat, Mar 13, 2010 at 05:11:43PM -0600, Rob Landley wrote:
>>> I found out that "-serial stdio" is apparently trying to open /dev/stdio,
>>> which Ubuntu 9.04 hasn't got.  If I say -serial /dev/tty it works from
>>> the command line (but not in scripts).
>>
>> This is actually not specific at all to sh4. See this thread:
>> http://www.mail-archive.com/qemu-devel@nongnu.org/msg20920.html
>
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg22763.html
>
>> This is redundant.  -nographic implies -serial stdio.
>
> Trying with just -nographic and no -serial lines, I get:
>
> $ qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage-sh4 -hda image-
> sh4.sqf -append "root=/dev/sda rw init=/usr/sbin/init.sh panic=1 PATH=/usr/bin
> console=ttySC0 noiotrap HOST=sh4"
> 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
>
> And it hangs.  No output from any of the kernel serial writes.
>
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg22775.html
>
>>>     eg this should work as you'd expect it
>>>
>>>       qemu -nodefaults -nographic -serial stdio
>>
>> -nographic is basically equivalent to -serial mon:stdio,signal=on -vga none
>> except it operates on defaults. Your invocation actually ends up being very
>> different as it doesn't multiplex the monitor and it doesn't disable ctrl-c.
>> Basically, your invocation is equivalent to qemu -vga none -serial stdio
>
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg22775.html
>
> $ qemu-system-sh4 -M r2d -nographic -no-reboot -kernel zImage-sh4 -hda image-
> sh4.sqf -append "root=/dev/sda rw init=/usr/sbin/init.sh panic=1 PATH=/usr/bin
> console=ttySC0 noiotrap HOST=sh4"  -vga none -serial stdio
> chardev: opening backend "stdio" failed
> qemu: could not open serial device 'stdio': Inappropriate ioctl for device
>
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg22777.html
>
> $ qemu-system-sh4 -M r2d -nodefaults -nographic -serial stdio -no-reboot -
> kernel zImage-sh4 -hda image-sh4.sqf -append "root=/dev/sda rw
> init=/usr/sbin/init.sh panic=1 PATH=/usr/bin console=ttySC0 noiotrap HOST=sh4"
> 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
>
> And the hang's back, no output...
>
> Ok, this seems to work:
>
> qemu-system-sh4 -M r2d -nodefaults -nographic -serial null -serial stdio -no-
> reboot -kernel zImage-sh4 -hda image-sh4.sqf -append "root=/dev/sda rw
> init=/usr/sbin/init.sh panic=1 PATH=/usr/bin console=ttySC0 noiotrap HOST=sh4"
>
> I no longer even pretend to know why...
>
> Do I have to say "-nodefaults" on every other target as well to disable the
> unwanted monitor I never knew was there?
>
> Rob

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

[Aurelien Jarno]

Shin-ichiro KAWASAKI a écrit :
> Hello, Rob,
> 
> This mail might be too late, but I want to report you that I
> encountered similar trouble.
> 
> Using the linux kernel after the following commit, the qemu-sh
> serial console shows no output.
> 
>    cd5f107628ab89c5dec5ad923f1c27f4cba41972
> 
> This trouble was discussed in sh-linux ML.
> 
>    http://marc.info/?l=linux-sh&m=127183863325672&w=2
> 
> To avoid this,
> 
>    - add "earlyprintk=sh-sci.1" to kernel command line, and
>    - modify CONFIG_SERIAL_SH_SCI_NR_UARTS valud from 1 to 2,
> 
> in kernel configuration menu.
> 
> I hope that this is the trouble you see.
> 

The main problem here is that QEMU emulates both SCI channels as serial
port, while the real board has one of the two channel configured as a
SPI bus (for the RTC clock), and the other as a serial port.

-- 
Aurelien Jarno                          GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

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

[Shin-ichiro KAWASAKI]

Hello, Aurelian,

Thank you for clarification.  I've understood the situation.
My comment is not the solution for Rob's problem.

Best Regards,
Shin-ichiro KAWASAKI


(2010/05/11 0:48), Aurelien Jarno wrote:
> Shin-ichiro KAWASAKI a écrit :
>> Hello, Rob,
>>
>> This mail might be too late, but I want to report you that I
>> encountered similar trouble.
>>
>> Using the linux kernel after the following commit, the qemu-sh
>> serial console shows no output.
>>
>>     cd5f107628ab89c5dec5ad923f1c27f4cba41972
>>
>> This trouble was discussed in sh-linux ML.
>>
>>     http://marc.info/?l=linux-sh&m=127183863325672&w=2
>>
>> To avoid this,
>>
>>     - add "earlyprintk=sh-sci.1" to kernel command line, and
>>     - modify CONFIG_SERIAL_SH_SCI_NR_UARTS valud from 1 to 2,
>>
>> in kernel configuration menu.
>>
>> I hope that this is the trouble you see.
>>
>
> The main problem here is that QEMU emulates both SCI channels as serial
> port, while the real board has one of the two channel configured as a
> SPI bus (for the RTC clock), and the other as a serial port.
>

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

[Jamie Lokier]

Rob Landley wrote:
> I found out that "-serial stdio" is apparently trying to open /dev/stdio, 
> which Ubuntu 9.04 hasn't got.  If I say -serial /dev/tty it works from the 
> command line (but not in scripts).

I don't think any Linux systems have /dev/stdio.

/dev/stdin, /dev/stdout, /dev/stderr, yes - and Ubuntu does have those.

-- Jamie