Serial is broken

[GXTX]

QEMU 5.1 both 32bit and 64bit are able to use the ports correctly without crashing - I assume it's something to do with the custom backend? Not sure. Issue happens with both elevated and not.

In the gif I was using a retail kernel however it makes no difference using a real debug or hacked kernel.

Launched with: .\xemu.exe -device lpc47m157 -serial COM1
Version: 2702f45

ERROR:hw/core/qdev.c:403:qdev_assert_realized_properly: assertion failed: (dev->realized)

[GXTX]

Attempting to use a unix socket in WSL appears to have the same issue. I'm not sure this is specific to Windows any longer. Someone on a Linux desktop should check with a real port and sockets.

[haxar]

Able to confirm on Linux by launching with -device lpc47m157 -serial unix:/tmp/xserial,server & using scripts/windpl/windpl.pl /tmp/xserial from XQEMU.

[GXTX]

With the proposed fix in #96 xemu no longer crashes on init, however it does lockup and freeze if you attach WinDbg to it using real ports.

[haxar]

What happens when you use: -device lpc47m157 -serial stdio

[GXTX]

That works (although not like you can read the kernel output), serial ports work as well until something connects to it. I would really consider this a separate issue (specific to Windows like the original issue).

[haxar]

I'm able to get kernel output from xbox-linux with -device lpc47m157 -serial stdio by appending the kernel parameter console=ttyS0,115200n8 to Cromwell's linuxboot.cfg.

[GXTX]

I'm positive that would work (on Windows), my specific issue was with Xbox kernel output.

[binarymaster]

With the proposed fix in #96 xemu no longer crashes on init, however it does lockup and freeze if you attach WinDbg to it using real ports.

I had exactly same problem while trying to debug ReactOS Xbox port with WinDbg using COM ports.

[haxar]

With QEMU, I'm able to write to the Linux console via -serial stdio, but not with lpc47m157 in xemu. Still investigating what it is.

Maybe WinDbg is trying to write something to the port & expecting a response, but simply connecting should unblock execution.

[GXTX]

In the initial issue I thought this was originally a legacy issue - however it seems to have evolved. @binarymaster can you try with XQEMU and see if this is infact a legacy problem? I'd be fine with #96 being merged as there is a real problem not being able to use ports in both OS's but not closing this.

[haxar]

PR #96 is now a draft, since I was able to write to the Linux console by removing all the serial init stuff out of (or simply by not using) lpc47m157 & using the below diff:

diff --git a/hw/xbox/xbox.c b/hw/xbox/xbox.c
index 8042026a0f..715f57f945 100644
--- a/hw/xbox/xbox.c
+++ b/hw/xbox/xbox.c
@@ -34,6 +34,7 @@
 #include "kvm_i386.h"
 #include "hw/kvm/clock.h"
 #include "hw/dma/i8257.h"
+#include "hw/char/serial.h"
 
 #include "hw/sysbus.h"
 #include "sysemu/arch_init.h"
@@ -300,6 +301,8 @@ void xbox_init_common(MachineState *machine,
 
     pcspk_init(pcms->pcspk, isa_bus, pit);
 
+    serial_hds_isa_init(isa_bus, 0, 1);
+
     PCIDevice *dev = pci_create_simple(pci_bus, PCI_DEVFN(9, 0), "piix3-ide");
     pci_ide_create_devs(dev);
     // idebus[0] = qdev_get_child_bus(&dev->qdev, "ide.0");

Unfortunately, this is not the right solution since IRQ 4 is used by NIC & IRQ 3 is used by GPU. It's not possible to reassign these interrupts as they're most likely hardcoded in hardware. The IRQ number for SERIRQ on the LPC header still has not been figured out before, and I'll have to see what it maps to on hardware via xbox-linux.

[binarymaster]

@binarymaster can you try with XQEMU and see if this is infact a legacy problem?

In fact, I tested it some time ago with XQEMU, so I can confirm it's a legacy problem, which deserves a separate issue probably.

[haxar]

I was able to break out SERIRQ pin 16 on the LPC header & assert it active low. Turns out it freezes the machine, at power on & during execution. At power on when held low, it powers on for a brief period & SMC power cycles, until it FRAGs. When asserted during execution, even in Cromwell, it freezes.

This pin is not usable as far as I know (unless it's handled by the SMC? seems to be southbridge related as the only connection). We'll have to use lpc47m157 to configure the IRQ number, but we can't use legacy IRQ 4 & 3, as that is for NIC & GPU, respectively.

Here's a list of hardcoded IRQs that are used:

 0 - timer
 1 - USB0
 2 - dma cascade
 3 - GPU
 4 - NIC
 5 - APU
 6 - ACI
 8 - rtc0
 9 - USB1
12 - extsmi
14 - IDE

I'll need to see how xbdm handles serial without a dedicated IRQ, unless it does use NIC IRQ. This previous convo seems relevant:

https://discord.com/channels/428359196719972353/428359408204906497/733421915880030280
JayFoxRox 07/16/2020
one of the worst XBDM issues is that it suddenly stops working if a game uses the network itself. and at that point you can no longer remote control your Xbox [meaning you have to manually gain control again]

[GXTX]

It doesn't seem to use that pin? Not sure. https://github.com/XboxDev/serial-usb-adapter/blob/master/images/schematic.png

[haxar]

I know for sure that SERIRQ cannot be used since it will freeze the machine. It seems to be southbridge related as the only connection. I'm not able to test this further with my built serial to USB adapter since my current modchip takes over MMIO for BIOS.

What I'm not sure on is how a debug Xbox kernel or xbdm handles input from serial without an IRQ. Maybe it does use IRQ 4 & conflicts with NIC, giving the behavior that JayFoxRox mentioned above. Just need to be sure for this PR.

Maybe serial can work for output only by not setting an IRQ (0 to disable as in the lpc47m157 datasheet). Cromwell may need to change the serial IRQ from 4 to 0 so that the conflict is not there, as introduced by XboxDev/cromwell#19.

[haxar]

PR #96 is now updated. It includes a build_aml callback that's specific to Windows & I'm not able to test that. That & most of the other cleanup was from hw/char/serial-isa.c & the lpc47m157 datasheet.

Writing to the Linux console still works, with IRQ 4, set by Cromwell. My debug Xbox kernel initializes with lpc47m157 COM1 enabled @ iobase=0x03f8 irq=0, which means that it's using no IRQ (0 for disabled) as output only (unless there's polling for input).

[GXTX]

Same situation where when it's connected to WinDbg xemu freezes/crashes.

[haxar]

I added a serial port IRQ menu option to the Peripherals menu in PR XboxDev/cromwell#49 so that the NIC IRQ 4 conflict can be toggled on or off. This PR also works with PR #96.

[GXTX]

Is this related with xbox-linux? Happens when launching Linux from Cromwell. I didn't enable serial in both command line or in cromwell so idk.

ERROR:D:/a/xemu/xemu/hw/xbox/xbox_pci.c:125:xbox_lpc_map_irq: assertion failed: (0)

[haxar]

Yes. That's Linux enumerating all the PCI devices. This should be fixed in #95: xbox_pci: Map PCI device slots 0 & 1 to a corresponding IRQ nibble index.

[mborgerson]

Fixed by #96