Booting from SD/es

From Openmoko

Revision as of 09:05, 19 July 2009 by Glenn (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Esta página explica como arrancar un FreeRunner desde la (micro-)SD card en vez de hacerlo desde la memória NAND Flash. La tarjeta SD comparte un bus con la GPU, aunque no es como debería funcionar, es otra opción.

WARNING: Posibles problemas al arrancar desde una SDHC (ver más adelante).


Contents

Arrancando desde SDHC / problemas al suspender

Primero, una advertencia. Existe un bug, posiblemente derivado del Kernel, que hace que se pierda la tabla de particiones de las tarjetas SD de alta capacidad (SDHC) cuando se entra en modo de suspensión. El ticket #1802. Ver this thread para una explicación de la perdida de la tabla de particiones al suspender y algún otro problema relacionado con las tarjetas SDHC. Para evitar problemas, se recomienda mantener una copia de la tabla de particiones, aunque sea en un papel, por si es necesario volver a crearlas.

Como funciona

En el Neo, el u-boot desarrolla una función similar a la del gestor de arranque 'grub' en un PC. U-boot carga la imagen del kernel en memoria y después le pasa la lista de parámetros. Estos parámetros especifican, entre otras cosas, el dispositivo en el cual el sistema de archivos raíz está localizado.

Cuando el kernel arranca, inicializa el hardware y monta el sistema de archivos raíz. Entonces el kernel ejecuta "/sbin/init", el cual maneja el resto de la secuencia de arranque (como se muestra en la pantalla y en la barra de progreso).

Ésta secuencia es la misma tanto si se arranca desde la Flash NAND como desde la tarjeta SD. La diferencia radica en como el kernel es cargado y que dispositivo es montado como sistema de archivos raíz.

Las siguientes secciones proporcionan los detalles adicionales.

Entradas de menu

Las entradas de menu de U-boot estan definidas en las variables de entorno llamadas "menu_X" (donde X es un número). El valor de las variables de entorno es un texto llamado "<label>:<commands>", donde <label> es el texto que se muestra en pantalla, y <commands> es la secuencia de comandos de u-boot (delimitados por el caracter ';') que se han de ejecutar cuando se escoje un punto de menu. Cuando se introduce un texto de comandos, los caracteres ';' y '$' han de ser escapados con la contrabarra ("\;" and "\$").

Cargando el Kernel

Un par de comandos de u-boot deben ser utilizados para cargar el kernel desde tarjeta la SD. primero "mmcinit", el cual hace que u-boot detecte la tarjeta. Después está el comando que carga el archivo en la memoria, que puede ser "fatload" o "ext2load" dependiendo de si el sistema de archivos donde se encuentra el kernel es FAT o ext2/ext3.

La sintaxis del comando es:

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

donde <p> es el número de partición, y <filepath> es la ruta al archivo que ha de ser cargado.

NOTE: El comando "ext2load" está dañado en los binarios de u-boot anteriores a "20080723", incluyendo el envío que se realizó con los primeros FreeRunners, estan afectados por el bug #799. Si actualizas tus paquetes de U-Boot y kernel podrás utilizar directamente el arranque en una partición ext2 / 3.


WARNING: Se ha de tener cuidado si se intenta actualizar el u-boot en un Neo1973 ya que existe el riesgo romper el dispositivo (a menos que se tenga la debug board). Esto no pasa en el Neo FreeRunner ya que el u-boot tiene una copia protegida en la NOR flash


NOTE: U-Boot soporta el protocolo de las tarjetas SDHC solo en el NeoFreerunner: en el Neo1973, u-boot es inestable al acceder a tarjetas SDHC (4G o mayores). El kernel tiene soporte SDHC en el Neo1973, por lo que es posible tener un sistema de archivos raíz en una SDHC y el kernel en la NAND flash para trabajar con el.


Parámetros del sistema de archivos raíz

El contenido de las variable de entorno "bootargs" son pasadas al kernel. Bootargs es una lista de valores delimitadas por espacios de definiciones "name=value". las partes relevantes para arrancar desde una SD son "root", "rootfstype", y "rootdelay".

Por ejemplo, la siguiente lista de parámetros le dirá al kernel que monte la tercera partición de la tarjeta SD como un sistema de archivos ext3:

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

El parametro "rootdelay" concede tiempo a la tarjeta para que sea correctamente inicializada antes de acceeder a ella.

Observa que el soporte ha de estar cargado en el kernel (no como un módulo) para el sistema de archivos especificado en "rootfstype". La configuración por defecto del kernel de Openmoko como de 2008-07-17 tiene cargado el soporte para ambos ext2 and ext3. Puedes verificar los sistemas de archivos disponibles a través del comando de linux

less /proc/filesystems

No es posible utilizar VFAT para el sistema de archivos raíz

NOTE: Resto de articulo pendiente de traducir


ext2 vs. ext3

Existen opiniones divididas en cuanto a que sistema de archivos es mejor utilizar ext2 o ext3. Ext3 en general es la mejor elección, ya que es un sistema de archivos con registro por diario (journaling) que no requiere un gran 'fsck' (file system check) despues de un apagado forzado. 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

Possibility 3 : Convert a jff2 image to a tarfile

See Userspace root image for more details on how to access contents of a jffs2 image.

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.

Should probably need to change type of first partition to FAT 16 too ?

(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)

How about a swap partition also?

if it exits with something like

  Calling ioctl() to re-read partition table
  fdisk: WARNING: rereading partition table failed, kernel still uses old table:   Device or resource busy

do

  umount /dev/mmcblk0p1

on another shell and try again.

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

Or, for some versions of NOR u-boot:

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

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

  • See also" Qi

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.

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

or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):

setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init 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

Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)

setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1: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 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:

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: ....
Personal tools

Esta página explica como arrancar un FreeRunner desde la (micro-)SD card en vez de hacerlo desde la memória NAND Flash. La tarjeta SD comparte un bus con la GPU, aunque no es como debería funcionar, es otra opción.

WARNING: Posibles problemas al arrancar desde una SDHC (ver más adelante).


Arrancando desde SDHC / problemas al suspender

Primero, una advertencia. Existe un bug, posiblemente derivado del Kernel, que hace que se pierda la tabla de particiones de las tarjetas SD de alta capacidad (SDHC) cuando se entra en modo de suspensión. El ticket #1802. Ver this thread para una explicación de la perdida de la tabla de particiones al suspender y algún otro problema relacionado con las tarjetas SDHC. Para evitar problemas, se recomienda mantener una copia de la tabla de particiones, aunque sea en un papel, por si es necesario volver a crearlas.

Como funciona

En el Neo, el u-boot desarrolla una función similar a la del gestor de arranque 'grub' en un PC. U-boot carga la imagen del kernel en memoria y después le pasa la lista de parámetros. Estos parámetros especifican, entre otras cosas, el dispositivo en el cual el sistema de archivos raíz está localizado.

Cuando el kernel arranca, inicializa el hardware y monta el sistema de archivos raíz. Entonces el kernel ejecuta "/sbin/init", el cual maneja el resto de la secuencia de arranque (como se muestra en la pantalla y en la barra de progreso).

Ésta secuencia es la misma tanto si se arranca desde la Flash NAND como desde la tarjeta SD. La diferencia radica en como el kernel es cargado y que dispositivo es montado como sistema de archivos raíz.

Las siguientes secciones proporcionan los detalles adicionales.

Entradas de menu

Las entradas de menu de U-boot estan definidas en las variables de entorno llamadas "menu_X" (donde X es un número). El valor de las variables de entorno es un texto llamado "<label>:<commands>", donde <label> es el texto que se muestra en pantalla, y <commands> es la secuencia de comandos de u-boot (delimitados por el caracter ';') que se han de ejecutar cuando se escoje un punto de menu. Cuando se introduce un texto de comandos, los caracteres ';' y '$' han de ser escapados con la contrabarra ("\;" and "\$").

Cargando el Kernel

Un par de comandos de u-boot deben ser utilizados para cargar el kernel desde tarjeta la SD. primero "mmcinit", el cual hace que u-boot detecte la tarjeta. Después está el comando que carga el archivo en la memoria, que puede ser "fatload" o "ext2load" dependiendo de si el sistema de archivos donde se encuentra el kernel es FAT o ext2/ext3.

La sintaxis del comando es:

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

donde <p> es el número de partición, y <filepath> es la ruta al archivo que ha de ser cargado.

NOTE: El comando "ext2load" está dañado en los binarios de u-boot anteriores a "20080723", incluyendo el envío que se realizó con los primeros FreeRunners, estan afectados por el bug #799. Si actualizas tus paquetes de U-Boot y kernel podrás utilizar directamente el arranque en una partición ext2 / 3.


WARNING: Se ha de tener cuidado si se intenta actualizar el u-boot en un Neo1973 ya que existe el riesgo romper el dispositivo (a menos que se tenga la debug board). Esto no pasa en el Neo FreeRunner ya que el u-boot tiene una copia protegida en la NOR flash


NOTE: U-Boot soporta el protocolo de las tarjetas SDHC solo en el NeoFreerunner: en el Neo1973, u-boot es inestable al acceder a tarjetas SDHC (4G o mayores). El kernel tiene soporte SDHC en el Neo1973, por lo que es posible tener un sistema de archivos raíz en una SDHC y el kernel en la NAND flash para trabajar con el.


Parámetros del sistema de archivos raíz

El contenido de las variable de entorno "bootargs" son pasadas al kernel. Bootargs es una lista de valores delimitadas por espacios de definiciones "name=value". las partes relevantes para arrancar desde una SD son "root", "rootfstype", y "rootdelay".

Por ejemplo, la siguiente lista de parámetros le dirá al kernel que monte la tercera partición de la tarjeta SD como un sistema de archivos ext3:

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

El parametro "rootdelay" concede tiempo a la tarjeta para que sea correctamente inicializada antes de acceeder a ella.

Observa que el soporte ha de estar cargado en el kernel (no como un módulo) para el sistema de archivos especificado en "rootfstype". La configuración por defecto del kernel de Openmoko como de 2008-07-17 tiene cargado el soporte para ambos ext2 and ext3. Puedes verificar los sistemas de archivos disponibles a través del comando de linux

less /proc/filesystems

No es posible utilizar VFAT para el sistema de archivos raíz

NOTE: Resto de articulo pendiente de traducir


ext2 vs. ext3

Existen opiniones divididas en cuanto a que sistema de archivos es mejor utilizar ext2 o ext3. Ext3 en general es la mejor elección, ya que es un sistema de archivos con registro por diario (journaling) que no requiere un gran 'fsck' (file system check) despues de un apagado forzado. 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

Possibility 3 : Convert a jff2 image to a tarfile

See Userspace root image for more details on how to access contents of a jffs2 image.

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.

Should probably need to change type of first partition to FAT 16 too ?

(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)

How about a swap partition also?

if it exits with something like

  Calling ioctl() to re-read partition table
  fdisk: WARNING: rereading partition table failed, kernel still uses old table:   Device or resource busy

do

  umount /dev/mmcblk0p1

on another shell and try again.

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

Or, for some versions of NOR u-boot:

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

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

  • See also" Qi

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.

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

or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):

setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init 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

Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)

setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts} ro\; mmcinit\; ext2load mmc 1: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 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:

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