This page explains how to boot a FreeRunner from the [[Supported_microSD_cards|(micro-)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.

+

This page explains how to boot a FreeRunner from the [[Supported_microSD_cards|(micro-)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 below).}}

+

== Booting from SDHC / suspend problems ==

== Booting from SDHC / suspend problems ==

Line 10:

Line 8:

== How it Works ==

== 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.

+

On the Neo, [[U-boot-gena2x]] 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).

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).

Line 57:

Line 55:

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

==== 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.

+

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 might to support wear leveling (check before you buy!), but this can not be guaranteed for all vendors.

====NILFS====

====NILFS====

−

NILFS ought to be tested?:

+

[[NILFS]] ought to be tested?

−

*[http://www.linux-mag.com/id/7345/ June 2nd, 2009: NILFS: A File System to Make SSDs Scream]

+

−

*[http://kernelnewbies.org/Linux_2_6_30#head-26a57d992910e405d688b760fc504dfe2e48e0a5 kernelnewbies.org: Linux 2.6.30: 1.1. NILFS2, a log-structured filesystem] Quote: "...Another advantage of this approach is that the log offers a coherent historical view of all the operations done in the disk in the past. This is called "continuous snapshotting" - snapshots of modifications done in all the filesystem at any time are created automatically due to the log-structure design, with no requirement of intervention from an admin, and with the filesystem size as the only limit. NILFS2 allows to access those snapshots and even mount them (on read-only mode)..."

+

−

*http://www.nilfs.org/

+

== Acquiring a tarfile rootfs ==

== Acquiring a tarfile rootfs ==

Line 100:

Line 95:

=== Partioning the SD card ===

=== Partioning the SD card ===

−

{{Note| This partition procedure it's '''NOT necessary if you use the [[Qi]] Bootloader'''. With [[Qi]] you can have the Kernel Bin in the same partition of the RootFS, there is no need to make this multipartition. Check [[Qi]] page for more information. }}

+

{{Note| This partition procedure it's '''NOT necessary if you use the [[Qi]] bootloader'''. With [[Qi]] you can have the Kernel Bin in the same partition of the RootFS, there is no need to make this multipartition. Check [[Qi]] page for more information. }}

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. Also see [[#Partitioning_Hints| Partitioning Hints]] before defining your partition layout.

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. Also see [[#Partitioning_Hints| Partitioning Hints]] before defining your partition layout.

−

# If the partitions are not unmounted the OS might overwrite it later and make it unusable?:

+

# If the partitions are not unmounted the OS might overwrite it later

−

umount /dev/mmcblk0

+

# with an old cached version and make it unusable? There it is best to unmount the partitions:

{{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}}

+

+

{{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<br>Image unstable 25. July Om2009 has it preinstalled.}}

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):

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):

−

+

umount /dev/mmcblk0p2

mkfs.ext3 /dev/mmcblk0p2

mkfs.ext3 /dev/mmcblk0p2

Line 203:

Line 191:

(Yes, lower case i and no extension.)

(Yes, lower case i and no extension.)

−

Make sure your kernel is called ''uImage.bin'' (or ''uimage'' for some versions of NOR u-boot). If the u-boot doesn't find the kernel image during boot, [[Bootloader#Using usbtty from Linux|log into the bootloader]] with ''[http://www.airs.com/ian/uucp.html cu]'', mount the partition with mmcinit and check the presence and the name of the kernel image with ''fatls mmc 1:1'' for FAT filesystem or ''ext2ls mmc 1:1'' for ext2 filesystem. Compare this carefully with the result of ''printenv sd_image_name''. Remember that you can modify the environment in NAND FLASH, but not in NOR FLASH, so if you plan to boot from NOR FLASH you have to modify the file name to match the environment variable.

+

Make sure your kernel is called ''uImage.bin'' (or ''uimage'' for some versions of NOR u-boot). If the U-Boot doesn't find the kernel image during boot, [[U-Boot#Using usbtty from Linux|log into the U-Boot]] with ''[http://www.airs.com/ian/uucp.html cu]'', mount the partition with mmcinit and check the presence and the name of the kernel image with ''fatls mmc 1:1'' for FAT filesystem or ''ext2ls mmc 1:1'' for ext2 filesystem. Compare this carefully with the result of ''printenv sd_image_name''. Remember that you can modify the environment in NAND FLASH, but not in NOR FLASH, so if you plan to boot from NOR FLASH you have to modify the file name to match the environment variable.

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

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

Line 217:

Line 205:

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.

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.

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]].

+

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#U-Boot_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:

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:

Line 238:

Line 226:

* help

* help

* help <command>

* help <command>

−

* and [[Bootloader]] and [[Bootloader commands]].

+

* and [[U-Boot]] and [[U-Boot 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| 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.}}

Line 353:

Line 341:

GTA01Bv4 # saveenv

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:

+

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

This page explains how to boot a FreeRunner from the (micro-)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.

First, a warning. There was a longstanding bug that could eat the partition table of high-capacity SD cards when the system suspended. This is ticket #1802 which is now closed. See this thread for explanation of the partition table removal on suspend and maybe other problems related to using high capacity SD cards. A safety net is to keep a written copy of the partition table on paper, just in case one needs to recreate it.

On the Neo, U-boot-gena2x 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.

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 "\$").

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.

where <p> 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 #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 supports SDHC protocol on the FreeRunner only: 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.

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 2008-07-17 have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command

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 might to support wear leveling (check before you buy!), but this can not be guaranteed for all vendors.

NOTE: This partition procedure it's NOT necessary if you use the Qi bootloader. With Qi you can have the Kernel Bin in the same partition of the RootFS, there is no need to make this multipartition. Check Qi page for more information.

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. Also see Partitioning Hints before defining your partition layout.

# If the partitions are not unmounted the OS might overwrite it later
# with an old cached version and make it unusable? There it is best to unmount the partitions:
umount /dev/mmcblk0p1
umount /dev/mmcblk0px

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. In case you obtain the error "mmc0: error -110 whilst initialising SD card", try flashing the FYP 3.18 Kernel UImage.bin from http://opensvn.csie.org/fyp/releases/3.18/ . The /dev/mmcblk0 should be detected as /dev/mmcblk0p1 (initiate "$ mount" to find what it is). The side effect is that FreeRunner does not connect to computer via USB cable. Furthermore, fdisk displays "WARNING: rereading partition table failed, kernel still uses old table: Invalid argument". This hack is an experiment only to enable the SD cards that do not mount with OM Kernel. Please update this hack should a proper Kernel or fix be found.

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.

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 automounting the SD on your host, confirm there are no unexpected mount options by using "mount" command alone to list the mounts.

halley:~ # mount -o remount,dev /dev/sdb2
# This is a USB-sdcard stick, so its name is /dev/sdb. YMMV

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

Make sure your kernel is called uImage.bin (or uimage for some versions of NOR u-boot). If the U-Boot doesn't find the kernel image during boot, log into the U-Boot with cu, mount the partition with mmcinit and check the presence and the name of the kernel image with fatls mmc 1:1 for FAT filesystem or ext2ls mmc 1:1 for ext2 filesystem. Compare this carefully with the result of printenv sd_image_name. Remember that you can modify the environment in NAND FLASH, but not in NOR FLASH, so if you plan to boot from NOR FLASH you have to modify the file name to match the environment variable.

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

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#U-Boot_prompt. Details on howto get into the NAND boot menu can be found 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

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 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.

Please watch partition numbers in the following commands. In particular, you may need to change some of

root=/dev/mmcblk0p#
fatload mmc#
ext2load mmc#

depending on which partition number your root and kernel, respectively, are located. Number starts from unity.

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 not supported in older u-boot versions 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:

u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.

Since SD-cards are accessed as mmc device nodes (Major 179 of Linux Allocated Devices) there are some things you should be aware of:

The device nodes numbering schema provides minor numbers from 1 to 7 (/dev/mmcblk0p1 ... /dev/mmcblk0p7). Minor number 8 is the next physical device (/dev/mmcblk1). So we're restricted to a maximum of 7 accessible partitions.

Currently most rootfs' supplies devices mmcblk0p1 through mmcblk0p4. If you want to use extended partitions (5 ...), you need to add those to the udev setup by creating the nodes in /lib/udev/devices/:

Since uboot only supports loading kernel images from the lower 2GB of a physical mmc device, it is recommended to put all kernel images in the first partition. Additionally this partition can come in handy to hold data shared amongst and symlinked from installed distributions, e.g. PIM data.

Booting a rootfs from an extended partition with uboot has been tested successfully.

[edit](Tutorial)Experience summary of a Navie windows user now on Moko

1)If you want to install a DISTRO i.e if you want to boot from an uSD ,I suggest doing a NOR boot and then updating your bootloader to Qi.

2)After this boot the phone with its existing DISTRO.

Set up an SSH access
Step by step procedure for this:

quick answer: plug the usb cable in your laptop (with ubuntu) and in
the freerunner, on ubuntu: type

sudo -i

it will ask password type and it will show "#" (you are root)

type ifconfig -a

it should appear usb0 or some eth1 or eth2 etc.

type ifconfig usb0 192.168.0.200

now type:

ssh root@192.168.0.202

it will ask password, press enter and you'll enter your openmoko!

Now you can type your commands at the phone's root prompt.

3)Then type fdisk /dev/mmcblk0 (for this there should be a uSD kept in the phone)
You will have to now create two partitions with the help of some command options.And before creating partitions you have to remove all its partitions.Type 'p' to view the current partition table and then type 'd' for deleting partitions.

5)Create another partition use the same procedure as above :press n then press 2 now enter the lower cylinder number which you can see in (lower-higher) and then the last cylinder number.

6) press 'w' and this should save partition table and quit.It might give a device busy signal to over come that you might say quit and again set up SSH access.

7)type
mkfs.vfat /dev/mmcblk0p1
and then
mkfs.ext3 /dev/mmcblk0p2

8)Now you have partitions ready.Say if you are loading SHR DISTRO download the rootfs file for SHR and the kernel file (.bin) file.This you can manually download on your desktop or laptop and then copy it into phones memory by saying
scp <file-name> ssh@192.168.0.202: (do this opening a new terminal window and when the phone is in SSH access)
Copy the shr-image-om-gta02.tar.gz and its kernel file uImage-om-gta02-latest.bin. (you can download these two files to your computer from the SHR distro page)

7)When in SSH go to root of phone (this you can do by typing "cd .." and pressing enter for two time.
Then say cd /mnt ,then type "mkdir shr" and also "mkdir shrkernel".With this you create two mounting directories one for the rootfile system image and the other for kernel .bin file.

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:

This page explains how to boot a FreeRunner from the (micro-)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 below).

Booting from SDHC / suspend problems

First, a warning. There was a longstanding bug that could eat the partition table of high-capacity SD cards when the system suspended. This is ticket #1802 which is now closed. See this thread for explanation of the partition table removal on suspend and maybe other problems related to using high capacity SD cards. A safety net is to keep a written copy of the partition table on paper, just in case one needs to recreate it.

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.

where <p> 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 #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 supports SDHC protocol on the FreeRunner only: 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 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.

NILFS

kernelnewbies.org: Linux 2.6.30: 1.1. NILFS2, a log-structured filesystem Quote: "...Another advantage of this approach is that the log offers a coherent historical view of all the operations done in the disk in the past. This is called "continuous snapshotting" - snapshots of modifications done in all the filesystem at any time are created automatically due to the log-structure design, with no requirement of intervention from an admin, and with the filesystem size as the only limit. NILFS2 allows to access those snapshots and even mount them (on read-only mode)..."

Possibility 3 : Convert a jff2 image to a tarfile

Prepare the SD card

Partioning the SD card

NOTE: This partition procedure it's NOT necessary if you use the Qi Bootloader. With Qi you can have the Kernel Bin in the same partition of the RootFS, there is no need to make this multipartition. Check Qi page for more information.

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. Also see Partitioning Hints before defining your partition layout.

# If the partitions are not unmounted the OS might overwrite it later and make it unusable?:
umount /dev/mmcblk0
umount /dev/mmcblk0p1
umount /dev/mmcblk0px

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. In case you obtain the error "mmc0: error -110 whilst initialising SD card", try flashing the FYP 3.18 Kernel UImage.bin from http://opensvn.csie.org/fyp/releases/3.18/ . The /dev/mmcblk0 should be detected as /dev/mmcblk0p1 (initiate "$ mount" to find what it is). The side effect is that FreeRunner does not connect to computer via USB cable. Furthermore, fdisk displays "WARNING: rereading partition table failed, kernel still uses old table: Invalid argument". This hack is an experiment only to enable the SD cards that do not mount with OM Kernel. Please update this hack should a proper Kernel or fix be found.

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.

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 automounting the SD on your host, confirm there are no unexpected mount options by using "mount" command alone to list the mounts.

halley:~ # mount -o remount,dev /dev/sdb2
# This is a USB-sdcard stick, so its name is /dev/sdb. YMMV

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

Make sure your kernel is called uImage.bin (or uimage for some versions of NOR u-boot). If the u-boot doesn't find the kernel image during boot, log into the bootloader with cu, mount the partition with mmcinit and check the presence and the name of the kernel image with fatls mmc 1:1 for FAT filesystem or ext2ls mmc 1:1 for ext2 filesystem. Compare this carefully with the result of printenv sd_image_name. Remember that you can modify the environment in NAND FLASH, but not in NOR FLASH, so if you plan to boot from NOR FLASH you have to modify the file name to match the environment variable.

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 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

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 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.

Please watch partition numbers in the following commands. In particular, you may need to change some of

root=/dev/mmcblk0p#
fatload mmc#
ext2load mmc#

depending on which partition number your root and kernel, respectively, are located. Number starts from unity.

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

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.

If you got error when loading kernel, add sleep to boot entry.

Before:

mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;

After:

mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;

See also Moving current system from flash to SD which shows how to move the running system currently running in flash to an SD card, in order to keep a backup system on SD on which to boot from.

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 not supported in older u-boot versions 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:

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

Partitioning Hints

u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.

Since SD-cards are accessed as mmc device nodes (Major 179 of Linux Allocated Devices) there are some things you should be aware of:

The device nodes numbering schema provides minor numbers from 1 to 7 (/dev/mmcblk0p1 ... /dev/mmcblk0p7). Minor number 8 is the next physical device (/dev/mmcblk1). So we're restricted to a maximum of 7 accessible partitions.

Currently most rootfs' supplies devices mmcblk0p1 through mmcblk0p4. If you want to use extended partitions (5 ...), you need to add those to the udev setup by creating the nodes in /lib/udev/devices/:

Since uboot only supports loading kernel images from the lower 2GB of a physical mmc device, it is recommended to put all kernel images in the first partition. Additionally this partition can come in handy to hold data shared amongst and symlinked from installed distributions, e.g. PIM data.

Booting a rootfs from an extended partition with uboot has been tested successfully.

(Tutorial)EXperience summary of a Navie windows user now on Moko

1)If you want to install a DISTRO i.e if you want to boot from an uSD ,I suggest doing a NOR boot and then updating your bootloader to Qi.

2)After this boot the phone with its existing DISTRO.

Set up an SSH access
Step by step procedure for this:

quick answer: plug the usb cable in your laptop (with ubuntu) and in
the freerunner, on ubuntu: type

sudo -i

it will ask password type and it will show "#" (you are root)

type ifconfig -a

it should appear usb0 or some eth1 or eth2 etc.

type ifconfig usb0 192.168.0.200

now type:

ssh root@192.168.0.202

it will ask password, press enter and you'll enter your openmoko!

Now you can type your commands at the phone's root prompt.

3)Then type fdisk /dev/mmcblk0 (for this there should be a uSD kept in the phone)
You will have to now create two partitions with the help of some command options.And before creating partitions you have to remove all its partitions.Type 'p' to view the current partition table and then type 'd' for deleting partitions.

5)Create another partition use the same procedure as above :press n then press 2 now enter the lower cylinder number which you can see in (lower-higher) and then the last cylinder number.

6) press 'w' and this should save partition table and quit.It might give a device busy signal to over come that you might say quit and again set up SSH access.

7)type
mkfs.vfat /dev/mmcblk0p1
and then
mkfs.ext3 /dev/mmcblk0p2

8)Now you have partitions ready.Say if you are loading SHR DISTRO download the rootfs file for SHR and the kernel file (.bin) file.This you can manually download on your desktop or laptop and then copy it into phones memory by saying
scp <file-name> ssh@192.168.0.202: (do this opening a new terminal window and when the phone is in SSH access)
Copy the shr-image-om-gta02.tar.gz and its kernel file uImage-om-gta02-latest.bin. (you can download these two files to your computer from the SHR distro page)

7)When in SSH go to root of phone (this you can do by typing "cd .." and pressing enter for two time.
Then say cd /mnt ,then type "mkdir shr" and also "mkdir shrkernel".With this you create two mounting directories one for the rootfile system image and the other for kernel .bin file.

Note :do step 8 and 9 from the directory of the phone where you have copied the two files using SCP by defualt this should be root@om-gta02 which again /home/root .

Reboot the phone and TADAAAA you have SHR running on the Worlds first truly customizable open source phone NEO-FREERUNNER.

Edited by R.Sriranjan under guidance of Nicola.Mfb

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: