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. firstname.lastname@example.org.
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
Information resources to help out with this course (Free and under US$10)
*) Self-Service Linux - Mastering the Art of Problem Determination, Open Publication Licensed http://www.informit.com/content/images/013147751X/downloads/013147751X_book.pdf
*) Debugging Linux Systems: US$7.99 http://www.informit.com/store/product.aspx?isbn=0136123546
*) SystemTap: Instrumenting the Linux Kernel for Analyzing Performance and Functional Problems http://www.redbooks.ibm.com/abstracts/redp4469.html
*) Linux Performance and Tuning Guidelines https://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/redp4285.html
Bit on the costly side, but highly recommended: Linux Debugging and Performance Tuning: Tips and Techniques, Steve Best ISBN-10: 0131492470 ISBN-13: 9780131492479 http://www.pearsonhighered.com/educator/product/Linux-Debugging-and-Performance-Tuning-Tips-and-Techniques/9780131492479.page
For industrial control applications, or even a simple assembly line, that machine can go almost 24/7 without a break. But what happens when the task is a little more complex? That’s where the “smart” machine would come in. The smart machine is one that has some simple (or complex in some cases) processing capability to be able to adapt to changing conditions. Such machines are suited for a host of applications, including automotive, aerospace, defense, medical, computers and electronics, telecommunications, consumer goods, and so on. This discussion will examine what’s possible with smart machines, and what tradeoffs need to be made to implement such a solution.