Good tools or methods for understanding structure of bootloader?

Question

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.

Answer 1

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.

Answer 2

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.