/dev/random

In December last year I accidentally got my hands on a Samsung H1, introduced as one of the first two phones supporting Vodafone's 360 platform. While neither the platform, nor the software stack it ships with (Linux Mobile, aka. LiMo on top of the Linux v2.6.24.7 kernel with a Samsung/Vodafone topping) have been able to convince me, what's under the hood actually is quite interesting.

Specs

• TI OMAP3430 application processor, TWL5030 companion chip, Qualcomm MSM6290 baseband
• 256 MB RAM, 512 MB OneNAND, 16 GB moviNAND and a MicroSD slot
• 3.5" AMOLED touchscreen
• TI Wl1271 802.11 b/g/(n) + Bluetooth 2.1+
• Two camera's, one Fujitsu 5 MP sensor on the back, Samsung VGA camera on the front
• Accelerometer, haptic feedback and eight buttons

Full (and much more detailed) specs can be found on the wiki.

Bricking it

Although the stock firmware runs a Linux kernel and userland, no shell or anything remotely useful is accessible via USB or WLAN. Having the ultimate goal of running my own up-to-date kernel I spent some time reversing the phone's bootloader in late December. What at first sight looked like the holy grail (code execution at  the bootloader level by (ab)using a mechanism used to write new firmware to NAND) turned out to be a huge pitfall as I overlooked a flag set to instruct the bootloader to re-create the partition table. This rendered the low level bootloader unable to load the secondary bootloader (which initializes 95% of the peripherals and provides the only means of recovery). The next two and a half months it served as an excellent paperweight whilst waiting for some goodies to arrive (summary: custom board adapter, one incompatible JTAG emulator and customs delays).

Fixing it

Using JTAG I managed to re-write the partition table, and thus revive the phone. In the meantime I had been working on adding board support code to U-boot and a less archaic revision of the Linux kernel (v2.6.33) (based on the source released by Samsung). Both turned out to run reasonably well after some fine tuning. Fast-forward a couple of weeks of off and on hacking, I managed to hack together support for a few peripherals as well.

Current state

Up until now quite a few people have been hopping by on IRC (#h1 on Freenode) showing interest in my effort. Unfortunately I've written every single line of code by myself so far (with support of a few regulars at #h1, which I do very much appreciate). I'll happily continue to spend my spare time on adding support for missing features and improving exisisting ones, but having others involved makes things go a lot faster, and it might just motivate me a bit more as well.

What we currently have

Odin

• An image loader which speaks the Samsung bootloader protocol. Allows for easily loading U-boot and a custom kernel from the phone's "download mode".
• Named after the protocol, as I haven't been able to come up with a proper name. Not to be confused with a leaked flashing tool which goes by the same name..
• Source can be found in my git repository

U-boot

• Based on U-boot's git master from January with some minor modifications and board support code for the H1.
• Source can be found in my git repository

Linux kernel

• Board support code based on v2.6.33. A kernel newbie's attempt at writing board support code.
• Nearly all OMAP3430 features are supported as they're in mainline (e.g. USB OTG)
• A functioning display, sound (earpiece, speaker and headphones through MAX9877 amplifier), bottom LED and keys.
• A basic Synaptics RMI4 touchscreen driver
• Source can be found in my git repository

Android

• A proof of concept (not as smooth as it could/should be, and lacking about everything except a working display and touchscreen).
• Needs lots of work and other patches (apart from kernel support) to make it remotely useful.
• I can push the relevant trees to my git repository if anyone's willing to contribute..

What we don't have

• WiFi #1: Nokia's Wl1271 SDIO driver from wireless-testing works but is extremely unstable due to some SDIO oddities. Having no datasheet for Wl1271 doesn't help much either.
• WiFi #2: Wl1271 support for v2.6.32 by TI scheduled for Q2 2010.
• Baseband: phone communicates with the baseband over dual-ported RAM ("dpram"). Needs lots of reversing engineering of the stock OS implementation.
• Accelerometer: datasheet is available, should be easy to add.
• Ambient light/proximity sensor: as above, though only Samsung's implementation can be used as a reference.
• Camera (CMOS/VGA): only Samsung's driver can be used as a reference, requires OMAP3430 camera support for the kernel (not yet supported in mainline).]
• Anything I forgot

Who cares?

I honestly wouldn't know. Perhaps:

• Those considering buying a beagleboard, and willing to drop the HDMI and a serial port for a smaller form factor, a case, much more memory, embedded sound and a really nice display.
• Someone affiliated with FreeSmartPhone/OpenMoko perhaps. Apparantly some are hacking the Palm Pre for it - Samsung H1 might have better hardware.
• Anyone not afraid of Linux kernel code and/or reverse engineering, currently in possession of the phone. Stop hiding and show yourself..

As a closing remark I can only strongly suggest buying another phone if you're looking for a (real) smartphone. You may be able to find it relatively cheap on your local craigslist though (listed for < 130 eur, but as there's no real demand for the phone I can imagine a cheaper deal being possible too)

I might write another post on actually getting Angstrom or Android (proof of concept) running on the phone. Anyone interested?

I'm still sticking around (with some regulars) on Freenode (#h1). Hop along, we don't bite (hard).

Note: See the update at the bottom of this post, which may remove the need for an external power supply.

In a previous post I described how to create a serial cable to be able to communicate with your iPod. Now this is great, but getting a microcontroller to do the same allows you to create accessories for your iPod which add extra features. For example you could turn your iPod into a TV remote, add GPS, or create a dongle which is able to perform the arm7_go exploit required for the (only publically available) iPod 2G jailbreak, redsn0w. Throughout this post I will be referring to the previous tutorial, so make sure you have read it, even if you don't need a serial cable (having one is recommended, though).

It is by no means a complete howto on creating a portable dongle solution, but it will provide a sample implementation which is able to boot a redsn0w prepared iPod without the use of a PC. With a little (electronics engineering) creativity an avid tinkerer might be able to turn it into something one can actually carry around.

You will need to prepare your iPod by installing redsn0w, as well as preparing the arm7_go exploit commands in an iBoot environment variable for easy execution. Preparing your iPod is outside the scope of this tutorial, but hints on doing so can be found at the Dev Team wiki.

Components

The microcontroller used in this example is Atmel's ATtiny2313, as it's cheap, easily obtainable, and has a hardware USART which makes setting up a serial connection a breeze. Last but not least, there's a port of GCC for AVR, so you're able to compile C code for AVR microcontrollers on all major platforms. If you're already familiar with eg. PICs, you can of course use one of those, but the microcontroller pinout and example code will be quite useless.

Just like in the previous tutorial, you will need an iPod dock connector (or PodBreakout for easier soldering) and a 3.3V power source. Ideally a dongle would be powered by the iPod itself, but some testing shows that the VCC pins are only powered when the Apple OS boots - the exploit needs to be performed before that, so the VCC pin cannot be used. As an alternative you can use a wall adapter and a few batteries together with a LM1117-3.3 until someone comes up with a better solution. Refer to the previous post for more information on where to get the dock connector and how to build the LM1117-3.3 power supply.

You will need at least the following parts:

• An ATtiny2313
• An AVR programmer
• iPod dock connector
• 470KΩ resistor
• 3.6864Mhz crystal
• 2x 22pF capacitor
• A soldering iron, tin, a piece of prototyping board, some wire and preferably a breadboard for easy testing.

Optional (and recommended):

• A serial cable which supports 3.3V TTL to be able to individually verify whether both your iPod and AVR's serial interface works. You can use a FTDI USB serial TTL module (available at the FTDI shop, Sparkfun or eBay) or follow the previous tutorial to build a MAX3232 based converter (serial port required).

If you do not have an AVR programmer yet, you can either buy a preassembled one (USB, serial or parallel) or simply build one yourself. A DB25 connector, four resistors and some wire is all you need for a (working) AVR parallel programmer. A nice schematic can be found here. You can either program the AVR out of circuit, or add a header/socket suitable for your programmer and program the AVR in-system (ISP). Commonly a 6 or 10 pin connector is used for the ISP, as shown below. Page 2 of the ATtiny2313 datasheet describes the corresponding pins on the microcontroller itself.

