Most of the "guides" for rooting the Droid involve manually downgrading from 2.1 to the older 2.0.1 (including radio baseband downgrade), then rooting from within 2.0.1, then flashing a newer system and radio baseband to get back up to 2.1. This is silly, in my opinion. A much better method is to directly flash a rooted "stock" 2.1 image onto the phone with no baseband changes, and then install the alternative 2.1-based build of your choice in a smoothly automated fashion from within the rooted-stock 2.1. So, let's do that.

I have made a few useful notes on the Android system architecture and on CyanogenMod, which I've included at the end. If you're a person that thrives on in-depth "big picture" information, skip to the end and read those bits, then come back and proceed.

The Very Short Story of what we'll accomplish:

1. Overwrite stock system with modified stock system using RSD Lite.
2. Install modified su for full superuser (root) permissions using SPRecovery.
3. Install Clockwork Recovery using RomManager.
4. Install CyanogenMod in an automated fashion using RomManager and Clockwork Recovery.
5. … steal underpants?
6. Profit!

Without further ado… here is Porter's Guide for Root and CyanogenMod on the Motorola Droid.

• Note:  This guide is loosely based on radar3d's "How-To Root your stock 2.1 Droid" guide on DroidMod, but I've simplified it significantly and added a bunch of CyanogenMod-specific info, and in the process hopefully improved the readability. Thanks to radar3d for the original info. The link has some screenshots that may be helpful to you, so refer to it if needed.
• Note:  This assumes use of Microsoft Windows for the first steps, because RSDlite (the Motorola service utility) only runs on Windows currently. Everything else in the guide is platform-agnostic. I'm a die-hard Ubuntu user on the desktop, so using Windows was painful for me too. Solidarity, folks… we'll get through this somehow!
• Note:  This will wipe your phone, so you will need to reinstall your apps. Sorry. You have good backup options available once you're running CyanogenMod, but you really don't on standard Android. So make a list, or use AppBrain and copy the list from there, if it's important to you.
   

Step 1:  Preparation

• Make sure you have an SD card with at least 2GB free in the phone, preferably 4GB+ free. It comes with a 16GB card, so I don't know how you might end up without any room available, but it's worth saying.
• Charge the phone to at least 80%, just to be safe.
• Download and install RSDlite 4.6 (the Motorola service utility) from the web:
  http://www.mediafire.com/file/cycwzg0j15b/RSDLite4.6.msi
• Download and install the Motorola USB drivers (32 bit or 64 bit as applicable):
  http://www.mediafire.com/file/gtgjmv4z3qq/USB_Drivers_32_bit_4.2.0.zip
  http://www.mediafire.com/file/eznivjnzmml/USB_Drivers_64_bit_4.2.0.zip
• Download [mbm]'s modified 2.1 sbf (system) file from Droidmod.org:
  http://www.mediafire.com/file/fpkzlmxzywr/SPRecovery_ESE81.sbf
• Download the superuser permissions update (su):
  http://www.mediafire.com/file/kjm5nzcgmmu/20100429h_update.zip
   

Step 2:  Loading Stock 2.1 (with root)

1. Connect the Droid via USB to prompt the drivers to load. Once fully connected/loaded (for Windows' benefit), disconnect again and power off the Droid.
2. Open RSDlite and select the sbf file you downloaded.
3. With the Droid keyboard open, hold the Up direction on the d-pad and connect the USB cable. The phone should power on by itself.
4. Continue holding the D-pad until you see
   Battery ok
   OK to program
   USB
5. Then in RSDlite, you should be able to see the Droid in the connected devices list that occupies the bottom half of the interface. If not, check the settings, I had to switch the DeviceId mode to "First Come First Serve" for it to detect and use my Droid properly. Also, you should be able to see populated information in both the "device" and "file" panes on the left and right of the top half of the interface.
6. Click Start and the new 2.1 image will transfer to the phone. The phone will then reboot on its own.
7. Close out of RSDlite once the phone reboots, and IGNORE the dire warnings about your device catching on fire if you close the window. RSDlite just gets confused for some reason when a connected device reboots, it's nothing to worry about. Also, don't worry about backups now, we will do that soon.
8. Rename that 20100429h_update.zip file that you downloaded to update.zip and place it on the root of your MicroSD card. Once installed, this will give us superuser permissions, aka "root".
9. Turn off the Droid and then reboot while holding the x button on the keyboard until SPRecovery starts.
10. Scroll down and select Install. Then click Allow update.zip from sdcard. Then click Apply update.zip from sdcard. The options may have changed slightly in the new SPRecovery, but you get the idea. Select Reboot to continue.
     

Step 3:  Installing RomManager, flashing ClockworkMod Recovery, and upgrading to CyanogenMod
(this is where we fully diverge from the guide that I linked earlier)

1. Add your primary Google Account to the phone per the normal method – this is so we can get into the Market. There's a manual way to do this install, but the Market makes it much simpler so we'll do it that way.
2. Definitely turn on WiFi, don't rely on the 3G network… there's lots of data coming shortly.
3. Search for RomManager on the market (vendor is "ClockworkMod") and install it. Don't worry about the Premium version now, that's just a license anyway… though you will probably feel compelled to purchase/donate later!
4. Open RomManager and flash the latest ClockworkMod Recovery (very first menu option). This is a more advanced recovery-partition utility than the SPRecovery you used earlier, and replaces it. RomManager may prompt you to do this automatically.
5. Now click on Download ROM. Then click CyanogenMod. Select the latest, which at the moment is 5.0.8 but may be 5.0.8.1 etc by the time you do this. Make sure you check the box for Google Apps when prompted. CyanogenMod and the Google Apps package will begin downloading to your SD card in the background.
6. IMPORTANT STEP!! - RomManager will prompt you automatically once the ROM is downloaded. Make SURE you check both the BACKUP and WIPE options. Backup is important for you in case of any trouble, it will store in the universal Nandroid format. The Wipe is important for system health… leftover cruft from your previous (stock) system can cause really bizarre errors and behavior, so do yourself a favor and wipe when installing.
7. The system will reboot into Clockwork Recovery automatically and begin automatic backup of the system to the SDcard in Nandroid format. Nandroid is a universal format that can be used to restore your system to pre-CM form using any of the various recovery tools available.
8. After the backup, Clockwork will automatically install the CyanogenMod system and will reboot.

Congratulations! You now have CyanogenMod on a Motorola Droid.
 

Step 4:  Post-Install Stuff:

• RomManager - CyanogenMod comes with RomManager preinstalled but it is rarely the fully current version. Always go to Market and download the latest one as the first step after install. This will bring RomManager current and prompt to reflash Clockwork Recovery again, which is necessary to tie the two together for seamless operation.
• Kernel Stuff - To maximize performance and battery life, even for very conservative users, I recommend the use of the optional bekit low voltage kernels combined with the SetCPU utility to manage the behavior of the native linux clock governor. The bekit kernels are easily installed using RomManager, they're found under Download ROM -> CyanogenMod -> bekit Kernels. I happen to use the bekit 800mhz 5-slot Low Voltage kernel, myself, though you may have good results with one of the others. Every Droid is apparently slightly different in terms of what it can be overclocked to reliably, and at what voltage, but I've been led to believe that the 800mhz low voltage 5-slot version works well on all of them, so it's quite safe.
  The SetCPU utility can be purchased from the Market (about $2 I think?) or can be downloaded for free for manual install from the XDA Developers forums. You'll need a file manager utility like Astro to install it manually, or use adb from the command line if you know how. It's worth mentioning that you shouldn't install a high-clock kernel and try to depend on SetCPU to keep the speed down for you, because when you attach the phone to a full-current wall charger the kernel will automatically bump to autoclocking between the highest three speeds available.
• Radio Baseband - There are new radio baseband versions available (from Verizon Froyo tester phones) that work well for CyanogenMod 5.0.8+, and will be required for Froyo anyway. The standard radio baseband on Droid 2.1 is C_01.3E.03P. You can upgrade via RomManager to the latest, but you will need to do it in two steps, first to C_01.41.00R and then to C_01.43.01P. Don't be alarmed if one of the install packages gives you an error, it's just a packaging thing from another project. Installing the newest baseband improves connection stability and voice quality, but will require you to reactivate the phone with Verizon each time (by calling *228, then option 1).
• Launchers - The stock launcher (GUI shell, gives you the home screens) in CyanogenMod 5.0.8 is called ADW, which is a separate project that's available as an installable launcher for other builds, including stock. It is essentially a fully customizable version of the stock launcher, allowing you to customize the number of home screens and gives all sorts of fine control over specific UI behavior. There are other launchers that have significant merit (such as LauncherPro, which I was using on CM builds prior to 5.0.8) but now that ADW is fully integrated in CM it's really a no-brainer.
• Tethering - Wireless Tether used to be integrated by in CM default, but since the developer is improving the tool all the time, and it runs as a standalone app anyway, it's now available as a free app on the Market. Install it and enjoy. USB and BT tethering is integrated into CM as part of the system but there's a small bug with permissions on the feature that won't be fixed until 5.0.8.1. Instead, you can install the "app" version of the feature directly using the .apk from the developer's project site. It works perfectly and provides native USB "ethernet" emulation, which will be detected and used automatically on most PC platforms. Turn on "Unknown Sources" in the Settings -> Applications menu and install using a file manager (like Astro) or from the command line using adb. Both Wireless and Wired tether apps provide full NAT and DHCP for connected devices.

I'm sure there's more, but I can't think of it at the moment. Let me know if you have any questions! And best of luck.
- Porter

APPENDIX:

Brief notes on Android system architecture:

This bit was important for me to understand so I figure it might be useful for you as well. Android has a rather interesting system architecture, involving a fairly standard linux filesystem structure on the primary system partition (as one would expect) as well as a hidden recovery partition that contains a full original copy of the base system for critical-recovery purposes. The "userspace" filesystem view is locked to the user's home folder, it's essentially a fairly standard linux chroot jail that functions as the "contents of the phone" from the user's point of view. Basically, what you see on the phone's memory from the normal run state is the contents of your Home folder. On the Motorola Droid the SDcard itself is actually used as the user's Home folder, but on other phones (like the HTC Incredible, for example) the user Home is on internal storage and the SDcard is treated simply as removable storage. Up-level from the user folder, there is the rest of the system partition (root filesystem space) which is normally both invisible to the user and read-only. You can see the full filesystem from some File Explorer apps, but you can't modify it.

There is a "recovery" boot mode, that is analogous to a BIOS-level system restore app. The recovery mode can restore the Android system completely from the recovery partition in the event of a major problem, or optionally can overwrite the recovery partition and/or system partition from a downloaded update. This is essentially how OTA upgrades work, the system update utility (in the Settings menu) compares the OTA-available image to the hidden recovery image, and downloads the new version to the SDcard if applicable. System updates are always saved to the root of the user's home folder (sdcard on the Droid) as "update.zip", which you'll also see used repeatedly for manual loading of just about anything you can think of to the phone. The stock 2.1 system only allows fully signed update.zip images, but the modded 2.1 system we will load allows unsigned images to be loaded freely, which is the critical thing. The recovery mode app itself can (and should) be replaced by significantly more capable alternatives that do a variety of backup and recovery tasks, such as SPRecovery (older) or Clockwork Recovery (newer). There are also other options out there, but those are the two most commonly used.

There is an important command-line utility called adb that is included in the downloadable Android SDK. It allows you to do all sorts of interesting things with attached Android devices, but most importantly for most users it provides direct shell access to the device in similar fashion to ssh. There are plenty of guides online for configuring and using adb should you feel the need. The Android SDK is freely available for Windows, Mac and Linux.

Brief notes on CyanogenMod:

Unlike many of the "alternative rom" software mods that are common in the mobile device space generally, CyanogenMod is not a hacked manufacturer-sourced or carrier-sourced ROM. It is not the product of a "leak", or of stolen/pirated IP, or anything else that could be construed as improper or even undesirable. In fact, it is not the product of any kind of amateurish hackery whatsoever. Instead, the Cyanogen team approached Android using the same philosophy as building a custom linux distribution in the traditional fashion, as a fork of the upstream project. Their objective is to produce a very "standard" open-source build of the Android OS, without any flashy or unnecessary cruft. They do include some additional optimizations and significant features over standard Android, but generally the aim is to provide a feature-complete Android system in a state that would be completely appropriate as a default build on any carrier's device.

CyanogenMod is entirely based on and built from the open Android sources (from source.android.com). They sync with the upstream codebase on a regular basis (much more regularly than the manufacturers) and where appropriate they contribute their optimizations and fixes back upstream to Android. To stay fully licensing-compliant, the Google Experience apps are provided as a separate installable package and are completely unmolested. The default kernel in CyanogenMod is a highly optimized "bekit" Android kernel, built by Brint Kriebel, who is coincidentally one of the primary developers for Ubuntu.

Any way you slice it, this is not the bullshit ROM hackery we've all come to know and expect on mobile devices, for example from the usual knuckleheads on HowardForums. This is responsible development done in the open with a proper git repository and full community code vetting. Their shit rocks. They've fully replaced (and in my opinion, significantly improved upon) the development and platform customization done thus far by Motorola and HTC on their own builds, and they integrated them together into a universal build that runs on both platforms. That's not a small accomplishment.

The new version is (finally) able to fully harness the wide dynamic range and huge color space of the Foveon X3F output and allow some really compelling photographic results from the sensor.  It is also now capable of directly outputting full-gamut ProPhotoRGB colorspace images in several formats including 16-bit TIFF, which is fantastic if the next step is a ProPhoto native tool like Lightroom or PS CS4+.  Take a look at an example of the kind of conversion control this thing can do, in this case using a very overexposed shot in hazy conditions…

 

Now, obviously this is in the middle of workflow and would have actual editing to do as the next step, but for a "digital developer" app preparing files for Lightroom or Photoshop, this thing has chops.  Definitely enough to make the camera itself a more capable, compelling tool for creative work.  The release of the new SD15 camera is a nice thing, but really the biggest improvements to the platform have been made in the post-process software.  It's enough of an improvement in terms of usable output that it will likely have me revisiting a bunch of my older raw images to make (much!) better gravy out of them.  I'll have to start shooting again in general to make that matter at all (har har) but I foresee having far less frustration with it in future.

Great job, Sigma.  Keep up the good work!

Dear Mr. @@@@,

Thanks for taking the time to speak with me today.  As we discussed, I have made a few small discoveries since our original discussions several months ago, that may shed some light on the red channel overexposure that I have experienced in certain situations using my SD14.  Rather than a capture problem in the camera, I have discovered that the issue may be related to the color-space conversion performed by the Sigma Photo Pro software during X3F import.

I have attached two versions of an image, one that illustrates the color issue that I have experienced in scenes that push the limits of the color space (gamut) used in the current Sigma Photo Pro 2.5 software. The difference between these images is obviously intended to represent a worst case scenario, so please don’t regard the “original” over-saturated image as the work of a talentless hack — it is purely for illustration purposes!

Click to read on –>

1) The “original” image is of a red flower, shot at ISO 50 using the 1.07 firware in my SD14.  This sample image is a direct, zero adjustment 16-bit TIFF export from SPP 2.5, that I have cropped and saved to JPEG (sRGB) using Photoshop with no other adjustments.  Illumination of the original scene was by direct afternoon sunlight, and exposure was spot-metered directly on the brightest surface of the flower petal area. There is no orange whatsoever in the original scene… the flower was purely red.  As you can see, the red channel is completely overexposed across the surface of the petals, and the “orange” areas that appear in the shot seem to be due to green-channel information creeping in through some type of color conversion error.  No combination of adjustments in SPP were able to bring the red channel overexposure into control in a way that was usable as a final image.  The detail is simply “gone”, as you can see:

