Oh! I'm not the only one seeing qemu segfault! I don't have the patch
available, but I've written a patch for my Zotac NM10 board with a
Nuvoton NCT5571D super IO. I'm trying to boot the vendor BIOS. I'm
sure that I'm using the correct clock in (48MHz) and settings, because
I can get a serial boot console in linux with the stock BIOS, and if I
look at serialice through minicom, I can see the console. If I start
qemu then start the system, I will get the same message you did
(target alife!) then something for a message about a communication
failure (0/a). It will then hang there. If I reboot it (turn it off
and back on) qemu segfaults.
I think this error is related to my null modem cable, nullmodem.com
illustrates two different types, mine is currently the type without
the CD signal connected to anything. I tried modifying it to short
pins 1 and 6 on both ends, but it doesn't seem to have worked. I'll
have another one here in a few days that hopefully does have the CD
tapped into the DTR signal.
I also had some problems trying to compile QEMU on 64-bit, oddly I
*did* get beyond those initial 2 lines (with the same cable), but it
would fail when trying to run the lua script. I couldn't get bitlib-25
to compile against Ubuntu 10.04 with lua from source, so I used
bitlib-26 at first, but it would give me an error in bit.so, trying to
call an undefined symbol, lua_pushnumber (IIRC). I then removed the
lua from source and installed Ubuntu's lua5.1 and liblua5.1 packages,
got bitlib-25 to compile (with --with-lua-suffix=5.1), compiled qemu
(after making symlinks in /usr/lib from liblua5.1.x to liblua.x), and
it would segfault about 6 lines down (during/after trying to reserve a
couple memory ranges). After that I got frustrated and installed
On Thu, Aug 26, 2010 at 8:26 PM, Idwer Vollering <vidwer(a)gmail.com> wrote:
2010/8/5 Idwer Vollering <vidwer(a)gmail.com>
2010/8/3 Myles Watson <mylesgw(a)gmail.com>
> On Tue, Aug 3, 2010 at 10:59 AM, Idwer Vollering <vidwer(a)gmail.com>
> > My problem is two-fold:
> > 1) Running the patched qemu segfaults.
> > $ sudo ./i386-softmmu/qemu -serialice /dev/ttyUSB0 -hda /dev/zero -L
> > bios/
> > [sudo] password for idwer:
> > SerialICE: Open connection to target hardware...
> > SerialICE: Waiting for handshake with target... target alife!
> try the latest qemu in the SerialICE tree
> It's already patched, and it has been updated more recently than the
> > 2) Right now, the serialice shell appears only once: after flashing
> > serialice.rom and performing a soft reset from vendor bios to
> > serialice.
> > SerialICE v1.5 (Aug 3 2010)
Following quote is after soft reset, typing some text and hitting the reset
SerialICE v1.5 (Aug 27 2010)
> Sounds like SerialICE is depending on some initialization from the
> vendor BIOS. I guess an ugly way to test it would be to copy the
> working configuration bits from lspci and hard code them into
> SerialICE until you find what's wrong.
Since the southbridge and superio datasheets mention the existence of two
serial ports, I followed their guidance.
I thought that (the console printing part of) SerialICE, when setup the
correct way, should survive a hard reset/power cycle regardless of the qemu
part is running or not.
Since I don't have an oscilloscope, I've tried setting CLKSEL to 24 MHz and
pnp_write_register(SUPERIO_CONFIG_PORT, 0x24, 0xb4); // 24 MHz and KBC=1
pnp_write_register(SUPERIO_CONFIG_PORT, 0x24, 0xc4); // 48 MHz and KBC=1
What information is leading, the info from the superio or the info from the
Attached the mainboard code as well.
Attaching .config, dmesg, lspci and the patch against svn.
SerialICE mailing list