Advanced Serial Debugging Guide - Revision history

Roman Kargin: /* Firmware method */

2020-12-26T18:52:44Z

Firmware method

← Older revision		Revision as of 18:52, 26 December 2020
Line 151:		Line 151:
	On X5000 it's the same U-Boot as with Sam/AmigaOne, so as example set serial, munge and debuglevel to 5:		On X5000 it's the same U-Boot as with Sam/AmigaOne, so as example set serial, munge and debuglevel to 5:

	setenv os4_commandline "serial munge debuglevel=5"		setenv os4_commandline serial munge debuglevel=5
	saveenv		saveenv

Roman Kargin: /* KDebug method */

2019-09-26T15:28:18Z

KDebug method

← Older revision		Revision as of 15:28, 26 September 2019
Line 165:		Line 165:

	This will set the debug level to 5 and output via the serial port.		This will set the debug level to 5 and output via the serial port.

		⚫	To note ,that in firmware method we use '=' for debuglevel, i.e. 'debuglevel=5'. But when we use 'kdebug", then instead of '=' we put space, i.e. 'debuglevel 5'.

	{{Note\|Quotation marks are mandatory when using the KDebug tool. What KDebug does is send whatever string you enter directly to the AmigaOS kernel for interpretation. The KDebug command itself does not parse the string.}}		{{Note\|Quotation marks are mandatory when using the KDebug tool. What KDebug does is send whatever string you enter directly to the AmigaOS kernel for interpretation. The KDebug command itself does not parse the string.}}

	{{Note\|KDebug method have higher priority. I.e. if you set your environment variable to some values, and then after os is boots use KDebug to change the settings, then they ''will'' be taken in account and previous one will be forgotten. The only thing that you can't enable/disable by KDebug is 'munge'.}}		{{Note\|KDebug method have higher priority. I.e. if you set your environment variable to some values, and then after os is boots use KDebug to change the settings, then they ''will'' be taken in account and previous one will be forgotten. The only thing that you can't enable/disable by KDebug is 'munge'.}}

⚫	~~{{Note\|As~~ ~~can~~ ~~be seen~~, in firmware method we use "=" for debuglevel, i.e. "debuglevel=5". But when we use ~~"munge~~", then instead of "=" we ~~use~~ space, i.e. "debuglevel 5".}}

	= Getting the Most out of Serial Debugging =		= Getting the Most out of Serial Debugging =

Roman Kargin: /* KDebug method */

2019-09-26T15:16:12Z

KDebug method

← Older revision		Revision as of 15:16, 26 September 2019
Line 161:		Line 161:

	KDebug is command line utility found in SYS:C which communicates with the AmigaOS kernel. With this utility you can redirect your output to serial or memory. It will override whatever you do with the os4_commandline firmware variable. This is very handy for setting different debug levels at the time you need it. For example, you may also put a command in S:User-Startup		KDebug is command line utility found in SYS:C which communicates with the AmigaOS kernel. With this utility you can redirect your output to serial or memory. It will override whatever you do with the os4_commandline firmware variable. This is very handy for setting different debug levels at the time you need it. For example, you may also put a command in S:User-Startup
	run >NIL: kdebug "~~debug level~~ 5"		run >NIL: kdebug "debuglevel 5"
	run >NIL: kdebug "console serial"		run >NIL: kdebug "console serial"

Line 169:		Line 169:

	{{Note\|KDebug method have higher priority. I.e. if you set your environment variable to some values, and then after os is boots use KDebug to change the settings, then they ''will'' be taken in account and previous one will be forgotten. The only thing that you can't enable/disable by KDebug is 'munge'.}}		{{Note\|KDebug method have higher priority. I.e. if you set your environment variable to some values, and then after os is boots use KDebug to change the settings, then they ''will'' be taken in account and previous one will be forgotten. The only thing that you can't enable/disable by KDebug is 'munge'.}}

			{{Note\|As can be seen, in firmware method we use "=" for debuglevel, i.e. "debuglevel=5". But when we use "munge", then instead of "=" we use space, i.e. "debuglevel 5".}}

	= Getting the Most out of Serial Debugging =		= Getting the Most out of Serial Debugging =

Roman Kargin: /* Firmware method */

2019-09-26T15:13:57Z

Firmware method

← Older revision		Revision as of 15:13, 26 September 2019
Line 149:		Line 149:
	saveenv		saveenv

	On X5000 U-Boot ~~same~~ with serial, munge and debuglevel to 5:		On X5000 it's the same U-Boot as with Sam/AmigaOne, so as example set serial, munge and debuglevel to 5:

	setenv os4_commandline "serial munge debuglevel 5"		setenv os4_commandline "serial munge debuglevel=5"
	saveenv		saveenv

Roman Kargin: /* Firmware method */

2019-09-26T08:23:33Z

Firmware method

← Older revision		Revision as of 08:23, 26 September 2019
Line 147:		Line 147:

	setenv os4_commandline "serial munge debuglevel=7"		setenv os4_commandline "serial munge debuglevel=7"
			saveenv

			On X5000 U-Boot same with serial, munge and debuglevel to 5:

			setenv os4_commandline "serial munge debuglevel 5"
	saveenv		saveenv

Steven Solie: /* Firmware method */

2015-11-16T20:25:23Z

Firmware method

← Older revision		Revision as of 20:25, 16 November 2015
Line 140:		Line 140:
	On AmigaOne X1000/CFE set munge, debuglevel to 4 and output to serial:		On AmigaOne X1000/CFE set munge, debuglevel to 4 and output to serial:

	setenv -p os4_commandline="serial munge debuglevel=4"		setenv -p os4_commandline "serial munge debuglevel=4"

	and then boot AmigaOS. For CFE if you are not using -p, then the variable is only saved for that session, not permanently.		and then boot AmigaOS. For CFE if you are not using -p, then the variable is only saved for that session, not permanently.

Roman Kargin: /* Introduction */

2015-04-06T09:09:34Z

Introduction

← Older revision		Revision as of 09:09, 6 April 2015
Line 13:		Line 13:
	That means that when you want to do some serious work and you need any way to catch your bugs and/or debug any of your problematic code, then serial debugging is the best and only one way. Of course it's still possible to hope that the system friendly GrimReaper will popup for you and that there will be nothing so hardcore which it will crash Intuition and "freeze" the OS but that's just not enough when it come to doing real work.		That means that when you want to do some serious work and you need any way to catch your bugs and/or debug any of your problematic code, then serial debugging is the best and only one way. Of course it's still possible to hope that the system friendly GrimReaper will popup for you and that there will be nothing so hardcore which it will crash Intuition and "freeze" the OS but that's just not enough when it come to doing real work.

	You may ask now why the serial port is used at all? Why not parallel or something else? Why does everyone keep telling you to use serial debugging as if there is nothing else you can connect a cable to? The answer is in simplicity and reliability. Serial was chosen because it is simple to transfer data, bit by bit, not like for example done with a parallel port. There are different interfaces which also can transfer information bit by bit (like Ethernet, Firewire and USB) but the standard serial port is common to all platforms and far less complex. It ~~comes~~ as no surprise that the old AmigaOS 3 which works on classic Amigas throw all the debug information via serial port as well. Today, we have different kinds of hardware, where for example USB is pervasive, but USB is more complex and still not as reliable for debugging purposes.		You may ask now why the serial port is used at all? Why not parallel or something else? Why does everyone keep telling you to use serial debugging as if there is nothing else you can connect a cable to? The answer is in simplicity and reliability. Serial was chosen because it is simple to transfer data, bit by bit, not like for example done with a parallel port. There are different interfaces which also can transfer information bit by bit (like Ethernet, Firewire and USB) but the standard serial port is common to all platforms and far less complex. Because of that it should come as no surprise that the old AmigaOS 3 which works on classic Amigas throw all the debug information via serial port as well. Today, we have different kinds of hardware, where for example USB is pervasive, but USB is more complex and still not as reliable for debugging purposes.

	= Serial and Null Modem =		= Serial and Null Modem =