The 470KΩ resistor is required to enable serial communication on the iPod side. Once again, you can find a more detailed pinout of the dock connector (as it's used in this guide) in the previous post.

As the serial protocol requires very specific timings, the internal oscillator of the AVR might be too far off (it can have up to a 10% error according to the datasheet). Using an external crystal solves this problem, especially when a specific frequency is used which is in sync with all common baud rates. While you may have some succes running the USART at 2400 baud using the internal oscillator, iBoot uses 115.200 baud, at which it certainly won't work correctly. You can find a neat overview of error percentages at specific frequencies/baud rates here. We will be using a 3.6864Mhz crystal, but you could replace for any other value with a 0% error rate at 115.200 baud (Atmel recommendeds a 2.0% max error). Be sure to stay well below 13Mhz, as this is the maximum frequency the ATtiny will operate at using a 3.3V input voltage.

Building

Putting everything together is fairly straightforward. Although the ATtiny RX to iPod TX line isn't required to make a working dongle, you'll need it if you'd like to do anything with data coming from the iPod. If you're using an in-system programmer which supplies power to the μC , make sure you disconnect the rest of the circuit (the iPod dock connector) to avoid frying your iPod - most ISPs supply 5v. The 3.3V power supply (used for normal operation) should work fine for programming as well.

Software

The example program allows the ATtiny to boot your iPod using the redsn0w exploit. To allow for easier verification of a correctly working micrcontroller (e.g. by connecting it to your computer using a serial cable) 'run rs\n' is sent every second in an infinite loop.

You can program the AVR using avrdude on any platform. The code may be compiled using avr-gcc. If you're using Windows, you should install WinAVR, which includes a nice editor (Programmer's Notepad) as well as a compiler and avrdude. Linux users probably have a package for avr-gcc and avrdude in their distro's repositories.

A download link is provided at the end of this tutorial. Included is the code, a Makefile and the program in (compiled) intel .hex format (for a 3.6864Mhz crystal). You can either open the included project in Programmer's Notepad (on Windows), and program using Tools > [WinAVR] Program or on any other platform simply cd to the directory and issue a 'make program'. Be sure to edit the Makefile first, especially paying attention to the AVRDUDE_PROGRAMMER and AVRDUDE_PORT variables. The settings can be left unchanged if you built the parallel programmer to which I've provided a link before. If you're using a different crystal you should change the F_CPU variable and recompile before programming.

Fuses