2) The “new method” image is from the same source file.  Rather than using SPP, I extracted and converted the raw data section of the X3F file to uncorrected 16-bit TIFF using a very clever and useful utility, which was coded for that purpose by an SD14 owner named Pavel Sokolov.  The uncorrected TIFF is very dark, so I brightened it using the Auto Curves function in Photoshop, then made a simple correction to color using the Hue center and Saturation controls, and finally cropped and saved it to JPEG in the sRGB color space.  Using this simple extraction utility, all of the detail in the source file was preserved, and the red-channel oversaturation experienced in Photo Pro was not a factor at all.  The results speak for themselves.  Obviously it’s not a great photo to begin with, but these results are MUCH better than what is possible with SPP given the same source X3F file.

It’s important to note that it is possible to capture this scene without the red overexposure, but in order to do so using the standard “Sigma” software workflow, the overall exposure must be reduced (in-camera) to the point that the blue and green channels are significantly underexposed.  That is not an ideal solution.  Obviously based on these two example images, the camera *is* capable of capturing the visual information, and in fact is doing so very well… it’s just that the range of color that the camera captures seems to be well outside the limits of the Sigma software’s color space conversion capabilities.  The camera works wonderfully, and thanks to Sigma for a fantastic design… but the software could definitely be improved.

Are there plans to update the Sigma Photo Pro software in the near future?  If so, and assuming that limitations in the available output color space options themselves are part of the problem, is it possible for a larger color space (such as the excellent ProPhoto RGB) to be offered as an output option?  That change alone could provide considerable improvements to the results of color conversion at the fully saturated edge of the CIE 1931 chromaticity space.