Roman Kargin: /* Introduction */

2015-04-06T09:08:27Z

Introduction

← Older revision		Revision as of 09:08, 6 April 2015
Line 13:		Line 13:
	That means that when you want to do some serious work and you need any way to catch your bugs and/or debug any of your problematic code, then serial debugging is the best and only one way. Of course it's still possible to hope that the system friendly GrimReaper will popup for you and that there will be nothing so hardcore which it will crash Intuition and "freeze" the OS but that's just not enough when it come to doing real work.		That means that when you want to do some serious work and you need any way to catch your bugs and/or debug any of your problematic code, then serial debugging is the best and only one way. Of course it's still possible to hope that the system friendly GrimReaper will popup for you and that there will be nothing so hardcore which it will crash Intuition and "freeze" the OS but that's just not enough when it come to doing real work.

	You may ask now why the serial port is used at all? Why not parallel or something else? Why does everyone keep telling you to use serial debugging as if there is nothing else you can connect a cable to? The answer is in simplicity and reliability. Serial was chosen because it is simple to transfer data, bit by bit, not like for example done with a parallel port. There are different interfaces which also can transfer information bit by bit (like Ethernet, Firewire and USB) but the standard serial port is common to all platforms and far less complex. It comes as no surprise that the old AmigaOS 3 which works on classic Amigas, all ~~output~~ debug information via serial ~~ports~~. ~~Now~~, we have different kinds of hardware where USB is pervasive but USB is more complex and still not as reliable for debugging purposes.		You may ask now why the serial port is used at all? Why not parallel or something else? Why does everyone keep telling you to use serial debugging as if there is nothing else you can connect a cable to? The answer is in simplicity and reliability. Serial was chosen because it is simple to transfer data, bit by bit, not like for example done with a parallel port. There are different interfaces which also can transfer information bit by bit (like Ethernet, Firewire and USB) but the standard serial port is common to all platforms and far less complex. It comes as no surprise that the old AmigaOS 3 which works on classic Amigas throw all the debug information via serial port as well. Today, we have different kinds of hardware, where for example USB is pervasive, but USB is more complex and still not as reliable for debugging purposes.

	= Serial and Null Modem =		= Serial and Null Modem =

Roman Kargin: /* Introduction */

2015-04-06T09:04:41Z

Introduction