Atmel allows you to reconfigure several AVR device settings by setting so-called fuses (they're not actual fuses, but simply bits stored in flash). The factory default fuse settings tell the ATtiny2313 to use the internal RC oscillator as a clock source (controlled using the CKDIV3..1 bits), divided by 8 (by enabling the CKDIV8 bit). The internal oscillator runs at 8Mhz, which results in a 1Mhz clock when divided by 8. We will have to change the fuse bits so the external 3.6864Mhz crystal is used instead. Avrdude can modify the fuses for you, by running the following command:

avrdude -c pony-stk200 -p attiny2313 -P lpt1 -U lfuse:w:0 xEC:m -U hfuse:w:0xDF:m

This writes the correct lfuse and hfuse bytes for use with our crystal (and disables CLKDIV8). If you're using a different programmer, adapt the -P and -c option accordingly.

To obtain a nice list of all supported programmer types, run:

avrdude -c ?

For a full overview of all fuse settings, take a look at the ATtiny2313 datasheet.

Testing

Having built the circuit, programmed the software and fuses you should be all set up. Power on your iPod and enter recovery mode. Then insert the dock connector, and the iPod should boot the jailbroken Apple OS. Mission complete.

You can download the example code and Makefile from: http://pargon.nl/iphone/files/ipt2g_rs_dongle.zip

Update: It was previously suggested to me that pin 27 is +3.3V, but I did not find anything on my iPod (which is a 1G). MuscleNerd was kind enough to check both his 1G and 2G, and was able to confirm that USB D+ (pin 27) is powered only on the 2G (thanks!).

You may be able to power your microcontroller from it - thus removing the need for the LM1117-3.3 and external power source, although I'm not sure whether Apple intended it to be used in that way.

This is a tutorial on how to create a serial cable for use with your iPod Touch or iPhone (usable for iBoot tinkering, iPhonelinux/OpeniBoot debugging etc). To communicate with the UART of your iPod, you will need a device which can operate at serial TTL levels.

FTDI USB solution

FTDI creates chips which support either 3.3V or 5V serial TTL level communication.  This is probably the most simple (and relatively inexpensive) option, and a must if your computer doesn't even have a serial port anymore. You can either buy a cable featuring one of these chips directly from the FTDI store (around  sixteen british pounds), or grab a conversion board from  Sparkfun or eBay. All of these converters can be conveniently plugged into a USB port, and drivers are available for Win/Linux/Max.  Of course you will still need the iPod dock connector and a few tiny bits to connect it to your FTDI cable/board (make sure you have a converter which supports 3.3V TTL).

Serial port (RS232) solution

If your computer still has a serial port (many recent motherboards do not, being largely replaced by USB) and you're feeling adventurous, you can use this instead of the FTDI solution. A computer's serial port however, uses RS232 standard levels (as opposed to TTL) - this means there may be voltages up to 15V present on the serial lines, enough to smoke your iPod. To convert this down to levels suitable for your iPod, you will need a RS232 to TTL level converter, ie. the MAX3232. Note that the MAX232 might also work, depending on whether the iPod is 5.5V tolerant (the extra 3 in MAX3232 indicates it's a model which supports 3.3V). I haven't seen anyone report either succes or failure, so get a 3232 to be on the safe side.

Components

You'll need at least the following parts for the cable:

• A DB9 'serial' connector
• MAX3232 or compatible clone
• Five 0.1μF capacitors
• iPod dock connector - available at Sparkfun, Ridax or Qables
  
• 470KΩ resistor
• LM1117T-3.3 voltage regulator (requires two 10μF capacitors) together with a 5V - 10V DC power source (wall adapter/batteries) - or any other 3.3V power source
• A soldering iron, tin and some wire to connect everything together

The MAX3232 seems a little harder to obtain than it's bigger brother, if you really cannot easily get it then you can sample it from Maxim (but please, do not abuse). You can also omit four of the 0.1μF capacitors if you can get your hands on a MAX3233 (which is also alot more expensive).

Warning - the iPod dock connector has a quite small pitch. It's however not impossible to solder, especially if you clip off all unneeded pins. In case of doubt you should consider getting a PodBreakout instead. (Another warning here: the podbreakout pinout might not match the pinout as I provide it in this tutorial. Please tell me if you know.)

Also, if you're only interested in using the serial port while the actual iPod/iPhone OS is up and running, you can omit the 3.3V power source, and instead draw power from pin 18 of the iPod dock connector (fig. 1) - it's not enabled until the OS loads, thus not usable if talking to iBoot is your goal.

If you're taking the FTDI route all you really need is the dock connector and the resistor.

Building

Having gathered all components, it's time to heat up your iron (or even better, dig up your breadboard as well). The serial protocol requires three wires on each end - TxD, RxD and GND. Additionally you will have to connect the resistor from pin 21 (accessory detect) to ground (pin 1)  on the iPod dock connector end - the iPod uses specific resistance values to identify the accessory connected. The 470KΩ resistor will enable the UART.

The following image provides an overview of the iPod dock connector pins, looking at it from behind (that's where you'll be soldering).

Solder wires to pin 1, 12 and 13 of the dock connector (so you can easily plug them into your breadboard) and add the resistor. Proceed by soldering three wires to the DB9 connector (see fig. 2). Now you're able to hook up both the iPod and DB9 connector to your breadboard, it's time to add the MAX3232. Use the schematic below (as well as the MAX3232 datasheet) as a reference. The VCC and GND pins of the MAX3232 are shown separately, as well as the LM1117-3.3 voltage converter (Vin should be +4.75V to +10V, Vout will then be the 3.3V you need for the MAX3232).

Testing

Once you're sure you've got everything right, first enable iBoot UART debugging using iRecovery if you haven't done so yet. Connect the iPod via USB and launch a shell using iRecovery -s and enter setenv debug-uarts 1 followed by saveenv.

Now you may connect the iPod to your serial dock connector (if it's off, it should turn on due to the accessory detect resistor). Fire up your preferred terminal program (Putty, Minicom, etc). Disable parity and flow control, and set the speed to 115200 baud, 8 data bits. Now restart the iPod and enter recovery mode, and if everything went well you should get the iBoot shell on your serial connection. Congratulations.