If such a change (or some other, unrelated improvement) could help to solve the color conversion and accuracy problems that many users have experienced, it could provide both a huge improvement in workflow and in overall image quality for Sigma owners.  Even more, it could result in a potentially huge improvement in the perception of Sigma’s camera products among professional and semi-professional photographers.

I look forward to hearing your thoughts on this, and please let me know if I can provide any additional information or assistance.

Best regards,

Jason Porter
Roanoke, VA

——————–

NOTE TO BLOG VISITORS:  Further discussion of the X3F Extractor Utility is available on the DPReview forums at http://forums.dpreview.com/forums/readflat.asp?forum=1027&thread=28576411

Give me a shout if you find something good that’s SD14-related on the web, and I’ll add it to the list!

Thanks,
Jason Porter

@@@@@,

As we discussed on the phone, I am writing to document my new SD14 camera’s unusual red saturation problem and provide raw X3F samples for your review.

Before I explain, here are the details of my particular unit and configuration:

Sigma SD14
serial no. [redacted]
firmware revision 1.07

Sigma 18-50mm F/2.8 EX Macro
serial no. [redacted]

Using Sigma Photo Pro 2.5 in Windows XP, using a color-corrected display (Spyder2Express calibrated).

The problem:

I have had my SD14 for one week, and like it very much! Unfortunately, I have discovered that it exhibits some unusual behavior when capturing images in bright sunlight. This became most evident when I attempted to capture a close-up shot of a red flowering plant on my front porch. Specifically, the camera seems to hugely over-saturate reds, to the point of total saturation in the red channel at 255 (per the “loupe” feature in Photo Pro 2.5) This behavior is consistent in both Program mode and Manual mode at ISO 100. In order to bring the red saturation down to the point where the red channel ceases to clip at 255, the image must be significantly underexposed in the other channels.

