9
\$\begingroup\$

I recently figured out the cause of a nasty bug I've been working on with an Atmel AT91SAM9G20 SBC running U-boot, an open source bootloader. The core of the problem was that U-boot expected the hardware to be configured differently than I had built it, so some of the device registers were misconfigured.

Now that I've figured out the problem, I need to tweak U-boot to configure the registers correctly. I can do this blindly by adding a few lines of code at the end of the program, but that's messy.

This brings me to my question: how can I figure out how U-boot works more efficiently than starting at main() and reading all possible code paths across all files? I've tried grepping around in the files and looking at the code near relevant identifiers. This has proved ineffective; it seems that most of the code is drivers for subsystems I don't care about. I actually understand how the bootloader works pretty well by now, but I'm hoping there exists a better method than my naive approach.

\$\endgroup\$
  • \$\begingroup\$ Have you tried asking on the uboot developers mailing list? \$\endgroup\$ – sybreon Dec 2 '10 at 0:20
6
\$\begingroup\$

There are several tools/strategies that might help:

  • Better tools for making sense of the source code:

    • cscope is a tool for exploring C code, it's like grep but understands syntax
    • Call graph generators to draw a picture of the function calling structure
    • Fenris looks interesting though I haven't tried it
  • Runtime analysis

    • Step through interesting sections with a debugger and analyse what's going on
    • Use gcc's instrumentation features to call a chunk of good on entry/exit of every function. eg. http://ndevilla.free.fr/etrace/
  • Writing your own mini bootloader

    • I often find that the best way to understand something is to recreate it myself

Unfortunately, there's no magic recipe which works for everything.

\$\endgroup\$
  • \$\begingroup\$ @Runtime Analysis - Not as viable on a separate embedded system, particularly when there is no underlying OS running at the same time, for example, a bootloader, which this is. \$\endgroup\$ – Connor Wolf Dec 1 '10 at 11:04
  • \$\begingroup\$ You can still step through it with a debugger as Joby suggests. Depending on the complexity it may or may not be helpful. \$\endgroup\$ – Nick T Dec 1 '10 at 16:04
  • \$\begingroup\$ Cscope is the sort of thing I was imagining. I was hoping for something a little more shiny, but it's a good start. Thanks. \$\endgroup\$ – pingswept Dec 1 '10 at 20:05
2
\$\begingroup\$

How did you configure it to build for the AT91?

The code tree appears to be designed such that any architecture specific stuff is located in the 'arch/(cpu class)/(cpu type)/...' tree. I found AT91 code under arch/arm/cpu/arm926ejs/at91... is the variant specific stuff you're looking to alter not located there? There's not that awfully much to look through in that directory, especially since almost half the files are individual AT91 variant-specific.

Sorry if this is obvious... but you didn't mention checking this.

I hadn't looked at the uBoot code tree yet, but your post scared me into doing so. A back burner project of mine involves eventually using uBoot and Linux on a custom iMX233 PCB. I'm very interested in getting this sort of feedback on how well the uBoot architecture and variant-specific stuff is isolated and how big of a pain that's going to be.

\$\endgroup\$
  • \$\begingroup\$ Yeah, I've spent some quality time with arch/arm/cpu/arm926ejs/at91/*, but thanks for the suggestion. It turns out that the code I was looking for was actually in the processor boot ROM, which only Atmel can access. The gory details are here: at91.com/forum/viewtopic.php/f,9/t,19732/start,0/st,0/sk,t/sd,a \$\endgroup\$ – pingswept Dec 1 '10 at 20:10
  • 1
    \$\begingroup\$ By the way, overall, I've been pretty impressed with U-boot. For the vast number of boards and CPUs that it supports, it's pretty well organized. The documentation is sparse, but that seems to be par for the course for bootloaders. \$\endgroup\$ – pingswept Dec 1 '10 at 20:11
  • \$\begingroup\$ @pingswept: hey, Linux on 4 layers. Nice. Maybe I should look into that chip instead of the iMX233. I was having a hell of a time trying to get my ARM + two SDRAM chips on 4 layers and shelved it to work on other projects. I'm an Altium user too. \$\endgroup\$ – darron Dec 1 '10 at 20:58
  • \$\begingroup\$ The 9G20 and the iMX233 are pretty close. I chose the 9G20 because the Ethernet MAC is built in, and the chips are a little cheaper in low quantity, but the iMX233 was a close runner up. \$\endgroup\$ – pingswept Dec 1 '10 at 22:30
  • \$\begingroup\$ Also, take a look at the Chumby Hacker Board-- might be a good place to start if you do decide to build a system around the iMX233. The Altium files are on this wiki page: wiki.chumby.com/mediawiki/index.php/Chumby_hacker_board_beta \$\endgroup\$ – pingswept Dec 1 '10 at 22:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.