OSDev.org

I've decided to have serial console output of my "kernel" so I can capture easily output when I'm testing stuff on actual HW. I'm starting simple - both bootloader and my kernel are just sending bytes by polling if byte can be sent via com0 serial port. My kernel init function: early_uart_init().

It does work however I wonder:
How can I detect if setting given speed is OK for remote side? Will reading LSR just after setting speed give me any information about that? Actually even int $0x14 AH=00h returns line status after attempted initialization. Can I assume 0xff as error during initialization ?

In my poll_uart_write() I set the arbitrary number to wait before I give up on sending a byte out. Some tutorials used infinite loop when waiting for it but I don't think it's a good idea. Is there a good common practice how long to wait? Can there be actually a situation when the buffer is always full ?

Will the remote side respond in a particular way when it receives data at the correct speed? If not, you have no way to detect whether the remote side understands the data you're sending.


Only if the remote side is trying to send data; LSR will usually indicate errors when the speed doesn't match.


It's pretty unlikely that the line status register would be 0xFF immediately after initialization, but you can be a lot more certain by also checking the modem status register (which is also returned). If both status registers are 0xFF, there's probably no UART.


If you're using one of the rare UARTs that actually supports hardware flow control in hardware and you've enabled that hardware flow control, the buffer could remain full forever if the remote device never requests more data. Otherwise, the only way the buffer could stay full is if the UART breaks.

At this time I don't expect any response from remote side. It's just passively showing whatever I send to it. At least at this stage. I was toying with the idea of creating gdb stub but it's nothing but an idea right now.

Thanks. I'll do a check on MSR too then.