What is particularly disturbing is that I am experiencing significant bloom into the green channel when I capture the same exact image at ISO 50. This occurs in areas of pure red on the subject that (when captured at ISO 100) are totally saturated at 255 red, with zero information in the green channel. When captured at ISO 50 using the same Program mode exposure and metering, the red channel is saturated at 255 and the green channel jumps to around 240 in many areas! This causes the flower to appear bright neon orange with obvious two-tone banding in the image. I can’t imagine that this is normal behavior for capturing an image of a common red flower in direct sunlight, and it was not even a particularly bright day!

I understand that ISO 50 has less “headroom” than the other ISO modes (per the note on the firmware download page), but even when using center metering directly on the brightest part of the flower petals, the saturation problem in the red channel is very much present. Also, this does not explain the green-channel bleed.

The X3F samples:

I have taken a series of raw X3F images of the red flower, for your review. If you have Photo Pro 2.5 on a Windows machine and you can use that to view these, it may be helpful so that we are comparing the same output. These images are all of the same subject in the same ambient light. All images are captured using the Daylight white balance setting on the camera, and using the 18-50mm F2.8 EX lens. I have hosted these files on my own server so that you can access them and download directly at your convenience. These are organized in folders by mode, by ISO, and by exposure.

Direct your browser to: http://jasonporter.us/photography/sigmasd14/

