jwessel: Actually we met once at LinuxWorld before that confernce went buns up. But, it's a small community and I'm sure we'll meet in real life again.
Mike, I would not be surprised if at some point we bump into each other in the future or may have even done so in the past. The embbedded community is still farily small even with the explosive growth in the Android world.
kernelkernel: I can speak from the angle of the Wind River tools, the answer is yes. If you have a big pocket book the ARM Real View tools will do "the whole nine yards".
That was one of the big pushes behind the debug core in the kernel was to allow other archs to fill out a "processor specific stub" + "a polled I/O driver", then you could get a whole debugger working.
I do have a new set of experiemental patches that I'll be brining to the 2012 kernel summit for KGDB over USB using those cheap $7-15 USB dongles (specifically the FTDI and PL2303 devices).
@jwessel: Yeah, it's nice to have it in there if you've got a way to interact with the user like on x86. Tough to do that on a router or printer though. I'd love to see KGDB over USB or KGDBoE come back. The Ethernet option was particularly handy because you could have th console and debug at the same time without the interleaving.
You just have to know the little tricks to turn it on. Another really useful device to have (which time didn't permit for in Mike's presentation) is the EHCI debug adapter, if you are using x86 HW. If you don't have a serial and don't have a jtag, this device will get you early_printk() as well as kdb / kgdb at 1 mbit speeds.
We recommend to customers and even Canonical Ubuntu does this to leave KDB built into the kernel. It is really nice to be able to catch those super evil panics and simply run dmesg.
Chuck, If Digi ever wants to contact me to go even deeper on kgdb / kdb or something like that in the future, I'd be happy to present. Mike only got to scratch the sufface of some of the power.
In the future I am looking to get the USB and perhaps kgdboe back in the kgdb dev branch. It is now working my local tree against the 3.4 -> linus head branch.
@kernelkernel: That presentation can be found at both the Linux Foundation website (I did it at the Android bulder's summit earlier this year) and at the OpenOCD website. I didn't do the original recording. So, I'm afraid I couldn't control the quality :(.
@timd: if you look at the boot output on the serial console, you'll see a line of output that tells you how much memory the kernel is using. If you try that from user space, the memory size includes buffers and chaching space as well. So, you can't tell how much the kernel proper is using. An you should always beconcerned about memory usage on an embedded platform.
@Michael, thank you very much, I did not know the size of that kmalloc() pool is #defined as opposed to kernel config. I will continue looking. PS. A world reknowned manufacturer could have done a better job differentiating where to use GFP_ATOMIC :|
@Michael: re JTAG interface chipset; yes, of course the FTDI USB chipset. I believe I have seen this in the TinCan and Flyswatter tools on the web. I'm looking to piece together an Eclipse-based (nominally ARM) based development platform with JTAG debugging, out of my own pocket. I'm a old UNIX kernel person from my first job at Bell Labs in the late 70's, then transitioned to embedded stuff in the 80's and early 90's. Doing "system engineering" work now but striving to get back to my first love doing embedded and looking to dig into embedded Linux. Thanks for the great overview course.
@arkamax: you're really talking about the kernel's emergency page pool (GFP_ATOMIC allocates from there). There's a #define that proovides a guidline for the size of the emergency page pool. But, at the moment, I can't recall the define's location :(. However, it's really bad form to use GFP_ATOMIC allocations indescriminantly. I'd recommend a detailed analisys of the driver to find where they really need ATOMIC vs. the normal GFP_KERNEL allocations and fix the driver.
I have a small embedded system with an ARM processor. How can I tell how much RAM the kernel is using? Is there a way to look at this from user-space? Should I be concerned about my programs using to much RAM?
jaranda: You can debug from power on all the way through the kernel user space depending on the tools. But certainly you can debug u-boot with a JTAG. We often refer to working on the boot loader and prior to having a working kernel printk as "board bring up".
Thanks Mike. I'm not a linux developer or user yet, but the ideas for instrumenting the system are really useful for future projects. They may be based on some kind of OS or just a state machine. Software instrumenting using dynamically loaded modules or stubs on the system code sounds good to me.
@Michael - yes, I do - there is about 25 places where kmalloc() is used, and the way the source is built, it's hard to understand what's called from where. Is there any way to increase mem pool for kmalloc()? They recommend 4 Mbytes at least. Thanks.
@gbabeki: The chipset is the FTDI 232H that is a dual channel USB and JTAG. It's used on the TinCan Tools Flyswatter 2 JTAG among others. Really great interface for ARM debugging.
@Michael: I didn't catch the whole statement, but I believe you mentioned something about a "chipset"(?) or a device make makes a decent JTAG interface, particularly ARM-based boards. Could you repeat what you were referencing. Thanks.
Speaking of kernel compiling... I've got a third party driver that is overly zealous on kmalloc() with GFP_ATOMIC flag set - it basically runs out of kmalloc()'able default memory pool I have on my ARM. Vendor says I can increase the size of kmalloc() memory pool - but I cannot find how to do that. Using LTIB from Freescale. Any comment helps. Thanks :)
There is no reference to the kdump's user space portion. You should google for "redhat" "crash". The crash utility is what you use to get the information out of a kdump.
Software folks need to be aware of the voltage of the target and how the JTAG interfaces to it. Some JTAG modules have voltage levelers. Some may require a jumper or switch to adjust.
JTAG is pretty much the only choice for lower end 8-bit controllers like AVR. A snap to use (at least in AVR), much easier to set up and get started with than even GDB.
i remember an old debugging vector scope in Byte. it had the address bus split on a pair of a/d converters. x-y scope display draws an signature of where the code is executing. a great tool to "sniff" the bus.
Personally own Scope, logic analyzer and RF Test equipment (Spetrum Analyzers, Sig Gens, Network analyzers) for Hobby use. (definitely was valueable to have designed them in the past :)
Used Oscillioscope yesterday to chase down problem with embedded code for a training course. The code is just wrong. Without oscilloscope almost impossible to find.
Mike, one thing that is not mentioned in the presentation is that KMS (Kernel Mode Setting) support was merged as well. The means you can take a kernel oops or panic while running on a graphics console and jump to the kdb prompt. (fully merged in 2010).
it has been a long time since I have had to work with assembly language. I have worked on IBM System/360, 8086, pdp 11, and a few others. I am confortable with assembly language, just rusty.
jl "wanted to know if you can go to a new/different memory instruction location and continue exec" A: Sure you can just change the program counter register and continue from anywhere.
The mainline version of KDB connects to the debug core. The KGDB / gdbstub connects to that very same debug core. The configuration is all done through the kgdboc (KGDB Over Console) which is the I/O driver layer.
Using a disassembler means I am really in deep trouble. I can program in assembly, but this is backwards and you need to really understand the compiler.
As energy efficiency becomes more and more a concern for makers of electronics devices, researchers are coming up with new ways to harvest energy from sound vibration, footsteps, and even electromagnetic fields in the air.
The government wants to study your brain, and DARPA wants to use similar information to give robots true autonomy beyond any artificial intelligence developed to date. Sound like science fiction? It's not.
From Dell / Intel® New Paradigms in Design Work Scott Hamilton, vertical market strategist for Dell Precision workstations, 5/2/2013 3
Early in my career, I worked as a draftsman and remember the days of drawing on vellum with numbered pencils and Mylar with plastic lead. This was a fun experience in the sense that I ...
I've been using workstations for more than 10 years and love finding ways to get more performance from my system. With demanding professional applications that require more power each ...
A lasting memory from my first job as an engineer in an auto assembly plant is standing on hard concrete at six in the morning, vending-machine coffee clutched in hand, listening to ...
A quick look into the merger of two powerhouse 3D printing OEMs and the new leader in rapid prototyping solutions, Stratasys. The industrial revolution is now led by 3D printing and engineers are given the opportunity to fully maximize their design capabilities, reduce their time-to-market and functionally test prototypes cheaper, faster and easier. Bruce Bradshaw, Director of Marketing in North America, will explore the large product offering and variety of materials that will help CAD designers articulate their product design with actual, physical prototypes. This broadcast will dive deep into technical information including application specific stories from real world customers and their experiences with 3D printing. 3D Printing is
To save this item to your list of favorite Design News content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Tweet This
1 
