Have not worked with Linux or Android though there has been a lot of discussion about it. I also agree there should of been a lower level preceeding seminar in Linux. Did pick up a couple of tidbits though.

Are there archived copies of this class and the other four classes in this series that I could get a copy of? I was not able to hear any sound because our IT department blocks all streaming audio and video. I could not get our IT department to unblock it in time. alan.barman@us.yazaki.com.

Thanks danlafleur for your help. my company block internet radio so i was not even seeing the red box. I am working from a computer that is not a company machine now so I am able to view/listen to it now.

@LevitonDave - Ubuntu etc will give you a leg up - especially with 'Linux mindset' and the tools. I was messing around with building the Android kernel last fall; broke my brain with all the new things to learn.

Ultimately you are always going to run on real hardware. The simulator is just a way to get started as well as a nice contained enviroment for general understanding of the linux core. Having simulators that match your HW platform is the absolute best possible place you can be. Hats off to the folks who have made that possible with ports of the beagle, gumstix and many others to QEMU.

@CHUCK: Thank you. I will send a note so you have my e-mail as well to keep me in the loop. I am not quitting, but I feel I won't benefit too much with this material in the current semester. This is at the "masters" level. :o)

@GBr Yes, the Linksys WRT54GL is a classic, cheap embedded target with many greate communities supporting it. OpenWRT is one such example. Greg Petersen and the guys at OpenWRT have done a great jopb at pulling together the toolchains and file systems to make it relatively painless to get started.

The use of QEMU as a playground is also a good starting point. You can do a lot of debugging in that context with risking a physical hardware crash. But, embedded Linux-capable hardware is cheap and available from (plug) Digikey ;-) . I use both beagleboards and beaglebones for development. Gumstix , APC and many many others are also available. I find that it's often easier to just use and real piece of hardware than get my desktop playing nicely with QEMU (better performance with the real hardware).

And interesting tidbit is that these days 90% development of the kernel debug core (which KDB / KGDB use as their back end) is done with Simulators where it is much easier to disect what went wrong. Of course debugging the debugger is a topic in and of itself which most folks are probably not too interested in. :-)

There is also a more simple way to learn about source debugging and debugging through interrupt contexts etc... If you use a simulator such as QEMU you can debug all the way from the power on through the kernel hand off to user space, assuming you have a bit of documentation about where to load symbols into the debugger. It is no different with JTAG + real hardware, but the JTAG can be very cumbersome compared to the simplicity of a Simulator.

Android features are now included in the latest Linux mainline kernel (3.x). So, if you're using a latest Linux distro like Ubuntu 12.04, you'll be able to use it as a springboard to learning out to create Android drivers.

The kallsyms allows you to see *all* of the symbols including the ones that were dynamically loaded via kernel modules. Without it enabled, you get just the addresses from the hash table without the symbol names. Then you can use ksymoops to decode.

Your best way to learn Linux as a beginner is to get an old PC, download a Linux distribtion and install it. I use Linux Mint, but a lot of folks use Ubuntu, Fedora and many others. Just search for "download Linux Mint" or "download fedora linux". That will take you to the page for downloads. Enjoy...

In terms of capture of an oops with embedded systems, the others that were not discussed are pmem, pstore, and kdump. The thing about kernel debugging is that there are lots of tools and sometimes no single tool will get you exactly what you need and they all have costs and benefits to implement.

strace vs. lttng... strace uses a different mechanism than lttng. I'll be discussing lttng later in the series. But, lttng can capture the system calls like strace does. But, strace is lighter weight and doesn't require patching tht kernel or rebuilding kernel modules.

@CHUCK: I am taking this CEC courses for about 4 months now (SECOND SEMESTER), and this Linux debugging course kind of feels out of sequence in the curriculum with no preliminary considerations. Everything else before was presented at a very basic level and evolved from there. Can you tell me what I'm missing?

What is even more useful is to get the lines for locations from the stack trace as that is your pointer in to where somethin crashed. It is not covered in this particular power point, but hopefully it will be at a later point. :-)

An oops can absolutely be fatal, not always but that is also the reason you can set the kernel to panic on oops. If a user space app generated an oops, that is certainly a way to you can end up exploting the system (for those security minded folks).

RandyS to answer your question: "Is there a specific flag to set to have the kernel automatically reboot on panic?" Yes, there is a kernel argument called panic=DELAY_IN_SECONDS see Documentation/kernel-parameters.txt

Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.