The first files to look at are the P mode ISO 100 and ISO 50 exposures, which are in folders marked “P_ISO100_EvalMeter” and “P_ISO50_EvalMeter”.

The P mode ISO 100 Evaluative Metering exposure (no. 182) exhibits the full red oversaturation I mentioned. The same shot taken in P mode ISO 50 (no. 183) exhibits the green-channel bleed resulting in bright yellow/orange coloration. A revised version of the ISO 50 shot using Spot Metering (no. 187) and metered directly on the red area shows the same behavior, but with slightly lower overall exposure and slightly less green channel bleed.

The rest of the files are captured in M mode to demonstrate the red channel behavior at various apertures and shutter speeds. There are two sequential sets of shots at F/2.8 and F/5.6 apertures, at a series of different shutter speeds, to show both the red channel behavior and the level of general overall green/blue underexposure required to bring the red channel into control. I have also included an F/20 1/15s shot and an F/8 1/250s shot, for reference at smaller apertures… these are both “best case” shots with the red channel just beginning to fully oversaturate.

It should be noted that if the aperture and shutter speed are reduced to keep the red from blowing out completely, the green areas and the background (and the shot in general) are significantly darker than they appeared to the eye. This subject was a balanced mixture of bright red and rich green tones. In fact, the P-mode Evaluative Metering shots that were so horribly overexposed on the red highlights are the closest to being accurate on the green background out of any of the shots, and even so, they are much darker and less saturated on those areas than they should be compared to the actual rich green color of the plant.

Thoughts:

The only clue to the origin of this odd red-channel behavior that I have come across was actually with the help of an open-source Raw converter program called UFRaw. (ufraw.sourceforge.net) It is a simple Raw-converter packge similar to Adobe Camera Raw or Sigma Photo Pro, and it supports the X3F format. Using UFRaw, there is an option available to disable the “Use color matrix” option for the input color gamut (in this case sRGB). Apparently the term “color matrix” is used in that software to refer to the color-space correction factor that is applied when normalizing an sRGB (or other) image source to the workspace. When this box is unchecked in UFRaw, some of the heavy red over-saturation decreases, and quite a bit of detail is restored. Unfortunately, no similar “feature” exists in Photo Pro 2.5. It isn’t perfect, but it is MUCH better than the default “corrected” setting, which is comparable to the look of the image in Sigma Photo Pro.

In any case, it raises the question: Is Photo Pro 2.5 applying an sRGB input gamut correction when it is inappropriate to do so?

I have checked these images on a non-color-corrected display, in order to rule out any potential problem with my calibrated monitor profile. The oversaturation behavior is consistent on all 4 computers that I have checked, including three different Windows XP systems, and an Ubuntu Linux machine using UFRaw.

By the way, I would like to be clear that I’m not naive about digital capture and the necessity of image editing… I have worked with digital workflow for quite a while and I recognize that every shot will require some tweaking to produce a quality, balanced result. With a camera like the SD14 that is designed for creative photography, that is even more true. This saturation problem, however, is not something that I can easily correct in Photoshop, and it’s not something that Sigma Photo Pro 2.5 seems capable of improving. This problem is simply blowing out all of the surface detail in the surface of brightly colored objects, and I don’t think that a 2 or 3 stop (or more) overall underexposure in the camera coupled with manually correcting the levels back up in the green and blue channels in Photoshop is the best way to achieve a professional result. Maybe I’m incorrect on that, but it’s not an approach that I have ever had to take with any other camera.

Thank you very much for your time and consideration, I know this was a long read, and I salute you if you made it through the whole thing. I would greatly appreciate your input and insight on this problem. I look forward to hearing from you.

And again, thanks for making a great product!

Best regards,

Jason Porter
Roanoke, Virginia, USA

P.S. – There is one other issue I’d like to point out, and see if you have experienced it. Some of the Raw X3F files are inexplicably much larger than others. Typical shots at 4.6mp in Raw mode are usually between 9mb and 13mb, but occasionally a file will be almost double in size. Shot number 206 in the F/5.6 set folder is a good example, the file is almost 22 megabytes! Is this a known issue with the 1.07 firmware?