From: Rob Landley <rob@landley.net>
To: aboriginal@lists.landley.net, qemu-devel <qemu-devel@nongnu.org>
Subject: [Qemu-devel] [PATCH] Fixing sh4 serial abort
Date: Fri, 27 Jul 2012 08:45:46 -0500 [thread overview]
Message-ID: <50129B8A.3060102@landley.net> (raw)
If you grab the current aboriginal linux build scripts:
http://landley.net/hg/aboriginal/archive/tip.tar.bz2
And "./build.sh sh4", then cd to build/system-image-sh4 and
"./run-emulator.sh" you get this:
sh_serial: unsupported read from 0x18
Aborted
The bug was triggered by linux kernel commit 73c3d53f38e0a8e6 back
between v3.2 and v3.3, which did this:
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1771,18 +1771,25 @@ static void sci_set_termios(struct uart_port
*port, struct ktermios *termios,
sci_init_pins(port, termios->c_cflag);
- if (s->cfg->capabilities & SCIx_HAVE_RTSCTS) {
- reg = sci_getreg(port, SCFCR);
- if (reg->size) {
- unsigned short ctrl;
+ reg = sci_getreg(port, SCFCR);
+ if (reg->size) {
+ unsigned short ctrl = sci_in(port, SCFCR);
- ctrl = sci_in(port, SCFCR);
+ if (s->cfg->capabilities & SCIx_HAVE_RTSCTS) {
I.E. sci_getreg(port, SCFCR) move to before checking whether or not
we'll ever possibly use the result. SCFCR is 0x18 and QEMU calls abort()
on an attempt to read from an unimplemented register.
I can patch the kernel to work around this (and probably will for this
release), but the _proper_ fix is to get qemu not to abort on a register
read that works fine if it just returns 0.
It turns out the qemu fix (in current git) is just:
--- a/hw/sh_serial.c
+++ b/hw/sh_serial.c
@@ -248,11 +248,9 @@ static uint64_t sh_serial_read(void *opaque,
target_phys
s->flags &= ~SH_SERIAL_FLAG_RDF;
}
break;
-#if 0
case 0x18:
ret = s->fcr;
break;
-#endif
case 0x1c:
ret = s->rx_cnt;
break;
(It can also just do ret = 0; and that works too. Or comment out the
abort() near the end of the function.)
Doing that, qemu boots the sh4 system image to a shell prompt, and the
result compiles "hello world" natively.
By the way, this board emulation (r2d) only has 64 megs ram. Is there an
easy way to get 256 megs out of it?
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
next reply other threads:[~2012-07-27 14:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-27 13:45 Rob Landley [this message]
2012-07-27 14:32 ` [Qemu-devel] [PATCH] Fixing sh4 serial abort Peter Maydell
2012-07-27 17:16 ` Rob Landley
2012-07-27 17:28 ` Peter Maydell
2012-08-01 11:50 ` Rob Landley
2012-08-01 12:01 ` Peter Maydell
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=50129B8A.3060102@landley.net \
--to=rob@landley.net \
--cc=aboriginal@lists.landley.net \
--cc=qemu-devel@nongnu.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.