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 32-bit ubuntu.
On Thu, Aug 26, 2010 at 8:26 PM, Idwer Vollering email@example.com wrote:
2010/8/5 Idwer Vollering firstname.lastname@example.org
2010/8/3 Myles Watson email@example.com
On Tue, Aug 3, 2010 at 10:59 AM, Idwer Vollering firstname.lastname@example.org wrote:
My problem is two-fold:
- 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 patch.
- 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 button:
SerialICE v1.5 (Aug 27 2010)
1 2 3 4 5 6 7 8 9 0 r e s e t
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 48 MHz: 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 southbridge ?
Attached the mainboard code as well.
Attaching .config, dmesg, lspci and the patch against svn.
SerialICE mailing list SerialICE@serialice.com http://serialice.com/mailman/listinfo/serialice