Booting from SD/de

Views

Personal tools

Languages:

English •  العربية •  Български •  Česky •  Dansk •  Deutsch •  Esperanto •  Eesti •  Español •  فارسی •  Suomi •  Français •  עברית •  Magyar •  Italiano •  한국어 •  Nederlands •  ‪Norsk (bokmål)‬ •  Polski •  Português •  Română •  Русский •  Svenska •  Slovenčina •  Українська •  ‪中文(中国大陆)‬ •  ‪中文(台灣)‬ •  Euskara •  Català

Diese Seite beschreibt, wie man mit dem FreeRunner von einer (Micro-)SD Karte statt vom eingebauten NAND-Flash-Speicher bootet. Da sich die SD-Karte einen Bus mit der GPU teilt, kann jedoch die Performance beeinträchtigt werden.

Booten von SDHC

Vorweg eine Warnung: Ein Bug im Linux-Kernel kann dazu führen, daß die Partitionstabelle der SDHC-Karte während des Suspend zerstöhrt wird. Ticket: #1802. Thread: [1] Am Besten legt man sich ein Backup der Partitionstabelle an, um sie im Notfall schnell wieder zur Verfügung zu haben.

So funktionierts

U-boot spielt auf dem NEO eine ähnliche Rolle wie der Bootloader 'grub' auf einem PC. U-boot läd ein Kernelimage in den Speicher und übermittelt dem Kernel anschießend eine Reihe vom Parametern. Diese Parameter enthalten unteranderem den Ort an dem sich das Rootfilesystem befindet.

Wenn der Kernel bootet, wird die Hardware initialisiert und das Rootfilesystem gemountet. Anschließed startet der Kernel "/sbin/init", welche die restlichen Boot-Up-Sequenzen enthält. (z.B. Startbildschirm und Fortschrittsbalken).

Diese Sequenz ist die gleiche, unabhängig davon ob das Gerät von Built-In-Flash oder von der SD-Karte bootet. Die Unterschiede sind, wie der Kernel geladen wird, und welches Device als Rootfilesystem gemountet ist.

U-Boot-Menü-Einträge

U-boot-Menü-Einträge werden über Umgebungsvariablen definiert. Diese sind nach dem Muster "menu_X" (wobei X eine Zahl ist) aufgebaut. Der Wert dieser Umgebungsvariable ist ein String nach dem Muster "<label>:<commands>", wobei <label> der Text ist, der auf dem Display angezeigt wird und <commands> eine Abfolge der U-boot-Befehle (getrennt durch ';') welche ausgefürht werden wenn der Menüpunkt auswählt wird Beim Eingeben einer Befehlsabfolge müssen ';' und '$' durch "\;" und "\$" ersetzt werden.

Laden des Kernels

Zum Laden des Kernels von der SD-Karte müssen folgende U-Boot-Befehle ausgeführt werden: Die SD-Karte mit "mmcinit" initialisieren. Den Kernel in den Arbeitsspeicher laden:

Kernel befindet sich auf einem FAT-Filesystem:

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

Kernel befindet sich auf einem ext2/ext3-Filesystem:

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

Hierbei entspricht <p> der Partitionsnummer und <filepath> dem Pfad zu dem zu ladendem Kernel.

Root-Filesystem Parameter

Der Inhalt der "bootargs" Umgebungsvariable die an den Kernel übergeben wird, ist eine durch Leerzeichen getrennte Liste bestehend aus "name=value"-Definitionen. Relevante Elemente für das Booten von einer SD-Karte sind "root", "rootfstype" und "rootdelay".

Beispiel: Folgende Parameter veranlassen den Kernel die dritte Partition der SD-Karte zu mounten:

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

Der "rootdelay"-Parameter gibt der SD-Karte die nötige Zeit um sich zu initialisieren bevor auf sie zugegriffen wird.

Wichtig ist, daß der Kernel das Root-Filesystem auch unterstützt. Der Default-Openmoko-Kernel 2008-07-17 unterstützt ext2 und ext3. Überprüfen kann man die unterstützten Filesysteme mit folgendem Linux-Befehl:

less /proc/filesystems

Es ist nicht möglich, VFAT als Root-Filesystem zu benutzen.

ext2 vs. ext3

Ext2 oder ext3 als Root-Filesystem verwenden? Das Journaling-Dateisystem Ext3 ist prinzipiell die bessere Wahl, da hier nach einem unsauberen Shutdown des Systems kein "fsck" (Datei-System-Check) durchgeführt werden muss. Jedoch unterstützt ext3 kein wear-leveling (schonende Schreibweise für Flash-Speicher).

Rootfs

Es gibt zwei Möglichkeiten an ein Rootfs-Image heran zu kommen. Entweder man baut sich mit der OpenEmbedded Distribution sein einges Rootfs-Image oder man läd es sich ein fertiges Image vom OpenMoko buildhost herunter.

Möglichkeit 1: Rootfs.tar und Kernel.tar vom Openmoko buildhost downloaden

Aktuelles Rootfs und Kernel einfach unter Latest Images downloaden.

Möglichkeit 2: Mit OpenEmbedded selber ein tar-File erstellen

Eine weitere Möglichkeit besteht darin, sich selber mit der OpenEmbedded Umgebung ein Rootfs-tar-Archiv zu erstellen.

Um OM-2007.2 zu erstellen, muss man "tar" zu den Image-Typen in seiner local.conf hinzudügen:

IMAGE_FSTYPES = "jffs2 tar"

Jetzt kann man das neue Image erstellen:

bitbake openmoko-devel-image

oder mit MokoMakefile:

make openmoko-devel-image

Das Openmoko-....tar findet sich anschließend im Out-Pfad.

Möglichkeit 3 : Ein jff2-Image in ein tar-File konvertieren

Siehe Userspace root image.

Vorbereiten der SD-Karte

Partitionieren der SD-Karte

U-Boot vor 2008-07-23 kan ausschließlich von FAT-Filesystemen booten. Nach einem U-Boot-Update kann auch von ext2/ext3 gebootet werden. Dieses Beispiel zeigt wie man mit fdisk Partitionen erstellt.

fdisk /dev/mmcblk0

Achtung: Der Gerätename kann variieren. Um sicher zu gehen, ob man den richtigen Gerätenamen hat, liest man die Kernel-Message-Log durch den Aufruf von dmesg. Jetzt erstellt man eine 8MB Partition für den Kernel und eine Partition mit dem restlichen Speicherplatz für das Root-Filesyetem.

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.

bei folgender Fehlermeldung:

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

einfach das Gerät aushängen:

umount /dev/mmcblk0p1

und nocheinmal von vorn beginnen.

Formatieren der SD-Karte

Folgender Befehl formatiert die erste Partition der SD-Karte mit dem FAT-Filesystem:

mkfs.vfat /dev/mmcblk0p1

Die zweite Partition wird mit dem ext3-Filesystem formatiert:

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

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 help help <command> and Bootloader and Bootloader commands.

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 root=/dev/mmcblk0p# and fatload mmc # or 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 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.

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

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

Languages:

English •  العربية •  Български •  Česky •  Dansk •  Deutsch •  Esperanto •  Eesti •  Español •  فارسی •  Suomi •  Français •  עברית •  Magyar •  Italiano •  한국어 •  Nederlands •  ‪Norsk (bokmål)‬ •  Polski •  Português •  Română •  Русский •  Svenska •  Slovenčina •  Українська •  ‪中文(中国大陆)‬ •  ‪中文(台灣)‬ •  Euskara •  Català

Search

Tools