Octocontrabass wrote: ↑Sun Dec 29, 2024 8:30 am
Connect a jumper between the TXD and RXD pins on any serial port. Turn off flow control. Send data. If you don't receive data, either your driver is broken or the port itself is broken.
Connect two working serial ports to each other using the GND, TXD, and RXD pins. Don't connect any of the other pins. Turn off flow control. Set both ports to the same speed. If you can't get them to communicate, swap TXD and RXD on one end and try again.
Well the jumpers that I have don't appear to properly fit either the port or pins of each serial connector. One of those cheap little wires broke while attempting to get them connected, so it seemed like a lost cause. I ordered a low profile IDC-10 to DB9 adapter last night that should come tomorrow, so I'll be sure to keep everybody posted on how it's going once I can try it out. I'd still very much love to get away from serial ports if I can.
Octocontrabass wrote: ↑Sun Dec 29, 2024 8:30 am
You said kernel debugging so they think you're trying to debug Windows. You need a real serial port on the PC you're debugging if you're debugging Windows. You're not debugging Windows so you can ignore them.
It's certainly possible they misunderstood, though I spoke about this in a platform-agnostic way with the leading question being "why is it that these cables seem to transmit data from usermode but not when I write to the serial port in kernel mode", and they give me this vague answer about how they don't support transferring data directly written to the serial port from kernel mode drivers because of how they implement their driver--which is all without my osdev project even running (we're just talking about standard Windows/Linux kernel drivers which have OUT/IN instructions used in them).
Here is a snippet of how that conversation began with StartTech. The FTDI guys were more helpful, but I can't seem to find that email chain.
Before we end up talking about how I didn't setup the serial port correctly in my kernel code, in addition to all of the custom code I wrote, I also utilized the official examples provided on the OSDEV wiki and never received data from the serial port in loopback mode via the following code example (taken from that aforementioned wiki page).
Code: Select all
#define PORT 0x3f8 // COM1
static int init_serial() {
outb(PORT + 1, 0x00); // Disable all interrupts
outb(PORT + 3, 0x80); // Enable DLAB (set baud rate divisor)
outb(PORT + 0, 0x03); // Set divisor to 3 (lo byte) 38400 baud
outb(PORT + 1, 0x00); // (hi byte)
outb(PORT + 3, 0x03); // 8 bits, no parity, one stop bit
outb(PORT + 2, 0xC7); // Enable FIFO, clear them, with 14-byte threshold
outb(PORT + 4, 0x0B); // IRQs enabled, RTS/DSR set
outb(PORT + 4, 0x1E); // Set in loopback mode, test the serial chip
outb(PORT + 0, 0xAE); // Test serial chip (send byte 0xAE and check if serial returns same byte)
// Check if serial is faulty (i.e: not same byte as sent)
if(inb(PORT + 0) != 0xAE) {
return 1;
}
// If serial is not faulty set it in normal operation mode
// (not-loopback with IRQs enabled and OUT#1 and OUT#2 bits enabled)
outb(PORT + 4, 0x0F);
return 0;
}
This occurred after their driver had been loaded, where my kernel module was then loaded and attempted to setup/access the serial port. I considered the possibility that maybe they were setting up the serial port in some special way, and I was messing that up, so I even omitted some of the setup code to piggyback on their implementation which also didn't work.
Octocontrabass wrote: ↑Sun Dec 29, 2024 8:30 am
Why would either PC need a "real" serial port if that driver works?
That's true, though even with that FTDI EDK2 driver I would be restricted to launching my project in UEFI's DXE space (after their driver is loaded), which is not something I'd prefer to shackle myself down to. In any event, I'd just really love to get away from using COM ports for communication if I can. That doesn't seem like a ridiculous ask to me, and it's a little surprising that a somewhat easy-to-setup technology doesn't exist for this purpose.
nullplan wrote: ↑Sun Dec 29, 2024 3:08 pm
I was referring to USB EHCI and XHCI debugging capabilities. For XHCI, it is defined in the XHCI specification chapter 7.6. Whether or not any of your computers even supports this is something you have to find out yourself.
Oh, yes, I've made some ground after reading through the xHCI specification with getting DbC workable for this purpose. So far the results haven't been as amazing as I would've hoped for, though that's certainly my fault. Something about the device failing a reset request after being enumerated (or something like that). I was able to transfer some data with the USB descriptor that was setup, so I know that it
works to some degree. As far as I've been made aware, xHCs exist on most consumer PCs and the DbC extended capability exists on most xHCs that are compliant with whatever standard they started including it with some long time ago. If I'm not able to get the serial port to work with a new adapter, and have to resort to using a DMA device to solve my most recent issue, I will probably continue in the direction of DbC after briefly exploring ethernet, as I'm yet to do so.
Utilizing ethernet controllers for this was included in most of the advice I've been given from several different people so far. My concern was that I would have to end up writing controller-specific code to support different ethernet hardware that may be on the system, but they were adamant in suggesting supporting E1000/E1000e, RTL8111, and perhaps some NetXtreme controller would be all that's required to reasonably support most consumer PC hardware via ethernet.