← Older revision		Revision as of 09:04, 6 April 2015
Line 7:		Line 7:
	= Introduction =		= Introduction =

	While AmigaOS has "hi-level" capabilities to help debug problems (e.g. redirecting debug outputs to memory and displaying the log with DumpDebugBuffer or using serial redirection tools like Sashimi) it is sometimes still not enough. For example, there is no protection for areas like input and Intuition so we can get into a situation where the GUI is not operational but the OS is still working. Intuition, input and any other necessary components can crash and then the GrimReaper utility has no way to spawn itself. Meanwhile, the kernel ~~can~~ still can output debug information about the crash on serial.		While AmigaOS has "hi-level" capabilities to help debug problems (e.g. redirecting debug outputs to memory and displaying the log with DumpDebugBuffer or using serial redirection tools like Sashimi) it is sometimes still not enough. For example, there is no protection for areas like input and Intuition so we can get into a situation where the GUI is not operational but the OS is still working. Intuition, input and any other necessary components can crash and then the GrimReaper utility has no way to spawn itself. Meanwhile, the kernel, still can output debug information about the crash on serial.

	To begin with, you should know that AmigaOS has 2 ''reapers''. One is a user friendly utility from SYS:System called GrimReaper. The GrimReaper can be called a "hi-level" one. Another ''reaper'' is called Reaper which is a part of the kernel itself. The kernel's Reaper actually launches the user-friendly GrimReaper when a required. So, you can imagine that when things get nasty, the kernel's reaper can catch some information and output it to the serial ~~and~~ ~~the~~ OS ~~may~~ ~~die~~ ~~soon~~ ~~after~~ ~~that.~~ ~~Visually~~, you just see a "freeze" of the OS and you ~~don~~'t ~~know~~ ~~what~~ ~~happened~~ ~~and~~ of ~~course~~ no ~~stack~~ ~~trace~~ or ~~register~~ ~~dump~~.		To begin with, you should know that AmigaOS has 2 ''reapers''. One is a user friendly utility from SYS:System called GrimReaper. The GrimReaper can be called a "hi-level" one. Another ''reaper'' is called Reaper which is a part of the kernel itself. The kernel's Reaper actually launches the user-friendly GrimReaper when a required. So, you can imagine that when things get nasty, the kernel's reaper not all the time can spawn a GrimReaper, but still can catch some information and output it to the serial. Visually, when such a nasty things happens and input and/or intuition die, you just see a "freeze" of the OS and may think that everything is freezes, while it not: you just can't operate with OS anymore as necessary parts of OS crashes, but OS itself still working and kernel's reaper already throw all the info into the serial.

	That means that when you want to do some serious work and you need any way to catch your bugs and/or debug any of your problematic code, then serial debugging is the best and only one way. Of course it's still possible to hope that the system friendly GrimReaper will popup for you and that there will be nothing so hardcore which it will crash Intuition and "freeze" the OS but that's just not enough when it come to doing real work.		That means that when you want to do some serious work and you need any way to catch your bugs and/or debug any of your problematic code, then serial debugging is the best and only one way. Of course it's still possible to hope that the system friendly GrimReaper will popup for you and that there will be nothing so hardcore which it will crash Intuition and "freeze" the OS but that's just not enough when it come to doing real work.

Philippe Ferrucci: /* Getting the Most out of Serial Debugging */

2015-01-26T15:24:38Z

Getting the Most out of Serial Debugging

← Older revision		Revision as of 15:24, 26 January 2015
Line 171:		Line 171:
	# [[Exec_Debug\|Exec Debug]]		# [[Exec_Debug\|Exec Debug]]

	To get the most out of serial debugging, developers should use what is called the debug kernel (named '''kernel.debug'''). The debug kernel provides you with more functionality compared with the release kernel at the cost of some execution speed. One thing provided is the ability to play with debug levels where you can choose how much "system" debug output you want to see. It's pretty easy to miss the fact that debug levels only work on debug kernels. ~~Usually~~ ~~developers~~ ~~start to plays~~ with levels, see no change, and ~~start~~ to ~~think~~ "Why ~~does~~ it ~~not~~ work?" It works, it is just that the kernel should be the debug one.		To get the most out of serial debugging, developers should use what is called the debug kernel (named '''kernel.debug'''). The debug kernel provides you with more functionality compared with the release kernel at the cost of some execution speed. One thing provided is the ability to play with debug levels where you can choose how much "system" debug output you want to see. It's pretty easy to miss the fact that debug levels only work on debug kernels. You can play with levels, see no change, and you then wonder "Why doesn't it work?". It works, it is just that the kernel should be the debug one.

	And while the debug kernel does give you some debug functionality, it still may not cover everything. For example, tools like the old MungWall tool can do a bit more: debug kernel has only the "munge" feature but not the "wall" feature. Another example is MemGuard (which can be found on [http://www.os4depot.net OS4Depot]) adds additional debug capabilities on top of what the debug kernel provides and catches more difficult to find bugs.		And while the debug kernel does give you some debug functionality, it still may not cover everything. For example, tools like the old MungWall tool can do a bit more: debug kernel has only the "munge" feature but not the "wall" feature. Another example is MemGuard (which can be found on [http://www.os4depot.net OS4Depot]) adds additional debug capabilities on top of what the debug kernel provides and catches more difficult to find bugs.