Openmoko - User contributions [en]

GTA02 bass fix

2009-03-08T22:05:59Z

Warmcat: /* Rework performed by Andy Green */

GTA02 bass issues and possible ways to fix it.

The lack of bass issue has been discussed several times on Community and Hardware lists, including by [[User:jOERG|Joerg Reisenweber]] (e.g. in this mailing list post: http://lists.openmoko.org/pipermail/hardware/2008-September/000552.html , and Andy Green).

== The problem description ==
A known issue is that output decoupling capacitors are too small, only 1uF (4.7uF in v7). This results in a very high cut-off frequency practically eliminating a possibility to use freerunner as a portable musical player. The possible fix is to add some decent 100uF C in parallel. (The other discussed way to do it was to short the original caps and instead place the big ones near the headset receptable or inside the headphone jack; this has multiple drawbacks as jack insert detection might no longer work, possible damage to U4401 and the like; in this case you should also remove R4116, R4117 and place them after your caps).

=== Rework performed by [[User:PaulFertser|Paul Fertser]] ===
'''Resulting sound is good with 32Ohm headphones (AKG K-55). With proper shielding GSM interference is very low or non existent. Effect on Bluetooth range is not yet measured!''' (Due to placement of the caps next to the Bluetooth antenna, it's possible this will reduce performance there).

Here i'll try to describe my take on rework that should radically improve the ability to use FreeRunner as a portable music player.

I used two 100uF 10V tantalum caps. They should be connected in parallel to C4110 and C4111. Make sure you connect the plus terminal (marked with a thick line) to the side that goes to U4101.

The can should be lifted very carefully. Use a pin-pointed knife for that and try to lift a little in every point you can reach going in circle. After several rounds the can will be easily dismounted. It can take about 10 minutes, please be patient. You can use a plastic sim-holder for a lever, but be very careful.

To avoid interference from GSM going into the can, use a piece of aluminium foil isolated from the caps with paper. I used a candypaper and it eliminated the audible GSM interference (i could listen to GSM call via headphones on loud volume without hearing any buzz). Be sure to provide electrical connection between the foil and the can (the more points you connect, the better shielding you get; don't be shy to experiment, EMI is a black magic sometimes). Placing small ferrite bead on every twisted pair just before it enters the can is recommended.

After the rework Bass and Treble regulators in mixer should be placed at the middle as it corresponds to 0db attenuation (and the bass boost set to Linear Control).

[[Image:Can_opened.jpg|800px]]
[[Image:bass_rework_can_closed.jpg|800px]]
[[Image:bass_rework_whole_picture.jpg|800px]]

=== Rework performed by [[User:warmcat|Andy Green]] ===
This document describes another type of rework where caps are placed inside the can: http://people.openmoko.org/andy/additional-headset-audio-caps.pdf . Among its strong points is that the signal doesn't go outside the can, therefore avoiding any possibility of interference with other hardware functions; unlike the modification described above the connections to the caps are very short and no modifications are needed to the can.

[[Image:Rnsop-00002.jpg]]

[[Image:Rnsop-00003.jpg]]

[[Image:Rnsop-00004.jpg]]

The weak points are that the maximum capacity is limited to 47uF due to the size; again due to the size constraint of being in the can only ceramic caps can be used (which can distort sound because of piezoceramic properties, although for X7R dialectric the effect is minimal).

=== Untested Notes and Suggestions ===

One possible solution is to place the additional caps outside the can, near the Bluetooth antenna; the other possibility is to build a cap from 20 pieces 4.7uF along a wire grid 4x5 which makes a nice high quality very flat 100uF. This would easily fit anywhere "1.floor" of can interior, just isolate it with a scotch film patch and throw them inside the can.

Also shorting R4407 and R4405 might worth trying (as well as throwing out the useless U4401).

Another idea proposed by [[User:jOERG|Joerg]] is to perform a modification similar to the popular iPod mod:

The purpose of the diyMod is to simplify the signal path from the DAC to the amp. To achieve this goal, the audio signal is taken directly after the DAC and sent to the amp. This path must include the DC blocking, also known as coupling, caps. By necessity, we place DC blocking caps behind the DAC to protect our listening apparatuses. Ensure that nothing lies between your DAC and amp but wires and traces.

Nobody has tried to implement it on FreeRunner yet, but this description along with published schematics should be enough: http://www.head-fi.org/forums/f6/apple-diymod-my-take-famous-imod-56k-killer-featuring-3g-4g-5g-nano-1g-269604/

[[Category:Neo_FreeRunner_Hardware]]

File:Rnsop-00004.jpg

2009-03-08T22:05:29Z

Warmcat:

File:Rnsop-00003.jpg

2009-03-08T22:04:42Z

Warmcat:

File:Rnsop-00002.jpg

2009-03-08T22:03:03Z

Warmcat:

File:Rnsop00001.jpg

2009-03-08T22:02:46Z

Warmcat:

GTA02 bass fix

2009-03-08T22:00:44Z

Warmcat: Reordered tested mods first; corrections

GTA02 bass issues and possible ways to fix it.

The lack of bass issue has been discussed several times on Community and Hardware lists, including by [[User:jOERG|Joerg Reisenweber]] (e.g. in this mailing list post: http://lists.openmoko.org/pipermail/hardware/2008-September/000552.html , and Andy Green).

== The problem description ==
A known issue is that output decoupling capacitors are too small, only 1uF (4.7uF in v7). This results in a very high cut-off frequency practically eliminating a possibility to use freerunner as a portable musical player. The possible fix is to add some decent 100uF C in parallel. (The other discussed way to do it was to short the original caps and instead place the big ones near the headset receptable or inside the headphone jack; this has multiple drawbacks as jack insert detection might no longer work, possible damage to U4401 and the like; in this case you should also remove R4116, R4117 and place them after your caps).

=== Rework performed by [[User:PaulFertser|Paul Fertser]] ===
'''Resulting sound is good with 32Ohm headphones (AKG K-55). With proper shielding GSM interference is very low or non existent. Effect on Bluetooth range is not yet measured!''' (Due to placement of the caps next to the Bluetooth antenna, it's possible this will reduce performance there).

Here i'll try to describe my take on rework that should radically improve the ability to use FreeRunner as a portable music player.

I used two 100uF 10V tantalum caps. They should be connected in parallel to C4110 and C4111. Make sure you connect the plus terminal (marked with a thick line) to the side that goes to U4101.

The can should be lifted very carefully. Use a pin-pointed knife for that and try to lift a little in every point you can reach going in circle. After several rounds the can will be easily dismounted. It can take about 10 minutes, please be patient. You can use a plastic sim-holder for a lever, but be very careful.

To avoid interference from GSM going into the can, use a piece of aluminium foil isolated from the caps with paper. I used a candypaper and it eliminated the audible GSM interference (i could listen to GSM call via headphones on loud volume without hearing any buzz). Be sure to provide electrical connection between the foil and the can (the more points you connect, the better shielding you get; don't be shy to experiment, EMI is a black magic sometimes). Placing small ferrite bead on every twisted pair just before it enters the can is recommended.

After the rework Bass and Treble regulators in mixer should be placed at the middle as it corresponds to 0db attenuation (and the bass boost set to Linear Control).

[[Image:Can_opened.jpg|800px]]
[[Image:bass_rework_can_closed.jpg|800px]]
[[Image:bass_rework_whole_picture.jpg|800px]]

=== Rework performed by [[User:warmcat|Andy Green]] ===
This document describes another type of rework where caps are placed inside the can: http://people.openmoko.org/andy/additional-headset-audio-caps.pdf . Among its strong points is that the signal doesn't go outside the can, therefore avoiding any possibility of interference with other hardware functions; unlike the modification described above the connections to the caps are very short and no modifications are needed to the can.

The weak points are that the maximum capacity is limited to 47uF due to the size; again due to the size constraint of being in the can only ceramic caps can be used (which can distort sound because of piezoceramic properties, although for X7R dialectric the effect is minimal).

=== Untested Notes and Suggestions ===

One possible solution is to place the additional caps outside the can, near the Bluetooth antenna; the other possibility is to build a cap from 20 pieces 4.7uF along a wire grid 4x5 which makes a nice high quality very flat 100uF. This would easily fit anywhere "1.floor" of can interior, just isolate it with a scotch film patch and throw them inside the can.

Also shorting R4407 and R4405 might worth trying (as well as throwing out the useless U4401).

Another idea proposed by [[User:jOERG|Joerg]] is to perform a modification similar to the popular iPod mod:

The purpose of the diyMod is to simplify the signal path from the DAC to the amp. To achieve this goal, the audio signal is taken directly after the DAC and sent to the amp. This path must include the DC blocking, also known as coupling, caps. By necessity, we place DC blocking caps behind the DAC to protect our listening apparatuses. Ensure that nothing lies between your DAC and amp but wires and traces.

Nobody has tried to implement it on FreeRunner yet, but this description along with published schematics should be enough: http://www.head-fi.org/forums/f6/apple-diymod-my-take-famous-imod-56k-killer-featuring-3g-4g-5g-nano-1g-269604/

[[Category:Neo_FreeRunner_Hardware]]

Qi

2009-02-19T07:27:19Z

Warmcat: /* Booting */

[[image:Screenshot-Qi.png|frame|Qi Boot messages]] Qi is a lightweight replacement for the [[Uboot|uBoot]] bootloader with everything that doesn't assist "loading" and "booting" Linux stripped out.

Its advantages comparing to [[Uboot|u-boot]] are:
* actively developed (u-boot on GTA02 is deprecated)
* easier configuration, more robust and predictable
* SD and SDHC cards supported properly with partitions of any size
* kernel size is detected by checking the start of the kernel image, so large (>2M) kernels are supported without tweaking or loading more than needed
* Very fast, simple boot direct to Linux

==About Qi==
===Requirements===
There is a [[Neo1973|GTA01]] build of Qi, but using it without a debug board is not recommended because Qi itself does not support DFU, so updating or going back to U-Boot is a difficult process.

[[Freerunner|GTA02 Hardware]] has NOR U-Boot always available to update Qi so it's safe to try it out.

===Features===
* booting from primary SD partitions (1st, 2nd or 3rd) in /boot directory
* booting from NAND (compatible with U-Boot's dynparts scheme)
* configuration per rootfs, by files in /boot in the rootfs
* automatically choose correct kernel for device hardware so rootfs can be used on multiple device types
* automatically tell kernel correct root= for rootfs kernel image came from, simplifying update
* ext2/3 are supported
* symlinks are supported
* parses identity partition and appends kernel commandline with device identity information
* zero "environment" or private persistent state - operation is completely deterministic

===Limitations===
* no DFU-Mode - USB is not initialized at all
* no boot menu
* FAT partitions are ignored

Both the lack of DFU and the boot menu are planned to be addressed by the backup / recovery rootfs.

FAT is not supported because it can't provide a rootfs, and Qi wants the kernel to come from the rootfs.

===Defaults===
If the kernel is found on uSD, Qi assumes the rootfs to be on the same partition as the kernel. In case of boot from NAND, it assumes that rootfs is also on NAND (just as u-boot does). See [[#/boot-Partition|below]] for help with an extra /boot-partition. The default rootdelay is 1 second.

===Files===
; /boot/uImage-GTA0[123].bin
: Kernel images, Qi will look for (can be in either uImage (u-boot image) or zImage format, file name should still be uImage-GTA0[123].bin)
; /boot/append-GTA0[123]
: Additional kernel arguments. All arguments should be on the first and the only line separated by spaces, for example: "<tt>loglevel=8 rootdelay=5 </tt>" . Make sure you have an extra space after the last argument (space is no longer needed if the version is from 31 Jan or older)!
; /boot/noboot-GTA0[123]
: make Qi skip this partition

===Boot Order===
[[image:Qi-drawings-bootsequence.png|frame|Qi GTA02 Booting order]]
# SD Partition 1
# SD Partition 2
# SD Partition 3
# NAND
# Memory Test

Qi will try to mount each SD partition as ext2 / 3, if that succeeds it will look for the kernel as /boot/uImage-GTA02.bin. If that is found, it'll be fetched, its CRC is checked and then it's booted into with a generated kernel commandline.

===Kernel Commandline Generation===
[[image:Qi-commandline-composition.png‎|frame|Qi commandline composition]]
Because Qi has no private stored state, it infers and composes a suitable kernel commandline on each boot.

One of its tasks is to scan NAND memory using the U-Boot dynparts rules to determine the start offset
of the NAND partitions on this device, from that it forms the mtdparts kernel parameter that sets Linux's
view of NAND partitioning.

The other thing it does is mount the "identity" partition and get from there the globally unique MAC
address for the USB over Ethernet function instead of the random one that is otherwise used.

===LED and Vibrator Signals===
* AUX LED is turned on either on:
** Successful partition mount
** Successful kernel pull
** Successful initramfs pull
* AUX LED is turned off and vibrator runs briefly either on:
** Fail of kernel pull
** Fail of initramfs pull
** Fail of mount partition
** Skipping of current boot possibility
* AUX LED is turned off either on:
** Start of the kernel
** Start of the mem test
** Start of the kernel pull
** Start of the initramfs pull
* One Blue shine every ~10 second: did not find any valid kernel to boot
* About four RED shines per second: kernel panic.

===Booting===
A short press on the power button is enough to make Qi start booting. In a few seconds the backlight will be lit, but the kernel will not spew any console messages unless something is wrong. It may take up to 2 minutes (depends on distribution) until X is started during which there will be no visual feedback. Please be patient.

You can force debug messages on the LCM console by holding in the power button before Linux starts.

===Choosing a Kernel===
If a user presses the AUX button after successful partition mount and
before start of the kernel pull (that is, while the red LED is on),
this boot possibility is skipped (and GTA02 owners can feel
vibration).

On versions newer than Jan 18 if a user holds the POWER button just before start of the kernel,
debugging parameters are added to the kernel command line and a lot of information is output to the screen.

===Boot Menu===
Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi. This does not exist yet (it's already implemented for some Angstrom-supported devices and for Zaurus, so porting should be relatively easy).

===Download and installation===
The daily download is a ''qi-s3cXXXX-andy_somenumber.udfu'' file at http://people.openmoko.org/andy/ .
Use the file appropriate to your device:
*GTA01 -> qi-s3c2410
*GTA02 -> qi-s3c2442
*GTA03 -> qi-s3c6410

The installation should be flashing like (do it in DFU mode of NOR u-boot):
# dfu-util -a u-boot -R -D qi-s3c6410-andy_8589b40295653557.udfu

===Source code===
git://git.openmoko.org/git/qi.git , http://git.openmoko.org/?p=qi.git;a=summary .
One can also just use strings(1) on the .udfu file to get an idea of where Qi currently looks for files.

===README===
The latest README file can be found in the git as well:http://git.openmoko.org/?p=qi.git;a=blob;f=README;hb=HEAD

==Tips, Tricks, Tweaks==
===General troubleshooting===
Qi does not bring up the LCD backlight. If the backlight is lit, it means you have succeeded to boot into Linux.

If nothing else is happening or there is a panic, enable debugging messages as described below.

===Enabling console messages===

You can just hold in the power button, this automatically appends verbose debugging to the kernel commandline (loglevel=8).

If you always want verbose "dmesg" type debugging messages, you can do it like this:

[http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006812.html]
If it's SD Card boot, just create a text file, e.g., for a [[GTA02]] use
/boot/append-GTA02
on the rootfs in question, put in there
loglevel=8
and you'll see the messages on boot. If it's NAND right now you need to edit the default commandline in Qi for gta02.

===/boot-Partition===
If you have a separate partition for /boot, so that your kernel and rootfs are not in fact on the same partition, you will need to append a root= entry on the kernel commandline to override the default action of trying to use the partition where the kernel came from as the rootfs.

Add this in /boot/append-GTA0[123]:
root=/dev/mmcblk0p2
for a rootfs on the second partition.

Note that a default Debian installation puts the kernel straight in the root of /dev/mmcblk0p1, not in a boot subdirectory, expecting u-boot to mount it as /boot. In order for Qi to recognise this, create a boot subdirectory with a symlink to the kernel.

===SD Initialisation===
If you don't specify loglevel=8 in append-GTAXX, and booting fails with a "VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)", the SD card needs a little bit more time to initialise.

Put a "rootdelay=5" in append-GTAXX like so:
rootdelay=5

== Testing speed improvements ==

Stopwatch results on Qi (error is approx ±1/2 second):

Booting SHR image with uBoot:
* 0:00 power button held down
* 0:07 splash screen appears
* 0:15 drops to console showing kernel messages scrolling by for ~1 minute
* 1:18 Openmoko 'please wait' splash
* 1:31 desktop animated splash
* 2:38 finished booting

Booting identical setup with Qi flashed over uBoot:
* 0:00 power button held down
* 0:06 backlit black
* 0:13 please wait booting... (only this text on console for next 38 seconds)
* 0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi)
* 0:54 Openmoko 'please wait' splash
* 1:05 desktop animated splash
* 1:54 finished booting

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the fist stages up until init (kernel finished establishing itself) to be faster.

[[Category:System Developers]]

Qi

2009-02-19T07:26:11Z

Warmcat: /* Enabling console messages */

[[image:Screenshot-Qi.png|frame|Qi Boot messages]] Qi is a lightweight replacement for the [[Uboot|uBoot]] bootloader with everything that doesn't assist "loading" and "booting" Linux stripped out.

Its advantages comparing to [[Uboot|u-boot]] are:
* actively developed (u-boot on GTA02 is deprecated)
* easier configuration, more robust and predictable
* SD and SDHC cards supported properly with partitions of any size
* kernel size is detected by checking the start of the kernel image, so large (>2M) kernels are supported without tweaking or loading more than needed
* Very fast, simple boot direct to Linux

==About Qi==
===Requirements===
There is a [[Neo1973|GTA01]] build of Qi, but using it without a debug board is not recommended because Qi itself does not support DFU, so updating or going back to U-Boot is a difficult process.

[[Freerunner|GTA02 Hardware]] has NOR U-Boot always available to update Qi so it's safe to try it out.

===Features===
* booting from primary SD partitions (1st, 2nd or 3rd) in /boot directory
* booting from NAND (compatible with U-Boot's dynparts scheme)
* configuration per rootfs, by files in /boot in the rootfs
* automatically choose correct kernel for device hardware so rootfs can be used on multiple device types
* automatically tell kernel correct root= for rootfs kernel image came from, simplifying update
* ext2/3 are supported
* symlinks are supported
* parses identity partition and appends kernel commandline with device identity information
* zero "environment" or private persistent state - operation is completely deterministic

===Limitations===
* no DFU-Mode - USB is not initialized at all
* no boot menu
* FAT partitions are ignored

Both the lack of DFU and the boot menu are planned to be addressed by the backup / recovery rootfs.

FAT is not supported because it can't provide a rootfs, and Qi wants the kernel to come from the rootfs.

===Defaults===
If the kernel is found on uSD, Qi assumes the rootfs to be on the same partition as the kernel. In case of boot from NAND, it assumes that rootfs is also on NAND (just as u-boot does). See [[#/boot-Partition|below]] for help with an extra /boot-partition. The default rootdelay is 1 second.

===Files===
; /boot/uImage-GTA0[123].bin
: Kernel images, Qi will look for (can be in either uImage (u-boot image) or zImage format, file name should still be uImage-GTA0[123].bin)
; /boot/append-GTA0[123]
: Additional kernel arguments. All arguments should be on the first and the only line separated by spaces, for example: "<tt>loglevel=8 rootdelay=5 </tt>" . Make sure you have an extra space after the last argument (space is no longer needed if the version is from 31 Jan or older)!
; /boot/noboot-GTA0[123]
: make Qi skip this partition

===Boot Order===
[[image:Qi-drawings-bootsequence.png|frame|Qi GTA02 Booting order]]
# SD Partition 1
# SD Partition 2
# SD Partition 3
# NAND
# Memory Test

Qi will try to mount each SD partition as ext2 / 3, if that succeeds it will look for the kernel as /boot/uImage-GTA02.bin. If that is found, it'll be fetched, its CRC is checked and then it's booted into with a generated kernel commandline.

===Kernel Commandline Generation===
[[image:Qi-commandline-composition.png‎|frame|Qi commandline composition]]
Because Qi has no private stored state, it infers and composes a suitable kernel commandline on each boot.

One of its tasks is to scan NAND memory using the U-Boot dynparts rules to determine the start offset
of the NAND partitions on this device, from that it forms the mtdparts kernel parameter that sets Linux's
view of NAND partitioning.

The other thing it does is mount the "identity" partition and get from there the globally unique MAC
address for the USB over Ethernet function instead of the random one that is otherwise used.

===LED and Vibrator Signals===
* AUX LED is turned on either on:
** Successful partition mount
** Successful kernel pull
** Successful initramfs pull
* AUX LED is turned off and vibrator runs briefly either on:
** Fail of kernel pull
** Fail of initramfs pull
** Fail of mount partition
** Skipping of current boot possibility
* AUX LED is turned off either on:
** Start of the kernel
** Start of the mem test
** Start of the kernel pull
** Start of the initramfs pull
* One Blue shine every ~10 second: did not find any valid kernel to boot
* About four RED shines per second: kernel panic.

===Booting===
A short press on the power button is enough to make Qi start booting. In a few seconds the backlight will be lit, but the kernel will not spew any console messages unless something is wrong. It may take up to 2 minutes (depends on distribution) until X is started during which there will be no visual feedback. Please be patient.

===Choosing a Kernel===
If a user presses the AUX button after successful partition mount and
before start of the kernel pull (that is, while the red LED is on),
this boot possibility is skipped (and GTA02 owners can feel
vibration).

On versions newer than Jan 18 if a user holds the POWER button just before start of the kernel,
debugging parameters are added to the kernel command line and a lot of information is output to the screen.

===Boot Menu===
Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi. This does not exist yet (it's already implemented for some Angstrom-supported devices and for Zaurus, so porting should be relatively easy).

===Download and installation===
The daily download is a ''qi-s3cXXXX-andy_somenumber.udfu'' file at http://people.openmoko.org/andy/ .
Use the file appropriate to your device:
*GTA01 -> qi-s3c2410
*GTA02 -> qi-s3c2442
*GTA03 -> qi-s3c6410

The installation should be flashing like (do it in DFU mode of NOR u-boot):
# dfu-util -a u-boot -R -D qi-s3c6410-andy_8589b40295653557.udfu

===Source code===
git://git.openmoko.org/git/qi.git , http://git.openmoko.org/?p=qi.git;a=summary .
One can also just use strings(1) on the .udfu file to get an idea of where Qi currently looks for files.

===README===
The latest README file can be found in the git as well:http://git.openmoko.org/?p=qi.git;a=blob;f=README;hb=HEAD

==Tips, Tricks, Tweaks==
===General troubleshooting===
Qi does not bring up the LCD backlight. If the backlight is lit, it means you have succeeded to boot into Linux.

If nothing else is happening or there is a panic, enable debugging messages as described below.

===Enabling console messages===

You can just hold in the power button, this automatically appends verbose debugging to the kernel commandline (loglevel=8).

If you always want verbose "dmesg" type debugging messages, you can do it like this:

[http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006812.html]
If it's SD Card boot, just create a text file, e.g., for a [[GTA02]] use
/boot/append-GTA02
on the rootfs in question, put in there
loglevel=8
and you'll see the messages on boot. If it's NAND right now you need to edit the default commandline in Qi for gta02.

===/boot-Partition===
If you have a separate partition for /boot, so that your kernel and rootfs are not in fact on the same partition, you will need to append a root= entry on the kernel commandline to override the default action of trying to use the partition where the kernel came from as the rootfs.

Add this in /boot/append-GTA0[123]:
root=/dev/mmcblk0p2
for a rootfs on the second partition.

Note that a default Debian installation puts the kernel straight in the root of /dev/mmcblk0p1, not in a boot subdirectory, expecting u-boot to mount it as /boot. In order for Qi to recognise this, create a boot subdirectory with a symlink to the kernel.

===SD Initialisation===
If you don't specify loglevel=8 in append-GTAXX, and booting fails with a "VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)", the SD card needs a little bit more time to initialise.

Put a "rootdelay=5" in append-GTAXX like so:
rootdelay=5

== Testing speed improvements ==

Stopwatch results on Qi (error is approx ±1/2 second):

Booting SHR image with uBoot:
* 0:00 power button held down
* 0:07 splash screen appears
* 0:15 drops to console showing kernel messages scrolling by for ~1 minute
* 1:18 Openmoko 'please wait' splash
* 1:31 desktop animated splash
* 2:38 finished booting

Booting identical setup with Qi flashed over uBoot:
* 0:00 power button held down
* 0:06 backlit black
* 0:13 please wait booting... (only this text on console for next 38 seconds)
* 0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi)
* 0:54 Openmoko 'please wait' splash
* 1:05 desktop animated splash
* 1:54 finished booting

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the fist stages up until init (kernel finished establishing itself) to be faster.

[[Category:System Developers]]

Qi

2009-02-05T14:51:58Z

Warmcat:

[[image:Screenshot-Qi.png|frame|Qi Boot messages]] Qi is a lightweight replacement for the [[Uboot|uBoot]] bootloader with everything that doesn't assist "loading" and "booting" Linux stripped out.

Its advantages comparing to [[Uboot|u-boot]] are:
* actively developed (u-boot on GTA02 is deprecated)
* easier configuration, more robust and predictable
* SD and SDHC cards supported properly with partitions of any size
* kernel size is detected by checking the start of the kernel image, so large (>2M) kernels are supported without tweaking or loading more than needed
* Very fast, simple boot direct to Linux

==About Qi==
===Requirements===
There is a [[Neo1973|GTA01]] build of Qi, but using it without a debug board is not recommended because Qi itself does not support DFU, so updating or going back to U-Boot is a difficult process.

[[Freerunner|GTA02 Hardware]] has NOR U-Boot always available to update Qi so it's safe to try it out.

===Features===
* booting from primary SD partitions (1st, 2nd or 3rd) in /boot directory
* booting from NAND (compatible with U-Boot's dynparts scheme)
* configuration per rootfs, by files in /boot in the rootfs
* automatically choose correct kernel for device hardware so rootfs can be used on multiple device types
* automatically tell kernel correct root= for rootfs kernel image came from, simplifying update
* ext2/3 are supported
* symlinks are supported
* parses identity partition and appends kernel commandline with device identity information
* zero "environment" or private persistent state - operation is completely deterministic

===Limitations===
* no DFU-Mode - USB is not initialized at all
* no boot menu
* FAT partitions are ignored

Both the lack of DFU and the boot menu are planned to be addressed by the backup / recovery rootfs.

FAT is not supported because it can't provide a rootfs, and Qi wants the kernel to come from the rootfs.

===Defaults===
If the kernel is found on uSD, Qi assumes the rootfs to be on the same partition as the kernel. In case of boot from NAND, it assumes that rootfs is also on NAND (just as u-boot does). See [[#/boot-Partition|below]] for help with an extra /boot-partition. The default rootdelay is 1 second.

===Files===
; /boot/uImage-GTA0[123].bin
: Kernel images, Qi will look for (can be in either uImage (u-boot image) or zImage format, file name should still be uImage-GTA0[123].bin)
; /boot/append-GTA0[123]
: Additional kernel arguments. All arguments should be on the first and the only line separated by spaces, for example: "<tt>loglevel=8 rootdelay=5 </tt>" . Make sure you have an extra space after the last argument (space is no longer needed if the version is from 31 Jan or older)!
; /boot/noboot-GTA0[123]
: make Qi skip this partition

===Boot Order===
[[image:Qi-drawings-bootsequence.png|frame|Qi GTA02 Booting order]]
# SD Partition 1
# SD Partition 2
# SD Partition 3
# NAND
# Memory Test

Qi will try to mount each SD partition as ext2 / 3, if that succeeds it will look for the kernel as /boot/uImage-GTA02.bin. If that is found, it'll be fetched, its CRC is checked and then it's booted into with a generated kernel commandline.

===Kernel Commandline Generation===
[[image:Qi-commandline-composition.png‎|frame|Qi commandline composition]]
Because Qi has no private stored state, it infers and composes a suitable kernel commandline on each boot.

One of its tasks is to scan NAND memory using the U-Boot dynparts rules to determine the start offset
of the NAND partitions on this device, from that it forms the mtdparts kernel parameter that sets Linux's
view of NAND partitioning.

The other thing it does is mount the "identity" partition and get from there the globally unique MAC
address for the USB over Ethernet function instead of the random one that is otherwise used.

===LED and Vibrator Signals===
* AUX LED is turned on either on:
** Successful partition mount
** Successful kernel pull
** Successful initramfs pull
* AUX LED is turned off and vibrator runs briefly either on:
** Fail of kernel pull
** Fail of initramfs pull
** Fail of mount partition
** Skipping of current boot possibility
* AUX LED is turned off either on:
** Start of the kernel
** Start of the mem test
** Start of the kernel pull
** Start of the initramfs pull
* One Blue shine every ~10 second: did not find any valid kernel to boot
* About four RED shines per second: kernel panic.

===Booting===
A short press on the power button is enough to make Qi start booting. In a few seconds the backlight will be lit, but the kernel will not spew any console messages unless something is wrong. It may take up to 2 minutes (depends on distribution) until X is started during which there will be no visual feedback. Please be patient.

===Choosing a Kernel===
If a user presses the AUX button after successful partition mount and
before start of the kernel pull (that is, while the red LED is on),
this boot possibility is skipped (and GTA02 owners can feel
vibration).

On versions newer than Jan 18 if a user holds the POWER button just before start of the kernel,
debugging parameters are added to the kernel command line and a lot of information is output to the screen.

===Boot Menu===
Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi. This does not exist yet (it's already implemented for some Angstrom-supported devices and for Zaurus, so porting should be relatively easy).

===Download and installation===
The daily download is a ''qi-s3cXXXX-andy_somenumber.udfu'' file at http://people.openmoko.org/andy/ .
Use the file appropriate to your device:
*GTA01 -> qi-s3c2410
*GTA02 -> qi-s3c2442
*GTA03 -> qi-s3c6410

The installation should be flashing like (do it in DFU mode of NOR u-boot):
# dfu-util -a u-boot -R -D qi-s3c6410-andy_8589b40295653557.udfu

===Source code===
git://git.openmoko.org/git/qi.git , http://git.openmoko.org/?p=qi.git;a=summary .
One can also just use strings(1) on the .udfu file to get an idea of where Qi currently looks for files.

===README===
The latest README file can be found in the git as well:http://git.openmoko.org/?p=qi.git;a=blob;f=README;hb=HEAD

==Tips, Tricks, Tweaks==
===General troubleshooting===
Qi does not bring up the LCD backlight. If the backlight is lit, it means you have succeeded to boot into Linux.

If nothing else is happening or there is a panic, enable debugging messages as described below.

===Enabling console messages===
[http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006812.html]
If it's SD Card boot, just create a text file, e.g., for a [[GTA02]] use
/boot/append-GTA02
on the rootfs in question, put in there
loglevel=8
and you'll see the messages on boot. If it's NAND right now you need to edit the default commandline in Qi for gta02.

===/boot-Partition===
If you have a separate partition for /boot, so that your kernel and rootfs are not in fact on the same partition, you will need to append a root= entry on the kernel commandline to override the default action of trying to use the partition where the kernel came from as the rootfs.

Add this in /boot/append-GTA0[123]:
root=/dev/mmcblk0p2
for a rootfs on the second partition.

Note that a default Debian installation puts the kernel straight in the root of /dev/mmcblk0p1, not in a boot subdirectory, expecting u-boot to mount it as /boot. In order for Qi to recognise this, create a boot subdirectory with a symlink to the kernel.

===SD Initialisation===
If you don't specify loglevel=8 in append-GTAXX, and booting fails with a "VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)", the SD card needs a little bit more time to initialise.

Put a "rootdelay=5" in append-GTAXX like so:
rootdelay=5

== Testing speed improvements ==

Stopwatch results on Qi (error is approx ±1/2 second):

Booting SHR image with uBoot:
* 0:00 power button held down
* 0:07 splash screen appears
* 0:15 drops to console showing kernel messages scrolling by for ~1 minute
* 1:18 Openmoko 'please wait' splash
* 1:31 desktop animated splash
* 2:38 finished booting

Booting identical setup with Qi flashed over uBoot:
* 0:00 power button held down
* 0:06 backlit black
* 0:13 please wait booting... (only this text on console for next 38 seconds)
* 0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi)
* 0:54 Openmoko 'please wait' splash
* 1:05 desktop animated splash
* 1:54 finished booting

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the fist stages up until init (kernel finished establishing itself) to be faster.

[[Category:System Developers]]

File:Qi-drawings-bootsequence.png

2009-02-05T12:21:26Z

Warmcat: uploaded a new version of "Image:Qi-drawings-bootsequence.png"

File:Qi-commandline-composition.png

2009-02-05T12:14:54Z

Warmcat: uploaded a new version of "Image:Qi-commandline-composition.png"

File:Qi-commandline-composition.png

2009-02-05T12:14:04Z

Warmcat:

File:Screenshot-Qi.png

2009-02-05T11:24:57Z

Warmcat:

File:Qi-drawings-bootsequence.png

2009-02-01T21:09:22Z

Warmcat:

Qi

2009-02-01T21:07:04Z

Warmcat: /* Limitations */

Qi is a replacement for the [[Uboot|uBoot]] bootloader reduced to the core bootloader functions.

Its advantages comparing to [[Uboot|u-boot]] are:
* actively developed (u-boot on GTA02 is not maintained lately)
* easier configuration, more robust and predictable
* large uSD cards support
* large (>2M) kernels support without tweaking

==About Qi==
===Requirements===
[[Freerunner|GTA02 Hardware]] is recommended over [[Neo1973|GTA01]], since GTA02 does have a fallback u-boot in nor that provides DFU-Mode. Qi does NOT provide DFU-Mode so GTA01-Users will have no (easy) way to flash their device!

===Features===
* booting from primary SD partitions (1st, 2nd or 3rd)
* booting from NAND
* configuration by files in /boot
* automatically choose correct kernel for device hardware
* ext2/3 are supported
* symlinks are supported

===Limitations===
* no DFU-Mode
* no boot menu
* FAT partitions are ignored

Both the lack of DFU and the boot menu are planned to be addressed by the backup / recovery rootfs. FAT is not supported because it can't provide a rootfs, and Qi wants the kernel to come from the rootfs.

===Defaults===
If the kernel is found on uSD, Qi assumes the rootfs to be on the same partition as the kernel. In case of boot from NAND, it assumes that rootfs is also on NAND (just as u-boot does). See [[#/boot-Partition|below]] for help with an extra /boot-partition. The default rootdelay is 1 second.

===Files===
; /boot/uImage-GTA0[123].bin
: Kernel images, Qi will look for (can be in either uImage (u-boot image) or zImage format, file name should still be uImage-GTA0[123].bin)
; /boot/append-GTA0[123]
: Additional kernel arguments. All arguments should be on the first and the only line separated by spaces, for example: "<tt>loglevel=8 rootdelay=5 </tt>" . Make sure you have an extra space after the last argument (space is no longer needed if the version is from 31 Jan or older)!
; /boot/noboot-GTA0[123]
: make Qi skip this partition

===Boot Order===
# SD Partition 1
# SD Partition 2
# SD Partition 3
# NAND
# Memory Test

===LED and Vibrator Signals===
* AUX LED is turned on either on:
** Successful partition mount
** Successful kernel pull
** Successful initramfs pull
* AUX LED is turned off and vibrator runs briefly either on:
** Fail of kernel pull
** Fail of initramfs pull
** Fail of mount partition
** Skipping of current boot possibility
* AUX LED is turned off either on:
** Start of the kernel
** Start of the mem test
** Start of the kernel pull
** Start of the initramfs pull
* One Blue shine every ~10 second: did not find any valid kernel to boot
* About four RED shines per second: kernel panic.

===Booting===
A short press on the power button is enough to make Qi start booting. In a few seconds the backlight will be lit, but the kernel will not spew any console messages unless something is wrong. It may take up to 2 minutes (depends on distribution) until X is started during which there will be no visual feedback. Please be patient.

===Choosing a Kernel===
If a user presses the AUX button after successful partition mount and
before start of the kernel pull (that is, while the red LED is on),
this boot possibility is skipped (and GTA02 owners can feel
vibration).

On versions newer than Jan 18 if a user holds the POWER button just before start of the kernel,
debugging parameters are added to the kernel command line and a lot of information is output to the screen.

===Boot Menu===
Qi's concept is to leave everything possible to Linux, that includes even the video init. Therefore Qi does NOT provide a boot menu. This should rather be implemented by a minimal Kernel, initramfs and menu system. It may be more comfortable for some users and may get them to switch from uboot to Qi. This does not exist yet (it's already implemented for some Angstrom-supported devices and for Zaurus, so porting should be relatively easy).

===Download and installation===
The daily download is a ''qi-s3cXXXX-andy_somenumber.udfu'' file at http://people.openmoko.org/andy/ .
Use the file appropriate to your device:
*GTA01 -> qi-s3c2410
*GTA02 -> qi-s3c2442
*GTA03 -> qi-s3c6410

The installation should be flashing like (do it in DFU mode of NOR u-boot):
# dfu-util -a u-boot -R -D qi-s3c6410-andy_8589b40295653557.udfu

===Source code===
git://git.openmoko.org/git/qi.git , http://git.openmoko.org/?p=qi.git;a=summary .
One can also just use strings(1) on the .udfu file to get an idea of where Qi currently looks for files.

===README===
The latest README file can be found in the git as well:http://git.openmoko.org/?p=qi.git;a=blob;f=README;hb=HEAD

==Tips, Tricks, Tweaks==
===Enabling console messages===
[http://lists.openmoko.org/pipermail/openmoko-kernel/2008-November/006812.html]
If it's SD Card boot, just create a text file, e.g., for a [[GTA02]] use
/boot/append-GTA02
on the rootfs in question, put in there
loglevel=8
and you'll see the messages on boot. If it's NAND right now you need to edit the default commandline in Qi for gta02.

===/boot-Partition===
If you have a Partition for /boot, you will need to add a argument for the kernel to know which partition is the rootfs.
Add this in /boot/append-GTA0[123]:
root=/dev/mmcblk0p2
for a rootfs on the second partition.

Note that a default Debian installation puts the kernel straight in the root of /dev/mmcblk0p1, not in a boot subdirectory, expecting u-boot to mount it as /boot. In order for Qi to recognise this, create a boot subdirectory with a symlink to the kernel.

===SD Initialisation===
If you don't specify loglevel=8 in append-GTAXX, and booting fails with a "VFS: Cannot open root device "mmcblk0p1" or unknown-block(2,0)", the SD card needs a little bit more time to initialise.

Put a "rootdelay=5" in append-GTAXX like so:
rootdelay=5

== Testing speed improvements ==

Stopwatch results on Qi (error is approx ±1/2 second):

Booting SHR image with uBoot:
* 0:00 power button held down
* 0:07 splash screen appears
* 0:15 drops to console showing kernel messages scrolling by for ~1 minute
* 1:18 Openmoko 'please wait' splash
* 1:31 desktop animated splash
* 2:38 finished booting

Booting identical setup with Qi flashed over uBoot:
* 0:00 power button held down
* 0:06 backlit black
* 0:13 please wait booting... (only this text on console for next 38 seconds)
* 0:51 Angstrom console message (at the end of kernel output with uBoot, but ONLY text display to appear throughout this stage with Qi)
* 0:54 Openmoko 'please wait' splash
* 1:05 desktop animated splash
* 1:54 finished booting

So for this particular configuration, it reduced time-to-desktop by about 28%, about 44 seconds. Surprisingly, the later segments of booting (desktop) were also noticeably faster than with uBoot - One would have expected just the fist stages up until init (kernel finished establishing itself) to be faster.

[[Category:System Developers]]

Hints on using GIT and stgit

2008-10-05T12:37:01Z

Warmcat: /* Cloning a remote git repo and adding stgit */

=Overview: stgit and git=
Linus Torvalds invented git and uses it heavily in Linux development, most people would take that as an impressive suggestion it might be useful in kernel and similar development work.

* '''git''' is a lightweight distributed revision control system. In practical terms, it adds a ./.git directory in the top level of your project, git stores everything in there about your project including all the revisions. The commands all start "git <something>". ''Nice feature: if you create tarball of your project directory, you will also capture all your project history as it will archive ./.git''

* '''stgit''' does a similar job to quilt, using the same kind of verbs like top, push, pop, refresh and so on, but it is internally completely aware it is running on top of git, and it too stores all its files down ./.git so you backup stgit's state completely with tar too. The commands all start "stg <something>". ''Nice feature: while quilt makes you do "quilt add" before you modify a file, stgit does not need it: it knows what you changed without being told by checking because of its integration with git. (You still have to do "stg add" if you created a new file though; that also adds it to git.)''

'''Your stgit patch stack appears in your local git repo in a synchronized way, without explicit commits''' -- as you add, edit and remove patches in stgit your git repo is making the same moves, without losing the patch stack.

When you use the two together, you have a fast and flexible system for dealing with many branches of large source trees, rebasing them in a controlled way, and generating and managing patches to export elsewhere.

=Setting up your development box=
You just need to install the '''git''' and '''stgit''' packages for your distribution. There are GUI tools like '''qgit''' that can be helpful to navigate projects that you can install too.

You can optionally edit your ~/.bashrc to define some environment variables to control your commit identity for git

* export GIT_AUTHOR_NAME=yourhandle
* export GIT_COMMITTER_NAME=yourhandle
* export GIT_AUTHOR_EMAIL="your@email"
* export GIT_COMMITTER_EMAIL="your@email"

=Beginning with git and stgit=

==Adding git and stgit to an existing project of your own==
# cd to the top level of your project
# '''git init''' -- this creates an empty ./.git tree with a "master" branch only
# '''make distclean''' -- or equivalent - clean out all generated files
# '''git add *''' -- prepares to make an initial commit of all your stuff
# '''git commit''' -- takes a commit message (like, "initial commit") in vi and stores all the added files into the repo
# '''stg init''' -- initializes the stgit state for the new branch

The git init command should have created a default ''.gitignore'' file at the top level directory of your project -- you can edit this to ensure that any generated files other than the default *.o and so on are ignored by git if you need to, normally the default ones are enough.

==Cloning a remote git repo and adding stgit==
If you want to work on a tree that already existed in a remote repo, the first move is to '''clone''' it. This is different than "checking it out", when you clone it you are not just getting HEAD but *all revisions* of the project. (If the remote repo lost everything about that project tomorrow, what you cloned would be a full replacement for what it had.)

# '''git clone git://git.openmoko.org/git/kernel.git linux-2.6''' -- this example shows how to pull the 2.6 tracking project into a new local directory called "linux-2.6"
# '''git branch -a''' -- list all the branches available in the repo we just pulled
# '''git checkout origin/andy''' -- configures the source files in the directory to reflect the state of the origin/andy branch instead of the default master branch. The "origin/" part is added in your local copy of the repo only for branches coming from upstream.
# '''git checkout -b fix-andys-bugs''' -- create a local branch based on origin/andy so you can do work on top of it
# '''stg init''' -- prepare your fix-andys-bugs branch to be used with stgit

What you end up there is a local branch fix-andys-bugs which has no patch stack, but is at exactly the state of origin/andy. So when you add local patches, they are against current origin/andy.

==Safe experimentation==
Don't forget to tarball up your project directory before doing an experiment with git and stgit, until you are used to it. The tarball will fully capture and restore the project and git / stgit state, so you can try things without worrying about how to "hit undo".

=Workflow=
==Basic stgit Workflow==
Using stgit is a great deal like using quilt.

* '''stg new my-patch-description.patch''' -- adds a new empty patch to the top of the stack and opens vi to add a description for the patch -- you need to ensure the first line of the description is "my-patch-description.patch", to avoid the patch filename getting lost if the patch is later pulled from git directly

* '''stg series''' lets you see the patch stack and where you are on it

* '''stg top''' lets you see the current top patch you would be modifying

* Then you just start editing files. If you create any new files, you should do '''stg add <filepath>''' which adds the file to git and the current stgit patch. If you deleted a file from the project as part of this patch, you can do '''stg rm <filepath>'''

* If you are worried about ensuring that you included any new files with stg add, you can do '''stg status''' at any time to see if there are files around that git does not know about

* '''stg refresh''' -- regenerates the top patch by finding all the edits you made

* '''stg show''' -- displays the top patch in vi

* '''stg pop''' and '''stg push''' move up and down the patch stack

* '''stg pop --all''' and '''stg push --all''' pop or push to the start or end of the series in one action

* '''stg goto <patchname>''' is a nice feature that pushes or pops as needed to get the requested patch to be the current top one. <patchname> is a name that appears in the series, eg, my-patch.patch

* '''stg delete <patchname>''' or, eg '''stg delete `stg top`''' will pop and delete the given patch (or the current top patch in the second example).

==Clearing merge problems==
If you experience a genuine merge problem during an stg push for example, stgit will tell you about which source file had the problem, and where it put a copy of the merge diff. When you cleared the problem, you must run

'''stg resolved <filepath>'''

to tell stgit that you have resolved the merge problem in <filepath>. Then you will be able to do

'''stg refresh'''

to capture the changes under that patch and go on about your business.

==Exporting patches==
Exporting patches is super easy

'''stg export'''

will very rapidly export your whole patch stack in a directory ./patches-<branch> and create a series file in there as well. If you append a patch name to stg export, it just exports that one to the same directory.

==Importing patches==
You can import individual patches with

'''stg import <path to patch>'''

or a whole series at a time by pointing it to the series

'''stg import -i -s <path to series file>'''

The patches are imported to be above the current applied patch top, which doesn't have to be the top of your patch series.

BUT stgit is picky about patch formatting on import.

* The first line of the patch file should be the patch's own filename, eg, my-patch.patch should have a first line of my-patch.patch. This is so that later recovery of the patch from git into stgit will result in the same filename used for the patch, and a consistent name is shown in gitweb (the web interface for git repos as used in git.openmoko.org)

* It will spew warnings about whitespace problems in the patch according to kernel rules, then quench them and report the total (thousands in the case of the YAFFS patch...). Kernel folks take the whitespace rules seriously, but the import will proceed okay.

* A serious one -- stgit has a bug at the moment where it will fail to recognize some diff headers sometimes. The workaround is to add a line

:''Index: blah''

:after the patch description and the first patch header, which allows it to match. You have to watch closely for this one because you only get a warning "''Warning: No diff found, creating empty patch''", and stgit has imported the whole patch silently as a long description with no diff! The diff appears in the description though so if you didn't know about the problem, it looks like a diff is in there! However, you can find these bad imports easily enough -- do an stg pop --all, then stg push one at a time. If a patch had this problem on import, the stg push will give a result like this

:''Pushing patch "gta01-no_nand_partitions.patch" ... done (empty patch)''

:You should do an '''stg remove `stg top`''', edit the patch to add the "Index: blah" workaround, and then re-import with '''stg import <path to patch>'''. You can then go on with pushing the other patches.

:Patches that are produced by git should be fine -- they have the Index: line already attached. I guess the stgit guys are only using patches from other git users and that is why this bug survives.

* Another serious one -- no fuzz is allowed in the incoming patch matching by default. It means that an incoming patch that will apply with the patch utility will claim to be a failure during '''stg import'''. The procedure to cope with this is to iteratively '''stg import -i -s <path to series file>''', and when you have a failure due to fuzz

::a=<path to patches dir>/`stg top`; patch -p1 <$a && if [ ! -z "`grep -- \-\-\-\ \/dev\/null $a`" ] ; then stg add `cat $a | sed -n '/\-\-\-\ \/dev\/null/{n;p;}' | cut -d' ' -f2 | cut -f1 | cut -d'/' -f2-` ; fi && stg refresh

:then resume the series import by repeating that command. If the patch itself really didn't apply fully, you can either merge it by hand if it is a genuine issue, or you can back out that import and fully recover by '''stg refresh''' then '''stg delete `stg top`''' and you can try to fix the patch and re-import it again.

Typically you are importing external patches once, but if you need to accept patches on a continuing basis you should export any patches that caused trouble from stgit once they are imported, and provide these versions back to where your imported patches came from so that ongoing patch updates will go in without difficulty next time. Most times you are in fact removing fuzz from the patches by doing this.

==Identifying patches that changed a file==
Sometimes you see there is a problem in a source file you need to fix, but you want to make sure the fix goes in the right patch and you don't know which is the right one.

'''stg patches <file>''' will list all the patches ''in the current branch patch stack'' that modfied <file>. You can then use '''stg goto <patch name>''' to move to that patch in the patch stack and make the edit in that context.

=Branches and rebasing=
==Introducing branches==
You can make hierarchies of branched versions in git/stgit really easily with minimal disturbance. The main thing you have to watch is that your "current working directory" as it were, the current branch you are in, is the one you think it is. You can check that with

* '''git branch''' or '''stg branch''' if the branch is initialized with stgit

You can move to an existing stgit-initialized branch with

* '''stg branch mybranch'''

:what this does is literally add, delete and modify the files in the project directory so they correspond to the state you left the "mybranch" branch at. Because of that, stgit takes care to first check there are no un-refreshed changes in the current branch before allowing the move to the different branch.

:It also configures stgit with ''that branch's'' patch stack, leaving the patch stack for whatever branch you were on safely with that branch.

* '''git branch mynewbranch'''
* '''stg branch mynewbranch'''
* '''stg init'''

:creates a new branch if the branch "mynewbranch" didn't already exist -- this new branch is "based on" the branch you were on when you created it.

* '''git branch -d myoldbranch''' deletes myoldbranch when you're finished with it

==Rebasing==
The branching stuff initially sounds like it can be a can of worms, because once you made these easy, cheap branches, what do you do when the thing you based it on gets new patches and commits? Your stuff is still based on the parent's version at the time you branched it, right? Isn't it just a big mess?

It's true that your branch will stay at the parent's version at the time it was branched, even if new commits come into the parent branch -- until you '''rebase''' it. Git and stgit together make rebasing almost as easy as spawning the new branch. Let's say we had the default "master" branch and we made a new branch from it

* '''stg branch master''' -- go to the master branch
* '''git branch newbranch''' -- create a branch off of master called newbranch
* '''stg branch newbranch''' -- move stgit to the new child branch
* '''stg init''' -- prepare newbranch to work with stgit
* '''stg series''' -- observe there are no patches yet in the new child branch

Then we did lots of work on newbranch

* '''stg new my-super-patch.patch'''
* <edits>
* '''stg refresh'''
* '''stg new another-awesome-patch.patch'''
* <edits>
* '''stg refresh'''

But then we decided we needed to update master (in this example master pulls from a remote repo to get updates) perhaps to get a bugfix

* '''stg branch master''' -- go to the master branch
* '''stg pull''' -- collect any new commits
* '''stg branch newbranch''' -- go back to newbranch (it's unchanged)

and we wanted those updates on newbranch too. Easy (we are in newbranch again remember)

* '''stg pop --all''' -- pop all our newbranch patches
* '''git reset --hard master''' -- reset our branch to current master
* '''stg push --all''' -- push all our newbranch patches back on

So we are able to update master and reset newbranch to start from the new master HEAD without disturbing the patch series associated with newbranch, except we have to push them back on and deal with any failures to merge due to conflicting edits in the new patches... but that's what we have to do anyway, and we can do it inside the patch stack system.

==Practical use for branches==
The kernel trees in git currently use branches in a structured way to allow staged rebasing.

* The default '''master''' branch is just the vanilla kernel.org kernel, either tracking git or at a fixed stable version.

* A '''mokopatches''' branch off master contains the current Openmoko kernel patchset for the kernel

* A '''development''' (or some other names) branch(es) off '''mokopatches''' then contains just the patch stack that is being worked on in that branch for whatever reason

This allows master to be pulled from kernel.org or otherwise updated when needed, separately the moko patchset can be updated when needed and lastly the working branches can be rebased as described above when needed

=stgit and branch history=
==stgit uses git history to track applied patches==
stgit has a very tight coupling to git commits -- when you stg pop a patch the patch is undone on the files and the commit history for the patch is '''erased''', not reverted. This works great for local use, since the patch stack retains the information needed to bring the patch back with stg push again and you didn't care about tracking your history of pushing and popping patches from the stack since you do it all the time randomly. The git 'history' in the local case is just reflecting the currently applied patchset rather than any actual 'history'.

==Public trees use git history as history to sync against==
The problems start when another repo, say a public repo you push to, or pull from, will have its own commit history for that project. If you clone the remote repo locally and then use stgit directly on the branches, say to stg uncommit and then stg delete a patch, your git history for that branch is no longer an unbroken thread in agreement with the origin: the uncommit snipped a bit of the history off on your version. You won't be able to push any more to the other repo: git will give you an error.

==Either: 1: Only use stgit on local-only or temporary branches==
The only way to maintain a consistent public history for people to work with is to never erase history with stgit on those shared branches. It means that you have to work on a temporary branch and export the patches, importing them into your stable branch in a single action without using stgit... but if you have to remove a patch that was committed to the stable branch, use '''git revert''' to issue an anti-patch.

==Or: 2: Your public repo branch is a "mirror"==
The other way to deal with this is to accept that the public repo isn't there to maintain a project history but to make public your branch in a "snapshot" kind of mode.

You do this by pushing your local branch using this syntax:

'''git push ssh://git@git.openmoko.org/var/cache/git/<projectname>.git +<remote-branch-name>:<local-branch-name>;'''

...this will overwrite <remote-branch-name> with the contents of <local-branch-name>. So when you want to expose a snapshot of your branch state on the public repo, you run the line above to force the remote branch into sync with yours.

=Making your tree public on git.openmoko.org=
# Send your ssh key to Gismo. He will add it to the git user authorized_keys, so you can ssh in
# '''ssh git@git.openmoko.org'''
# '''cd /var/cache/git'''
# '''./ADD_NEW_REPO <your-project-name>''' -- without the .git on the end
# in your project directory, execute the suggested git push command shown by the ADD_NEW_REPO script
# '''vi <your-project-name>.git/description''' -- change to a few words describing your project
# You can immediately see your tree on http://git.openmoko.org/ and browse it

Keep a copy of the git push command, you can use it without the --all to update the remote git repo with changes to your local git

If something goes wrong, you can fully delete your project on there with

'''rm -rf /var/cache/git/<your-project-name>.git'''

and start over from step 3.

You can backup your remote repo either on the git.openmoko.org box by using:

'''tar czf /home/git/<project>-backup.tar.gz /var/cache/git/<project>.git'''

or remotely by something like:

'''rsync -avz --delete git@git.openmoko.org:/var/cache/git/<project>.git <project>-backup'''

[[Category:System Developers]]
[[Category:Application Developer]]

Hints on using GIT and stgit

2008-10-05T12:33:35Z

Warmcat: /* Cloning a remote git repo and adding stgit */

=Overview: stgit and git=
Linus Torvalds invented git and uses it heavily in Linux development, most people would take that as an impressive suggestion it might be useful in kernel and similar development work.

* '''git''' is a lightweight distributed revision control system. In practical terms, it adds a ./.git directory in the top level of your project, git stores everything in there about your project including all the revisions. The commands all start "git <something>". ''Nice feature: if you create tarball of your project directory, you will also capture all your project history as it will archive ./.git''

* '''stgit''' does a similar job to quilt, using the same kind of verbs like top, push, pop, refresh and so on, but it is internally completely aware it is running on top of git, and it too stores all its files down ./.git so you backup stgit's state completely with tar too. The commands all start "stg <something>". ''Nice feature: while quilt makes you do "quilt add" before you modify a file, stgit does not need it: it knows what you changed without being told by checking because of its integration with git. (You still have to do "stg add" if you created a new file though; that also adds it to git.)''

'''Your stgit patch stack appears in your local git repo in a synchronized way, without explicit commits''' -- as you add, edit and remove patches in stgit your git repo is making the same moves, without losing the patch stack.

When you use the two together, you have a fast and flexible system for dealing with many branches of large source trees, rebasing them in a controlled way, and generating and managing patches to export elsewhere.

=Setting up your development box=
You just need to install the '''git''' and '''stgit''' packages for your distribution. There are GUI tools like '''qgit''' that can be helpful to navigate projects that you can install too.

You can optionally edit your ~/.bashrc to define some environment variables to control your commit identity for git

* export GIT_AUTHOR_NAME=yourhandle
* export GIT_COMMITTER_NAME=yourhandle
* export GIT_AUTHOR_EMAIL="your@email"
* export GIT_COMMITTER_EMAIL="your@email"

=Beginning with git and stgit=

==Adding git and stgit to an existing project of your own==
# cd to the top level of your project
# '''git init''' -- this creates an empty ./.git tree with a "master" branch only
# '''make distclean''' -- or equivalent - clean out all generated files
# '''git add *''' -- prepares to make an initial commit of all your stuff
# '''git commit''' -- takes a commit message (like, "initial commit") in vi and stores all the added files into the repo
# '''stg init''' -- initializes the stgit state for the new branch

The git init command should have created a default ''.gitignore'' file at the top level directory of your project -- you can edit this to ensure that any generated files other than the default *.o and so on are ignored by git if you need to, normally the default ones are enough.

==Cloning a remote git repo and adding stgit==
If you want to work on a tree that already existed in a remote repo, the first move is to '''clone''' it. This is different than "checking it out", when you clone it you are not just getting HEAD but *all revisions* of the project. (If the remote repo lost everything about that project tomorrow, what you cloned would be a full replacement for what it had.)

# '''git clone git://git.openmoko.org/git/kernel.git linux-2.6''' -- this example shows how to pull the 2.6 tracking project into a new local directory called "linux-2.6"
# '''git branch -a''' -- list all the branches available in the repo we just pulled
# '''git checkout origin/andy''' -- configures the source files in the directory to reflect the state of the origin/andy branch instead of the default master branch
# '''git checkout -b fix-andys-bugs''' -- create a local branch based on origin/andy so you can do work on top of it
# '''stg init''' -- prepare your fix-andys-bugs branch to be used with stgit

What you end up there is a local branch fix-andys-bugs which has no patch stack, but is at exactly the state of origin/andy. So when you add local patches, they are against current origin/andy.

==Safe experimentation==
Don't forget to tarball up your project directory before doing an experiment with git and stgit, until you are used to it. The tarball will fully capture and restore the project and git / stgit state, so you can try things without worrying about how to "hit undo".

=Workflow=
==Basic stgit Workflow==
Using stgit is a great deal like using quilt.

* '''stg new my-patch-description.patch''' -- adds a new empty patch to the top of the stack and opens vi to add a description for the patch -- you need to ensure the first line of the description is "my-patch-description.patch", to avoid the patch filename getting lost if the patch is later pulled from git directly

* '''stg series''' lets you see the patch stack and where you are on it

* '''stg top''' lets you see the current top patch you would be modifying

* Then you just start editing files. If you create any new files, you should do '''stg add <filepath>''' which adds the file to git and the current stgit patch. If you deleted a file from the project as part of this patch, you can do '''stg rm <filepath>'''

* If you are worried about ensuring that you included any new files with stg add, you can do '''stg status''' at any time to see if there are files around that git does not know about

* '''stg refresh''' -- regenerates the top patch by finding all the edits you made

* '''stg show''' -- displays the top patch in vi

* '''stg pop''' and '''stg push''' move up and down the patch stack

* '''stg pop --all''' and '''stg push --all''' pop or push to the start or end of the series in one action

* '''stg goto <patchname>''' is a nice feature that pushes or pops as needed to get the requested patch to be the current top one. <patchname> is a name that appears in the series, eg, my-patch.patch

* '''stg delete <patchname>''' or, eg '''stg delete `stg top`''' will pop and delete the given patch (or the current top patch in the second example).

==Clearing merge problems==
If you experience a genuine merge problem during an stg push for example, stgit will tell you about which source file had the problem, and where it put a copy of the merge diff. When you cleared the problem, you must run

'''stg resolved <filepath>'''

to tell stgit that you have resolved the merge problem in <filepath>. Then you will be able to do

'''stg refresh'''

to capture the changes under that patch and go on about your business.

==Exporting patches==
Exporting patches is super easy

'''stg export'''

will very rapidly export your whole patch stack in a directory ./patches-<branch> and create a series file in there as well. If you append a patch name to stg export, it just exports that one to the same directory.

==Importing patches==
You can import individual patches with

'''stg import <path to patch>'''

or a whole series at a time by pointing it to the series

'''stg import -i -s <path to series file>'''

The patches are imported to be above the current applied patch top, which doesn't have to be the top of your patch series.

BUT stgit is picky about patch formatting on import.

* The first line of the patch file should be the patch's own filename, eg, my-patch.patch should have a first line of my-patch.patch. This is so that later recovery of the patch from git into stgit will result in the same filename used for the patch, and a consistent name is shown in gitweb (the web interface for git repos as used in git.openmoko.org)

* It will spew warnings about whitespace problems in the patch according to kernel rules, then quench them and report the total (thousands in the case of the YAFFS patch...). Kernel folks take the whitespace rules seriously, but the import will proceed okay.

* A serious one -- stgit has a bug at the moment where it will fail to recognize some diff headers sometimes. The workaround is to add a line

:''Index: blah''

:after the patch description and the first patch header, which allows it to match. You have to watch closely for this one because you only get a warning "''Warning: No diff found, creating empty patch''", and stgit has imported the whole patch silently as a long description with no diff! The diff appears in the description though so if you didn't know about the problem, it looks like a diff is in there! However, you can find these bad imports easily enough -- do an stg pop --all, then stg push one at a time. If a patch had this problem on import, the stg push will give a result like this

:''Pushing patch "gta01-no_nand_partitions.patch" ... done (empty patch)''

:You should do an '''stg remove `stg top`''', edit the patch to add the "Index: blah" workaround, and then re-import with '''stg import <path to patch>'''. You can then go on with pushing the other patches.

:Patches that are produced by git should be fine -- they have the Index: line already attached. I guess the stgit guys are only using patches from other git users and that is why this bug survives.

* Another serious one -- no fuzz is allowed in the incoming patch matching by default. It means that an incoming patch that will apply with the patch utility will claim to be a failure during '''stg import'''. The procedure to cope with this is to iteratively '''stg import -i -s <path to series file>''', and when you have a failure due to fuzz

::a=<path to patches dir>/`stg top`; patch -p1 <$a && if [ ! -z "`grep -- \-\-\-\ \/dev\/null $a`" ] ; then stg add `cat $a | sed -n '/\-\-\-\ \/dev\/null/{n;p;}' | cut -d' ' -f2 | cut -f1 | cut -d'/' -f2-` ; fi && stg refresh

:then resume the series import by repeating that command. If the patch itself really didn't apply fully, you can either merge it by hand if it is a genuine issue, or you can back out that import and fully recover by '''stg refresh''' then '''stg delete `stg top`''' and you can try to fix the patch and re-import it again.

Typically you are importing external patches once, but if you need to accept patches on a continuing basis you should export any patches that caused trouble from stgit once they are imported, and provide these versions back to where your imported patches came from so that ongoing patch updates will go in without difficulty next time. Most times you are in fact removing fuzz from the patches by doing this.

==Identifying patches that changed a file==
Sometimes you see there is a problem in a source file you need to fix, but you want to make sure the fix goes in the right patch and you don't know which is the right one.

'''stg patches <file>''' will list all the patches ''in the current branch patch stack'' that modfied <file>. You can then use '''stg goto <patch name>''' to move to that patch in the patch stack and make the edit in that context.

=Branches and rebasing=
==Introducing branches==
You can make hierarchies of branched versions in git/stgit really easily with minimal disturbance. The main thing you have to watch is that your "current working directory" as it were, the current branch you are in, is the one you think it is. You can check that with

* '''git branch''' or '''stg branch''' if the branch is initialized with stgit

You can move to an existing stgit-initialized branch with

* '''stg branch mybranch'''

:what this does is literally add, delete and modify the files in the project directory so they correspond to the state you left the "mybranch" branch at. Because of that, stgit takes care to first check there are no un-refreshed changes in the current branch before allowing the move to the different branch.

:It also configures stgit with ''that branch's'' patch stack, leaving the patch stack for whatever branch you were on safely with that branch.

* '''git branch mynewbranch'''
* '''stg branch mynewbranch'''
* '''stg init'''

:creates a new branch if the branch "mynewbranch" didn't already exist -- this new branch is "based on" the branch you were on when you created it.

* '''git branch -d myoldbranch''' deletes myoldbranch when you're finished with it

==Rebasing==
The branching stuff initially sounds like it can be a can of worms, because once you made these easy, cheap branches, what do you do when the thing you based it on gets new patches and commits? Your stuff is still based on the parent's version at the time you branched it, right? Isn't it just a big mess?

It's true that your branch will stay at the parent's version at the time it was branched, even if new commits come into the parent branch -- until you '''rebase''' it. Git and stgit together make rebasing almost as easy as spawning the new branch. Let's say we had the default "master" branch and we made a new branch from it

* '''stg branch master''' -- go to the master branch
* '''git branch newbranch''' -- create a branch off of master called newbranch
* '''stg branch newbranch''' -- move stgit to the new child branch
* '''stg init''' -- prepare newbranch to work with stgit
* '''stg series''' -- observe there are no patches yet in the new child branch

Then we did lots of work on newbranch

* '''stg new my-super-patch.patch'''
* <edits>
* '''stg refresh'''
* '''stg new another-awesome-patch.patch'''
* <edits>
* '''stg refresh'''

But then we decided we needed to update master (in this example master pulls from a remote repo to get updates) perhaps to get a bugfix

* '''stg branch master''' -- go to the master branch
* '''stg pull''' -- collect any new commits
* '''stg branch newbranch''' -- go back to newbranch (it's unchanged)

and we wanted those updates on newbranch too. Easy (we are in newbranch again remember)

* '''stg pop --all''' -- pop all our newbranch patches
* '''git reset --hard master''' -- reset our branch to current master
* '''stg push --all''' -- push all our newbranch patches back on

So we are able to update master and reset newbranch to start from the new master HEAD without disturbing the patch series associated with newbranch, except we have to push them back on and deal with any failures to merge due to conflicting edits in the new patches... but that's what we have to do anyway, and we can do it inside the patch stack system.

==Practical use for branches==
The kernel trees in git currently use branches in a structured way to allow staged rebasing.

* The default '''master''' branch is just the vanilla kernel.org kernel, either tracking git or at a fixed stable version.

* A '''mokopatches''' branch off master contains the current Openmoko kernel patchset for the kernel

* A '''development''' (or some other names) branch(es) off '''mokopatches''' then contains just the patch stack that is being worked on in that branch for whatever reason

This allows master to be pulled from kernel.org or otherwise updated when needed, separately the moko patchset can be updated when needed and lastly the working branches can be rebased as described above when needed

=stgit and branch history=
==stgit uses git history to track applied patches==
stgit has a very tight coupling to git commits -- when you stg pop a patch the patch is undone on the files and the commit history for the patch is '''erased''', not reverted. This works great for local use, since the patch stack retains the information needed to bring the patch back with stg push again and you didn't care about tracking your history of pushing and popping patches from the stack since you do it all the time randomly. The git 'history' in the local case is just reflecting the currently applied patchset rather than any actual 'history'.

==Public trees use git history as history to sync against==
The problems start when another repo, say a public repo you push to, or pull from, will have its own commit history for that project. If you clone the remote repo locally and then use stgit directly on the branches, say to stg uncommit and then stg delete a patch, your git history for that branch is no longer an unbroken thread in agreement with the origin: the uncommit snipped a bit of the history off on your version. You won't be able to push any more to the other repo: git will give you an error.

==Either: 1: Only use stgit on local-only or temporary branches==
The only way to maintain a consistent public history for people to work with is to never erase history with stgit on those shared branches. It means that you have to work on a temporary branch and export the patches, importing them into your stable branch in a single action without using stgit... but if you have to remove a patch that was committed to the stable branch, use '''git revert''' to issue an anti-patch.

==Or: 2: Your public repo branch is a "mirror"==
The other way to deal with this is to accept that the public repo isn't there to maintain a project history but to make public your branch in a "snapshot" kind of mode.

You do this by pushing your local branch using this syntax:

'''git push ssh://git@git.openmoko.org/var/cache/git/<projectname>.git +<remote-branch-name>:<local-branch-name>;'''

...this will overwrite <remote-branch-name> with the contents of <local-branch-name>. So when you want to expose a snapshot of your branch state on the public repo, you run the line above to force the remote branch into sync with yours.

=Making your tree public on git.openmoko.org=
# Send your ssh key to Gismo. He will add it to the git user authorized_keys, so you can ssh in
# '''ssh git@git.openmoko.org'''
# '''cd /var/cache/git'''
# '''./ADD_NEW_REPO <your-project-name>''' -- without the .git on the end
# in your project directory, execute the suggested git push command shown by the ADD_NEW_REPO script
# '''vi <your-project-name>.git/description''' -- change to a few words describing your project
# You can immediately see your tree on http://git.openmoko.org/ and browse it

Keep a copy of the git push command, you can use it without the --all to update the remote git repo with changes to your local git

If something goes wrong, you can fully delete your project on there with

'''rm -rf /var/cache/git/<your-project-name>.git'''

and start over from step 3.

You can backup your remote repo either on the git.openmoko.org box by using:

'''tar czf /home/git/<project>-backup.tar.gz /var/cache/git/<project>.git'''

or remotely by something like:

'''rsync -avz --delete git@git.openmoko.org:/var/cache/git/<project>.git <project>-backup'''

[[Category:System Developers]]
[[Category:Application Developer]]

Who is Who

2008-08-07T12:52:04Z

Warmcat: /* Officials members of the Openmoko Team */

If you subscribe to a mailing list, you will see people speaking, answering some questions, but you may ask:
* Who is who?
* Who can I trust when they say something?

So I propose to fill out this list to help people get to know each other.

== Officials members of the Openmoko Team ==

The Openmoko team (alphabetical by last name):
{| class="wikitable sortable" style="margin: 0em " cellspacing="0" cellpadding="5" border="1"
! Name !! email !! Wiki username !! IRC nickname !! Position
|-
| Allen Chang || || {{user|allen_chang}} || || GTA Hardware Engineer
|-
| Andy Green || ''andy'' at openmoko dot ''com'' || {{user|warmcat}} || agreen || Software Developer
|-
| Anthony Chang || || || || Software Developer
|-
| Candy Chou || || {{user|candy_chou}} || || GTA/HXD Hardware Engineer
|-
| Dkay Chen || || {{user|dkay_chen}} || || GTA/HXD Hardware Engineer
|-
| Jeremy Chang || || || || Software Developer
|-
| Jollen Chen || || || || Marketing
|-
| Tick Chen || || || || Software Developer
|-
| Guillaume 'Charlie' Chereau || ''charlie'' at openmoko dot ''org'' || || ||
|-
| Julian Chu || ''julian_chu'' at openmoko dot ''com'' || || || Software Developer
|-
| Holger 'Zecke' Freyther || ''zecke'' at openmoko dot ''org'' || || || Software Developer
|-
| Graeme Gregory || ''graeme'' at openmoko dot ''org'' || || XorA ||
|-
| Carsten Haitzler || ''raster'' at openmoko dot ''org'' || || raster || Software Developer
|-
| Matt Hsu || || {{user|Matt}} || || Software Developer
|-
| Wendy Hung || || || || Testing
|-
| Regina Kim || || || || Testing
|-
| William Lai || ''will'' at openmoko dot ''com'' || || || Design Team Project Manager
|-
| Michael 'Mickey' Lauer || || {{user|Mickey}} || || Software Developer
|-
| John Lee || || || || Software Developer
|-
| Tim Lee || || {{user|Tim}} || || Hardware Manager
|-
| Marek Lindner || ''marek'' at openmoko dot ''com'' || || || Software Developer
|-
| Xiangfu Liu || ''xiangfu'' at openmoko dot ''org'' || || || Software Developer
|-
| Jan 'Shoragan' Luebbe || || || || Openmoko student (part-time)
|-
| Steven Mosher || || {{user|steve}} || || Vice President of Marketing
|-
| Sean Moss-Pultz || || {{user|Sean}} || || CEO
|-
| Shawn Lin || || {{user|shawn_lin}} || || RF Engineer
|-
| Joerg Reisenweber || || {{user|jOERG}} || || Hardware Engineer
|-
| Michael Shiloh || ''michael'' at openmoko dot ''org'' || {{user|Michaelshiloh}} || || Head of Developer Relations
|-
| Wolfgang Spraul || ''wolfgang'' at openmoko dot ''com'' || || || Vice President of Engineering
|-
| Joachim Steiger || || {{user|Roh}} || roh || Central Services
|-
| Harry Tsai || ''harry'' at openmoko dot ''com'' || || || Vice President of Sales
|-
| Neng-Yu 'Tony' Tu || || {{user|Tony Tu}} || || Software Developer
|-
| Brenda Wang || ''brenda_wang'' at openmoko dot ''com'' || {{user|Coolcat}} || || Wiki editor
|-
| Harald Welte || ''laforge'' at openmoko dot ''org'' || {{user|HaraldWelte}} || LaF0rge || (Left Openmoko. Here for archives.)
|-
| Daniel 'Alphaone' Willmann || || {{user|DanielWillmann}} || || Software Developer
|-
| Thomas Wood || || {{user|ThomasWood}} || ||
|-
| OLV Wu || ''olv'' at openmoko dot ''org'' || || || Software Developer
|-
| Erin Yeh || || || || Software Developer
|}

== Proeminent community members ==

Only add people who made a significant contribution to the Openmoko community.

{| class="wikitable sortable" style="margin: 0em " cellspacing="0" cellpadding="5" border="1"
! Name !! email !! Wiki username !! IRC nickname !! Position
|-
| Lorn Potter || ''lpotter'' at ''trolltech'' dot ''com'' || || lpotter || Qtopia developer
|-
| Rod Whitby || || {{user|RodWhitby}} || rwhitby || [[MokoMakefile]] author
|}

== See also ==

* [[The original core team]]

[[Category:Openmoko Inc]]

FreeRunner backup kernel

2008-08-07T08:14:14Z

Warmcat: New page: == Freerunner backup kernel == The Freerunner NAND partition for the monolithic kernel is set to be 8MBytes, but currently kernels are around 2MBytes in size. This allows us to stash a s...

== Freerunner backup kernel ==

The Freerunner NAND partition for the monolithic kernel is set to be 8MBytes, but currently kernels are around 2MBytes in size. This allows us to stash a second, backup kernel in that partition for use in an emergency. If your USB network connection is unavailable was knocked out for some reason, or the modules in the rootfs are bad and crash on every boot, this can be highly useful to have alongside DFU as a boot menu option eventually.

[[Image:Recovery-kernel.png]]

Since this was only implemented after production, factory Freerunners do not currently have a recovery kernel, but it's possible to add as described here.

Once you installed the recovery kernel, it won't get overwritten by subsequent DFU kernel updates because DFU only erases as far as it writes, which is no more than 2MBytes for normal kernel update.

=== Current packaging compatability issue ===
<blockquote>Right this second the packaged kernels erase the whole partition on update, but I am requesting that be changed so they won't touch the backup kernel either.</blockquote>

== Installing the backup kernel ==

Recovery kernels are "moredrivers" kernels that include the critical drivers in the main kernel already. Additionally, because they share a partition with the normal kernel, they are around 6MB in size to get the recovery part at the 4MB offset as shown in the picture above.

You can get a 6MB recovery image from here: [http://warmcat.com/recovery-uImage-moredrivers-stable_507c3c1ba3921bb7.bin 6M recovery kernel image]

Just DFU it in normally to the kernel partition. When the issue about packaged erase is fixed, subsequent updates by DFU or kernel package will update the first kernel normally, but leave the backup one at +4MBytes alone.

== Selecting the backup kernel in U-Boot ==

This one-liner at the U-Boot prompt will boot you into the backup kernel. (FIXME: integrate into boot menu to make all this actually useful)

<blockquote>setenv bootcmd nand read.e 0x32000000 kernel \; setenv bootargs \${mtdparts} rootfstype=jffs2 root=/dev/mtdblock6 console=tty0 console=ttySAC2,115200 loglevel=3 init=/sbin/init \; bootm 0x32400000 ; boot</blockquote>

File:Recovery-kernel.png

2008-08-06T22:35:54Z

Warmcat:

Booting the Neo FreeRunner from SD via U-Boot

2008-07-30T08:14:28Z

Warmcat: /* Add uboot boot entry */

This page explains how to boot a Freerunner from the SD card rather than from the built-in NAND flash memory. The SD card shares a bus with the GPU, so it may not perform as well, but it is another option.

{{Warning | Booting from SDHC may cause problems at this time. }} See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| this thread.]

== How it Works ==

On the Neo, [[u-boot]] performs a similar role to the 'grub' bootloader on a PC. U-boot loads a kernel image into memory and then passes a list of parameters to the kernel. These parameters specify, among other things, the device on which the root filesystem is located.

As the kernel boots, it initializes the hardware and then mounts the root filesystem. The kernel then runs "/sbin/init", which handles the rest of the boot-up sequence (such as displaying the splash screen and progress bar).

This sequence is the same whether the device is booting from built-in Flash or from the SD card. The differences are how the kernel is loaded, and which device is mounted as the root filesystem.

The following sections provide additional details.

=== Menu Entries ===

U-boot menu entries are defined by environment variables named "menu_X" (where X is a number). The value of the environment variable is a string "<label>:<commands>", where <label> is the text shown on the screen, and <commands> is a sequence of u-boot commands (delimited by ';' characters) to be executed when the menu item is selected. When entering a string of commands, the ';' and '$' characters must be backslash-escaped ("\;" and "\$").

=== Loading the Kernel ===

A pair of u-boot commands must be used to load the kernel from SD. First is "mmcinit", which will cause u-boot to detect the card. Next is a command to load a file into memory - either "fatload" or "ext2load" depending on whether the kernel is on a FAT filesytem or an ext2/ext3 filesystem.

The command syntax is:

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

where is the partition number, and <filepath> is the path to the file that is to be loaded.

{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of Freerunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}

{{Warning | Be careful when updating u-boot on a Neo1973 as there is a risk of bricking the device (unless you have a debug board). This is not an issue for the Freerunner as it has a protected copy of u-boot in the NOR flash }}

{{Note| U-Boot only supports SDHC protocol on Freerunner: on the Neo1973, u-boot is unable to access SDHC cards (4G or larger). The kernel does have SDHC support on Neo1973, so it is possible to have the root filesystem on SDHC and the kernel on NAND flash to work around it. }}

=== Root Filesystem Parameters ===

The contents of the "bootargs" environment variable are passed to the kernel. Bootargs is a space-delimited list of "name=value" definitions. The items relevant to SD-booting are "root", "rootfstype", and "rootdelay".

For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed.

Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command

less /proc/filesystems

It is not possible to use VFAT for the root filesystem.

==== ext2 vs. ext3 ====

Opinion is divided on whether it is better to use ext2 or ext3 for the root filesystem. Ext3 in general is a superior choice, because it is a journalled filesystem and so does not require a long 'fsck' (file system check) after an unclean shutdown. However, if used on a flash device that does not support wear-leveling then ext3 may cause premature wear on the blocks of the card where the journal is stored. SD cards are supposed to support wear leveling, but this can not be guaranteed for all vendors.

== Acquiring a tarfile rootfs ==

There are two ways of acquiring an rootfs image as a tar archive. You can either build it on your own using the OpenEmbedded Distribution. Or download it from the openmoko buildhost.

=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===

Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].

=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===

Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.

To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':

IMAGE_FSTYPES = "jffs2 tar"

After that build a new image by issuing:

bitbake openmoko-devel-image

or if you are using the MokoMakefile:

make openmoko-devel-image

After the process finished there will be a ''OpenMoko-....tar'' in the deploy directory, which is your newly created rootfs archive

== Prepare the SD card ==

=== Partioning the SD card ===

u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.
This example shows how to do an example partition using the fdisk utility. Feel free to use the partitioning utility of your liking for this task.

fdisk /dev/mmcblk0

'''''Note:''''' The device file might differ on your system. If you are not sure about it, you may check your kernel message log by calling ''dmesg'' to find the correct device.

We will now create a 8 mb partition for our kernel and another one for the rootfs which will take up all the remaining space.

Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.

=== Formatting the SD card ===

Just issue the following command to create at FAT filesystem:

mkfs.vfat /dev/mmcblk0p1

Note: if you do not have mkfs.vfat you must find and install the "dosfstools" package. This package does not seem to be in the official feeds, but an unofficial build may be downloaded from http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk

The second partition is about to be formatted with ext3 (for ext2 to work you need to make sure you compiled the kernel with the correct configuration):

mkfs.ext3 /dev/mmcblk0p2

== Populate SD card ==

Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.

Mount the second partition of your SD card somewhere and put the image on it:

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

'''''Note:''''' As always in this guide the device name as well as the rootfs name needs to be adjusted to your device and filename structure

'''''Note:''''' There's a nice gotcha to take care about if you use your host OS automount. Some hosts mount these removable devices with "nodev" option by default for security. If the image you are unpacking has a populated /dev directory, the nodes will fail to create as devices then. If auomounting the SD on your host, confirm there are no unexpected mount options by using "mount" command alone to list the mounts.

The next step is to mount the first partition of the sd card and install the kernel on it.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Make sure your kernel is called ''uImage.bin'' after copying it to the card.

Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:

umount /mnt/moko
umount /mnt/mokokernel
sync

== Add uboot boot entry ==
Depending on the revision of the phone and the partition type (ext2/ext3) you are using, it might be necessary to add an entry to the bootmenu to be able to boot the system off your SD card.
If you are using a Freerunner and have created an FAT kernel/ext2 rootfs partition you should be able to boot from the card right out of the box, because a boot menu entry for this should already exist in the NOR/NAND boot menu.
In any other case you should at least make sure the needed entry exists in your menu before proceeding.
You will need to enter the uboot shell of the NAND boot menu for this. A description on how to connect to the uboot loader shell can be found in this article: [[Uboot#Bootloader_prompt]]. Details on howto get into the NAND boot menu can be found [[Booting#Log_into_U-Boot_in_the_NAND_Flash|here]].

After you read these two references you should be connected to your NAND uboot shell right now. The first thing to do is to set the boot menu timeout to a really high value. Unfortunately if you don't do this, the boot loader will continue booting after the default timeout (60 seconds) even if you are connected to the uboot shell. Just enter the following command to the menu prompt:

setenv boot_menu_timeout 99999

This will set the timeout to 99999 seconds which should definitely enough time for us finish whatever work we want accomplish in the boot loader shell.

Now we will make sure a appropriate menu item for booting from sd exists, or create it otherwise. You can print the defined boot loader environment by issuing the command:

printenv

If it shows a line beginning with ''menu_'' followed by the commands which are just to follow in this guide, you do not need to create a new menu entry. In any other case please proceed with the following.

Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see
help
help <command>
and [[Bootloader]] and [[Bootloader commands]].

{{Note| The backslashes (\) are important for uboot to set the command as new environment variable (menu_9) instead of just executing them as soon as enter is pressed.}}

{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}

It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.

'''Boot entry for FAT kernel+ext3 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for FAT kernel+ext2 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
You are nearly done. Just issue a

printenv

and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anyone).

If everything looks fine enter

saveenv

into the prompt and press enter. The new configuration should now be saved to the NAND.

Shutdown your neo with the following command:

neo1973 power-off

After you restarted the Neo and got back to the NAND boot menu you should be able to select your newly created menu entry and successfully boot into the rootfs from your SD card.

== Appendix ==

=== Boot from SDHC ===

{{Note|the following text was written for the Neo1973. SDHC and SD should both work in a Freerunner if you have u-boot from 2008-07-23 or later.}}

As SDHC is currently not supported in u-boot you can't use the Booting from SD guide.
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:

First you can follow Step 1 to get an kernel-image with mmc- and ext2-support. But instead of copying the image to the rootfs you will have to flash it to the Neo's internal NAND-Flash (using [[Dfu-util]]).
Now you can continue with Step 2 (like mentioned before you do not have to copy your uImage to the rootfs) and follow the instructions to Step 3.
Instead of the setenv commands in Step 3 you have to enter the following:

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

And that's it!
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.

=== Autoboot from SDHC ===

Maybe you want to Boot automatically from SDHC:
Set a new Bootmenu Entry for booting from NAND first

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

then Power-off, and enter the Bootmenu to test the new Entry.If you can boot from NAND, shutdown, enter Boot menu, connect to bootloader and set the (auto)bootcmd for boot from SDHC:

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Now you boot from SDHC everytime you press the Power-Button or reboot and if you like to boot from NAND -just use the bootmenu.

=== Fixing udev automount ===

Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarks on Kernel Parameters ===

==== loglevel ====

Some people suggested adding:

loglevel=8

to the kernel command line. IF you also have "console=tty0" on your kernel commandline this makes the boot process extremely slow because the framebuffer (the neo display in text mode) has to print out tons of lines of debug messages like:

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

{{Languages|Booting_from_SD}}

[[Category:Guides]]
[[Category:Flashing Openmoko]]
[[Category:Documentation]]
[[Category:System Developers]]

Booting the Neo FreeRunner from SD via U-Boot

2008-07-30T08:10:04Z

Warmcat: /* Add uboot boot entry */

This page explains how to boot a Freerunner from the SD card rather than from the built-in NAND flash memory. The SD card shares a bus with the GPU, so it may not perform as well, but it is another option.

{{Warning | Booting from SDHC may cause problems at this time. }} See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| this thread.]

== How it Works ==

On the Neo, [[u-boot]] performs a similar role to the 'grub' bootloader on a PC. U-boot loads a kernel image into memory and then passes a list of parameters to the kernel. These parameters specify, among other things, the device on which the root filesystem is located.

As the kernel boots, it initializes the hardware and then mounts the root filesystem. The kernel then runs "/sbin/init", which handles the rest of the boot-up sequence (such as displaying the splash screen and progress bar).

This sequence is the same whether the device is booting from built-in Flash or from the SD card. The differences are how the kernel is loaded, and which device is mounted as the root filesystem.

The following sections provide additional details.

=== Menu Entries ===

U-boot menu entries are defined by environment variables named "menu_X" (where X is a number). The value of the environment variable is a string "<label>:<commands>", where <label> is the text shown on the screen, and <commands> is a sequence of u-boot commands (delimited by ';' characters) to be executed when the menu item is selected. When entering a string of commands, the ';' and '$' characters must be backslash-escaped ("\;" and "\$").

=== Loading the Kernel ===

A pair of u-boot commands must be used to load the kernel from SD. First is "mmcinit", which will cause u-boot to detect the card. Next is a command to load a file into memory - either "fatload" or "ext2load" depending on whether the kernel is on a FAT filesytem or an ext2/ext3 filesystem.

The command syntax is:

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

where is the partition number, and <filepath> is the path to the file that is to be loaded.

{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of Freerunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}

{{Warning | Be careful when updating u-boot on a Neo1973 as there is a risk of bricking the device (unless you have a debug board). This is not an issue for the Freerunner as it has a protected copy of u-boot in the NOR flash }}

{{Note| U-Boot only supports SDHC protocol on Freerunner: on the Neo1973, u-boot is unable to access SDHC cards (4G or larger). The kernel does have SDHC support on Neo1973, so it is possible to have the root filesystem on SDHC and the kernel on NAND flash to work around it. }}

=== Root Filesystem Parameters ===

The contents of the "bootargs" environment variable are passed to the kernel. Bootargs is a space-delimited list of "name=value" definitions. The items relevant to SD-booting are "root", "rootfstype", and "rootdelay".

For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed.

Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command

less /proc/filesystems

It is not possible to use VFAT for the root filesystem.

==== ext2 vs. ext3 ====

Opinion is divided on whether it is better to use ext2 or ext3 for the root filesystem. Ext3 in general is a superior choice, because it is a journalled filesystem and so does not require a long 'fsck' (file system check) after an unclean shutdown. However, if used on a flash device that does not support wear-leveling then ext3 may cause premature wear on the blocks of the card where the journal is stored. SD cards are supposed to support wear leveling, but this can not be guaranteed for all vendors.

== Acquiring a tarfile rootfs ==

There are two ways of acquiring an rootfs image as a tar archive. You can either build it on your own using the OpenEmbedded Distribution. Or download it from the openmoko buildhost.

=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===

Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].

=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===

Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.

To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':

IMAGE_FSTYPES = "jffs2 tar"

After that build a new image by issuing:

bitbake openmoko-devel-image

or if you are using the MokoMakefile:

make openmoko-devel-image

After the process finished there will be a ''OpenMoko-....tar'' in the deploy directory, which is your newly created rootfs archive

== Prepare the SD card ==

=== Partioning the SD card ===

u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.
This example shows how to do an example partition using the fdisk utility. Feel free to use the partitioning utility of your liking for this task.

fdisk /dev/mmcblk0

'''''Note:''''' The device file might differ on your system. If you are not sure about it, you may check your kernel message log by calling ''dmesg'' to find the correct device.

We will now create a 8 mb partition for our kernel and another one for the rootfs which will take up all the remaining space.

Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.

=== Formatting the SD card ===

Just issue the following command to create at FAT filesystem:

mkfs.vfat /dev/mmcblk0p1

Note: if you do not have mkfs.vfat you must find and install the "dosfstools" package. This package does not seem to be in the official feeds, but an unofficial build may be downloaded from http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk

The second partition is about to be formatted with ext3 (for ext2 to work you need to make sure you compiled the kernel with the correct configuration):

mkfs.ext3 /dev/mmcblk0p2

== Populate SD card ==

Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.

Mount the second partition of your SD card somewhere and put the image on it:

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

'''''Note:''''' As always in this guide the device name as well as the rootfs name needs to be adjusted to your device and filename structure

'''''Note:''''' There's a nice gotcha to take care about if you use your host OS automount. Some hosts mount these removable devices with "nodev" option by default for security. If the image you are unpacking has a populated /dev directory, the nodes will fail to create as devices then. If auomounting the SD on your host, confirm there are no unexpected mount options by using "mount" command alone to list the mounts.

The next step is to mount the first partition of the sd card and install the kernel on it.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Make sure your kernel is called ''uImage.bin'' after copying it to the card.

Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:

umount /mnt/moko
umount /mnt/mokokernel
sync

== Add uboot boot entry ==
Depending on the revision of the phone and the partition type (ext2/ext3) you are using, it might be necessary to add an entry to the bootmenu to be able to boot the system off your SD card.
If you are using a Freerunner and have created an FAT kernel/ext2 rootfs partition you should be able to boot from the card right out of the box, because a boot menu entry for this should already exist in the NOR/NAND boot menu.
In any other case you should at least make sure the needed entry exists in your menu before proceeding.
You will need to enter the uboot shell of the NAND boot menu for this. A description on how to connect to the uboot loader shell can be found in this article: [[Uboot#Bootloader_prompt]]. Details on howto get into the NAND boot menu can be found [[Booting#Log_into_U-Boot_in_the_NAND_Flash|here]].

After you read these two references you should be connected to your NAND uboot shell right now. The first thing to do is to set the boot menu timeout to a really high value. Unfortunately if you don't do this, the boot loader will continue booting after the default timeout (60 seconds) even if you are connected to the uboot shell. Just enter the following command to the menu prompt:

setenv boot_menu_timeout 99999

This will set the timeout to 99999 seconds which should definitely enough time for us finish whatever work we want accomplish in the boot loader shell.

Now we will make sure a appropriate menu item for booting from sd exists, or create it otherwise. You can print the defined boot loader environment by issuing the command:

printenv

If it shows a line beginning with ''menu_'' followed by the commands which are just to follow in this guide, you do not need to create a new menu entry. In any other case please proceed with the following.

Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see
help
help <command>
and [[Bootloader]] and [[Bootloader commands]].

{{Note| The backslashes (\) are important for uboot to set the command as new environment variable (menu_9) instead of just executing them as soon as enter is pressed.}}

{{Note| Copy and paste may not work depending on your terminal emulator. Commi (http://linux-source.de/index.php?artid=4&changelang=5) just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}

It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.

'''Boot entry for FAT kernel+ext3 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for FAT kernel+ext2 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
You are nearly done. Just issue a

printenv

and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anyone).

If everything looks fine enter

saveenv

into the prompt and press enter. The new configuration should now be saved to the NAND.

Shutdown your neo with the following command:

neo1973 power-off

After you restarted the Neo and got back to the NAND boot menu you should be able to select your newly created menu entry and successfully boot into the rootfs from your SD card.

== Appendix ==

=== Boot from SDHC ===

{{Note|the following text was written for the Neo1973. SDHC and SD should both work in a Freerunner if you have u-boot from 2008-07-23 or later.}}

As SDHC is currently not supported in u-boot you can't use the Booting from SD guide.
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:

First you can follow Step 1 to get an kernel-image with mmc- and ext2-support. But instead of copying the image to the rootfs you will have to flash it to the Neo's internal NAND-Flash (using [[Dfu-util]]).
Now you can continue with Step 2 (like mentioned before you do not have to copy your uImage to the rootfs) and follow the instructions to Step 3.
Instead of the setenv commands in Step 3 you have to enter the following:

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

And that's it!
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.

=== Autoboot from SDHC ===

Maybe you want to Boot automatically from SDHC:
Set a new Bootmenu Entry for booting from NAND first

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

then Power-off, and enter the Bootmenu to test the new Entry.If you can boot from NAND, shutdown, enter Boot menu, connect to bootloader and set the (auto)bootcmd for boot from SDHC:

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Now you boot from SDHC everytime you press the Power-Button or reboot and if you like to boot from NAND -just use the bootmenu.

=== Fixing udev automount ===

Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarks on Kernel Parameters ===

==== loglevel ====

Some people suggested adding:

loglevel=8

to the kernel command line. IF you also have "console=tty0" on your kernel commandline this makes the boot process extremely slow because the framebuffer (the neo display in text mode) has to print out tons of lines of debug messages like:

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

{{Languages|Booting_from_SD}}

[[Category:Guides]]
[[Category:Flashing Openmoko]]
[[Category:Documentation]]
[[Category:System Developers]]

Booting the Neo FreeRunner from SD via U-Boot

2008-07-30T08:06:48Z

Warmcat: /* loglevel */

This page explains how to boot a Freerunner from the SD card rather than from the built-in NAND flash memory. The SD card shares a bus with the GPU, so it may not perform as well, but it is another option.

{{Warning | Booting from SDHC may cause problems at this time. }} See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| this thread.]

== How it Works ==

On the Neo, [[u-boot]] performs a similar role to the 'grub' bootloader on a PC. U-boot loads a kernel image into memory and then passes a list of parameters to the kernel. These parameters specify, among other things, the device on which the root filesystem is located.

As the kernel boots, it initializes the hardware and then mounts the root filesystem. The kernel then runs "/sbin/init", which handles the rest of the boot-up sequence (such as displaying the splash screen and progress bar).

This sequence is the same whether the device is booting from built-in Flash or from the SD card. The differences are how the kernel is loaded, and which device is mounted as the root filesystem.

The following sections provide additional details.

=== Menu Entries ===

U-boot menu entries are defined by environment variables named "menu_X" (where X is a number). The value of the environment variable is a string "<label>:<commands>", where <label> is the text shown on the screen, and <commands> is a sequence of u-boot commands (delimited by ';' characters) to be executed when the menu item is selected. When entering a string of commands, the ';' and '$' characters must be backslash-escaped ("\;" and "\$").

=== Loading the Kernel ===

A pair of u-boot commands must be used to load the kernel from SD. First is "mmcinit", which will cause u-boot to detect the card. Next is a command to load a file into memory - either "fatload" or "ext2load" depending on whether the kernel is on a FAT filesytem or an ext2/ext3 filesystem.

The command syntax is:

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

where is the partition number, and <filepath> is the path to the file that is to be loaded.

{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of Freerunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}

{{Warning | Be careful when updating u-boot on a Neo1973 as there is a risk of bricking the device (unless you have a debug board). This is not an issue for the Freerunner as it has a protected copy of u-boot in the NOR flash }}

{{Note| U-Boot only supports SDHC protocol on Freerunner: on the Neo1973, u-boot is unable to access SDHC cards (4G or larger). The kernel does have SDHC support on Neo1973, so it is possible to have the root filesystem on SDHC and the kernel on NAND flash to work around it. }}

=== Root Filesystem Parameters ===

The contents of the "bootargs" environment variable are passed to the kernel. Bootargs is a space-delimited list of "name=value" definitions. The items relevant to SD-booting are "root", "rootfstype", and "rootdelay".

For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed.

Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command

less /proc/filesystems

It is not possible to use VFAT for the root filesystem.

==== ext2 vs. ext3 ====

Opinion is divided on whether it is better to use ext2 or ext3 for the root filesystem. Ext3 in general is a superior choice, because it is a journalled filesystem and so does not require a long 'fsck' (file system check) after an unclean shutdown. However, if used on a flash device that does not support wear-leveling then ext3 may cause premature wear on the blocks of the card where the journal is stored. SD cards are supposed to support wear leveling, but this can not be guaranteed for all vendors.

== Acquiring a tarfile rootfs ==

There are two ways of acquiring an rootfs image as a tar archive. You can either build it on your own using the OpenEmbedded Distribution. Or download it from the openmoko buildhost.

=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===

Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].

=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===

Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.

To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':

IMAGE_FSTYPES = "jffs2 tar"

After that build a new image by issuing:

bitbake openmoko-devel-image

or if you are using the MokoMakefile:

make openmoko-devel-image

After the process finished there will be a ''OpenMoko-....tar'' in the deploy directory, which is your newly created rootfs archive

== Prepare the SD card ==

=== Partioning the SD card ===

u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.
This example shows how to do an example partition using the fdisk utility. Feel free to use the partitioning utility of your liking for this task.

fdisk /dev/mmcblk0

'''''Note:''''' The device file might differ on your system. If you are not sure about it, you may check your kernel message log by calling ''dmesg'' to find the correct device.

We will now create a 8 mb partition for our kernel and another one for the rootfs which will take up all the remaining space.

Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.

=== Formatting the SD card ===

Just issue the following command to create at FAT filesystem:

mkfs.vfat /dev/mmcblk0p1

Note: if you do not have mkfs.vfat you must find and install the "dosfstools" package. This package does not seem to be in the official feeds, but an unofficial build may be downloaded from http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk

The second partition is about to be formatted with ext3 (for ext2 to work you need to make sure you compiled the kernel with the correct configuration):

mkfs.ext3 /dev/mmcblk0p2

== Populate SD card ==

Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.

Mount the second partition of your SD card somewhere and put the image on it:

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

'''''Note:''''' As always in this guide the device name as well as the rootfs name needs to be adjusted to your device and filename structure

'''''Note:''''' There's a nice gotcha to take care about if you use your host OS automount. Some hosts mount these removable devices with "nodev" option by default for security. If the image you are unpacking has a populated /dev directory, the nodes will fail to create as devices then. If auomounting the SD on your host, confirm there are no unexpected mount options by using "mount" command alone to list the mounts.

The next step is to mount the first partition of the sd card and install the kernel on it.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Make sure your kernel is called ''uImage.bin'' after copying it to the card.

Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:

umount /mnt/moko
umount /mnt/mokokernel
sync

== Add uboot boot entry ==
Depending on the revision of the phone and the partition type (ext2/ext3) you are using, it might be necessary to add an entry to the bootmenu to be able to boot the system off your SD card.
If you are using a Freerunner and have created an FAT kernel/ext2 rootfs partition you should be able to boot from the card right out of the box, because a boot menu entry for this should already exist in the NOR/NAND boot menu.
In any other case you should at least make sure the needed entry exists in your menu before proceeding.
You will need to enter the uboot shell of the NAND boot menu for this. A description on how to connect to the uboot loader shell can be found in this article: [[Uboot#Bootloader_prompt]]. Details on howto get into the NAND boot menu can be found [[Booting#Log_into_U-Boot_in_the_NAND_Flash|here]].

After you read these two references you should be connected to your NAND uboot shell right now. The first thing to do is to set the boot menu timeout to a really high value. Unfortunately if you don't do this, the boot loader will continue booting after the default timeout (60 seconds) even if you are connected to the uboot shell. Just enter the following command to the menu prompt:

setenv boot_menu_timeout 99999

This will set the timeout to 99999 seconds which should definitely enough time for us finish whatever work we want accomplish in the boot loader shell.

Now we will make sure a appropriate menu item for booting from sd exists, or create it otherwise. You can print the defined boot loader environment by issuing the command:

printenv

If it shows a line beginning with ''menu_'' followed by the commands which are just to follow in this guide, you do not need to create a new menu entry. In any other case please proceed with the following.

Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see
help
help <command>
and [[Bootloader]] and [[Bootloader commands]].

{{Note| The backslashes (\) are important for uboot to set the command as new environment variable (menu_9) instead of just executing them as soon as enter is pressed.}}

{{Note| Copy and paste may not work. To get copy/paste working, you will need the [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}

It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.

'''Boot entry for FAT kernel+ext3 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for FAT kernel+ext2 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
You are nearly done. Just issue a

printenv

and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anyone).

If everything looks fine enter

saveenv

into the prompt and press enter. The new configuration should now be saved to the NAND.

Shutdown your neo with the following command:

neo1973 power-off

After you restarted the Neo and got back to the NAND boot menu you should be able to select your newly created menu entry and successfully boot into the rootfs from your SD card.

== Appendix ==

=== Boot from SDHC ===

{{Note|the following text was written for the Neo1973. SDHC and SD should both work in a Freerunner if you have u-boot from 2008-07-23 or later.}}

As SDHC is currently not supported in u-boot you can't use the Booting from SD guide.
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:

First you can follow Step 1 to get an kernel-image with mmc- and ext2-support. But instead of copying the image to the rootfs you will have to flash it to the Neo's internal NAND-Flash (using [[Dfu-util]]).
Now you can continue with Step 2 (like mentioned before you do not have to copy your uImage to the rootfs) and follow the instructions to Step 3.
Instead of the setenv commands in Step 3 you have to enter the following:

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

And that's it!
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.

=== Autoboot from SDHC ===

Maybe you want to Boot automatically from SDHC:
Set a new Bootmenu Entry for booting from NAND first

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

then Power-off, and enter the Bootmenu to test the new Entry.If you can boot from NAND, shutdown, enter Boot menu, connect to bootloader and set the (auto)bootcmd for boot from SDHC:

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Now you boot from SDHC everytime you press the Power-Button or reboot and if you like to boot from NAND -just use the bootmenu.

=== Fixing udev automount ===

Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarks on Kernel Parameters ===

==== loglevel ====

Some people suggested adding:

loglevel=8

to the kernel command line. IF you also have "console=tty0" on your kernel commandline this makes the boot process extremely slow because the framebuffer (the neo display in text mode) has to print out tons of lines of debug messages like:

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

{{Languages|Booting_from_SD}}

[[Category:Guides]]
[[Category:Flashing Openmoko]]
[[Category:Documentation]]
[[Category:System Developers]]

Booting the Neo FreeRunner from SD via U-Boot

2008-07-30T07:40:03Z

Warmcat: /* Populate SD card */

This page explains how to boot a Freerunner from the SD card rather than from the built-in NAND flash memory. The SD card shares a bus with the GPU, so it may not perform as well, but it is another option.

{{Warning | Booting from SDHC may cause problems at this time. }} See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| this thread.]

== How it Works ==

On the Neo, [[u-boot]] performs a similar role to the 'grub' bootloader on a PC. U-boot loads a kernel image into memory and then passes a list of parameters to the kernel. These parameters specify, among other things, the device on which the root filesystem is located.

As the kernel boots, it initializes the hardware and then mounts the root filesystem. The kernel then runs "/sbin/init", which handles the rest of the boot-up sequence (such as displaying the splash screen and progress bar).

This sequence is the same whether the device is booting from built-in Flash or from the SD card. The differences are how the kernel is loaded, and which device is mounted as the root filesystem.

The following sections provide additional details.

=== Menu Entries ===

U-boot menu entries are defined by environment variables named "menu_X" (where X is a number). The value of the environment variable is a string "<label>:<commands>", where <label> is the text shown on the screen, and <commands> is a sequence of u-boot commands (delimited by ';' characters) to be executed when the menu item is selected. When entering a string of commands, the ';' and '$' characters must be backslash-escaped ("\;" and "\$").

=== Loading the Kernel ===

A pair of u-boot commands must be used to load the kernel from SD. First is "mmcinit", which will cause u-boot to detect the card. Next is a command to load a file into memory - either "fatload" or "ext2load" depending on whether the kernel is on a FAT filesytem or an ext2/ext3 filesystem.

The command syntax is:

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

where is the partition number, and <filepath> is the path to the file that is to be loaded.

{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of Freerunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}

{{Warning | Be careful when updating u-boot on a Neo1973 as there is a risk of bricking the device (unless you have a debug board). This is not an issue for the Freerunner as it has a protected copy of u-boot in the NOR flash }}

{{Note| U-Boot only supports SDHC protocol on Freerunner: on the Neo1973, u-boot is unable to access SDHC cards (4G or larger). The kernel does have SDHC support on Neo1973, so it is possible to have the root filesystem on SDHC and the kernel on NAND flash to work around it. }}

=== Root Filesystem Parameters ===

The contents of the "bootargs" environment variable are passed to the kernel. Bootargs is a space-delimited list of "name=value" definitions. The items relevant to SD-booting are "root", "rootfstype", and "rootdelay".

For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed.

Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command

less /proc/filesystems

It is not possible to use VFAT for the root filesystem.

==== ext2 vs. ext3 ====

Opinion is divided on whether it is better to use ext2 or ext3 for the root filesystem. Ext3 in general is a superior choice, because it is a journalled filesystem and so does not require a long 'fsck' (file system check) after an unclean shutdown. However, if used on a flash device that does not support wear-leveling then ext3 may cause premature wear on the blocks of the card where the journal is stored. SD cards are supposed to support wear leveling, but this can not be guaranteed for all vendors.

== Acquiring a tarfile rootfs ==

There are two ways of acquiring an rootfs image as a tar archive. You can either build it on your own using the OpenEmbedded Distribution. Or download it from the openmoko buildhost.

=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===

Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].

=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===

Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.

To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':

IMAGE_FSTYPES = "jffs2 tar"

After that build a new image by issuing:

bitbake openmoko-devel-image

or if you are using the MokoMakefile:

make openmoko-devel-image

After the process finished there will be a ''OpenMoko-....tar'' in the deploy directory, which is your newly created rootfs archive

== Prepare the SD card ==

=== Partioning the SD card ===

u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.
This example shows how to do an example partition using the fdisk utility. Feel free to use the partitioning utility of your liking for this task.

fdisk /dev/mmcblk0

'''''Note:''''' The device file might differ on your system. If you are not sure about it, you may check your kernel message log by calling ''dmesg'' to find the correct device.

We will now create a 8 mb partition for our kernel and another one for the rootfs which will take up all the remaining space.

Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.

=== Formatting the SD card ===

Just issue the following command to create at FAT filesystem:

mkfs.vfat /dev/mmcblk0p1

Note: if you do not have mkfs.vfat you must find and install the "dosfstools" package. This package does not seem to be in the official feeds, but an unofficial build may be downloaded from http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk

The second partition is about to be formatted with ext3 (for ext2 to work you need to make sure you compiled the kernel with the correct configuration):

mkfs.ext3 /dev/mmcblk0p2

== Populate SD card ==

Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.

Mount the second partition of your SD card somewhere and put the image on it:

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

'''''Note:''''' As always in this guide the device name as well as the rootfs name needs to be adjusted to your device and filename structure

'''''Note:''''' There's a nice gotcha to take care about if you use your host OS automount. Some hosts mount these removable devices with "nodev" option by default for security. If the image you are unpacking has a populated /dev directory, the nodes will fail to create as devices then. If auomounting the SD on your host, confirm there are no unexpected mount options by using "mount" command alone to list the mounts.

The next step is to mount the first partition of the sd card and install the kernel on it.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Make sure your kernel is called ''uImage.bin'' after copying it to the card.

Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:

umount /mnt/moko
umount /mnt/mokokernel
sync

== Add uboot boot entry ==
Depending on the revision of the phone and the partition type (ext2/ext3) you are using, it might be necessary to add an entry to the bootmenu to be able to boot the system off your SD card.
If you are using a Freerunner and have created an FAT kernel/ext2 rootfs partition you should be able to boot from the card right out of the box, because a boot menu entry for this should already exist in the NOR/NAND boot menu.
In any other case you should at least make sure the needed entry exists in your menu before proceeding.
You will need to enter the uboot shell of the NAND boot menu for this. A description on how to connect to the uboot loader shell can be found in this article: [[Uboot#Bootloader_prompt]]. Details on howto get into the NAND boot menu can be found [[Booting#Log_into_U-Boot_in_the_NAND_Flash|here]].

After you read these two references you should be connected to your NAND uboot shell right now. The first thing to do is to set the boot menu timeout to a really high value. Unfortunately if you don't do this, the boot loader will continue booting after the default timeout (60 seconds) even if you are connected to the uboot shell. Just enter the following command to the menu prompt:

setenv boot_menu_timeout 99999

This will set the timeout to 99999 seconds which should definitely enough time for us finish whatever work we want accomplish in the boot loader shell.

Now we will make sure a appropriate menu item for booting from sd exists, or create it otherwise. You can print the defined boot loader environment by issuing the command:

printenv

If it shows a line beginning with ''menu_'' followed by the commands which are just to follow in this guide, you do not need to create a new menu entry. In any other case please proceed with the following.

Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see
help
help <command>
and [[Bootloader]] and [[Bootloader commands]].

{{Note| The backslashes (\) are important for uboot to set the command as new environment variable (menu_9) instead of just executing them as soon as enter is pressed.}}

{{Note| Copy and paste may not work. To get copy/paste working, you will need the [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}

It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.

'''Boot entry for FAT kernel+ext3 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for FAT kernel+ext2 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
You are nearly done. Just issue a

printenv

and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anyone).

If everything looks fine enter

saveenv

into the prompt and press enter. The new configuration should now be saved to the NAND.

Shutdown your neo with the following command:

neo1973 power-off

After you restarted the Neo and got back to the NAND boot menu you should be able to select your newly created menu entry and successfully boot into the rootfs from your SD card.

== Appendix ==

=== Boot from SDHC ===

{{Note|the following text was written for the Neo1973. SDHC and SD should both work in a Freerunner if you have u-boot from 2008-07-23 or later.}}

As SDHC is currently not supported in u-boot you can't use the Booting from SD guide.
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:

First you can follow Step 1 to get an kernel-image with mmc- and ext2-support. But instead of copying the image to the rootfs you will have to flash it to the Neo's internal NAND-Flash (using [[Dfu-util]]).
Now you can continue with Step 2 (like mentioned before you do not have to copy your uImage to the rootfs) and follow the instructions to Step 3.
Instead of the setenv commands in Step 3 you have to enter the following:

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

And that's it!
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.

=== Autoboot from SDHC ===

Maybe you want to Boot automatically from SDHC:
Set a new Bootmenu Entry for booting from NAND first

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

then Power-off, and enter the Bootmenu to test the new Entry.If you can boot from NAND, shutdown, enter Boot menu, connect to bootloader and set the (auto)bootcmd for boot from SDHC:

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Now you boot from SDHC everytime you press the Power-Button or reboot and if you like to boot from NAND -just use the bootmenu.

=== Fixing udev automount ===

Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarks on Kernel Parameters ===

==== loglevel ====

Some people suggested adding:

loglevel=8

to the kernel command line. This makes the boot process extremely slow because
the framebuffer (the neo display in text mode) has to print out tons of lines of
debug messages like:

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

{{Languages|Booting_from_SD}}

[[Category:Guides]]
[[Category:Flashing Openmoko]]
[[Category:Documentation]]
[[Category:System Developers]]

Booting the Neo FreeRunner from SD via U-Boot

2008-07-30T07:36:06Z

Warmcat: /* Loading the Kernel */

This page explains how to boot a Freerunner from the SD card rather than from the built-in NAND flash memory. The SD card shares a bus with the GPU, so it may not perform as well, but it is another option.

{{Warning | Booting from SDHC may cause problems at this time. }} See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| this thread.]

== How it Works ==

On the Neo, [[u-boot]] performs a similar role to the 'grub' bootloader on a PC. U-boot loads a kernel image into memory and then passes a list of parameters to the kernel. These parameters specify, among other things, the device on which the root filesystem is located.

As the kernel boots, it initializes the hardware and then mounts the root filesystem. The kernel then runs "/sbin/init", which handles the rest of the boot-up sequence (such as displaying the splash screen and progress bar).

This sequence is the same whether the device is booting from built-in Flash or from the SD card. The differences are how the kernel is loaded, and which device is mounted as the root filesystem.

The following sections provide additional details.

=== Menu Entries ===

U-boot menu entries are defined by environment variables named "menu_X" (where X is a number). The value of the environment variable is a string "<label>:<commands>", where <label> is the text shown on the screen, and <commands> is a sequence of u-boot commands (delimited by ';' characters) to be executed when the menu item is selected. When entering a string of commands, the ';' and '$' characters must be backslash-escaped ("\;" and "\$").

=== Loading the Kernel ===

A pair of u-boot commands must be used to load the kernel from SD. First is "mmcinit", which will cause u-boot to detect the card. Next is a command to load a file into memory - either "fatload" or "ext2load" depending on whether the kernel is on a FAT filesytem or an ext2/ext3 filesystem.

The command syntax is:

fatload mmc 1: 0x32000000 <filepath>
ext2load mmc 1: 0x32000000 <filepath>

where is the partition number, and <filepath> is the path to the file that is to be loaded.

{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of Freerunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}

{{Warning | Be careful when updating u-boot on a Neo1973 as there is a risk of bricking the device (unless you have a debug board). This is not an issue for the Freerunner as it has a protected copy of u-boot in the NOR flash }}

{{Note| U-Boot only supports SDHC protocol on Freerunner: on the Neo1973, u-boot is unable to access SDHC cards (4G or larger). The kernel does have SDHC support on Neo1973, so it is possible to have the root filesystem on SDHC and the kernel on NAND flash to work around it. }}

=== Root Filesystem Parameters ===

The contents of the "bootargs" environment variable are passed to the kernel. Bootargs is a space-delimited list of "name=value" definitions. The items relevant to SD-booting are "root", "rootfstype", and "rootdelay".

For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:

root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5

The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed.

Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command

less /proc/filesystems

It is not possible to use VFAT for the root filesystem.

==== ext2 vs. ext3 ====

Opinion is divided on whether it is better to use ext2 or ext3 for the root filesystem. Ext3 in general is a superior choice, because it is a journalled filesystem and so does not require a long 'fsck' (file system check) after an unclean shutdown. However, if used on a flash device that does not support wear-leveling then ext3 may cause premature wear on the blocks of the card where the journal is stored. SD cards are supposed to support wear leveling, but this can not be guaranteed for all vendors.

== Acquiring a tarfile rootfs ==

There are two ways of acquiring an rootfs image as a tar archive. You can either build it on your own using the OpenEmbedded Distribution. Or download it from the openmoko buildhost.

=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===

Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].

=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===

Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.

To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':

IMAGE_FSTYPES = "jffs2 tar"

After that build a new image by issuing:

bitbake openmoko-devel-image

or if you are using the MokoMakefile:

make openmoko-devel-image

After the process finished there will be a ''OpenMoko-....tar'' in the deploy directory, which is your newly created rootfs archive

== Prepare the SD card ==

=== Partioning the SD card ===

u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.
This example shows how to do an example partition using the fdisk utility. Feel free to use the partitioning utility of your liking for this task.

fdisk /dev/mmcblk0

'''''Note:''''' The device file might differ on your system. If you are not sure about it, you may check your kernel message log by calling ''dmesg'' to find the correct device.

We will now create a 8 mb partition for our kernel and another one for the rootfs which will take up all the remaining space.

Command (m for help): d
Selected partition 1
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-983, default 1):
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 2
First cylinder (18-983, default 18):
Using default value 18
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):
Using default value 983
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.

=== Formatting the SD card ===

Just issue the following command to create at FAT filesystem:

mkfs.vfat /dev/mmcblk0p1

Note: if you do not have mkfs.vfat you must find and install the "dosfstools" package. This package does not seem to be in the official feeds, but an unofficial build may be downloaded from http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk

The second partition is about to be formatted with ext3 (for ext2 to work you need to make sure you compiled the kernel with the correct configuration):

mkfs.ext3 /dev/mmcblk0p2

== Populate SD card ==

Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.

Mount the second partition of your SD card somewhere and put the image on it:

mount /dev/mmcblk0p2 /mnt/moko
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz

'''''Note:''''' As always in this guide the device name as well as the rootfs name needs to be adjusted to your device and filename structure

The next step is to mount the first partition of the sd card and install the kernel on it.

mount /dev/mmcblk0p1 /mnt/mokokernel
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin

Make sure your kernel is called ''uImage.bin'' after copying it to the card.

Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:

umount /mnt/moko
umount /mnt/mokokernel
sync

== Add uboot boot entry ==
Depending on the revision of the phone and the partition type (ext2/ext3) you are using, it might be necessary to add an entry to the bootmenu to be able to boot the system off your SD card.
If you are using a Freerunner and have created an FAT kernel/ext2 rootfs partition you should be able to boot from the card right out of the box, because a boot menu entry for this should already exist in the NOR/NAND boot menu.
In any other case you should at least make sure the needed entry exists in your menu before proceeding.
You will need to enter the uboot shell of the NAND boot menu for this. A description on how to connect to the uboot loader shell can be found in this article: [[Uboot#Bootloader_prompt]]. Details on howto get into the NAND boot menu can be found [[Booting#Log_into_U-Boot_in_the_NAND_Flash|here]].

After you read these two references you should be connected to your NAND uboot shell right now. The first thing to do is to set the boot menu timeout to a really high value. Unfortunately if you don't do this, the boot loader will continue booting after the default timeout (60 seconds) even if you are connected to the uboot shell. Just enter the following command to the menu prompt:

setenv boot_menu_timeout 99999

This will set the timeout to 99999 seconds which should definitely enough time for us finish whatever work we want accomplish in the boot loader shell.

Now we will make sure a appropriate menu item for booting from sd exists, or create it otherwise. You can print the defined boot loader environment by issuing the command:

printenv

If it shows a line beginning with ''menu_'' followed by the commands which are just to follow in this guide, you do not need to create a new menu entry. In any other case please proceed with the following.

Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see
help
help <command>
and [[Bootloader]] and [[Bootloader commands]].

{{Note| The backslashes (\) are important for uboot to set the command as new environment variable (menu_9) instead of just executing them as soon as enter is pressed.}}

{{Note| Copy and paste may not work. To get copy/paste working, you will need the [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}

It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.

'''Boot entry for FAT kernel+ext3 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for FAT kernel+ext2 rootfs partitions:'''

setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000

'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''

setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000
You are nearly done. Just issue a

printenv

and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anyone).

If everything looks fine enter

saveenv

into the prompt and press enter. The new configuration should now be saved to the NAND.

Shutdown your neo with the following command:

neo1973 power-off

After you restarted the Neo and got back to the NAND boot menu you should be able to select your newly created menu entry and successfully boot into the rootfs from your SD card.

== Appendix ==

=== Boot from SDHC ===

{{Note|the following text was written for the Neo1973. SDHC and SD should both work in a Freerunner if you have u-boot from 2008-07-23 or later.}}

As SDHC is currently not supported in u-boot you can't use the Booting from SD guide.
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:

First you can follow Step 1 to get an kernel-image with mmc- and ext2-support. But instead of copying the image to the rootfs you will have to flash it to the Neo's internal NAND-Flash (using [[Dfu-util]]).
Now you can continue with Step 2 (like mentioned before you do not have to copy your uImage to the rootfs) and follow the instructions to Step 3.
Instead of the setenv commands in Step 3 you have to enter the following:

GTA01Bv4 # setenv menu_5 Boot from SDHC: setenv bootargs root=/dev/mmcblk0p1 console=tty0 rootdelay=5 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

And that's it!
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.

=== Autoboot from SDHC ===

Maybe you want to Boot automatically from SDHC:
Set a new Bootmenu Entry for booting from NAND first

GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

then Power-off, and enter the Bootmenu to test the new Entry.If you can boot from NAND, shutdown, enter Boot menu, connect to bootloader and set the (auto)bootcmd for boot from SDHC:

GTA01Bv4 # setenv bootcmd setenv bootargs root=/dev/mmcblk0p1 rootdelay=10 console=tty0 neo1973-nand:0x00040000(u-boot),0x00004000(u-boot_env),0x00200000(kernel),0x000a0000(splash)\; nand read.e 0x32000000 kernel\; bootm 0x32000000
GTA01Bv4 # saveenv

Now you boot from SDHC everytime you press the Power-Button or reboot and if you like to boot from NAND -just use the bootmenu.

=== Fixing udev automount ===

Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with

echo /dev/mmcblk >> /etc/udev/mount.blacklist

=== Remarks on Kernel Parameters ===

==== loglevel ====

Some people suggested adding:

loglevel=8

to the kernel command line. This makes the boot process extremely slow because
the framebuffer (the neo display in text mode) has to print out tons of lines of
debug messages like:

s3c2410-sdi s3c2410-sdi: ......
mmc0: ....

{{Languages|Booting_from_SD}}

[[Category:Guides]]
[[Category:Flashing Openmoko]]
[[Category:Documentation]]
[[Category:System Developers]]

Finding hardware revision

2008-07-25T19:30:09Z

Warmcat:

NOTE! The string found in /proc/cpuinfo IS NOT A RELIABLE INDICATOR OF WHICH HARDWARE YOU HAVE! [citation needed -- for shipping A5 and A6 PCBs it should be perfectly reliable]

You will need to login via [[USB Networking]] or otherwise SSH into your FreeRunner, and find the hardware revision as follows:

<pre>
root@om-gta02:~# libgsmd-tool -m shell
libgsm-tool - (C) 2006-2007 by Harald Welte and OpenMoko, Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

rv
# # Get revision
revision: "HW: GTA02BV5, GSM:
gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko8"
</pre>

[[Category:Hardware]]

GTA02 sysfs

2008-07-23T11:28:52Z

Warmcat: New page: ==GTA02 Kernel sysfs highlights== sysfs is a filesystem that is mounted on /sys which contains various fake "files" that are actually filled by a variety of drive...

==GTA02 Kernel sysfs highlights==
sysfs is a filesystem that is mounted on /sys which contains various fake "files" that are actually filled by a variety of drivers and other kernel subsystems. You can often also write stuff into these "files" using

echo 1 > /sys/blah...

to change settings and behaviours of the kernel and drivers dynamically. (When doing this, take care you have a space before the redirection operator > or the shell will do something completely different with your command.)

===USB Host / Device===
====/sys/devices/platform/neo1973-pm-host.0/hostmode====
* Defaults to 0, GTA02 USB hardware is configured to be a device, no power is generated for USB, charging is enabled and host 15K pulldowns are removed from D+ and D-
* Set to 1 to put the GTA02 USB hardware into host mode, so it starts to generate 5V power, disables charging from USB, and applies 15K pulldowns to USB D+ and D-
====/sys/devices/platform/s3c2410-ohci/usb_mode====
* Defaults to "device", it means the USB peripheral in the CPU is logically configured for device mode
* Set to "host" to logically configure the peripheral to act like a host for other USB devices to be plugged into it

Normally you set these two guys at the same time for the same mode, but there is a trick possible to select logical host mode but leave the power arrangements as if it was in device mode and apply external power. You need to externally add 15K pulldowns on D+ and D- if you do this, because we did not enable them the normal way. With this, you can have a USB device attached to GTA02, and use external power and charge the battery at the same time.

===GSM Subsystem===
====/sys/devices/platform/neo1973-pm-gsm.0/power_on====
* Defaults to "0", GSM power OFF
* Set to "1" to enable power to GSM logic
====/sys/devices/platform/neo1973-pm-gsm.0/reset====
* Defaults to "0", no reset
* Set to "1" briefly after power applied to reset GSM logic
====/sys/devices/platform/neo1973-pm-gsm.0/download====
* Defaults to "0", no insane clicking sound
* Set to "1" to drive yourself crazy and enable serial access to GSM chips down headphone socket / once a second loud clicks / chirps

===Resume Reason===
====/sys/devices/platform/neo1973-resume.0/resume_reason====
If you cat this you get a list of possible resume sources in text with one or more * at the left of the active source that woke us. You need a recent U-Boot to get the * set.

===MEMCONFIG===
====/sys/devices/platform/neo1973-memconfig.0/BANKCON0 .. 7====
For extreme meddlers (I salute you), these let you control the wait states and other characteristics of the memory regions of the Freerunner. Information and warnings about how to use these are here:

http://git.openmoko.org/?p=kernel.git;a=commitdiff;h=fd25f90517322fc6c07bfb8d34752d3cb41cb4b6

===FIQ and HDQ===
====/sys/devices/platform/sc32440_fiq.0/fiq/count====
FIQ is used to provide precision interrupt service in order to implement the HDQ protocol used to the battery couloumb counter. This shows how many FIQ interrupts have been run since the kernel started. It's turned off unless it is required.
====/sys/devices/platform/gta02-hdq.0/hdq/dump====
If you cat this, you will see the raw contents of HDQ device register space. This is the bq27000 couloumb counter in our case.
====/sys/devices/platform/gta02-hdq.0/hdq/write====
This allows you to write to raw HDQ registers, using "<decimal register index> <decimal value>"

===power_supply battery information===
Most of these are coming from the coulomb counter over HDQ dynamically, but the bq27000 does not update a lot of its registers any more often than once per 4 seconds. Therefore a lot of this info can be a bit stale or averaged over that period.
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/type====
Just says "Battery"
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/status====
This will summarize what goes on generally with the battery
* "Not Charging" - there's a charger in, but right now it isn't charging us. Normal if you are fully charged and still powered.
* "Charging" - there's a charger in and it is charging the battery
* "Discharging" - we are running on battery
* "Full" - not normally given as a result (Not Charging used instead)
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/voltage_now====
Battery voltage in uV, averaged. Obviously this depends on load and place on discharge curve, etc.
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/current_now====
Current being drawn from battery (+ve) or pushed into battery during charging (-ve) in uA
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/charge_full====
Coulomb Counter's estimate of the capacity of the battery measured in uA/h. It roughly means that if full, for one hour it could supply current at this rate. I saw 1197913 reported on mine, so it estimates it can provide 1.2A for an hour.
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/temp====
This is the battery temperature reported by the Coulomb Counter chip that is part of the physical battery. It is in Celcius * 10, so 251 means 25.1 degrees.
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/technology====
"Li-ion"
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/present====
* "0" the battery is absent, or not one with a Coulomb Counter
* "1" the smart battery is present
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/time_to_empty_now====
At current rate of discharge, estimate of how long we can run for. If battery is not discharging, it won't make an estimate and will return a magic value "3932100" meaning "no estimate". The coulomb counter averages the load and adjusts this value slowly to be its estimate of when we will blow chunks.
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/time_to_full_now====
This estimates how long until we are fully charged, at current rate of charging, in seconds. If we are not charging, it gives the magic value "3932100" meaning "no estimate".
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/capacity====
This is the remaining capacity of charge in the battery in percent. This is probably the most useful figure here.
====/sys/devices/platform/bq27000-battery.0/power_supply/bat/online====
* "0" no charger is present
* "1" A powered charger is present

===PMU info===
====/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/chgmode====
* "enabled" means the charger is powered and willing to charge, although if you're full it might not be right now
* "disabled" means there was no power or not enough power supplied to charge
====/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/charger_type====
Shows the detected charger type followed by the mode it is running in. So "charger 500mA mode 100mA" would be the case for non-enumerated USB connection, "charger 500mA mode 500mA" for after enumeration.
====/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/force_usb_limit_dangerous====
This is added to allow the PMU to be told to take more current than the default rules allow. Use it only if you know your charger source can handle it. For example

echo 500 > /sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/force_usb_limit_dangerous

will allow PMU to draw 500mA even though you are connected to a dumb charger where the limit is normally held at 100mA, since it didn't enumerate the GTA02. You can give 0, 100, 500 or 1000 here, but make sure your charger source can handle what you give here, otherwise it can exceed what is safe for your charging source to provide.
====/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/dump_regs====
cat this to get a dump of the I2C registers for the PMU, useful for debugging power problems.

===Bluetooth===
====/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/neo1973-pm-bt.0/power_on====
* Default "0" no power to Bluetooth device
* set to "1" to enable power to Bluetooth
====/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/neo1973-pm-bt.0/reset====
* Default to "0", no reset
* set to "1" to reset BT (needed after powerup)

===GPS===
====/sys/devices/platform/s3c2440-i2c/i2c-adapter/i2c-0/0-0073/neo1973-pm-gps.0/pwron====
* Default "0" GPS unpowered
* set to "1" to power GPS section

===Audio codec===
====/sys/devices/platform/soc-audio/codec_reg====
cat this to get a dump of codec registers. Note they are 9-bit wide.
====/sys/devices/platform/soc-audio/codec_reg_write====
You can write to any codec register by echoing "<codec reg index in hex> <value in hex>" to here

===Glamo===
====/sys/devices/platform/glamo3362.0/regs====
cat this to get a dump of selected Glamo regs. You can write the regs by echoing "<glamo reg index in decimal> <value in decimal>" here.

Neo FreeRunner Hardware

2008-03-12T11:49:18Z

Warmcat: /* USB Host */

[[OpenMoko]] is a software distribution stack that sits on top of a [[hardware]] platform. The [[Neo FreeRunner]] phone is the second hardware platform to take advantage of OpenMoko. You can find specifics of the hardware by reviewing this introduction page and the pages in the category as shown at the bottom of this page.

{{note|This page is about hardware that is currently in '''design/prototype''' phase, changes are frequent}}

[[Image:Gta02a5 pcba cs.JPG|thumb|400px|display (top) side NOTE: GTA02 A5 PCBA Component Side photo]]
[[Image:Gta02a5 pcba ps.JPG|thumb|400px|component (back) side NOTE: GTA02 A5 PCBA Print Side photo]]
[[Image:GTA02 A5 PCB CS.jpg|thumb|400px|component (back) side NOTE: GTA02 A5 PCB Component Side photo]]
[[Image:GTA02 A5 PCB PS.jpg|thumb|400px|component (back) side NOTE: GTA02 A5 PCB Print Side photo]]

=Summary=
*FIC building a Linux based smart phone with full GPL compatible firmware source code for OPENMOKO, project code named GTA02 (Neo FreeRunner)

Detail hardware component selection could be found in [[Neo FreeRunner GTA02 Hardware]]

=Features=
*Display- Topply o2.8, 480 x 640 pixels, VGA, 200 NIT minimum, resistance type touch

*User Interface Navigation- Touch screen on LCD, 2 control “buttons”, 1 Power button, 1 Aux for 911 emergency call

*Built in 802.11b/g Radio (Atheros chipset AR6001 Flash version)

*Built in Bluetooth 2.0 + EDR (CSR and support PCM audio , BC4 frimware version)

*Built in 2D/3D graphics acceleration chip (S-Media 3362)

*Built in 2x Tri-Axis sensor (ST accelerometer LIS3LV02DL)

*Built in GPS Radio – -130 dbm with internal antenna, -157 dbm tracking on chipset specification , TTFF under 40 seconds with -130 dbm signal strength, and tracking (u-Blox)

*Antenna – Specialized antenna for best in hand hold GPS, GPRS and Wi-Fi/Bluetooth performance are required, -105dbm on receiving, Tx 30dbm+2 on GSM

*External Antennae – MMCX GPS connector

*GPRS Radio –GSM/GPRS radio. A Pre-PTCRB certified module will be preferred

*Linux – Linux kernel 2.6.24 or later OpenMoko kernel

*USB - Client and Host mode switch-able (to be used for software downloading), provide host 5v power

*Power- Normal mode power will be via 1200 mAh battery with built-in coulomb counter, could charge via specialized charger. Internal Lithium Ion or Lithium Polymer battery will keep device in standby mode. Battery life (Approximation/Ideal Target) Standby time 150-200 Hrs (GSM) Talk time (Backlight off) Up to 3-4 hrs(GSM)

*LED- LED indicator under Aux/Power button key

=Hardware Specification=
===Hardware Electrical===

*400/500 MHz Samsung 2442B Processor/SOC (400 minimum)
*Boot code in NAND FLASH or 2MB NOR FLASH (optional design)
*128 MB SDRAM total, 64 MB CPU internal, 64 MB external
*256MB NAND Flash MCP package.

=== Display ===
*Topploy VGA ; 2.8” diagonal, 480 x 640 pixels
*Transmissive display: good readability in high ambient light is essential
*White LED backlight. Required brightness is 200 NIT minimum.
*Resistance type touch panel.

=== WiFi 802.11 b/g transceiver ===
*Must have GPL support source or GPL compatible policy
*TX power at 11 Mbps: 13 dBm minimum
*RX sensitivity at 11 Mbps: -89 dBm desired, -83 dBm minimum
*AP mode desirable, not required
*WEP and WPA supported
*Atheros perferred because it's GPL policy

=== Serial interfaces (UART) ===
*Three serial interfaces are required
*Console
*A-GPS or GPS
*GSM/GPRS

=== Accelerometer ===
* 2x accelerometer required
* Could support interrupt while suspend or power save mode
* 3 axis sensing

=== A-GPS ===
*GPS chipset receiver and antenna
*Sensitivity at Antenna port: -157 dBm tracking on chipset specifiaction
*LNA and SAW filter for maximum interference protection
*Cold start time to first fix: 40 sec typical at -130 dBm, 60 sec max
*Must support GPL for Assist-GPS function with open API
*Industry quality GPS
*Could fit in GTA01 GPS area on the PCB

=== GPS Antenna Performance ===
*Antenna is passive and internal; 15 mm x 15 mm ceramic patch is nominal design
*Antenna LNA and SAW filter are required to meet GPS performance
*15 mm square ground plane (minimum 1 mm ground border around patch) (TBA)
*There will be one external GPS antenna connector (MMCX)
*C/N ratio should higher than 35 on production testing

=== Buttons ===
*Touch screen over LCD is primary data entry mechanism
*Two “hard” buttons: Power button (on side of Neo1973) is a mechanical switch actuated by a plastic pushbutton in a hole in the housing. Aux (911) button on the top of the device, All two of these buttons, when pushed by the operator, are binary inputs (on/off or pressed/not pressed) to the software. The effect of each button is determined by the application software in the device
*Buttons may need to be backlit
*50000 cycles on hardware specification

=== Sound outputs ===
*Speaker in box (need good volume and acoustic behavior innoise environment)
*Audio is monophonic*Max volume: 100 dB at 5 cm to assure good performance in environment.
*Support earphone with mic by jack

=== Power Design Requirements===
*Software based power managment uint perferred
*NXP PCF series perferred
*Need support charge from USB function
*Need support powered by USB function
*Power switch: Neo1973 will have a power switch, for power on/off and suspend
* Power/Aux switch must be backlit
*Switch controls whether device is running or suspended by presses of the switch
*Switch does not shut off the power; it only suspends/resumes the device
*Internal Li-Ion or Li-Polymer battery is included. This battery supplies standby power to the device eliminates the rebooting of the device when local power is again reapplied. Battery is 1200 ma-hr.
*Battery life (Approximation) Ideal/Target Standby time 150-200 Hrs (GSM) Talk time (Backlight off) Up to 4 hrs(GSM)
*Estimated current draw for the entire device when in suspend mode (and ALL peripherals are turned off or set for deep sleep) is <5 mA at 3.6 volts (LiIon terminal voltage).
*GSM module deep sleep(alive and keep contact with base station) stage should take less than 8mA
*Battery will reach half capacity (~600 ma-hr) with 500 charge-discharge cycles. This will occur in less than 2 years of daily service.
*When powered continuously, Neo1973 must suspend (to low power mode) based either on observed low battery voltage condition or a configurable time delay.
*Neo1973 must monitor battery status while suspended and resume automatically if the charger is inserted.
*Primary power connection: 1200mAh battery
*USB charger have ID pin 47.5k pull down for OPENMOKO identification
*Indicators: an LED indicator visible from the side of the unit will illuminate when charging or have missing incoming call

=== GSM/GPRS ===
*850/1800/1900 and 900/1800/1900 MHz bands must be supported
*Design should allow for multi-band version (850/900 MHz)
*Module based GPRS transceiver could meeting PTCRB and appropriate FCC certifications. It preferred that the module be pre-certified with PTCRB or OTA test
*FCC/CE certification required for GSM/GPRS part

=== GSM-GPRS Antenna Performance ===
*-105 dBm receiving on each channel (GSM/PCS)
*30+2 dBm transmission on GSM channel

=== Wi-Fi Modules ===
*Must support GPL driver
*Atheros AR6k perferred
*Flash version required

=== Wi-Fi Antenna Performance ===
*The Wi-Fi antenna with TX 13 to 15 dBm
*RX -89 to -83 dBm @802.11b 11Mbps or an equivalent performance antenna

=== Bluetooth ===
*CSR BC4 or later solutions

=== USB ===
*Neo1973 GTA02 will have USB, client/host. Using USB 1.1
*Could provide USB host 5v power
*Could be powered by USB

=== Microphone ===
1 microphone is in the device

=== Firmware Image ===
*Using Linux 2.6.24 or later
*Could support boot from NAND or Boot from NOR
*Shiiping image should come with basic phone function
*Could do full firmware upgrade by USB cable

=== PSN ===
*Device will have a PSN (product serial number) printed on the product label and machine readable in system NAND memory

=== IMEI ===
*Production phase should have IMEI code wriiten

= Package Specification =
*Weight: ~150 grams with battery.
*4 in 1 laser pen passed RoHs and safty regulation for laser equipment safty
*1x 512MB microSD Card (SandDisk/Trendcend)
*1x USB cable Standard A to mini-B connector
*1x 1200mAh smart/gauge battery
*Quick start guide
*5v USB power cord w/100-240 switchable power plug
*Safety card, warrantee card
*Package could pass 1m to 1.5m drop test
*AC USB charger,100v-240v, Passed UL and all required safty regulation
*Must pass FCC/CE certification
*Must pass NCC certification for Taiwain import regulation
*RoHS Compatible
*WEEE Report required

= Life Cycle Specification =

=== Product Life ===
The product is designed to last a minimum of 2 years.

=== Operating Temperature ===
*Target operating range is –10°C to +60°C

=== Storage Temperature ===
*-15 deg C to +70 deg C

=== ESD ===
The device can withstand a 4.0kV contact discharge and 8.0kV air

=== Drop test ===
Should pass 1m direct drop to concrete ground or 1.5m on slide with carpet

[[Category:Hardware ]]
[[Category:Supported Phone| ]]
[[Category:GTA02 Hardware]]

= GTA02 Hardware Component Selection =

== Physical Dimensions ==
* 120.7 x 62 x 18.5 mm (4.75 x 2.44 x 0.728 inch)
* 110 +/- 5 g (4 ounces) without battery 

== Main components ==
=== Processor ===
The main Processor (CPU) of the Neo1973 GTA02 is a [[Samsung S3C2442B B54]] (running at 400 MHz)

* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=SC32442 Samsung SC32442B]
* User Manual: FIXME
* Core: ARM920T
* Instruction Set: ARMv4 (Android ''currently'' requires ARMv5)
* Built-in 64MB SDRAM
* Built-in 256 MB NAND
* Could run at 500Mhz
* GPIO Assignments: https://svn.openmoko.org/trunk/doc/hardware/GTA02v4/gpio.txt 
* Evaluation board: [http://www.meritech.co.kr/products/product_view.php?num=52 S3C2442 EVB]

=== Power Management ===
A NXP PCF50633 04 N3 is used for [[Neo1973_Power_Management|power management]].

* NXP PMU index: [http://www.nxp.com/products/power_management/pmu/index.html NXP PMU index page] 
* Product Datasheet: [http://people.openmoko.org/tony_tu/GTA02/datasheet/PMU/PCF50633DS_02.pdf NXP PCF50633 Product Data Sheet] 
* Product User manual: [http://people.openmoko.org/tony_tu/GTA02/datasheet/PMU/PCF50633UM_6.pdf NXP PCF50633 User Manual] 
**Special thanks NXP provide full user manual and support openness for all developer
**Datasheet/User manual usage [http://lists.openmoko.org/pipermail/community/2008-March/013898.html was legally authorized by NXP]
* Connected to: S3C2442 via I2C, client address is 0x08. 
* Driver Source: https://svn.openmoko.org/trunk/src/target/kernel/patches/pcf50633.patch 

=== Flash ===
==== NAND Flash ====
256MB integrated Samsung NAND flash inside the 2442 multi-chip package, attached to the S3C2442 NAND controller

* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=SC32442 S3C2442]
* Data Sheet: S3C2442 B54 comes with 256 MB NAND MCP package
* Connected to: S3C2442 NAND controller 

==== NOR Flash ====

16MBit ST M58WR016KB706E NOR flash for 'unbrickable emergency boot' feature.

* Product Homepage: [http://www.st.com/stonline/products/families/memories/fl_nor_mob/index.htm ST Mobile Flash NOR/Mobile Terminal]
* Data Sheet: FIXME
* Connected to: S3C2442 NAND controller 

=== SDRAM ===
128MB SDRAM (64MB inside 2442 MCP, 1x Samsung K4M51323PC) attached to S3C2442 SDRAM controller
* Product Homepage: [http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=136&partnum=K4M51323PC Samsung K4M51323PC]
* Data Sheet: [http://www.samsung.com/global/system/business/semiconductor/product/2007/6/11/MobileSDRAM/MobileSDRSDRAM/512Mbit/K4M51323PC/ds_k4m51323pc.pdf Samsung K4M51323PC]
* Connected to: S3C2442 

== GSM/GPRS ==
The [[GSM]] (including GPRS) modem is Texas Instruments Calypso based.

* Connected to: S3C2442 UART1 (full-uart, RxD, TxD, CTS, RTS), /dev/ttySAC0 in userspace
* PM Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-power_control.patch
* Accessible GSM/GPRS antenna jack (if battery cover is removed) 

=== CALYPSO ASIC digital baseband ===
Unfortunately we cannot provide many details on the GSM chipset due to very tight [http://en.wikipedia.org/wiki/Non-disclosure_agreement NDA]s. However, this is not neccessarily required, since it interfaces using a standard UART serial line with the S3C2442. On that interface, [http://www.3gpp.org/ftp/Specs/archive/07_series/07.05/ GSM 07.05], [http://www.3gpp.org/ftp/Specs/archive/07_series/07.10/ GSM 07.10] and other standardized protocols are used.

*Calypso D751992AZHH 
*The firmware within GTA02 should be moko6 or later (internal code name)

=== TI TWL3025BZGMR analog baseband ===
*Product Homepage: [http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12295&contentId=4703 TWL3014] 

=== TI TRF6151 (GSM/PCS) RF Transceiver ===
*Product Homepage: [http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=12296&contentId=4701 TRF6151] 
GPRS Class12/CS4 

== AGPS ==
u-blox ANTARIS 4 chip
* Connected to: S3C2442 UART2, /dev/ttySAC1 in userspace
* Driver: none needed, talks standard NMEA
* u-blox Antaris 4 Protocol [http://www.u-blox.com/customersupport/antaris_doc.html Protocol download page]
* ATR0635 Datasheet: [http://www.u-blox.com/products/Data_Sheets/ATR0630_35_SglChip_Data_Sheet(GPS.G4-X-06009).pdf u-blox ATR0635] 

== Accelerometers ==
Two ST LIS302DL
* Homepage: http://www.st.com/stonline/products/literature/ds/12726/lis302dl.htm
* Datasheet: http://www.st.com/stonline/products/literature/ds/12726.pdf
* Connected to: S3C2442 via SPI interface
* S3C2442 SPI EINT interrupt inputs 

== Graphics/3D Acceleration ==

Smedia Glamo 3362.
* Homepage: http://www.smediatech.com/product3362.htm
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/smedia-glamo.patch
* Data sheet: FIXME
* Connected to: S3C2442 Address/Data bus 

=== microSD ===
The GTA02 has one microSD aka Transflash slot. Using the Glamo 3362 MMC/SD controller

*It should support SDHC, and 4GB card has been tested. Anyone with 8GB card? MicroSD slot is [[Disassembling_Neo1973#Opening_back_cover|under battery]].
* Connected to: Glamo 3362 MMC/SD controller
* Driver: Check svn for the SMedia driver with SD implementation
* [[Supported microSD cards]]
* Specifications: [http://www.sdcard.org/about/memory_card/pls/ SD Simplified Specification], [http://www.mmca.org/compliance/buy_spec/AN_MMCA050419.pdf MMC (partial)], [http://www.sandisk.com/Assets/File/OEM/Manuals/manual-rs-mmcv1.0.pdf MMC (product manual)]
* SANDISK 128 MB/512 MB and some 4G SDHC card been verified could work on GTA02 

== LCD Module (LCM) ==
Toppoly (tpo) 2.8" diagonal (1.7" x 2.27" - 43mm x 58mm) 480x640 TD028TTEC1 module, using a Toshiba JBT6K74 TFT
LCD Driver Chipset. 
* Homepage: [http://www.tpo.biz/ENG/business-eng/Activer-Matrix-VGA.htm Activer-Matrix-VGA.htm]
* Specification: FIXME
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-jbt6k74.patch
* Backlight Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-backlight.patch
* Connected to: Glamo3362 LCM interface and Glamo3362 SPI Interface 

==== Touch Screen ====
* Connected to: S3C2442 TS controller
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/s3c2410_touchscreen.patch

== Bluetooth Module==
Delta DFBM-CS320 Class2 Module, using CSR BlueCore4

* Data Sheet: [http://www.delta.com.tw/product/cp/vco/BT/download/pdf/CS/2.DFBM-CS320.pdf 2.DFBM-CS320.pdf]
* CSR Data Sheet: [http://www.csrsupport.com/download/2302/CS-101564-DSP10%20BlueCore4-ROM%20Product%20Data%20Sheet.pdf CS-101564-DSP10 BlueCore4-ROM Product Data Sheet.pdf]
* Driver: Stock Linux Kernel BlueZ
* Connected to: S3C2442 USB Host controller (OHCI)
* PM Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-power_control.patch 

=== Bluetooth Audio ===
This one is wired via PCM bus from the CSR Bluetooth chip to the Wolfson codec. 

== WiFi Module==

Accton (WLAN 802.11b/g SiP-M WM3236AQ(Flash Ver:2.0 Atheros AR6001GZ)
* Connected to: S3C2442 SDIO Host controller 
* Datasheet: [http://www.accton.com/products/Datasheet/WM3236A.AQ.pdf Accton 3236AQ datasheet] 
* Driver: http://svn.openmoko.org/developers/sameo/patches/ 

== Vibrator ==
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/gta01-vibrator.patch
* Connected to: S3C2442 GPIO

== USB Host ==
The USB Host controller is inside the S3C2442
* Driver: Stock Linux kernel ohci_hcd
* USB version 1.1
* Supply USB 5v in Host mode using usb power switch AAT1275IRN-5.0-T1
** http://www.analogictech.com/products/digitalfiles/AAT1275.pdf
* A net EN_USBHOST is controlled by PMU GPIO "GPO", this one signal when asserted (high)
** enables generation of 5V for external device using a charge pump
** enables connection of 15K pulldowns to D+ and D- to allow device insertion and removal detection for host mode
** DISABLES the path for USB power to charge the battery

It should also be possible to use host mode with externally-provided power. This will allow the FreeRunner to be connected to a USB device and be powered and charging the battery if present at the same time.

* Connect 0V, d+, d-, +5 to your USB device
* Connect a 15k ohm resistor between d+ and ground
* Connect a 15k ohm resistor between d- and ground
* Connect 0V, +5 to your >1A power source
** If your power source was not the OpenMoko 1A charger, additionally connect a 47K ohm 5% resistor between the ID pin and ground to pretend to be the 1A charger.

In addition you need to make sure EN_USBHOST signal that enables the physical Host mode power generation and disables the USB -> PMU charging path is deasserted. This may be taken care of automatically shortly by detection of the 48K resistor on a USB insertion leading to forcing EN_USBHOST deasserted. The charge pump that generates the 5V in host mode doesn't seem to mind getting external 5V given to it, but the real issue is that the battery will not be charged at all if we leave EN_USBHOST asserted since one of its jobs is to stop that happening.

The last two points are taken care of by the external AC charger, so you could use a Y cable that brings the AC adapter together with a cable that connects up the rest.

== USB Device ==
The USB Device controller is inside the S3C2442
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/s3c2410_udc.patch
* Please see [[USB Product IDs]] on information about which Vendor/Product IDs we use
* 1200mAh lithium battery charges when connected to powered host.
* Mini-AB connector similar to [http://www.cypressindustries.com/shoponline/proddetail.asp?prod=CCMUSBAB-32005-700&cat=34 this one].

== I2C Devices ==
The I2C is a simple communication standard intended to move small amounts of data a few inches between chips.
Please see [[I2C | Neo I2C Devices]] for more information & a list of devices & the addresses currently in use & documented for the Neo1973. 

== Audio ==
See also: [[Neo1973 Audio Subsystem]]

=== Wolfson Codec ===
There's a [[WM8753]] Wolfson Microelectronics CODEC (This is not a 'smart' codec that can interpret MP3/... it is a simple dumb 'sound card'.
* Product Homepage: http://www.wolfsonmicro.com/products/WM8753/
* Data Sheet: [http://www.wolfsonmicro.com/uploads/documents/en/WM8753.pdf WM8753.pdf]
* Connected to: S3C2442 IIS interface (PCM data), S3C2442 I2C (Control)
* Driver: https://svn.openmoko.org/trunk/src/target/kernel/patches/asoc.patch

=== Mono Amplifier ===
There's a National Semiconductor [[LM4853]] Mono Amplifier at the analog audio output of the WM8753

* Product Homepage: [http://www.national.com/pf/LM/LM4853.html LM4853.html]
* Data Sheet: [http://www.national.com/ds.cgi/LM/LM4853.pdf LM4853.pdf]
* Connects to: S3C2442 I2C (Control)

=== Analog wired Headset ===
There's a four-ring 2.5mm stereo jack which provides connectivity to old-fashioned wired headsets.

The headsets used by Motorola smartphones (A780,A1200, ...) and the V-360 have a compatible configuration.

=== Buttons ===
The Neo1973 GTA02 features two buttons:
* [[Neo1973 Power Button|The Power Button]]
* [[Neo1973 AUX Button|The "Aux" button]]

== Case ==
The new case for the FreeRunner is all black, as seen on the front page on the wiki.
Source: Mickey on IRC
=Accessory=

== Stylus ==

Using 4 in 1 laser pen
*Vendor: [http://www.quarton.com/laser_pen.html Quarton XPII]
*GTA02 standard setup comes with [http://www.quarton.com.tw/laser_pen_infiniter_xp_2.html QUARTON XPII 4 in 1 laser pen]

== Battery ==
The [[Neo FreeRunner (GTA02) Battery]] is mechanically and electrically compatible with the [[Neo1973 GTA01 Battery]], as well as limited compatibility with a Nokia BL6C battery.
According to [http://lists.openmoko.org/pipermail/community/2007-February/003758.html this] post on the mailinglist.
[http://wiki.openmoko.org/index.php?title=Image:Neo1973-with-BL5C-battery.png Photo] of the battery inside the Neo1973.

* GTA02 using the smart battery based on TI bq27000 chipset
* SANYO UF653450S 1200mAh cell. 
* Battery schematics: [http://people.openmoko.org/tony_tu/GTA02/hardware/GTA02/CT-GTA02.pdf GTA02 Smart Battery Schematics]

== microSD Card ==

GTA02 should comes with one of following microSD card

* [http://www.transcendusa.com/ Transcend] 512MB microSD card
* [http://www.sandisk.com/ SanDisk] 512MB microSD card 

== Charger ==

AKII Technology Charger

*Model: [http://www.ak2.com.tw/pd_main.asp?sg_id=11 A10P1-05MP]
*Input: 100-240v~ /0.3A
*Output: +5v up to 2.0A
*Add 47.5k 1% resistor between ID pin and ground for openmoko charger identification 

= History =

== GTA02v1 ==
First generation of prototypes that was given to internal OpenMoko software developers. Total 30 pcs fabricated.

*It is working just fine, but still based on 2440, with external NAND/SDRAM and no NOR flash
*Using the PCF50633 05 N3 due to 04 N3 not available, re-work power for basic schematics verification
*Using GTA01 SIM socket
*Add external debug port
*Still using Global locate A-GPS

== GTA02v2 ==
Second generation of prototypes, Total 50 pcs run at Taipei SMT factory MOUNT

*Ideal is have 256 MB NAND on Samsung package, Due to chip availability Start using S3C2442 B43
*Using correct PMU PCF50633 04 N3
*Change new SIM socket
*Change to u-blox A-GPS
*Change LCM power from 3.3v to 1.8v
*USB power switch layout/pin assignment mistake, could not verify USB host supply 5v function
*GPS function verified ok with good senstivity

== GTA02v3 ==
Production verification version, 2007/10/11 28 pcs fabricate at FIC SuZhou

*Still using S3C2442 B43 for hardware verification
*Using control pilot run to verify S3C2442 B54 chips 

== GTA02v4 ==
Mass production release candicate version 1

2 weeks after v3 gerber out, release the v4 gerber, and 2007/10/20 20 pcs fabricate at FIC SuZhou

*Change LCM power from 1.8v to 3.3v for display stability issue
*fabricate another 200 pcs for yield rate/production verification
*fabricate 50 pcs with S3C2442 B43 (128 MB NAND) for quality comparsion
*USB host power chip have some output voltage stability issues with Vb/Vcc comes from different power source, need layout change to fix the issue
*Battery Coulomb design not working on A4

== GTA02v5 ==
Mass production candicate version 2/Mass production version

* First batch fabricate 2008/1/14 at FIC SuZhou
* Mass production A5 trial run start from 2008 March, including some resistor/capacitor change compare with inital 100 pcs prototypes A5, and prototypes for GTA02 developers was tracked in the [[Prototypes| Prototypes Page]]
* Coulomb counter issue fixed
* USB host power switch fixed
* Need add capacitor for PMU Vbat input for stability issue, this could be done by direct SMT or hand rework
* Need rework (still using SMT in production) add capacitor for PMU Vbat input for PMU stability issue.
* Need manual rework GSM IR UART path a 100k pull down for better GSM deep sleep
* ATAG_REVISION: 0350

== GTA02v6 ==
Mass production candicate version 3/Mass production version 

A6 will be fine tune version of A5, only minor schematic change for better product quality and version control. Capacitor and resistor change A6 also on mass production A5 

*First 100 pcs might start from end of 2008 March
*Add capacitor space for Vbat, reduce the SMT effort
*Add GSM IR resistor for better GSM deep sleep
*Reserve 3 GPIO for hardware version control

= Debug Board =

== Debug Board Connector defination ==

This is the connector used to connect the [[Debug Board]] and possibly other hardware.

Connections are:
* 39 - GND
* 38 - STDI
* 37 - _RESET
* 36 - STMS
* 35 - STCK
* 34 - STDO
* 33 - GSM_EN
* 29 - _STRST
* 19 - X_I2C_SCL (H-TP4703)
* 18 - X_I2C_SDA (H-TP4704)
* 17 - SPI_CLK0
* 16 - SPI_MOSI0
* 15 - SPI-MISO0
* 14 - SS0
* 13 - EINT3 (H-TP4705)
* 3 - CONSOLE_TXD (H-TP4701)
* 2 - CONSOLE_RXD (H-TP4702)

Information from [http://people.openmoko.org/roh/Debugport_GTA01bv4.png].

= Distinguishing hardware revisions =
== Inside the [[Bootloader]] ==
Every hardware revision has its own u-boot image type. Thus, the bootloader has the revision hard-coded.
The hardware revision is passed on to the kernel via the ATAG mechanism (ATAG_REVISION)

== Inside the [[Kernel]] ==
The kernel receives the ATAG_REVISION during bootup, and saves its contents in the "system_rev" global variable.

== From Userspace ==
The kernel exports the system_rev variable in /proc/cpuinfo as "Revision :" line.

= Certification =

== FCC ==
** 850/1800/1900 Band, FCC ID: EUNGTA02
** 900/1800/1900 Band, FCC ID: EUNGTA02E

== NCC ==
(for Taiwan Import)

{{Languages|Neo1973 GTA02 Hardware}}

[[Category:Hardware ]]
[[Category:Hardware Support| ]]
[[Category:GTA02 Hardware]]

Overview on power management design

2008-02-14T10:17:23Z

Warmcat: /* State diagram */

== State diagram ==
* Normal Mode
* Sleep Mode
* Poweroff Mode
* Slow Mode ??

There has also been discussion (from Cesar) on the kernel list about exploiting the PM suspend and resume driver APIs on a more finegrained basis to tailor consumption to what the device finds itself doing, maybe driven by what dev nodes have handles open on them.

== Profile of suspend/resume ==
* Estimate suspend current
System only keeps two power sources, AUTO3v3 and DOWN2 1v8, when it is in suspend. Theoretically, the suspend current should be the sum of the current of all modules which are in sleep/suspend mode connected these two power channels. So we have to know the current consumption of following modules which are in sleep/suspend mode individually.

** Glamo
** BT
** AMP
** WLAN
** SDRAM
** NAND
** LCM

* Wake-up source
The following modules/events are listed as wake-up sources for GTA02 so far.

** GSM:OK
***But the suspend current is somehow too high (18mA). Need more investigation.
** WiFi:[Not verified/implemented]
** PMU
*** Power key:[OK]
*** RTC(alarm clock):[Not verified/implemented]
*** USB insert: [Not verified/implemented]
** Aux key:This button is used as NOR booting control. It would not enable as wake-up source anymore.
** Jackinsert [Not verified/implemented]

== GPIO config ==
* gpio config on A5
* gpio config when system get into sleep mode (suspend)
* config of glamo in sleep mode

== Automated suspend/resume testing ==
Initial idea is to provide an environment to test suspend/resume process and collect the suspending current.
Basically, we could use multimeter with GPIB to achieve the whole process automatically.

Prototypes

2008-02-02T14:48:01Z

Warmcat: /* #3 GTA02 A5 */

Prototypes are pieces of hardware such as boards, fully assembled devices, batteries, accessories that OpenMoko uses during the development of new hardware.

This page tracks such prototypes, in which condition their life started, and what happened to them during their lifetime.

Prototypes cannot be purchased. They will be loaned out on a case by case basis, and collected back for post mortem analysis.

If you believe you need a prototype of some upcoming hardware, please mailto:openmoko-kernel@lists.openmoko.org.

=== #21 GTA02 A5 ===
current holder: Tony (may be fixed in future) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad, GPS broken 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #20 GTA02 A5 ===
current holder: Tony (available) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #19 GTA02 A5 ===
current holder: Tony (available) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #18 GTA02 A5 ===
current holder: Erin 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #17 GTA02 A5 ===
current holder: Vitaly (Atheros) 
01 Feb 2008 Delivered to Vitaly, Atheros 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #16 GTA02 A5 ===
current holder: Samuel 
31 Jan 2008 Sent to Samuel 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #15 GTA02 A5 ===
current holder: Matt (fixing shutdown bug) 
31 Jan 2008 Running from battery shuts down 5 seconds after reboot. Running from power source (plugged into battery connectors) is stable 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #14 GTA02 A5 ===
current holder: Sean Chiang 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #13 GTA02 A5 ===
current holder: Tony (may be fixed in future) 
29 Jan 2008 Miles: Bluetooth scan doesn't work, Power Key broken 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #12 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #11 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #10 GTA02 A5 ===
current holder: Willie 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #9 GTA02 A5 ===
current holder: Matt 
29 Jan 2008 Matt: Found out jack insert interrupt line is floating 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #8 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #7 GTA02 A5 ===
current holder: Miles 
29 Jan 2008 Miles: receiver test failed (receiver broken) 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #6 Highcell battery 3.7V 1250mAh with Coulomb counter ===
current holder: Tony (available) 
29 Jan 2008 Willie: verified

=== #5 Highcell battery 3.7V 1250mAh with Coulomb counter ===
current holder: Andy 
29 Jan 2008 sent to Andy 
29 Jan 2008 Willie: verified

=== #4 Highcell battery 3.7V 1200mAh with Coulomb counter ===
current holder: Werner 
30 Jan 2008 sent to Werner 
29 Jan 2008 Willie: verified

=== #3 GTA02 A5 ===
current holder: Andy 
02 Feb 2008 I see similar behaviour to #15 today on battery + USB. Appears to be related to, eg, starting LCM backlight making power problems resulting in immediate shutdown. Current limit issue somehow? 
01 Feb 2008 Behaving well. 
29 Jan 2008 sent to Andy 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #2 GTA02 A5 ===
current holder: Harald 
29 Jan 2008 sent to Harald 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #1 GTA02 A5 ===
current holder: Werner 
30 Jan 2008 sent to Werner 
30 Jan 2008 Miles: verified hardware, same exceptions as below 
30 Jan 2008 Allen Chang: reworked to add NOR protection (R2505 closed, R2506 opened) 
29 Jan 2008 Miles: verified hardware, except for
* microSD
* suspend/resume
* Bluetooth audio
* Coulomb counter & motion sensor only low-level verification (no drivers)
* USB host only low-level verification (no device)
* charging (only 500mA verified), running on USB only, switching between charging modes
* full memory verification
* wakeup interrupts (WiFi, USB, GSM, motion sensors, 2 buttons, RTC, headphone jack)
28 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
28 Jan 2008 Tony: Rework wifi FW to 2.0.0.40 
28 Jan 2008 Batch of 10 from Suzhou, PCBA with all modules, wifi FW 1.3, NOR protection disabled, full DM1 (v009) and DM2 (v012)

Prototypes

2008-02-02T14:45:32Z

Warmcat: /* #3 GTA02 A5 */

Prototypes are pieces of hardware such as boards, fully assembled devices, batteries, accessories that OpenMoko uses during the development of new hardware.

This page tracks such prototypes, in which condition their life started, and what happened to them during their lifetime.

Prototypes cannot be purchased. They will be loaned out on a case by case basis, and collected back for post mortem analysis.

If you believe you need a prototype of some upcoming hardware, please mailto:openmoko-kernel@lists.openmoko.org.

=== #21 GTA02 A5 ===
current holder: Tony (may be fixed in future) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad, GPS broken 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #20 GTA02 A5 ===
current holder: Tony (available) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #19 GTA02 A5 ===
current holder: Tony (available) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #18 GTA02 A5 ===
current holder: Erin 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #17 GTA02 A5 ===
current holder: Vitaly (Atheros) 
01 Feb 2008 Delivered to Vitaly, Atheros 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #16 GTA02 A5 ===
current holder: Samuel 
31 Jan 2008 Sent to Samuel 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #15 GTA02 A5 ===
current holder: Matt (fixing shutdown bug) 
31 Jan 2008 Running from battery shuts down 5 seconds after reboot. Running from power source (plugged into battery connectors) is stable 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #14 GTA02 A5 ===
current holder: Sean Chiang 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #13 GTA02 A5 ===
current holder: Tony (may be fixed in future) 
29 Jan 2008 Miles: Bluetooth scan doesn't work, Power Key broken 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #12 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #11 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #10 GTA02 A5 ===
current holder: Willie 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #9 GTA02 A5 ===
current holder: Matt 
29 Jan 2008 Matt: Found out jack insert interrupt line is floating 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #8 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #7 GTA02 A5 ===
current holder: Miles 
29 Jan 2008 Miles: receiver test failed (receiver broken) 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #6 Highcell battery 3.7V 1250mAh with Coulomb counter ===
current holder: Tony (available) 
29 Jan 2008 Willie: verified

=== #5 Highcell battery 3.7V 1250mAh with Coulomb counter ===
current holder: Andy 
29 Jan 2008 sent to Andy 
29 Jan 2008 Willie: verified

=== #4 Highcell battery 3.7V 1200mAh with Coulomb counter ===
current holder: Werner 
30 Jan 2008 sent to Werner 
29 Jan 2008 Willie: verified

=== #3 GTA02 A5 ===
current holder: Andy 
02 Feb 2008 I see similar behaviour to #15 today on battery + USB. Appears to be related to, eg, starting LCM backlight making power problems resulting in immediate shutdown. Current limit issue somehow?
01 Feb 2008 Behaving well.
29 Jan 2008 sent to Andy 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #2 GTA02 A5 ===
current holder: Harald 
29 Jan 2008 sent to Harald 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #1 GTA02 A5 ===
current holder: Werner 
30 Jan 2008 sent to Werner 
30 Jan 2008 Miles: verified hardware, same exceptions as below 
30 Jan 2008 Allen Chang: reworked to add NOR protection (R2505 closed, R2506 opened) 
29 Jan 2008 Miles: verified hardware, except for
* microSD
* suspend/resume
* Bluetooth audio
* Coulomb counter & motion sensor only low-level verification (no drivers)
* USB host only low-level verification (no device)
* charging (only 500mA verified), running on USB only, switching between charging modes
* full memory verification
* wakeup interrupts (WiFi, USB, GSM, motion sensors, 2 buttons, RTC, headphone jack)
28 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
28 Jan 2008 Tony: Rework wifi FW to 2.0.0.40 
28 Jan 2008 Batch of 10 from Suzhou, PCBA with all modules, wifi FW 1.3, NOR protection disabled, full DM1 (v009) and DM2 (v012)

Prototypes

2008-02-02T14:44:06Z

Warmcat: /* #15 GTA02 A5 */

Prototypes are pieces of hardware such as boards, fully assembled devices, batteries, accessories that OpenMoko uses during the development of new hardware.

This page tracks such prototypes, in which condition their life started, and what happened to them during their lifetime.

Prototypes cannot be purchased. They will be loaned out on a case by case basis, and collected back for post mortem analysis.

If you believe you need a prototype of some upcoming hardware, please mailto:openmoko-kernel@lists.openmoko.org.

=== #21 GTA02 A5 ===
current holder: Tony (may be fixed in future) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad, GPS broken 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #20 GTA02 A5 ===
current holder: Tony (available) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #19 GTA02 A5 ===
current holder: Tony (available) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #18 GTA02 A5 ===
current holder: Erin 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #17 GTA02 A5 ===
current holder: Vitaly (Atheros) 
01 Feb 2008 Delivered to Vitaly, Atheros 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #16 GTA02 A5 ===
current holder: Samuel 
31 Jan 2008 Sent to Samuel 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #15 GTA02 A5 ===
current holder: Matt (fixing shutdown bug) 
31 Jan 2008 Running from battery shuts down 5 seconds after reboot. Running from power source (plugged into battery connectors) is stable 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #14 GTA02 A5 ===
current holder: Sean Chiang 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #13 GTA02 A5 ===
current holder: Tony (may be fixed in future) 
29 Jan 2008 Miles: Bluetooth scan doesn't work, Power Key broken 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #12 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #11 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #10 GTA02 A5 ===
current holder: Willie 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #9 GTA02 A5 ===
current holder: Matt 
29 Jan 2008 Matt: Found out jack insert interrupt line is floating 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #8 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #7 GTA02 A5 ===
current holder: Miles 
29 Jan 2008 Miles: receiver test failed (receiver broken) 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #6 Highcell battery 3.7V 1250mAh with Coulomb counter ===
current holder: Tony (available) 
29 Jan 2008 Willie: verified

=== #5 Highcell battery 3.7V 1250mAh with Coulomb counter ===
current holder: Andy 
29 Jan 2008 sent to Andy 
29 Jan 2008 Willie: verified

=== #4 Highcell battery 3.7V 1200mAh with Coulomb counter ===
current holder: Werner 
30 Jan 2008 sent to Werner 
29 Jan 2008 Willie: verified

=== #3 GTA02 A5 ===
current holder: Andy 
29 Jan 2008 sent to Andy 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #2 GTA02 A5 ===
current holder: Harald 
29 Jan 2008 sent to Harald 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #1 GTA02 A5 ===
current holder: Werner 
30 Jan 2008 sent to Werner 
30 Jan 2008 Miles: verified hardware, same exceptions as below 
30 Jan 2008 Allen Chang: reworked to add NOR protection (R2505 closed, R2506 opened) 
29 Jan 2008 Miles: verified hardware, except for
* microSD
* suspend/resume
* Bluetooth audio
* Coulomb counter & motion sensor only low-level verification (no drivers)
* USB host only low-level verification (no device)
* charging (only 500mA verified), running on USB only, switching between charging modes
* full memory verification
* wakeup interrupts (WiFi, USB, GSM, motion sensors, 2 buttons, RTC, headphone jack)
28 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
28 Jan 2008 Tony: Rework wifi FW to 2.0.0.40 
28 Jan 2008 Batch of 10 from Suzhou, PCBA with all modules, wifi FW 1.3, NOR protection disabled, full DM1 (v009) and DM2 (v012)

Prototypes

2008-02-02T14:29:50Z

Warmcat: /* #15 GTA02 A5 */

Prototypes are pieces of hardware such as boards, fully assembled devices, batteries, accessories that OpenMoko uses during the development of new hardware.

This page tracks such prototypes, in which condition their life started, and what happened to them during their lifetime.

Prototypes cannot be purchased. They will be loaned out on a case by case basis, and collected back for post mortem analysis.

If you believe you need a prototype of some upcoming hardware, please mailto:openmoko-kernel@lists.openmoko.org.

=== #21 GTA02 A5 ===
current holder: Tony (may be fixed in future) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad, GPS broken 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #20 GTA02 A5 ===
current holder: Tony (available) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #19 GTA02 A5 ===
current holder: Tony (available) 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #18 GTA02 A5 ===
current holder: Erin 
01 Feb 2008 Miles: verified hardware, same exceptions as #1, Bluetooth sensitivity very bad 
31 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
31 Jan 2008 Batch of 4 from Suzhou, PCBA with all modules, NOR protection disabled, full DM1 (v009) and DM2 (v012)

=== #17 GTA02 A5 ===
current holder: Vitaly (Atheros) 
01 Feb 2008 Delivered to Vitaly, Atheros 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #16 GTA02 A5 ===
current holder: Samuel 
31 Jan 2008 Sent to Samuel 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #15 GTA02 A5 ===
current holder: Matt (fixing shutdown bug) 
02 Feb 2008 (From Andy: I see similar behaviour today on battery + USB. Appears to be related to, eg, starting LCM backlight making power problems)
31 Jan 2008 Running from battery shuts down 5 seconds after reboot. Running from power source (plugged into battery connectors) is stable 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #14 GTA02 A5 ===
current holder: Sean Chiang 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #13 GTA02 A5 ===
current holder: Tony (may be fixed in future) 
29 Jan 2008 Miles: Bluetooth scan doesn't work, Power Key broken 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #12 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #11 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #10 GTA02 A5 ===
current holder: Willie 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #9 GTA02 A5 ===
current holder: Matt 
29 Jan 2008 Matt: Found out jack insert interrupt line is floating 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #8 GTA02 A5 ===
current holder: Tony (end of life) 
21 Jan 2008 Allen: Added Bluetooth module, reworked for power measurements, broken 
18 Jan 2008 Arrived from Suzhou (batch of 4) as PCBA without modules

=== #7 GTA02 A5 ===
current holder: Miles 
29 Jan 2008 Miles: receiver test failed (receiver broken) 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #6 Highcell battery 3.7V 1250mAh with Coulomb counter ===
current holder: Tony (available) 
29 Jan 2008 Willie: verified

=== #5 Highcell battery 3.7V 1250mAh with Coulomb counter ===
current holder: Andy 
29 Jan 2008 sent to Andy 
29 Jan 2008 Willie: verified

=== #4 Highcell battery 3.7V 1200mAh with Coulomb counter ===
current holder: Werner 
30 Jan 2008 sent to Werner 
29 Jan 2008 Willie: verified

=== #3 GTA02 A5 ===
current holder: Andy 
29 Jan 2008 sent to Andy 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #2 GTA02 A5 ===
current holder: Harald 
29 Jan 2008 sent to Harald 
29 Jan 2008 Same as #1 until 29 Jan 2008

=== #1 GTA02 A5 ===
current holder: Werner 
30 Jan 2008 sent to Werner 
30 Jan 2008 Miles: verified hardware, same exceptions as below 
30 Jan 2008 Allen Chang: reworked to add NOR protection (R2505 closed, R2506 opened) 
29 Jan 2008 Miles: verified hardware, except for
* microSD
* suspend/resume
* Bluetooth audio
* Coulomb counter & motion sensor only low-level verification (no drivers)
* USB host only low-level verification (no device)
* charging (only 500mA verified), running on USB only, switching between charging modes
* full memory verification
* wakeup interrupts (WiFi, USB, GSM, motion sensors, 2 buttons, RTC, headphone jack)
28 Jan 2008 Tony: Put inside GTA01 case, speaker, antennas 
28 Jan 2008 Tony: Rework wifi FW to 2.0.0.40 
28 Jan 2008 Batch of 10 from Suzhou, PCBA with all modules, wifi FW 1.3, NOR protection disabled, full DM1 (v009) and DM2 (v012)

Main Page

2008-01-23T08:39:43Z

Warmcat: Add link to Kernel-dev-status

{{Languages|Main_Page}}
__NOTOC__
__NOEDITSECTION__
__NOTOC__
{| cellspacing="5" cellpadding="0" style="padding: 2%; margin:0em 0em 1em 0em; border:1px solid #F9D163; background:#FCE9B4; width:100%"
| <big>'''Welcome to the [[OpenMoko]]™ public Wiki'''</big> 
|}

[[Image:200px-FIC-neo1973_small_neu.jpg|200px|right|frontside]]
OpenMoko™ is an [http://en.wikipedia.org/wiki/Open_source Open Source] project to create the world's first free mobile phone operating system which runs a full X server and can therefore run most X applications.

The [[OpenMoko]] project is a community that anyone can join, to help design their ideal phone.

You can install any OpenMoko software over the whole range of [[OpenMoko-supported hardware|supported phones]], and if you upgrade your phone, you don't lose that software. Bugs fixed on any phone are fixed on all.

The [[Neo1973]] from [[FIC]] is the first of possibly many phones that OpenMoko may be used on. Buy it at [https://direct.openmoko.com/ Openmoko Online Shop]. You may check out the [[SH1 FAQ|Shipment 1 FAQ]] and the [[Phase 1 Software Testing|Phase 1 software test reports]].

Please join us in collaborating on the OpenMoko project through any of the [[Development resources | project resources]] including this OpenMoko wiki. Please see the [[Help:Contents | wiki editing help]] page for information on making contributions to this wiki. A [[Meet the Core Team | core team]] of developers funded by FIC, Inc. leads the project.

An [[introduction]] page is available, with [[Introduction#Photos|photos]] and [[Introduction#Videos|videos]]. Moreover, the usual [[FAQ | Frequently Asked Questions]] (FAQ) page might be helpful. Developers may find the [[ChangeLog | change log]] an important resource.

{{warning|'''The OpenMoko GUI applications are not suitable for end users yet.''' They are still in beta. Do not expect to always and reliably make and receive calls from the OpenMoko GUI. Thanks to the openness of the FIC Neo1973 hardware, there is also an alternative to the OpenMoko GUI: Qtopia 4.3.x is released under GPL and is at the edge of being usable for phone use.}}

'''OpenMoko Open Source Engineering and Schedule Policy'''
As an extension of the Open Source attitude towards source code, OpenMoko attempts to be open about as much of the engineering process as possible. Obviously this is not always possible, and because this is a fairly new notion, we are still learning how to do this properly. Our current policy is to attempt to tell you as much as possible about what we are doing, but never to attempt any schedule prediction. This is not due to secrecy, but rather is due to the large number of dependencies that are out of our control. For the latest status updates, see [[Community_Updates|Community Updates]]

'''Neo1973 DEVELOPMENT STATUS'''
[[Neo1973|Neo1973 GTA02]] is still under development. We are on the fourth revision of the PCB (GTA02A4) and are still testing some of the hardware. Once we complete this we will create and then test GTA02A5, incorporating whatever changes were dictated by the testing of GTA02A4. If GTA02A5 tests successfully, we will build a few more for further testing within the company. If this testing is successful, then we will start manufacturing units for sale. For the latest status updates, see [[Community_Updates|Community Updates]]

Status on the U-Boot and Kernel side can be found at [[Kernel-dev-status|Kernel-dev-status]].

{| class="wikitable" cellspacing="0" cellpadding="5" width=100%
! width=100% colspan="2" style="background:#F9D163;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Latest status
|-
|valign="TOP" width="50%" style="background:#FCE9B4;border-left:5px solid white;border-bottom:5px solid white;" |
* The latest Qtopia snapshot can now be successfully used to make and receive calls, to send and receive SMS and use Contacts for both. However, if you do not enable suspend, one battery will only last 3-5 hours, but in suspend, incoming calls do not wake up Qtopia! See [[Qtopia on Neo 1973]] for instructions.
|valign="TOP" width="50%" style="background:#FCE9B4;border-right:5px solid white;border-bottom:5px solid white;" |
* The [http://downloads.openmoko.org/snapshots/2007.11/ OpenMoko 2007.11 Snapshot] can make and receive calls most of the time. Power management (suspend, standby time) are still experiencing problems.
* For the latest status updates, see [[Community_Updates|Community Updates]]
|}

{| class="wikitable" cellspacing="0" cellpadding="5" width=100%
! width=100% colspan="2" style="background:#F9D163;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | What's Your Interest?
|-
|valign="TOP" width="50%" style="background:#FCE9B4;border-left:5px solid white;border-bottom:5px solid white;" |
* [[Basic End-user]] - Information for end users who want basic functionality and no surprises
* [[Advanced End-user]] - Information for advanced end-users who want advanced and experimental functionality but who are not programmers
* [[Business Development]] - Exchange of commercial opportunities for promoting widespread end-user acceptance.
|valign="TOP" width="50%" style="background:#FCE9B4;border-right:5px solid white;border-bottom:5px solid white;" |
* [[Application Developer]] - Information for application developers, including ideas and specifications for applications, and tools to build them
* [[System Developer]] - Information for system developers, including bootloader, kernel, and libraries
* [[Hardware Developer]] - Information for hardware developers, including hardware specs and debug board
|}

{| class="wikitable" cellspacing="0" cellpadding="5" width=100%
! width=33% style="background:#d1d1d1;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | General
! width=33% style="background:#C5FDAF;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Developer Guides
! width=33% style="background:#FDAFAF;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Developer Reference Documentation
|-
|valign="TOP" style="background:#ebebeb;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" |
* [[Development resources | Project Resources]] - Provides a centralized location of all resources such as [[Development resources#Mailing_Lists|mailing lists]], [[Development resources#IRC | IRC]], and other software development oriented resources.

* [[Current events]] - Information on both past and future events where FIC or OpenMoko had or will have a presence.
* [http://forums.makeopensource.com/ Unofficial OpenMoko Forums] - Everyone is invited to collaborate with OpenMoko users and developers on the forums.
* Most of the documentation and Wiki assumes you are using Linux; here are some notes for users of [[Other OSes]].
* [[MacOS_X|Mac OS X]] - Information specific for those who use Mac OS X
* [[OpenLab]] - A physical area where OpenMoko can interact with FOSS community

'''Administrative + Organizational'''
* [[Shipping Notes]] - Information to help FIC figure out how to ship products to you, and how much it might cost.
* [[My Account]] - Ideas for what sort of account-based services FIC should provide with the phone.
* [[Hear Me FIC]] - Information to help FIC know what the community wants.
* [[Listen Up Community]] - Community's To-Do-List
* [[Wiki Issues]] - problems/requests regarding this Wiki

|valign="TOP" style="background:#E8FFDF;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" |
* [[Getting Started with your Neo1973]]
* [[installation_guide|A guide for flashing and emulating the openmoko software]] (In progress, this should replace the following options)
** [[Flashing_openmoko|Flashing Neo1973 with the kernel, the root filesystem and optionally u-boot.]]
** [[MokoMakefile|Building OpenMoko using the MokoMakefile]]
** [[Application Development Crash Course]] -A very basic how-to for the new people.
** [[OpenMoko2007.2|Building OpenMoko 2007.2]]
** [[Building OpenMoko 2007.1 from scratch]]
*** [[Building a hello world application]]
*** Old [[Building OpenMoko from scratch (pre-BBT)]]
** [[Running OpenMoko on PC]]
*** [[Getting OpenMoko working on host with Xoo]]
*** [[Getting OpenMoko working on host with Xephyr]]
*** [[How to run OpenMoko Apps on PC]]
*** [[OpenMoko under QEMU]]
*** [[Test Openmoko Emulation with chroot image|Test Openmoko Emulation with a Prebuilt chroot Image]]
* [[Migration to bad block tolerant builds]]
* [[Booting from SD]]
* [[DailyBuiltImages|Getting daily built images]]

|valign="TOP" style="background:#FFDADA;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;"|
'''Hardware Reference Documentation'''
* All [[:Category:Hardware|Hardware]] related documentation and specifications are found on the [[:Category:Hardware|Hardware page]].
* The [[Neo1973 Hardware]] page provides an overview of the hardware components used by the [[:Category:Neo1973 Hardware|Neo1973 hardware platform]]. PCB photographs are also included. A [[Disassembling Neo1973 | photo disassembly story]] may be an interesting starting place.
* [[:Category:Neo1973 Hardware Debugging | Neo1973 Hardware Debugging]] is assisted with the [[Debug Board | Neo1973 debug board]]. A page discussing [[Connecting Neo1973 with Debug Board v2 | debug board and Neo1973 configurations]] is also provided.

'''Software Reference Documentation'''
* Architectural
** [[OpenMokoFramework]] - The OpenMoko Application Framework
* [[Neo1973 host software]]
* Device Software
** Low-Level
*** [[u-boot]] - The bootloader we use, including documentation for our modifications
*** [[kernel]] - The Linux kernel we use, including documentation for our modifications
** Userspace
*** [[binary compatibility]]
*** [[gsmd]] - the GSM daemon managing the GSM Modem
*** [[gpsd]] - the AGPS (Assisted GPS) daemon
|}

{| class="wikitable" cellspacing="0" cellpadding="5" width=100%
! width=33% style="background:#FCC6FF;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | OpenMoko-specific Development
! width=33% style="background:#B3DDF4;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | OpenMoko Miscellaneous Development
! width=33% style="background:#F5FC7F;border-left:5px solid white;border-right:5px solid white;border-top:5px solid white;" | Miscellaneous
|-
|valign="TOP" style="background:#FEE9FF;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" |
* [[Roadmap]] - Roadmap for further OpenMoko development
* [[OpenEmbedded]] - The distribution-building framework
* [[Toolchain]] - The toolchain we use for compilation
* [[OpenMoko]] - The OpenMoko distribution
** [[OpenMoko2007]] - The first intended release of it
** [[OpenMoko2007.2]] - An improved release with more formalized style guidelines.
** [[Userspace root image]]
* [[Test Plans]] - How we test our phones

'''User Interface Related'''
* [[GUI Style Guidelines]] -- New for [[OpenMoko2007.2]]
* [[Look & Feel]]
** [[Artwork]]
* [[Applications|Application Roadmap]]
* [[Widgets]]
** [[Widget Inheritance Graph]]
* [[Application UI Design Recommendations]]

|valign="TOP" style="background:#D4EDFB;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" |
* [[Thesis work]]
* [[Freshman todo]]
* [[Templates]]
* [[PIM Storage]]
* [[Coding Guidelines]]
* [[OpenMoko#Setting_up_an_OpenMoko_SDK|How to setup the OpenMoko SDK]]
* Alternative distributions for [[Neo1973]] GTA01: [[Angstrom on Neo1973]], [http://pokylinux.org Poky] [http://www.usome.com](instructions needed!)
* [[License]] - How we license our code
* [[Development resources]] - Describes resources for developers (lists, svn, ...)
* [[Neo1973 Phase 0]] - Information for Phase 0 device owners
* [[Wishlist:Neo1973 P0 Review]] - Impressions of the Phase 0 hardware device, also the Phase 0 FAQ
* [[Neo1973 Phase 1]] - Information for Phase 1 device owners
* [[Wishlist:Neo1973 P1 Review]] - Impressions of the Phase 1 hardware device
* [[External Feeds]] - List of feeds from people blogging about OpenMoko

|valign="TOP" style="background:#FCFFCD;border-left:5px solid white;border-right:5px solid white;border-bottom:5px solid white;" |
* [[WiFi support in OpenMoko]]
* [[Neo1973 and Windows]]
* [[Press Coverage]] - What the press says about the OpenMoko project
* [[mFAQ]] - The OpenMoko Misinformation FAQ ('''mFAQ''') - What the press '''''incorrectly''''' says about the OpenMoko project
* [[Current Applications]] - Applications (GUI based) currently included in the main/core build of OpenMoko
* [[Wish List]]s: [[Wish List - Hardware|Hardware]], [[Wishlist:BuiltInScriptingLanguage|Scripting Languages]], [[Wish List - OpenMoko Ringtones and Sounds|ringtones and sounds]]
* [[Media Content]] - What types of media on the device can we use (that is non-software)?
* [[Testimonials]] - How did you get to OpenMoko?
* [[Buying Interest List]] - (Not official and not a pre-order page) Have you put money aside for Neo1973? Put your nick here.
* Comparsion with the [[iPhone]]
* [[Translation]] of OpenMoko
* Project applications for Google's [[Summer of code]]
* Purcase OpenMoko [[SWAG]] T-Shirts!
* The OpenMoko [[Trademark Policy]]
|}

The members of the OpenMoko community would like to thank FIC Inc. for their continued leadership of the OpenMoko project.



[[Category:Information| ]]
[[Category:Categories| ]]