OSDev.org

Korona wrote:@vvaltchev: Do you have physical hardware where 0x3F8 does not work? On the machines that I tested on (even newer ones), COM1 is still at that port (but COM 2, 3, 4 might not be at their legacy addresses - I have not checked that).

Octocontrabass wrote:Well, there you go. Your serial port is using I/O port 0x3F8 and (ISA) IRQ 4.

If the serial port doesn't echo back the data you send when you short pins 2 and 3 together (with nothing else connected), the UART isn't programmed correctly.

Bonfra wrote:Do I need to connect together those two pins on their own or does the cable need to be plugged to the other end? it's a bit trivial to shorten them while it's connected. I tried to connect just these two pins without plugging the cable and nothing is sent back, maybe I need to do something else with the other pins?

vvaltchev wrote: Let me just throw a theory: maybe you don’t wait the mandatory 2 microseconds in the right places? Such things don’t really matter in VMs, but on real hw, they do.

uart_init:
    push rax
    push rdx

    mov dx, 0x3f9
    ; IER int off
    xor al, al
    out dx, al
    ; LCR set divisor mode
    mov al, 0x80
    add dl, 2
    out dx, al
    ; DLL divisor lo 115200
    mov al, 1
    sub dl, 3
    out dx, al
    ; DLH divisor hi
    xor al, al
    inc dl
    out dx, al
    ; FCR fifo off
    inc dl
    out dx, al
    ; LCR 8N1, break on
    mov al, 0x43
    inc dl
    out dx, al
    ; MCR Aux out 2
    mov al, 0x8
    inc dl
    out dx, al
    ; clear receiver/transmitter
    xor al, al
    sub dl, 4
    in al, dx

    pop rax
    pop rdx
    ret

; Param RDI[low8] => character to put
uart_putc:
    push rax
    push rcx
    push rdx
    mov ecx, 10000
    mov dx, 0x3fd
.one:
    in al, dx
    pause
    cmp al, 0xff
    je .two
    dec ecx
    jz .two
    and al, 0x20
    jz .one

    mov ax, di
    sub dl, 5
    out dx, al
.two:

    pop rdx
    pop rcx
    pop rax
    ret

uart_getc:
    push rdx

    xor rax, rax

    mov dx, 0x3fd
.one:
    pause
    in al, dx
    and al, 1
    jz .one
    sub dl, 5
    in al, dx

    cmp al, 13 ; '\r'
    jne .done
    mov al, 10 ; '\n'
.done:

    pop rdx
    ret

vvaltchev wrote: you could check if the receiver is configured correctly by using another OS instead of yours and making sure the communication works both ways. If that’s all OK, the problem is exclusively in your kernel.

pvc wrote: Short the pins without connecting the other end. I often used metal tweezers to do that . But it would be safer, for the hardware, to use some kind of resistor (maybe about 100 ohms).

rdos wrote: The next issue is that practically no modern computer has serial ports, and so debugging using serial ports doesn't seem like a good idea. Sure, there are USB to serial converters, but using those requires a functions USB stack and a functional USB COM driver, and many problems with real hardware are connected to USB. You also need functional OHCI, UHCI, EHCI, XHCI and USB hub implementations to make use of it.

rdos wrote: I think a far better method to debug an OS is to use the network interface. At least on many PCs there are real Ethernet connectors and many computers use the same network chipsets (often RTL8169 or compatible).

rdos wrote:The next issue is that practically no modern computer has serial ports, and so debugging using serial ports doesn't seem like a good idea.

Bonfra wrote:I use a pause instruction to waste some time, maybe I should read to some blank port instead?

Bonfra wrote:Tomorrow I'll burn a small Linux distro to test this, anyway I'm going to set the baud rate of the port with `stty` and then just `cat` the port to read and `echo` to write. Is this enough?

Bonfra wrote:The computer with my os has the serial port, the other pc where I should receive data does not have it so I use a USB adapter, literally this cable. could this be the issue?

pvc wrote:

rdos wrote:The next issue is that practically no modern computer has serial ports, and so debugging using serial ports doesn't seem like a good idea.

I would like to disagree. Many modern, 'non-budget' motherboards still have physical serial ports. On server boards serial port is a norm. There are also many PCI/PCIe adapters. Most of these are usually compatible with good old 16550. So I think using serial port for debugging is perfectly good idea. Easy to program and require very little of the OS still functioning, even when most of the OS went kaput.

I use GDB over serial port for real machine debugging and it works just fine on my main, X570 machine (both ways, as debugger and as debugee).

vvaltchev wrote:I always used a C implementation, using: https://wiki.osdev.org/Serial_Ports as a starting point.

vvaltchev wrote:Ah, oops, there's ONE MORE THING: on modern Linux kernels (from 4.11), it's not possible anymore from user space to directly write to serial ports (not talking to the usb-adapter side)

Bonfra wrote:But knowing the initialization piece of code from the wiki fails is something to work right?

vvaltchev wrote:Ah, oops, there's ONE MORE THING: on modern Linux kernels (from 4.11), it's not possible anymore from user space to directly write to serial ports

nexos wrote:Why in the world did they do that? Some people still use serial ports!

nexos wrote:Anyway, @Bonfra, try testing the serial code in QEMU and see if anything gets sent to the serial monitor.