Page 1 of 2

When serial isn't an option, what should I use for debug?

Posted: Mon Nov 02, 2015 1:53 pm
by zdz
If there is already a thread on this subject / a wiki page that I managed to skip I am sorry and I will happily go there.

I usually use serial for debug output / input. It's pretty easy and convenient. But I want to test my work on a laptop and I loose this option. I imagine that I can use some serial-*something_else_adapter*, but that won't really help me as I will have to send data over that something_else anyway. So assuming I have no serial on both my developer machine and my test machine, what's recommended?
Firewire comes in mind, but I have the same problem: I can't put it in my laptop.

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 2:39 pm
by BASICFreak
My recommendation, which I do on HW, is printf debugging. (may also need delays or stop points if trying to locate a bug)

Also, I haven't done so yet, you could check out the Debug Registers

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 2:44 pm
by iansjack
What about the network?

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 2:56 pm
by Combuster
I once used the keyboard LEDs for serial output while debugging graphics driver code. Not that I can recommend that.

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 3:03 pm
by BASICFreak
iansjack wrote:What about the network?
The network requires a working system.

Network stack
NIC Drivers
TCP/IP
UDP
and whatever else is needed for the communication...

And most of the time the debugging is needed well before these can be implemented.

But if OP is at that point it is an option.

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 3:10 pm
by zdz
BASICFreak wrote:My recommendation, which I do on HW, is printf debugging. (may also need delays or stop points if trying to locate a bug)

Also, I haven't done so yet, you could check out the Debug Registers
That is an option up until a point. My bad, I should have given a bit more context: I'm not really making an OS, I'm making a hyper-visor (osdev is still a extremely valuable source of information). I can't print on screen once a guest is loaded; also, some output may be a bit large, sometimes I want / need to be able to send debug commands (from setting breakpoints, to modifying memory / registers, single stepping etc). I'm talking about full debugging support (which already exists, I just need to find a way to use it).
The network requires a working system.

Network stack
NIC Drivers
TCP/IP
UDP
and whatever else is needed for the communication...

And most of the time the debugging is needed well before these can be implemented.

But if OP is at that point it is an option.
This is what I wanted to ask. Well, I need and want to have something, so everything is an option. I just don't know what option is better.
I once used the keyboard LEDs for serial output while debugging graphics driver code. Not that I can recommend that.
That must have been fun. My darkest memory is generating BSODs on purpose in order to debug a Windows driver on a machine that WinDbg refused to accept in it's life. Now I feel that my darkest memory is boring :(

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 3:22 pm
by BASICFreak
USB would probably be easier to program than a NIC.

Then you could use USB-to-RS232 adapter and have the serial output you already use.

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 3:28 pm
by zdz
BASICFreak wrote:USB would probably be easier to program than a NIC.

Then you could use USB-to-RS232 adapter and have the serial output you already use.
I'm thinking that if I implement another method for communication I should implement it on both ends. So in the end I will have both serial - serial and USB - USB / network - network / etc. The more, the better, you never know what could happen.

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 3:32 pm
by alexfru
Combuster wrote:I once used the keyboard LEDs for serial output while debugging graphics driver code. Not that I can recommend that.
And we still have speakers. Morse code or not, why not? :)

Re: When serial isn't an option, what should I use for debug

Posted: Mon Nov 02, 2015 4:20 pm
by Nutterts
zdz wrote:
BASICFreak wrote:Then you could use USB-to-RS232 adapter and have the serial output you already use.
I'm thinking that if I implement another method for communication I should implement it on both ends. So in the end I will have both serial - serial and USB - USB / network - network / etc. The more, the better, you never know what could happen.
yet you said
zdz wrote:But I want to test my work on a laptop and I loose this option
Cause yeah, you want to redirect stdout in your OS. But if it's just for testing your work on a device that doesn't have a serial port. Then use one of those cheap USB-to-RS232 adapters. Just make sure you get the right one, if you tell me what you normally do I'd be happy to lookup the right one for you.

If you want to add another i/o device (usb, etc) to use for debug... it's nice to be able to debug while developing it.

Also.. you don't want serial<->serial, you want serial<>any-other-compatible-io-device. So like on any other OS, a usb->serial converter should atleast at the user level basicly be the same thing as serial<>serial.

Re: When serial isn't an option, what should I use for debug

Posted: Tue Nov 03, 2015 12:56 am
by Techel
Bochs supports writing output to console using port 0xE9.

Re: When serial isn't an option, what should I use for debug

Posted: Tue Nov 03, 2015 1:47 pm
by zdz
Nutterts wrote:
zdz wrote:
BASICFreak wrote:Then you could use USB-to-RS232 adapter and have the serial output you already use.
I'm thinking that if I implement another method for communication I should implement it on both ends. So in the end I will have both serial - serial and USB - USB / network - network / etc. The more, the better, you never know what could happen.
yet you said
zdz wrote:But I want to test my work on a laptop and I loose this option
Cause yeah, you want to redirect stdout in your OS. But if it's just for testing your work on a device that doesn't have a serial port. Then use one of those cheap USB-to-RS232 adapters. Just make sure you get the right one, if you tell me what you normally do I'd be happy to lookup the right one for you.

If you want to add another i/o device (usb, etc) to use for debug... it's nice to be able to debug while developing it.

Also.. you don't want serial<->serial, you want serial<>any-other-compatible-io-device. So like on any other OS, a usb->serial converter should atleast at the user level basicly be the same thing as serial<>serial.
I think you're right. But after I have seril <> USB working I will probably want to have USB <> USB, because why not?

What other devices fall into the other-compatible-device category? I've done some reading and USB seems far easier than network.
In the next days I will probably look for some gotchas met by people around here who implemented USB support. Just having debug input / output it not like having full USB support so I should be fine.

Suggestions, advises, tips, other methods are still valuable to me so please don't treat this as a solved topic :)
Bochs supports writing output to console using port 0xE9.

That's not helping me in any way.

Re: When serial isn't an option, what should I use for debug

Posted: Tue Nov 03, 2015 1:53 pm
by Techel
I did't see the laptop thing. You could also write your output to storage like hdd etc. and analyze it afterwards.

Re: When serial isn't an option, what should I use for debug

Posted: Tue Nov 03, 2015 2:19 pm
by iansjack
I've done some reading and USB seems far easier than network.
I wouldn't be too sure about that.

Providing you have a documented NIC it is relatively simple to write a workable network driver; it is then trivial to implement a custom protocol to transfer your debug information to another machine.

Re: When serial isn't an option, what should I use for debug

Posted: Tue Nov 03, 2015 2:28 pm
by zdz
Roflo wrote:I did't see the laptop thing. You could also write your output to storage like hdd etc. and analyze it afterwards.
Writing to disk comes with it's own problems and I will need a stable environment and debugger when I'll implement that. For short, I have to make sure that the portion of the disk that I write to will never be used by the guest. Details are... a bit more complicated.
Providing you have a documented NIC it is relatively simple to write a workable network driver; it is then trivial to implement a custom protocol to transfer your debug information to another machine.
My first thought (when I opened this thread) is that it can't be that hard to make the NIC work and after that a simple communication protocol is trivial. Once I started to look into things that first impression changed.

I guess that I have to weight my options. Right now I'm almost sure that I want USB, but I don't really have time for development in this period (~2 weeks). The good news is that I can read about this and that so I have time to look over things and come with a list of pro and cons and a plan.
Any examples on how USB might backfire / be harder to make it work properly?