http://openmoko.org/api.php?action=feedcontributions&user=Lokomoko&feedformat=atomOpenmoko - User contributions [en]2024-03-28T13:18:39ZUser contributionsMediaWiki 1.19.24http://openmoko.org/wiki/NavitNavit2009-10-20T14:49:07Z<p>Lokomoko: /* Preselect Country of Destination */</p>
<hr />
<div>{{Application|Navit}}<br />
<br />
As described on the [http://navit.sourceforge.net/ Navit home page],<br />
<br />
<i>"'''Navit''' is a car navigation system with routing engine.<br />
<br />
Its modular design is capable of using vector maps of various formats for routing and rendering of the displayed map. It's even possible to use multiple maps at a time.<br />
<br />
The GTK+ or SDL user interfaces are designed to work well with touch screen displays. Points of Interest of various formats are displayed on the map.<br />
<br />
The current vehicle position is either read from gpsd or directly from NMEA GPS sensors."</i><br />
<br />
Some people say Navit is also a good choice for pedestrian and bicycle navigation.<br />
<br />
[[Image:Navit-2241.png|thumb|Navit-r2241]]<br />
<br />
== Acknowledgment ==<br />
<br />
Thanks to [[User:Alessandro | Alessandro]], stefan_schmidt, cp15 and all Navit developers I have done a small ("not really working") preview of Navit on Neo1973 at [http://www.telemobilityforum.com/eng/ Telemobility Forum 2007]. Thanks to [http://gfoss.it GFoss] guys to invite me.<br />
''[[User:Tyrael | Tyrael]]''<br />
<br />
==Setting up Navit==<br />
<br />
===Install Navit===<br />
==== FSO (OM2008.x,SHR,...) ====<br />
<br />
You can now simply add a feed from there : http://download.navit-project.org/navit/openmoko/svn/<br />
<br />
Essentially, to enable this directory as [[Om_2008.8_Installer#How to add a Repository ?|feed]] and install or update navit do:<br />
* Only for the first time:<br />
echo src navit http://download.navit-project.org/navit/openmoko/svn > /etc/opkg/navit-feed.conf<br />
opkg update<br />
<br />
* Always:<br />
opkg install navit<br />
<br />
Navit will be auto-updated when you run opkg upgrade later<br />
<br />
Navit might not be able to use gpsd at startup:<br />
navit:plugin_load:can't load '/usr/lib/navit/vehicle/<br />
libvehicle_gpsd.so', Error 'libgps.so.16: cannot open shared object <br />
file: No such file or directory'<br />
navit:vehicle_new:invalid type 'gpsd'<br />
<br />
to solve this issue (necessary for SHR):<br />
<br />
opkg install libgps17<br />
ln -s /usr/lib/libgps.so.17 /usr/lib/libgps.so.16<br />
<br />
====Debian====<br />
Navit is now in Debian [http://packages.debian.org/source/testing/navit testing] and [http://packages.debian.org/source/unstable/navit unstable].<br />
<br />
Add the following line to <tt>/etc/apt/sources.list</tt> with e.g. editor <tt>vi</tt> or <tt>nano</tt>:<br />
<br />
deb http://ftp.de.debian.org/debian unstable main<br />
<br />
Then update with apt-get:<br />
<br />
apt-get update<br />
<br />
The up-to-date source package is available through git at '''git://git.debian.org/git/collab-maint/navit.git''' ([http://git.debian.org/?p=collab-maint/navit.git;a=summary browse]).<br />
<br />
===Set up the maps you want===<br />
<br />
====The Easy Way====<br />
Use [http://maps.navit-project.org/download/ Navit pre-processed OSM maps]. Navigate to the region you want, and click select to select it, select the region you want, then click download. [[Image:osmdownload.jpg|200px|thumb|Download OpenStreetMaps]] <br />
<br />
If you just want the entire planet (as of this writing, ~1.8 GB), it's [http://maps.navit-project.org/planet.bin here].<br />
<br />
[http://downloads.cloudmade.com/ CloudMade] also has up-to-date maps from OpenStreetMap by country (by state in the US).<br />
<br />
====From the command line====<br />
'''OpenStreetMap''' - follow directions at http://wiki.navit-project.org/index.php/OpenStreetMaps<br />
* There are some pre-processed, up-to-date maps that can be grabbed with wget:<br />
<br />
<pre>wget -O germany.bin http://maps.navit-project.org/api/map/?bbox=5.185546875,46.845703125,15.46875,55.634765625</pre><br />
<br />
You can put a shell script into <tt>/usr/local/bin/update-maps</tt><br />
#!/bin/sh<br />
echo "Update OpenstreetMaps"<br />
echo "---------------------"<br />
echo " download and store OSM maps on /media/card/maps"<br />
wget -O /media/card/maps/germany.bin http://maps.navit-project.org/api/map/?bbox=5.185546875,46.845703125,15.46875,55.634765625<br />
echo "update germany.bin finished"<br />
You have to make the script executable with:<br />
chmod u+x /usr/local/bin/update-maps<br />
Then you can update with this script all your maps on the SD-card if you have internet connection:<br />
update-maps<br />
<br />
* Here's an example to get the maps for the area around Seattle, WA:<br />
** Find the map coordinates using http://informationfreeway.org/?lat=47.520270037501454&lon=-122.20130713167327&zoom=9&layers=B000F000<br />
** Download 4 regions from OpenStreetMaps ([[Navit#Script_to_download_OSM_maps|see below]] for a script to do this for you automatically for largish areas):<br />
<br />
<pre>wget -O map1.osm http://www.openstreetmap.org/api/0.5/map?bbox=-122.2,47.5,-122,47.7<br />
wget -O map2.osm http://www.openstreetmap.org/api/0.5/map?bbox=-122.4,47.5,-122.2,47.7<br />
wget -O map3.osm http://www.openstreetmap.org/api/0.5/map?bbox=-122.4,47.3,-122.2,47.5<br />
wget -O map4.osm http://www.openstreetmap.org/api/0.5/map?bbox=-122.2,47.3,-122,47.5</pre><br />
<br />
* A binary Navit map file needs to be created. The following uses osm2navit, and it's recommended that this command be used on something more powerful than the Neo:<br />
<br />
<pre>cat *.osm | osm2navit --dedupe-ways mymap.bin</pre><br />
<br />
===Copy the map to the NEO===<br />
To copy the map using scp (replace ''/directory'' as is appropriate in the following):<br />
<pre>scp mymap.bin root@neo:/directory</pre><br />
If you copy the map <tt>germany.bin</tt> to the SD card on the Neo use e.g.<br />
<pre>scp germany.bin root@neo:/media/card</pre><br />
<br />
Once it's somewhere on the NEO, Navit needs to know that it's there.<br />
<pre>mkdir ~/.navit<br />
cp /usr/share/navit/navit.xml ~/.navit/navit.xml<br />
vi ~/.navit/navit.xml</pre><br />
<br />
===Enable Maps in Navit ===<br />
Now you must let Navit know the maps you want to use. Several disabled mapset-tags are predefined. <br />
In the navit.xml file, put the following into a new <mapset> section (and disable the default <mapset> just above - or else it will not work):<br />
<pre><map type="binfile" enabled="yes" data="/directory" /></pre><br />
For example with a <tt>germany.bin</tt> on the SD-card you use:<br />
<mapset enabled="yes"><br />
<map type="binfile" enabled="yes" data="/media/card/germany.bin" /><br />
</mapset><br />
or if you store all downloaded maps in the directory <tt>/media/card/maps</tt> then add the following lines to <tt>navit.xml</tt>.<br />
<mapset enabled="yes"><br />
<map type="binfile" enabled="yes" data="/media/card/maps/*.bin"/><br />
</mapset><br />
Note that the bin-file and the map set both have to be enabled.<br />
<br />
Disable unused mapset sections by setting enabled to <tt>no</tt>, e.g. the pre-installed sample maps at line 370 in <tt>navit.xml</tt>.<br />
<mapset enabled="no"><br />
<xi:include href="$NAVIT_SHAREDIR/maps/*.xml"/><br />
</mapset><br />
<br />
<br />
* Run navit<br />
** Start [[gllin]] (for GTA01)<br />
** Start [[gpsd]] ( gpsd /tmp/nmeaNP )<br />
** Start navit<br />
<br />
* The version of osm2navit with which you build the maps should match the version of navit you have. If in doubt, build the maps on the Openmoko.<br />
<br />
===Tips and Tricks===<br />
====Center on Vehicle====<br />
Navit supports a "always center on vehicle" option. <br />
<br />
To activate this add<br />
follow="3"<br />
to the <tt>vehicle</tt> tag in navit.xml. <br />
<vehicle name="Local GPS" profilename="car" enabled="yes" active="1" follow="3" <br />
source="gpsd://localhost" gpsd_query="w+xj" color="#0000ff"><br />
The "3" causes to give the gui time to do something between the repaints (drag the map or browse the menu). When its set to "1" navit does nothing more than repainting the map continuously.<br />
<br />
==Routing==<br />
[[Image:navit_main_menu.png|100px|thumb|Navit Main Menu]]<br />
[[Image:navit_action_menu.png|100px|thumb|Navit Action Menu]]<br />
The main menu has 4 submenus<br />
* Action<br />
* Settings<br />
* Tools<br />
* Route<br />
Normally you would assume the entering a town can be found under the submenu Route, but Town is hidden under submenu Action. Route will provide the description of the route as text and a height profile of your trip. Tools was not working on 08/2009 Version of navit on SHR (see [[SHR User Manual]]).<br />
<br />
===Preselect Country of Destination===<br />
Normally you have to select the the country first before choosing the town and street name. It might be more convenient for you if you preselect the country already with your settings.<br />
The article [[Configure SHR for German-speaking use]] had a preselection of the country "Austria" in Navit. Adapt the localization for your country and maps in Navit, so that do not need to select the country anymore.<br />
<br />
Actually Navit derives the preselected country from the calling environments's locale (see [[Localization]]). Make sure, that LC_ALL ist '''not''' set though. Otherwise navit fails to interprete gpsd output and you end up with strange gps coordinates. When starting from gui (e.g. illume) you can achieve this by supplying an executable script /usr/local/bin/navit which might look like this:<br />
<pre><br />
#!/bin/bash<br />
#export LANG=xx_YY.UTF-8 # Uncomment this line and replace xx_YY, if <br />
# your gui's locale is not setup accordingly. <br />
unset LC_ALL<br />
/usr/bin/navit<br />
</pre><br />
So a valid locale environment preselecting search for German cities would look like this:<br />
<pre><br />
root@om-gta02 ~ $ locale<br />
LANG=de_DE.UTF-8<br />
LC_CTYPE="de_DE.UTF-8"<br />
LC_NUMERIC="de_DE.UTF-8"<br />
...<br />
LC_MEASUREMENT="de_DE.UTF-8"<br />
LC_IDENTIFICATION="de_DE.UTF-8"<br />
LC_ALL=<br />
</pre><br />
Note that there's a limited number of [http://wiki.navit-project.org/index.php/OpenStreetMaps#Known_countries_by_osm2navit countries supported by osm2navit] and Navit's search function.<br />
<br />
===Select Destination===<br />
[[Image:navit_select_country.png|100px|thumb|Select Country]]<br />
<br />
When you click in the main menu on <i>Action</i> the <i>Action</i> menu appears with 4 subitems.<br />
* Bookmarks of previous locations (stored in <tt>/home/root/.navit/destinations.txt</tt><br />
* a globe showing a location as destination,<br />
* a vehicle that shows the current GPS position of the vehicle. If the freerunner receives no GPS signal the locations of the vehicle is set to 0.0.0N and 0.0.0E. <br />
* Town is the action to enter a destination.<br />
* Quit navit is the last action in this submenu.<br />
<br />
Select the icon <i>Town</i>.<br />
<br />
<br />
====Select Country====<br />
[[Image:navit_country_selected.png|100px|thumb|Country Options]]<br />
[[Image:navit_destination_details.png|100px|thumb|Enter Bookmark Details]]<br />
<br />
Before you can search for City you have to select a Country. To do that, click on the icon in the left upper corner of the search field (could look like a white square with blue top-left quadrant).<br />
<br />
Just type in the first letter of the country (e.g. "G") and Navit makes suggestions (e.g. Gabon, Germany).<br />
<br />
====Enter Town====<br />
<br />
When you have selected the country (e.g. Germany) the flag appears and you can select the town.<br />
Then you can save the town as bookmark and enter more details like streets to the selected town.<br />
<br />
The search is still a little buggy.<br />
<br />
====Enter Street====<br />
You can enter the street and streetnumber and save it as bookmark when you use the destination often. <br />
<br />
====Bookmarks====<br />
Navigation and planning of routes with Navit can be organized with bookmarks.<br />
* set a bookmark as current position <br />
* set a bookmark as destination<br />
Then you can see the suggested route in blue on the map. <br />
<br />
Bookmarks are stored in:<br />
/home/root/.navit/bookmark.txt<br />
<br />
The GPS-location (if GPS-signal is available) will be highlighted with a small blue circle. The color of the circle can be defined via editing the <tt>navit.xml</tt> (see [http://wiki.openmoko.org/wiki/Navit#Set_Cursor_Color select cursor color]).<br />
* a dot in the blue circle is indicating that your are not moving,<br />
* an arrowhead is indicating the direction, when you are moving.<br />
Then routing can start and in the map the route is highlighted.<br />
<br />
====Screenshots in Navit Documentation====<br />
The screenshots are made with <tt>gpe-scap</tt>, that can be installed by:<br />
opkg install gpe-scap<br />
if not installed already. Navigation through your installed application navit and login via ssh on your Freerunner <br />
ssh -l root 192.168.0.202<br />
assuming that your Freerunner has the IP 192.168.0.202.<br />
Any time you want to make a screenshot just start via your desktop computer <br />
gpe-scap<br />
and save the screenshot to you freerunner.<br />
Download the screenshot to your desktop computer with<br />
desktop# sftp://root@192.168.0.202<br />
<br />
== News ==<br />
A deeper look into configuring Navit can be found in the [http://wiki.navit-project.org/index.php/Configuring_Navit Navit-Wiki].<br />
<br />
=== Getting the display right ===<br />
<br />
If using SHR the keyboard in country/town/street search mode does not fit on the street, make sure your gui configuration is set to the following line:<br />
<br />
<gui type="internal" font_size="350"/><br />
<br />
The example line provided for freerunners hides some important icons. Namely, instead of typing your city name first, you will first have to click the button on the top left, to go into country search mode. Enter your country name, then the city name, in order to enable the search function. This requires your map data to be searchable.<br />
<br />
You can start in fullscreen mode with fullscreen="1"<br />
<br />
<gui type="internal" font_size="350" fullscreen="1"/><br />
<br />
If you want to enable "+" and "-" as Zoom-In and Zoom-Out buttons on the bottom of the map enable the button with the following xml-tags:<br />
<osd enabled="yes" type="button" x="-96" y="-96" command="zoom_in()" src="zoom_in.xpm"/><br />
<osd enabled="yes" type="button" x="0" y="-96" command="zoom_out()" src="zoom_out.xpm"/><br />
<br />
=== Set Cursor Color ===<br />
[[Image:red_cursor.png|90px|thumb|Red Cursor]]<br />
If you navigate, the route is marked in blue color on the map. The current position of the vehicle is displayed by a blue circle. The circle is sometimes difficult to see on the blue track. If you want to change the color, size of the vehicle cursor edit the vehicle XML-environment in navit.xml (e.g. replace blue color #0000FF with red color #FF0000 -- for details of [http://html-color-codes.info Color Codes] select color, copy and paste code in <tt>navit.xml</tt>) <br />
<br />
<vehicle name="Local GPS" profilename="car" enabled="yes" active="1" source="gpsd://localhost" gpsd_query="w+xj" color="#0000ff"><br />
<!-- Navit can write a tracklog in several formats (gpx, nmea or textfile): --><br />
<!-- <log type="gpx" data="track_%Y%m%d-%i.gpx" flush_size="1000" flush_time="30"/> --><br />
<cursor w="56" h="56"><br />
<!-- tag defines the circle for the cursor --><br />
<itemgra><br />
<circle color="#ff0000" radius="42" width="6"><br />
<coord x="0" y="0"/><br />
</circle><br />
<circle color="#ffffff" radius="48" width="2"><br />
<coord x="0" y="0"/><br />
</circle><br />
</itemgra><br />
<!-- tag defines the dot when the vehicle is not moving --><br />
<itemgra speed_range="-2"><br />
<polyline color="#ff0000" width="6"><br />
<coord x="1" y="1"/><br />
<coord x="1" y="-1"/><br />
<coord x="-1" y="-1"/><br />
<coord x="-1" y="-1"/><br />
</polyline><br />
<circle color="#ffffff" radius="9" width="2"><br />
<coord x="0" y="0"/><br />
</circle><br />
</itemgra><br />
<!-- This itemgra-tag defines the arrow when the vehicle moves --><br />
<itemgra speed_range="3-"><br />
<polyline color="#ff0000" width="6"><br />
<coord x="-7" y="-10"/><br />
<coord x="0" y="12"/><br />
<coord x="7" y="-10"/><br />
</polyline><br />
<polyline color="#ffffff" width="2"><br />
<coord x="+10" y="-10"/><br />
<coord x="3" y="15"/><br />
</polyline><br />
<polyline color="#ffffff" width="2"><br />
<coord x="-10" y="-10"/><br />
<coord x="-3" y="15"/><br />
</polyline><br />
</itemgra><br />
</cursor><br />
</vehicle><br />
The following screenshot show Navit with a red cursor on a blue track:<br />
<br />
[[Image:navit_color_cursor.png|200px|thumb|Red Cursor Color on blue track - vehicle not moving]]<br />
<br />
=== Speech ===<br />
Navit can speak if you install [http://espeak.sourceforge.net/ eSpeak] + [http://www.freebsoft.org/speechd speech-dispatcher] and updates your navit.xml file.<br />
For adventurous people, one way to do this (for SHR and <tt>navit</tt> speaking german see [[Configure SHR for German-speaking use]]):<br />
<br />
* mokoTTS aims to integrate these packages in OM:<br />
http://projects.openmoko.org/projects/mokotts/<br />
<br />
install espeak, dotconf, and then speech-dispatcher.<br />
note: running 2008.8 updating from zecke's "testing" repo does not require "dotconf"<br />
<br />
* change the speech tag in navit.xml:<br />
<speech type="cmdline" data="spd-say '%s'" /><br />
<br />
or "spd-say -l fr '%s'" for using the French voice for example.<br />
<br />
The speech-dispatcher is blocking the audio after suspend. So after a suspend you will hear no ringtone, when a phone call is coming in and you cannot listen do audio files.<br />
A solution is to disable starting of speech-dispatcher with:<br />
update-rc.d -f speech-dispatcher remove<br />
Then the speech-dispatcher should be started if and only if navit is running and shut down when navit is closed.<br />
<br />
Furthermore navit should be started indirect with a script <tt>navit.sh</tt> instead of a direct start with the binary located in <tt>/usr/bin/navit</tt>. The script <tt>navit.sh</tt> listed below starts speech-dispatcher before navit, and stops it afterwards. See http://lists.openmoko.org/nabble.html#nabble-td1088795<br />
<br />
The following script is doing the suggested procedure. This script includes a language fix for Austria (see [[Configure SHR for German-speaking use]]).<br />
export LANG=de_AT.utf8<br />
Replace '''<tt>de_AT</tt>''' in this line with the appropriate language variable in the following script <tt>navit.sh</tt>.<br />
<pre><br />
#! /bin/sh<br />
#<br />
# Copyright Matthias Hentges <devel@hentges.net> (c) 2008<br />
# License: GPL (see http://www.gnu.org/licenses/gpl.txt for a copy of the license)<br />
#<br />
# Filename: navit.sh<br />
# Date: 20080105 (YMD)<br />
#<br />
#################################################################################<br />
#<br />
# 20080105 - v0.0.1 - Initial release<br />
# 20090818 - - Zoff <zoff@zoff.cc> addons and fixes<br />
#<br />
#<br />
#################################################################################<br />
<br />
<br />
#################################################################################<br />
#<br />
# On devices with low memory (< 512Mb?) Navit will segfault on start.<br />
# This can be worked around by doing<br />
# "echo 1 > /proc/sys/vm/overcommit_memory"<br />
#<br />
#################################################################################<br />
<br />
<br />
. /etc/profile<br />
<br />
set|grep LC<br />
<br />
#### Stop the speech dispatcher ####<br />
/etc/init.d/speech-dispatcher stop<br />
<br />
#### Language Fix #################<br />
set|grep LC<br />
<br />
<br />
export LC_ALL=''<br />
unset LC_ALL<br />
export LANG=de_AT.utf8<br />
<br />
set|grep LC<br />
<br />
#### Start the speech dispatcher ####<br />
/etc/init.d/speech-dispatcher start &<br />
<br />
<br />
set|grep LC<br />
<br />
<br />
# need cpu and display<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy Display enabled<br />
<br />
<br />
if test "`cat /proc/meminfo | grep ^MemTotal | awk '{print $2}'`" -lt "500000"<br />
then<br />
if test "$USER" = "root"<br />
then<br />
echo "Enabling low-mem workaround..."<br />
echo 1 > /proc/sys/vm/overcommit_memory<br />
else<br />
echo "I need root-privs to enable the low-mem workaround!"<br />
fi<br />
fi<br />
<br />
######### Start NAVIT NOW ############<br />
<br />
navit $*<br />
<br />
#### Stop the speech dispatcher ####<br />
<br />
/etc/init.d/speech-dispatcher stop<br />
<br />
# release cpu and display<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy Display auto<br />
<br />
</pre><br />
Save the <tt>navit.sh</tt> script in:<br />
/usr/bin/navit.sh<br />
Make the script executable:<br />
chmod u+x /usr/bin/navit.sh<br />
Now you have to edit the desktop icon, so that it starts this script <tt>navit.sh</tt> instead of the binary <tt>/usr/bin/navit</tt>.<br />
nano /usr/share/applications/navit.desktop<br />
Edit the line with <tt>Exec=...</tt>, so that it starts the script <br />
<pre><br />
[Desktop Entry]<br />
Version=1.0<br />
Name=Navit<br />
Name[de]=Navit<br />
Name[fr]=Navit<br />
Comment=The open source vector based navigation program with routing engine<br />
Comment[de]=Ein vektorbasiertes Navigationsprogramm<br />
Comment[fr]=Le logiciel opensource de navigation vectorielle<br />
Exec=/usr/bin/navit.sh<br />
Icon=navit<br />
StartupNotify=true<br />
Terminal=false<br />
Type=Application<br />
Categories=GTK;Utility;Geography;<br />
GenericName=Navit<br />
GenericName[de]=Navit<br />
<br />
</pre><br />
<br />
'''Alternatively''', you can make speech-dispatcher restart on resume, see http://trac.shr-project.org/trac/ticket/494<br />
<br />
=== Script to download OSM maps ===<br />
[[User:Wurp|Wurp]] wrote a little python script to download all OSM maps within a lat/long rectangle. Just copy the script to a file called dlOSM.sh, chmod +x it, and run it like<br />
dlOSM.sh <minimum latitude> <maximum latitude> <minimum longitude> <maximum longitude><br />
<br />
It takes a long time for large maps. I could optimize it some by having it try to get a big section at once, then if it fails, break it into smaller pieces and recurse. I'm not sure when/if I'll get around to that...<br />
<br />
dlOSM.sh:<br />
<pre><br />
#!/usr/bin/python<br />
<br />
import os<br />
import sys<br />
#import math<br />
<br />
def doIt(cmd):<br />
os.system(cmd)<br />
<br />
def getOsms(basename, minLat, maxLat, minLon, maxLon):<br />
'''basename - base name of map, maps are named {basename}{count}.osm<br />
minLat - latitude of the west side of the map<br />
maxLat - latitude of the east side of the map<br />
minLon - longitude of the north side of the map<br />
maxLon - longitude of the south side of the map'''<br />
<br />
wgetCmdTemplate = 'wget -O %s%s.osm http://api.openstreetmap.org/api/0.6/map?bbox=%s,%s,%s,%s'<br />
<br />
currLat = minLat<br />
mapCount = 0<br />
while currLat < maxLat:<br />
nextLat = min(currLat + 0.1, maxLat)<br />
<br />
currLon = minLon<br />
while currLon < maxLon:<br />
nextLon = min(currLon + 0.1, maxLon)<br />
<br />
doIt(wgetCmdTemplate % (basename, mapCount, currLon, currLat, nextLon, nextLat))<br />
<br />
currLon = nextLon<br />
mapCount = mapCount + 1<br />
<br />
currLat = nextLat<br />
<br />
(minLat, maxLat, minLon, maxLon) = map(float, sys.argv[1:])<br />
getOsms('map', minLat, maxLat, minLon, maxLon)<br />
</pre><br />
<br />
<onlyinclude><br />
{{ApplicationBox|<br />
Name=[[Navit]]|<br />
Description=Navit is a car navigation system with routing engine.|<br />
Screenshot=Screenshot-3.png|<br />
Homepage=http://navit.sourceforge.net|<br />
TestedOn=|<br />
PackageName=<br />
}}<br />
</onlyinclude><br />
<br />
[[Category:GPS Applications]]</div>Lokomokohttp://openmoko.org/wiki/NavitNavit2009-10-20T14:27:01Z<p>Lokomoko: /* Preselect Country of Destination */</p>
<hr />
<div>{{Application|Navit}}<br />
<br />
As described on the [http://navit.sourceforge.net/ Navit home page],<br />
<br />
<i>"'''Navit''' is a car navigation system with routing engine.<br />
<br />
Its modular design is capable of using vector maps of various formats for routing and rendering of the displayed map. It's even possible to use multiple maps at a time.<br />
<br />
The GTK+ or SDL user interfaces are designed to work well with touch screen displays. Points of Interest of various formats are displayed on the map.<br />
<br />
The current vehicle position is either read from gpsd or directly from NMEA GPS sensors."</i><br />
<br />
Some people say Navit is also a good choice for pedestrian and bicycle navigation.<br />
<br />
[[Image:Navit-2241.png|thumb|Navit-r2241]]<br />
<br />
== Acknowledgment ==<br />
<br />
Thanks to [[User:Alessandro | Alessandro]], stefan_schmidt, cp15 and all Navit developers I have done a small ("not really working") preview of Navit on Neo1973 at [http://www.telemobilityforum.com/eng/ Telemobility Forum 2007]. Thanks to [http://gfoss.it GFoss] guys to invite me.<br />
''[[User:Tyrael | Tyrael]]''<br />
<br />
==Setting up Navit==<br />
<br />
===Install Navit===<br />
==== FSO (OM2008.x,SHR,...) ====<br />
<br />
You can now simply add a feed from there : http://download.navit-project.org/navit/openmoko/svn/<br />
<br />
Essentially, to enable this directory as [[Om_2008.8_Installer#How to add a Repository ?|feed]] and install or update navit do:<br />
* Only for the first time:<br />
echo src navit http://download.navit-project.org/navit/openmoko/svn > /etc/opkg/navit-feed.conf<br />
opkg update<br />
<br />
* Always:<br />
opkg install navit<br />
<br />
Navit will be auto-updated when you run opkg upgrade later<br />
<br />
Navit might not be able to use gpsd at startup:<br />
navit:plugin_load:can't load '/usr/lib/navit/vehicle/<br />
libvehicle_gpsd.so', Error 'libgps.so.16: cannot open shared object <br />
file: No such file or directory'<br />
navit:vehicle_new:invalid type 'gpsd'<br />
<br />
to solve this issue (necessary for SHR):<br />
<br />
opkg install libgps17<br />
ln -s /usr/lib/libgps.so.17 /usr/lib/libgps.so.16<br />
<br />
====Debian====<br />
Navit is now in Debian [http://packages.debian.org/source/testing/navit testing] and [http://packages.debian.org/source/unstable/navit unstable].<br />
<br />
Add the following line to <tt>/etc/apt/sources.list</tt> with e.g. editor <tt>vi</tt> or <tt>nano</tt>:<br />
<br />
deb http://ftp.de.debian.org/debian unstable main<br />
<br />
Then update with apt-get:<br />
<br />
apt-get update<br />
<br />
The up-to-date source package is available through git at '''git://git.debian.org/git/collab-maint/navit.git''' ([http://git.debian.org/?p=collab-maint/navit.git;a=summary browse]).<br />
<br />
===Set up the maps you want===<br />
<br />
====The Easy Way====<br />
Use [http://maps.navit-project.org/download/ Navit pre-processed OSM maps]. Navigate to the region you want, and click select to select it, select the region you want, then click download. [[Image:osmdownload.jpg|200px|thumb|Download OpenStreetMaps]] <br />
<br />
If you just want the entire planet (as of this writing, ~1.8 GB), it's [http://maps.navit-project.org/planet.bin here].<br />
<br />
[http://downloads.cloudmade.com/ CloudMade] also has up-to-date maps from OpenStreetMap by country (by state in the US).<br />
<br />
====From the command line====<br />
'''OpenStreetMap''' - follow directions at http://wiki.navit-project.org/index.php/OpenStreetMaps<br />
* There are some pre-processed, up-to-date maps that can be grabbed with wget:<br />
<br />
<pre>wget -O germany.bin http://maps.navit-project.org/api/map/?bbox=5.185546875,46.845703125,15.46875,55.634765625</pre><br />
<br />
You can put a shell script into <tt>/usr/local/bin/update-maps</tt><br />
#!/bin/sh<br />
echo "Update OpenstreetMaps"<br />
echo "---------------------"<br />
echo " download and store OSM maps on /media/card/maps"<br />
wget -O /media/card/maps/germany.bin http://maps.navit-project.org/api/map/?bbox=5.185546875,46.845703125,15.46875,55.634765625<br />
echo "update germany.bin finished"<br />
You have to make the script executable with:<br />
chmod u+x /usr/local/bin/update-maps<br />
Then you can update with this script all your maps on the SD-card if you have internet connection:<br />
update-maps<br />
<br />
* Here's an example to get the maps for the area around Seattle, WA:<br />
** Find the map coordinates using http://informationfreeway.org/?lat=47.520270037501454&lon=-122.20130713167327&zoom=9&layers=B000F000<br />
** Download 4 regions from OpenStreetMaps ([[Navit#Script_to_download_OSM_maps|see below]] for a script to do this for you automatically for largish areas):<br />
<br />
<pre>wget -O map1.osm http://www.openstreetmap.org/api/0.5/map?bbox=-122.2,47.5,-122,47.7<br />
wget -O map2.osm http://www.openstreetmap.org/api/0.5/map?bbox=-122.4,47.5,-122.2,47.7<br />
wget -O map3.osm http://www.openstreetmap.org/api/0.5/map?bbox=-122.4,47.3,-122.2,47.5<br />
wget -O map4.osm http://www.openstreetmap.org/api/0.5/map?bbox=-122.2,47.3,-122,47.5</pre><br />
<br />
* A binary Navit map file needs to be created. The following uses osm2navit, and it's recommended that this command be used on something more powerful than the Neo:<br />
<br />
<pre>cat *.osm | osm2navit --dedupe-ways mymap.bin</pre><br />
<br />
===Copy the map to the NEO===<br />
To copy the map using scp (replace ''/directory'' as is appropriate in the following):<br />
<pre>scp mymap.bin root@neo:/directory</pre><br />
If you copy the map <tt>germany.bin</tt> to the SD card on the Neo use e.g.<br />
<pre>scp germany.bin root@neo:/media/card</pre><br />
<br />
Once it's somewhere on the NEO, Navit needs to know that it's there.<br />
<pre>mkdir ~/.navit<br />
cp /usr/share/navit/navit.xml ~/.navit/navit.xml<br />
vi ~/.navit/navit.xml</pre><br />
<br />
===Enable Maps in Navit ===<br />
Now you must let Navit know the maps you want to use. Several disabled mapset-tags are predefined. <br />
In the navit.xml file, put the following into a new <mapset> section (and disable the default <mapset> just above - or else it will not work):<br />
<pre><map type="binfile" enabled="yes" data="/directory" /></pre><br />
For example with a <tt>germany.bin</tt> on the SD-card you use:<br />
<mapset enabled="yes"><br />
<map type="binfile" enabled="yes" data="/media/card/germany.bin" /><br />
</mapset><br />
or if you store all downloaded maps in the directory <tt>/media/card/maps</tt> then add the following lines to <tt>navit.xml</tt>.<br />
<mapset enabled="yes"><br />
<map type="binfile" enabled="yes" data="/media/card/maps/*.bin"/><br />
</mapset><br />
Note that the bin-file and the map set both have to be enabled.<br />
<br />
Disable unused mapset sections by setting enabled to <tt>no</tt>, e.g. the pre-installed sample maps at line 370 in <tt>navit.xml</tt>.<br />
<mapset enabled="no"><br />
<xi:include href="$NAVIT_SHAREDIR/maps/*.xml"/><br />
</mapset><br />
<br />
<br />
* Run navit<br />
** Start [[gllin]] (for GTA01)<br />
** Start [[gpsd]] ( gpsd /tmp/nmeaNP )<br />
** Start navit<br />
<br />
* The version of osm2navit with which you build the maps should match the version of navit you have. If in doubt, build the maps on the Openmoko.<br />
<br />
===Tips and Tricks===<br />
====Center on Vehicle====<br />
Navit supports a "always center on vehicle" option. <br />
<br />
To activate this add<br />
follow="3"<br />
to the <tt>vehicle</tt> tag in navit.xml. <br />
<vehicle name="Local GPS" profilename="car" enabled="yes" active="1" follow="3" <br />
source="gpsd://localhost" gpsd_query="w+xj" color="#0000ff"><br />
The "3" causes to give the gui time to do something between the repaints (drag the map or browse the menu). When its set to "1" navit does nothing more than repainting the map continuously.<br />
<br />
==Routing==<br />
[[Image:navit_main_menu.png|100px|thumb|Navit Main Menu]]<br />
[[Image:navit_action_menu.png|100px|thumb|Navit Action Menu]]<br />
The main menu has 4 submenus<br />
* Action<br />
* Settings<br />
* Tools<br />
* Route<br />
Normally you would assume the entering a town can be found under the submenu Route, but Town is hidden under submenu Action. Route will provide the description of the route as text and a height profile of your trip. Tools was not working on 08/2009 Version of navit on SHR (see [[SHR User Manual]]).<br />
<br />
===Preselect Country of Destination===<br />
Normally you have to select the the country first before choosing the town and street name. It might be more convenient for you if you preselect the country already with your settings.<br />
The article [[Configure SHR for German-speaking use]] had a preselection of the country "Austria" in Navit. Adapt the localization for your country and maps in Navit, so that do not need to select the country anymore.<br />
<br />
Actually Navit derives the preselected country from the calling environments's locale. See [[Localization]] for how to do that. You need to make sure, that LC_ALL ist '''not''' set. Otherwise navit fails to interprete gpsd output and you end up with strange gps coordinates. When starting from gui (e.g. illume) you can achieve this by supplying an executable script /usr/local/bin/navit which might look like this:<br />
<pre><br />
#!/bin/bash<br />
unset LC_ALL<br />
/usr/bin/navit<br />
</pre><br />
So a valid locale environment preselecting search for German cities would look like this:<br />
<pre><br />
root@om-gta02 ~ $ locale<br />
LANG=de_DE.UTF-8<br />
LC_CTYPE="de_DE.UTF-8"<br />
LC_NUMERIC="de_DE.UTF-8"<br />
...<br />
LC_MEASUREMENT="de_DE.UTF-8"<br />
LC_IDENTIFICATION="de_DE.UTF-8"<br />
LC_ALL=<br />
</pre><br />
<br />
===Select Destination===<br />
[[Image:navit_select_country.png|100px|thumb|Select Country]]<br />
<br />
When you click in the main menu on <i>Action</i> the <i>Action</i> menu appears with 4 subitems.<br />
* Bookmarks of previous locations (stored in <tt>/home/root/.navit/destinations.txt</tt><br />
* a globe showing a location as destination,<br />
* a vehicle that shows the current GPS position of the vehicle. If the freerunner receives no GPS signal the locations of the vehicle is set to 0.0.0N and 0.0.0E. <br />
* Town is the action to enter a destination.<br />
* Quit navit is the last action in this submenu.<br />
<br />
Select the icon <i>Town</i>.<br />
<br />
<br />
====Select Country====<br />
[[Image:navit_country_selected.png|100px|thumb|Country Options]]<br />
[[Image:navit_destination_details.png|100px|thumb|Enter Bookmark Details]]<br />
<br />
Before you can search for City you have to select a Country. To do that, click on the icon in the left upper corner of the search field (could look like a white square with blue top-left quadrant).<br />
<br />
Just type in the first letter of the country (e.g. "G") and Navit makes suggestions (e.g. Gabon, Germany).<br />
<br />
====Enter Town====<br />
<br />
When you have selected the country (e.g. Germany) the flag appears and you can select the town.<br />
Then you can save the town as bookmark and enter more details like streets to the selected town.<br />
<br />
The search is still a little buggy.<br />
<br />
====Enter Street====<br />
You can enter the street and streetnumber and save it as bookmark when you use the destination often. <br />
<br />
====Bookmarks====<br />
Navigation and planning of routes with Navit can be organized with bookmarks.<br />
* set a bookmark as current position <br />
* set a bookmark as destination<br />
Then you can see the suggested route in blue on the map. <br />
<br />
Bookmarks are stored in:<br />
/home/root/.navit/bookmark.txt<br />
<br />
The GPS-location (if GPS-signal is available) will be highlighted with a small blue circle. The color of the circle can be defined via editing the <tt>navit.xml</tt> (see [http://wiki.openmoko.org/wiki/Navit#Set_Cursor_Color select cursor color]).<br />
* a dot in the blue circle is indicating that your are not moving,<br />
* an arrowhead is indicating the direction, when you are moving.<br />
Then routing can start and in the map the route is highlighted.<br />
<br />
====Screenshots in Navit Documentation====<br />
The screenshots are made with <tt>gpe-scap</tt>, that can be installed by:<br />
opkg install gpe-scap<br />
if not installed already. Navigation through your installed application navit and login via ssh on your Freerunner <br />
ssh -l root 192.168.0.202<br />
assuming that your Freerunner has the IP 192.168.0.202.<br />
Any time you want to make a screenshot just start via your desktop computer <br />
gpe-scap<br />
and save the screenshot to you freerunner.<br />
Download the screenshot to your desktop computer with<br />
desktop# sftp://root@192.168.0.202<br />
<br />
== News ==<br />
A deeper look into configuring Navit can be found in the [http://wiki.navit-project.org/index.php/Configuring_Navit Navit-Wiki].<br />
<br />
=== Getting the display right ===<br />
<br />
If using SHR the keyboard in country/town/street search mode does not fit on the street, make sure your gui configuration is set to the following line:<br />
<br />
<gui type="internal" font_size="350"/><br />
<br />
The example line provided for freerunners hides some important icons. Namely, instead of typing your city name first, you will first have to click the button on the top left, to go into country search mode. Enter your country name, then the city name, in order to enable the search function. This requires your map data to be searchable.<br />
<br />
You can start in fullscreen mode with fullscreen="1"<br />
<br />
<gui type="internal" font_size="350" fullscreen="1"/><br />
<br />
If you want to enable "+" and "-" as Zoom-In and Zoom-Out buttons on the bottom of the map enable the button with the following xml-tags:<br />
<osd enabled="yes" type="button" x="-96" y="-96" command="zoom_in()" src="zoom_in.xpm"/><br />
<osd enabled="yes" type="button" x="0" y="-96" command="zoom_out()" src="zoom_out.xpm"/><br />
<br />
=== Set Cursor Color ===<br />
[[Image:red_cursor.png|90px|thumb|Red Cursor]]<br />
If you navigate, the route is marked in blue color on the map. The current position of the vehicle is displayed by a blue circle. The circle is sometimes difficult to see on the blue track. If you want to change the color, size of the vehicle cursor edit the vehicle XML-environment in navit.xml (e.g. replace blue color #0000FF with red color #FF0000 -- for details of [http://html-color-codes.info Color Codes] select color, copy and paste code in <tt>navit.xml</tt>) <br />
<br />
<vehicle name="Local GPS" profilename="car" enabled="yes" active="1" source="gpsd://localhost" gpsd_query="w+xj" color="#0000ff"><br />
<!-- Navit can write a tracklog in several formats (gpx, nmea or textfile): --><br />
<!-- <log type="gpx" data="track_%Y%m%d-%i.gpx" flush_size="1000" flush_time="30"/> --><br />
<cursor w="56" h="56"><br />
<!-- tag defines the circle for the cursor --><br />
<itemgra><br />
<circle color="#ff0000" radius="42" width="6"><br />
<coord x="0" y="0"/><br />
</circle><br />
<circle color="#ffffff" radius="48" width="2"><br />
<coord x="0" y="0"/><br />
</circle><br />
</itemgra><br />
<!-- tag defines the dot when the vehicle is not moving --><br />
<itemgra speed_range="-2"><br />
<polyline color="#ff0000" width="6"><br />
<coord x="1" y="1"/><br />
<coord x="1" y="-1"/><br />
<coord x="-1" y="-1"/><br />
<coord x="-1" y="-1"/><br />
</polyline><br />
<circle color="#ffffff" radius="9" width="2"><br />
<coord x="0" y="0"/><br />
</circle><br />
</itemgra><br />
<!-- This itemgra-tag defines the arrow when the vehicle moves --><br />
<itemgra speed_range="3-"><br />
<polyline color="#ff0000" width="6"><br />
<coord x="-7" y="-10"/><br />
<coord x="0" y="12"/><br />
<coord x="7" y="-10"/><br />
</polyline><br />
<polyline color="#ffffff" width="2"><br />
<coord x="+10" y="-10"/><br />
<coord x="3" y="15"/><br />
</polyline><br />
<polyline color="#ffffff" width="2"><br />
<coord x="-10" y="-10"/><br />
<coord x="-3" y="15"/><br />
</polyline><br />
</itemgra><br />
</cursor><br />
</vehicle><br />
The following screenshot show Navit with a red cursor on a blue track:<br />
<br />
[[Image:navit_color_cursor.png|200px|thumb|Red Cursor Color on blue track - vehicle not moving]]<br />
<br />
=== Speech ===<br />
Navit can speak if you install [http://espeak.sourceforge.net/ eSpeak] + [http://www.freebsoft.org/speechd speech-dispatcher] and updates your navit.xml file.<br />
For adventurous people, one way to do this (for SHR and <tt>navit</tt> speaking german see [[Configure SHR for German-speaking use]]):<br />
<br />
* mokoTTS aims to integrate these packages in OM:<br />
http://projects.openmoko.org/projects/mokotts/<br />
<br />
install espeak, dotconf, and then speech-dispatcher.<br />
note: running 2008.8 updating from zecke's "testing" repo does not require "dotconf"<br />
<br />
* change the speech tag in navit.xml:<br />
<speech type="cmdline" data="spd-say '%s'" /><br />
<br />
or "spd-say -l fr '%s'" for using the French voice for example.<br />
<br />
The speech-dispatcher is blocking the audio after suspend. So after a suspend you will hear no ringtone, when a phone call is coming in and you cannot listen do audio files.<br />
A solution is to disable starting of speech-dispatcher with:<br />
update-rc.d -f speech-dispatcher remove<br />
Then the speech-dispatcher should be started if and only if navit is running and shut down when navit is closed.<br />
<br />
Furthermore navit should be started indirect with a script <tt>navit.sh</tt> instead of a direct start with the binary located in <tt>/usr/bin/navit</tt>. The script <tt>navit.sh</tt> listed below starts speech-dispatcher before navit, and stops it afterwards. See http://lists.openmoko.org/nabble.html#nabble-td1088795<br />
<br />
The following script is doing the suggested procedure. This script includes a language fix for Austria (see [[Configure SHR for German-speaking use]]).<br />
export LANG=de_AT.utf8<br />
Replace '''<tt>de_AT</tt>''' in this line with the appropriate language variable in the following script <tt>navit.sh</tt>.<br />
<pre><br />
#! /bin/sh<br />
#<br />
# Copyright Matthias Hentges <devel@hentges.net> (c) 2008<br />
# License: GPL (see http://www.gnu.org/licenses/gpl.txt for a copy of the license)<br />
#<br />
# Filename: navit.sh<br />
# Date: 20080105 (YMD)<br />
#<br />
#################################################################################<br />
#<br />
# 20080105 - v0.0.1 - Initial release<br />
# 20090818 - - Zoff <zoff@zoff.cc> addons and fixes<br />
#<br />
#<br />
#################################################################################<br />
<br />
<br />
#################################################################################<br />
#<br />
# On devices with low memory (< 512Mb?) Navit will segfault on start.<br />
# This can be worked around by doing<br />
# "echo 1 > /proc/sys/vm/overcommit_memory"<br />
#<br />
#################################################################################<br />
<br />
<br />
. /etc/profile<br />
<br />
set|grep LC<br />
<br />
#### Stop the speech dispatcher ####<br />
/etc/init.d/speech-dispatcher stop<br />
<br />
#### Language Fix #################<br />
set|grep LC<br />
<br />
<br />
export LC_ALL=''<br />
unset LC_ALL<br />
export LANG=de_AT.utf8<br />
<br />
set|grep LC<br />
<br />
#### Start the speech dispatcher ####<br />
/etc/init.d/speech-dispatcher start &<br />
<br />
<br />
set|grep LC<br />
<br />
<br />
# need cpu and display<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy Display enabled<br />
<br />
<br />
if test "`cat /proc/meminfo | grep ^MemTotal | awk '{print $2}'`" -lt "500000"<br />
then<br />
if test "$USER" = "root"<br />
then<br />
echo "Enabling low-mem workaround..."<br />
echo 1 > /proc/sys/vm/overcommit_memory<br />
else<br />
echo "I need root-privs to enable the low-mem workaround!"<br />
fi<br />
fi<br />
<br />
######### Start NAVIT NOW ############<br />
<br />
navit $*<br />
<br />
#### Stop the speech dispatcher ####<br />
<br />
/etc/init.d/speech-dispatcher stop<br />
<br />
# release cpu and display<br />
mdbus -s org.freesmartphone.ousaged /org/freesmartphone/Usage org.freesmartphone.Usage.SetResourcePolicy Display auto<br />
<br />
</pre><br />
Save the <tt>navit.sh</tt> script in:<br />
/usr/bin/navit.sh<br />
Make the script executable:<br />
chmod u+x /usr/bin/navit.sh<br />
Now you have to edit the desktop icon, so that it starts this script <tt>navit.sh</tt> instead of the binary <tt>/usr/bin/navit</tt>.<br />
nano /usr/share/applications/navit.desktop<br />
Edit the line with <tt>Exec=...</tt>, so that it starts the script <br />
<pre><br />
[Desktop Entry]<br />
Version=1.0<br />
Name=Navit<br />
Name[de]=Navit<br />
Name[fr]=Navit<br />
Comment=The open source vector based navigation program with routing engine<br />
Comment[de]=Ein vektorbasiertes Navigationsprogramm<br />
Comment[fr]=Le logiciel opensource de navigation vectorielle<br />
Exec=/usr/bin/navit.sh<br />
Icon=navit<br />
StartupNotify=true<br />
Terminal=false<br />
Type=Application<br />
Categories=GTK;Utility;Geography;<br />
GenericName=Navit<br />
GenericName[de]=Navit<br />
<br />
</pre><br />
<br />
'''Alternatively''', you can make speech-dispatcher restart on resume, see http://trac.shr-project.org/trac/ticket/494<br />
<br />
=== Script to download OSM maps ===<br />
[[User:Wurp|Wurp]] wrote a little python script to download all OSM maps within a lat/long rectangle. Just copy the script to a file called dlOSM.sh, chmod +x it, and run it like<br />
dlOSM.sh <minimum latitude> <maximum latitude> <minimum longitude> <maximum longitude><br />
<br />
It takes a long time for large maps. I could optimize it some by having it try to get a big section at once, then if it fails, break it into smaller pieces and recurse. I'm not sure when/if I'll get around to that...<br />
<br />
dlOSM.sh:<br />
<pre><br />
#!/usr/bin/python<br />
<br />
import os<br />
import sys<br />
#import math<br />
<br />
def doIt(cmd):<br />
os.system(cmd)<br />
<br />
def getOsms(basename, minLat, maxLat, minLon, maxLon):<br />
'''basename - base name of map, maps are named {basename}{count}.osm<br />
minLat - latitude of the west side of the map<br />
maxLat - latitude of the east side of the map<br />
minLon - longitude of the north side of the map<br />
maxLon - longitude of the south side of the map'''<br />
<br />
wgetCmdTemplate = 'wget -O %s%s.osm http://api.openstreetmap.org/api/0.6/map?bbox=%s,%s,%s,%s'<br />
<br />
currLat = minLat<br />
mapCount = 0<br />
while currLat < maxLat:<br />
nextLat = min(currLat + 0.1, maxLat)<br />
<br />
currLon = minLon<br />
while currLon < maxLon:<br />
nextLon = min(currLon + 0.1, maxLon)<br />
<br />
doIt(wgetCmdTemplate % (basename, mapCount, currLon, currLat, nextLon, nextLat))<br />
<br />
currLon = nextLon<br />
mapCount = mapCount + 1<br />
<br />
currLat = nextLat<br />
<br />
(minLat, maxLat, minLon, maxLon) = map(float, sys.argv[1:])<br />
getOsms('map', minLat, maxLat, minLon, maxLon)<br />
</pre><br />
<br />
<onlyinclude><br />
{{ApplicationBox|<br />
Name=[[Navit]]|<br />
Description=Navit is a car navigation system with routing engine.|<br />
Screenshot=Screenshot-3.png|<br />
Homepage=http://navit.sourceforge.net|<br />
TestedOn=|<br />
PackageName=<br />
}}<br />
</onlyinclude><br />
<br />
[[Category:GPS Applications]]</div>Lokomokohttp://openmoko.org/wiki/LocalizationLocalization2009-10-20T13:54:58Z<p>Lokomoko: /* Localize SHR */</p>
<hr />
<div>This page is for openmoko localization.<br />
<br />
= Adding UTF-8 input support to e =<br />
'''NOTICE''': thanks to great work by Ainulindale, it's already there in shr-unstable, so none of the following steps are needed. Read [[Localization#Localize_SHR|Localize SHR]] for a quick introduction.<br />
<br />
E input doesn't work without proper locale, therefore you must install and use a utf8 locale.<br />
I made a package that creates en_US.utf8 locale and sets it on boot time.<br />
if you have any bug fixes/suggestions please let me know. (TAsn)<br />
<br />
Package: [http://www.stosb.com/openmoko/shr-utf8_0.1_armv4t.ipk Locale]<br />
<br />
What it generally does:<br />
# installs all dependencies<br />
# installs locale-gen script (took from arch linux and removed a deprecated section)<br />
# generates locales<br />
# adds the locale to the system by adding a script to profile.d/locale.sh<br />
<br />
<br />
Known issues:<br />
The correct keyboard layout should be loaded before use.<br />
Either by a hack like in: [http://lucky.awardspace.co.uk/openmoko xmodmap]<br />
or by proper layout loading.<br />
<br />
According to raster (and verified by me), the e version used by openmoko is old and this was resolved in later versions. Should update the distro's build version.<br />
<br />
= Localize SHR =<br />
On SHR you install the desired locales, rename the folder $HOME/.e and restart X to choose you're locale when asked for it. You can change the locale any time via illume wrench language settings.<br />
<pre><br />
opkg install locale-base-XX-YY # (e.g. locale-base-de-de, locale-base-es-es, ...) <br />
mv ~/.e ~/.e.bak # move e's config cache<br />
/etc/init.d/xserver-nodm restart # restart X and choose your locale<br />
</pre><br />
For more information see the [[SHR_User_Manual#Localization|SHR User Manual]].<br />
<br />
[[Category:Middleware]]</div>Lokomokohttp://openmoko.org/wiki/LocalizationLocalization2009-10-20T13:54:16Z<p>Lokomoko: /* Localize SHR */</p>
<hr />
<div>This page is for openmoko localization.<br />
<br />
= Adding UTF-8 input support to e =<br />
'''NOTICE''': thanks to great work by Ainulindale, it's already there in shr-unstable, so none of the following steps are needed. Read [[Localization#Localize_SHR|Localize SHR]] for a quick introduction.<br />
<br />
E input doesn't work without proper locale, therefore you must install and use a utf8 locale.<br />
I made a package that creates en_US.utf8 locale and sets it on boot time.<br />
if you have any bug fixes/suggestions please let me know. (TAsn)<br />
<br />
Package: [http://www.stosb.com/openmoko/shr-utf8_0.1_armv4t.ipk Locale]<br />
<br />
What it generally does:<br />
# installs all dependencies<br />
# installs locale-gen script (took from arch linux and removed a deprecated section)<br />
# generates locales<br />
# adds the locale to the system by adding a script to profile.d/locale.sh<br />
<br />
<br />
Known issues:<br />
The correct keyboard layout should be loaded before use.<br />
Either by a hack like in: [http://lucky.awardspace.co.uk/openmoko xmodmap]<br />
or by proper layout loading.<br />
<br />
According to raster (and verified by me), the e version used by openmoko is old and this was resolved in later versions. Should update the distro's build version.<br />
<br />
= Localize SHR =<br />
On SHR you install the desired locales, rename the folder $HOME/.e and restart X to choose you're locale when asked for it. You can change the locale any time via illume wrench language settings.<br />
<pre><br />
opkg install locale-base-XX-YY # (e.g. locale-base-de-de, locale-base-es-es, ...) <br />
mv ~/.e ~/.e.bak # move e's config cache<br />
/etc/init.d/xserver-nodm restart # restart X and choose your locale<br />
</pre><br />
For more information see the [[SHR_User_Manual#Localization|SHR User Manual]]<br />
<br />
[[Category:Middleware]]</div>Lokomokohttp://openmoko.org/wiki/LocalizationLocalization2009-10-20T13:46:24Z<p>Lokomoko: /* Adding UTF-8 input support to e */</p>
<hr />
<div>This page is for openmoko localization.<br />
<br />
= Adding UTF-8 input support to e =<br />
'''NOTICE''': thanks to great work by Ainulindale, it's already there in shr-unstable, so none of the following steps are needed. Read [[Localization#Localize_SHR|Localize SHR]] for a quick introduction.<br />
<br />
E input doesn't work without proper locale, therefore you must install and use a utf8 locale.<br />
I made a package that creates en_US.utf8 locale and sets it on boot time.<br />
if you have any bug fixes/suggestions please let me know. (TAsn)<br />
<br />
Package: [http://www.stosb.com/openmoko/shr-utf8_0.1_armv4t.ipk Locale]<br />
<br />
What it generally does:<br />
# installs all dependencies<br />
# installs locale-gen script (took from arch linux and removed a deprecated section)<br />
# generates locales<br />
# adds the locale to the system by adding a script to profile.d/locale.sh<br />
<br />
<br />
Known issues:<br />
The correct keyboard layout should be loaded before use.<br />
Either by a hack like in: [http://lucky.awardspace.co.uk/openmoko xmodmap]<br />
or by proper layout loading.<br />
<br />
According to raster (and verified by me), the e version used by openmoko is old and this was resolved in later versions. Should update the distro's build version.<br />
<br />
= Localize SHR =<br />
On SHR you install the desired locales, rename the folder $HOME/.e and restart X to choose you're locale when asked for it. You can change the locale any time via illume wrench language settings.<br />
<pre><br />
opkg install locale-base-XX-YY # (e.g. locale-base-de-de, locale-base-es-es, ...) <br />
mv ~/.e ~/.e.bak # move e's config cache<br />
/etc/init.d/xserver-nodm restart # restart X and choose your locale<br />
</pre><br />
<br />
[[Category:Middleware]]</div>Lokomokohttp://openmoko.org/wiki/Flashing_the_GSM_FirmwareFlashing the GSM Firmware2009-05-16T19:42:21Z<p>Lokomoko: Structural improvements</p>
<hr />
<div>{{Languages|GSM/Flashing}}<br />
((please also refer to [http://lists.openmoko.org/pipermail/devel/2008-November/003150.html this thread on devel-ML]))<br><br />
'''Please note the uSD-method mentioned end of this page is the recommended procedure, and it's also recommended to do update to *all* devices GTA02'''<br />
<br />
==Introduction==<br />
<br />
This is a step-by-step description of how the firmware is upgraded on a Neo with the "FLUID" tool running on the device (FLUID stands for "Flash Loader Utility Independent of Device"). Note that this process tolerates almost no variations. Stray from the instructions at your own peril. Instructions based on a posting by Werner (http://lists.openmoko.org/pipermail/openmoko-devel/2008-April/002605.html), thanks.<br />
<br />
Please note: Update to MOKO9-beta firmware isn't recommended by OM, and probably won't fix any recent issues like [http://docs.openmoko.org/trac/ticket/1024 #1024] at all. Use the latest firmware version instead.<br />
<br />
Please see http://people.openmoko.org/joerg/calypso_moko_FW for more recent FW-images.<br />
<br />
Please see http://people.openmoko.org/joerg/calypso_moko_FW/all_version__CHANGELOG.txt for the firmware changelog (including versions for the different GTA02 revisions).<br />
<br />
For now there is some moko11, which should fix [http://docs.openmoko.org/trac/ticket/666 #666] (compatibility with some 3G sim cards), and also has a new command AT+CSIM. It also includes fixes related to hardware flow control and wakeup interrupt.<br />
<br />
This version is not supposed to fix [http://docs.openmoko.org/trac/ticket/1024 #1024] (constant re-registrations leading to lost calls and messages). For a workaround use a distro where deep sleep mode can be deactivated.<br />
<br />
We are planning to include this version in the factory image of the A7 run.<br />
<br />
We recommend you don't update by following this procedure, unless you feel very comfortable with commandline. Don't miss-spell any FLUID command!<br />
<br />
There is an SD-image (see bottom of this page), that greatly simplifies the whole GSM-update process - we suggest everybody who's not feeling completely comfortable with the procedure described herein use the image instead (not applicable to gta01 owners).<br />
<br />
'''Warning: there are chances to _irrecoverably_ damage your GSM modem calibration data, thus rendering it useless on messing around with FLUID! Use only the commands from this wiki page! Never downgrade to a version earlier than Moko6, or you will render the GSM unusable (certain internal data structures changed between Moko5 and Moko6).'''<br />
<br />
The GSM-firmware didn't differ from GTA01 to GTA02, as the GSM-hardware didn't either. This means you can flash MOKO11 (or any other recent GSM-FW) to GTA01 as well.<br />
According to mwester, this worked for him to update from MOKO1 on a GTA01Bv4 to MOKO10b2, by following the steps described herein (if the main firmware can't be started, see troubleshooting section for additional instructions).<br />
<br />
Any reports on successful update, as well as problems encountered, or SIMs seen to work after update, all highly appreciated. Please add to the "discussion" tab of this wikipage. Thanks!<br />
<br />
==Manual Update (GTA01, GTA02)==<br />
===Phase 1: Preparations===<br />
<br />
* Download and install a distribution to your device that gives you SSH access. We recommend the fso-console image:<br />
<pre><br />
mickey@amethyst$ cd /tmp<br />
mickey@amethyst$ wget http://people.openmoko.org/mickey/images/openmoko-fso-console-image-glibc-ipk--20081028-om-gta02.rootfs.jffs2.summary<br />
mickey@amethyst$ dfu-util -a rootfs -R -D ./openmoko-fso-console-image-glibc-ipk--20081028-om-gta02.rootfs.jffs2.summary<br />
mickey@amethyst$ wget http://people.openmoko.org/mickey/images/uImage-2.6.24+r10+gitr75999+54524f4531c8b262431b794fea610d81bb351c86-r10-om-gta02.bin<br />
mickey@amethyst$ dfu-util -a kernel -R -D ./uImage-2.6.24+r10+gitr75999+54524f4531c8b262431b794fea610d81bb351c86-r10-om-gta02.bin<br />
</pre><br />
* Install http://people.openmoko.org/joerg/calypso_moko_FW/fluid_0.0+svn20070817-r2_armv4t_eabi.ipk on your device:<br />
<pre><br />
root@om-gta02:~# opkg install http://people.openmoko.org/joerg/calypso_moko_FW/fluid_0.0+svn20070817-r2_armv4t_eabi.ipk<br />
</pre><br />
* Install http://people.openmoko.org/joerg/calypso_moko_FW/s3c24xx-gpio_1.0+svnr4130-r2.1_armv4t.ipk on your device:<br />
<pre><br />
root@om-gta02:~# opkg install http://people.openmoko.org/joerg/calypso_moko_FW/s3c24xx-gpio_1.0+svnr4130-r2.1_armv4t.ipk<br />
</pre><br />
* Download <br />
http://people.openmoko.org/joerg/calypso_moko_FW/moko11/calypso-moko11.m0<br />
and place it into the /home/root directory:<br />
<pre><br />
root@om-gta02:~# cd $HOME<br />
root@om-gta02:~# wget http://people.openmoko.org/joerg/calypso_moko_FW/moko11/calypso-moko11.m0<br />
</pre><br />
<br />
===Phase 2: The Lobotomy===<br />
<br />
* Make sure '''nothing''' is accessing the GSM modem. If you're using the fso-console image from the link above, this will happen automagically on boot. On other systems, kill processes as you see fit (for FSO it's zhone, frameworkd and gsm0710muxd; for SHR it's ophonekitd, frameworkd and gsm0710muxd). If you're using a stable (or andy-tracking) kernel from Feb 26 or later on GTA02, see below for simplified instructions on powering the modem on/off (if you use the simplified method to turn it off, you must also use the simplified method to turn it on; no s3c24xx-gpio invocations are needed).<br />
<br />
* Power off the modem:<br />
<pre><br />
root@om-gta02:~# echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on<br />
root@om-gta02:~# echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on<br />
root@om-gta02:~# s3c24xx-gpio b7=0<br />
root@om-gta02:~# stty 0:4:18b2:8a00:0:0:7f:15:4:0:0:0:0:0:0:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 -F /dev/ttySAC0<br />
root@om-gta02:~# stty 0:4:18b2:8a00:0:0:7f:15:4:0:0:0:0:0:0:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 -F /dev/ttySAC0<br />
root@om-gta02:~# echo -en "AT@POFF\r" >/dev/ttySAC0; sleep 1; echo -en "AT@POFF\r" >/dev/ttySAC0<br />
</pre><br />
<br />
* Launch the FLUID binary:<br />
<pre><br />
root@om-gta02:~# cd /usr/sbin<br />
root@om-gta02:/usr/sbin# FLUID_PORT=/dev/ttySAC0 fluid.exe \<br />
-oo -od13,13 -b 115200 \<br />
-f $HOME/calypso-moko11.m0<br />
</pre><br />
It should say something like this (takes a few seconds to load the file):<br />
<pre><br />
FLUID Revision 2.27, ...<br />
Bootloader: (reset target)<br />
</pre><br />
(this fluid command works even if the previous flashing was aborted and you have a broken and non-functional gsm-firmware due to this, as it uses the calypso ROM bootloader instead of the firmware bootloader. But in the case of non-functional gsm-firmware there's no way to power off the modem with AT@POFF command, therefore GTA02 users need to follow "modern kernel" (they might work even with older kernels) instructions and GTA01 users the troubleshooting section. Changing the -b to some lower baudrate might improve stability of flashing-process - the bootloader does autobaud, so you're free to use any rate)<br />
<br />
* Start a second SSH session and start the modem:<br />
<pre><br />
root@om-gta02:~# s3c24xx-gpio b7=1<br />
</pre><br />
<br />
FLUID should now say something like this (it will take a couple of minutes to finish):<br />
<br />
<pre><br />
(fluid, version 3) ok<br />
Checksumming (269 * 8kB = 2152kB): ok<br />
Flash Detect: (0xEC, 0x22A0) Samsung K5A3240CT ok<br />
Program: (34 sectors, 267*8k=2136k) (*******************) ok<br />
</pre><br />
<br />
Congratulations, the update was successful!<br />
<br />
'''Note: If you get this instead: MESSAGE: File cmd.m0 not found, then you didn't do the ''cd /usr/sbin''. Please pay attention ;-)'''<br />
<br />
If FLUID does nothing, curse your bad luck and repeat the reset sequence, this is the whole 'echo 0/1, b7=0/1 stuff'.<br />
<br />
* To verify that everything went well, do this in either of the two sessions (this doesn't always work but you can be sure that if fluid didn't report any errors, everything went well; you can check AT+CGMR output later with mickeyterm):<br />
<pre><br />
root@om-gta02:~# stty crtscts -F /dev/ttySAC0<br />
root@om-gta02:~# cat /dev/ttySAC0 &<br />
root@om-gta02:~# echo -en 'AT\r' >/dev/ttySAC0; sleep 1; echo -en 'AT+CGMR\r' >/dev/ttySAC0<br />
+CGMR: "GSM: gsm_ac_gp_fd_pu_em_cph_ds_vc_cal35_ri_36_amd8_ts0-Moko11"<br />
...<br />
root@om-gta02:~# kill %1<br />
</pre><br />
<br />
====Hints====<br />
<br />
In some case you may receive this:<br />
<br />
<pre><br />
(fluid, version 3) ok<br />
Checksumming (269 * 8kB = 2152kB): ok<br />
Flash Detect: (0xEC, 0x22A0) Samsung K5A3240CT ok<br />
Program: (0 sectors, 0*8k=0k) () ok<br />
</pre><br />
<br />
It means the checksums of all sectors in calypso's FW and the new file to flash are identical. Probably you're trying to flash same version of FW that's already installed.<br />
<br />
With modern kernels on GTA02 you can use this single command to "Power off the modem":<br />
<pre><br />
echo 0 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on<br />
</pre><br />
<br />
Now you can start fluid as described above.<br />
<br />
To "start the modem" you need to issue:<br />
<pre><br />
echo 1 >/sys/bus/platform/devices/neo1973-pm-gsm.0/power_on<br />
</pre><br />
<br />
===Troubleshooting===<br />
<br />
Some users weren't able to complete the upgrade since they got an error while the firmware was uploading in the GSM chip (like ''Flash operation timeout'').<br />
<br />
However a solution [http://n2.nabble.com/problems-with-calypso-firmware-update-tp1565196p1566012.html has been found] and it allows to use again the GSM modem.<br />
(please note this topic resides on [http://lists.openmoko.org/pipermail/devel/2008-November/003150.html devel-ML]. Don't spread over multiple lists please, as it won't help in getting a response to your request just in time, and most people following the main thread likely will miss your postings anyway)<br />
<br />
Use the following fluid command:<br />
<br />
<pre><br />
cd /usr/sbin<br />
FLUID_PORT=/dev/ttySAC0 fluid.exe -oo -od13,13 -b 115200 -f $HOME/calypso-moko11.m0<br />
</pre><br />
(Without FLOWCONTROL and with -oo to choose the ROM bootloader)<br />
<br />
Then on a ''second ssh session'' please use this instead of the gpio command:<br />
<pre><br />
echo 0 > /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on<br />
echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on<br />
</pre><br />
The firmware download should start now.<br />
<br />
=== Half-flashed GTA01bv4 GSM Modem ===<br />
<br />
For GTA01 the process of flashing when the main firmware is absent is more complicated as we have no easy way to power-cycle the modem.<br />
<br />
I recently had to do a special process to recover my GTA01bv4 after breaking the gsm modem with a failed flash. The process is actually fairly simple.<br />
<br />
* Unplug USB and remove the battery for about 10s to ensure that the GSM chipset is powered off, then replace the battery and re-connect the USB<br />
* boot up from a distro that is neutered so that it does not access or turn on the gsm modem at all (this is a really important prerequisitive, as nothing should turn on the modem by touching MODEM_ON line until fluid is ready to connect to it); one can do that simply by disabling start of ophonekitd (and to be on the safe side framworkd too) on SHR<br />
* issue this stty command twice:<br />
stty 0:4:18b2:8a00:0:0:7f:15:4:0:0:0:0:0:0:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0 -F /dev/ttySAC0<br />
* cd /usr/sbin<br />
* issue this fluid command (replace $HOME/filename.m0 with path to firmware you want to flash):<br />
FLUID_PORT=/dev/ttySAC0 fluid.exe -oo -od13,13 -b115200 -f $HOME/filename.m0<br />
* in another ssh session, issue this command:<br />
echo 1 > /sys/bus/platform/devices/neo1973-pm-gsm.0/power_on<br />
<br />
After this, the flashing proceeded as expected. You don't need to do any special checks to ensure you have successfully flashed; if fluid reports everything is ok, it is actually ok.<br />
<br />
== uSD-card Image (GTA02 only)==<br />
'''We recommend to update all devices by using this uSD-image for flashing MOKO11 to GTA02 Freerunner only (not suitable for GTA01 Neo1973).'''<br><br />
This works by starting the FreeRunner from a system installed on the uSD, which will automatically apply all needed instructions to flash the GSM firmware to the chip. The uSD image will have to be written on a uSD, which will overwrite all its content, so as to make sure it is repartitioned correctly and that it contains the correct bootable system.<br />
The procedure has proven to do a reliable job on flashing MOKO11 to GTA02. Chances anything fails are minimal if you _strictly_ follow the instructions. There's no way to do any harm to your device by using this method.<br />
<br />
'''Take special care though about the destination of `dd`, it has to be the *physical* device (e.g. foo0) of your uSD-card, *not* any partition (e.g. foo0p1). Also make sure there are *no* mounted partitions left on the uSD when starting `dd`!'''<br><br />
''Triple-check you are not accidentally overwriting your system-HD, by e.g using /dev/sda instead of /dev/sdc! Double-check once more! This is the one-typo-kills-system case ;-) You've been warned.''<br />
<br />
* Download and ''untar'' http://people.openmoko.org/joerg/calypso_moko_FW/moko11/flash-moko11_uSD-image.tar.gz on your preferred computer.<br />
* read the "README.txt" file that came with the tarball.<br />
* (apply `sudo` or use root-terminal according to your taste to get root privileges needed to write to the uSD card;)<br />
* Insert a uSD to your computer's reader, and `umount` all uSD-partitions that might have been automounted (use `mount` or `df -h` to check). Do not use "safely remove" for this.<br />
<br />
* use `dd` to write the image "flash-moko11-2.image" to the '''physical(!)''' uSD-device (this will erase all data from your uSD, including previous partition table and partitions! ''It will as well erase all data from your computer's HD, in case you accidentally `dd` to this device instead of uSD''). `Sync` or `eject <device>` to make sure everything is flushed to the uSD before physically removing it from the reader.<br />
<br />
* Insert the uSD to your FreeRunner, and boot from '''NOR-U-Boot''' and select the "Boot from uSD" option,<br />
<br />
* See the boot and flashing process happen, and wait until a green "d_o_n_e" message shows on screen (takes some 6min). You may can now remove bat and uSD, or login via ssh and use `mickeyterm` to access the modem and check the firmware version is indeed moko11.<br />
<br />
===NOTE===<br />
If you don't have a uSD reader on your PC, you can `dd` from neo: install task-base-smbfs, u(n)mount /media/card, mount the directory in which you have the "flash-moko11-2.image" file and do the dd stuff. This will take about 12 minutes.<br />
<br />
===NOTE 2===<br />
If you have [[Qi]] installed ((no, *always*, see above!)) as your boot loader, power up to the NoR menu (Hold AUX Key, press Power button) and select Boot from SD (fat/ext2) to begin the installation process (per DocScrutinizer in #openmoko). '''Do not''' let Qi boot the uSD. Although it still seems to flash OK, the green "d_o_n_e" does not show up, to give you the warm feeling that everything is OK.<br />
<br />
You can confirm the firmware version number using the [[OpenmokoFramework/mickeyterm|mickeyterm]] (cmd: "AT+CGMR"). In SHR-Settings, Phone/Modem Information will supply the same number.<br />
<br />
[[Category:GSM]]<br />
[[Category:GSM]]</div>Lokomokohttp://openmoko.org/wiki/Openmoko_Local_Groups:_KarlsruheOpenmoko Local Groups: Karlsruhe2009-03-24T23:05:04Z<p>Lokomoko: /* Meetings, Events */</p>
<hr />
<div>It would be great to have a local user group also in Karlsruhe. According this list [[GroupSales#Karlsruhe]] many people of the beatyful city of Karlsruhe were interested in the Moko Project. We could meet informally at one of Karlsruhes many bars.<br />
<br />
Just add your name to the list and we will see if there is any interest in a Karlsruhe User Group.<br />
<br />
=== People ===<br />
{|border="1" cellspacing="0" cellpadding="5" <br />
!Name<br />
!Skills<br />
!Level of Interest<br />
!Location<br />
!Other<br />
!Has Device<br />
!Has Debug Board<br />
|-<br />
|[[User:Poseidon|Poseidon]]<br />
|C++/python and Linux<br />
|multimedia, outdoor usage, gps<br />
|Karlsruhe<br />
|<br />
|[[Image: Moko.jpg|center]]<br />
|<br />
|-<br />
|[[User:Digmig|Dan]]<br />
|C/C++/Python and Linux<br />
|PIM, Multimedia, gps<br />
|Karlsruhe<br />
|<br />
|Neo<br />
|no. But can solder 0402:-)<br />
|}<br />
<br />
<br />
=== Meetings, Events ===<br />
Meeting language is German ;-)<br />
{|border="1" cellspacing="0" cellpadding="5" align="left"<br />
!<br />
!Date<br />
!Location<br />
!Topic<br />
!Who<br />
|-<br />
|1<br />
|2009-02-12<br />
|[https://entropia.de/wiki/OpenMoko_User_Meet entropia e.V.]<br />
|[https://www.joachim-breitner.de/blog/archives/318-Openmoko-User-Meeting-in-Karlsruhe.html various, pyneo, mokopedia]<br />
|<br />
|-<br />
|2<br />
|[http://doodle.com/participation.html?pollId=25cmwambxt2pihaq 2009-03-18]<br />
|entropia e.V.<br />
|[https://entropia.de/wiki/OpenMoko_User_Meet#Treffen_am_18.3.2009 here]<br />
|<br />
|}<br />
<br />
<br />
<br />
<br />
<br />
[[Category:Openmoko Local Groups]]</div>Lokomokohttp://openmoko.org/wiki/Talk:Community_Updates/2009-02-20Talk:Community Updates/2009-02-202009-02-18T17:26:07Z<p>Lokomoko: /* Community */</p>
<hr />
<div>The 12th community updates will released on February 20, 2009.<br />
Before releasing , I will put the draft on TALK page. Feel free to update the new for community.<br />
<br />
<br />
<br />
==Distributions==<br />
[[Image:Fyp.png|200px|align|right]]<br />
* [[Fyp]] is a Debian for Freerunner based distribution which uses [http://lxde.org/ LXDE] and [[Zhone]] on top. It is a FreeYourPhone.de community project. Now the first beta image is released. You can download Fyp distribution [http://opensvn.csie.org/fyp/releases/ here], then uses [[NeoTool]] for installation. After you finished the installation and boot up, you can press AUX (short press) shows the keyboard, and use Power button to pops up the shutdown/suspend menu, then select the options.<br />
<br />
* [mailto:mickey@openmoko.org Mickey] announced [[Qi]] now it's "officially" supported by FSO.<br />
<br />
* FSO meets paroli-for a fully functional paroli, FSO team came up with fso milestone 5.5. fso ms 5.5 will contains everything needed by paroli.<br />
<br />
== Application ==<br />
<br />
=== New Applications ===<br />
*[[Momtools]]-(momtools = MyOpenMoko tools) the idea of this tool is creating an easy-to-use application, allowing the freerunner (gta-02) to connect to wifi and gprs, and add some useful applications such as a slim media-player and a little accelerometers-game. This project now is on progress. You can check this on it's wiki page.<br />
<br />
*[[Enscribi]]-a new handwriting recognition input method, now it only support writing Japanese and Chinese characters. You can download ipk files and install it on FSO. Then goto "setup" --> "keyboard" --> "enscribi", then you get a Chinese input method. For more inforamtion , you can check : http://olofsj.github.com/enscribi/ . <br />
<br />
* [http://www.opkg.org/package_136.html OpenMiaoCat], like [[OpenMooCow]], makes your phone became a cat! Simply stroke gently the lovely cat to make it purr!<br />
<br />
=== Application updates ===<br />
[[image:OpenMooCow.png|100px|align|left]]<br />
* [[Kustomizer]]-[http://risto.kurppa.fi/blog/kustomizer-02-for-200812/ version 0.2 released]. GSM works again. Many fixes done - now Kustomizer can give you two different configurations, see [[Kustomizer#What_does_it_do.3F|here]]. [[Kustomizer#Changelog|Changelog]] and [http://kurppa.fi/freerunner/kustomizer_files/kustomizer_0.2_log_20090206.txt test run log].<br />
<br />
* [[Linball]]-Updates 0.1 version to 0.2 version. Download new version here : http://linball.sf.net/linball-openmoko_0.2_armv4t.opk<br />
<br />
* [[Qwo]]-Version 0.4 was released on Feb, 7. The changes include :window can be resized dynamically, added Paste, Alt key, page up, down, home, end plus others ...etc. You can download the new version [http://download.savannah.nongnu.org/releases/qwo/qwo_0.4_armv4t.ipk here]<br />
<br />
* [[Yaouh!]]-[http://minucci.net/file/opkg/yaouh_0.4_all.opk Version 0.4] is out. This release includes bugfix and add support for multiple wget download , probably faster.<br />
<br />
* [[Paroli]]-There is packages in fso MS5 openmoko unstable. You can downloads paroli from : http://downloads.freesmartphone.org/fso- milestone5/feeds//armv4t/paroli_0.2.1+gitr7a2fdc16174258e9276e7c2d80f500b4dd624442- r0_armv4t.ipk<br />
<br />
* [[Guitartune]]- [http://www.opkg.org/package_115.html Version 0.30] released on 16 Feb. Changes include a new GUI, wider range (from A0 to C8) and threaded architecture.<br />
<br />
== Trick and Tips ==<br />
<br />
* MokoGeocaching Installing-After you install MokoGeocaching , if the app won't even start, you may need to install these dependencies manually (Om2008.12):<br />
::: + <br />
opkg install python-netclient python-mime python-netclient<br />
<br />
<br />
* How to search bugs real quick , instead of using trac.openmoko.org ? You can use the [http://lindi.iki.fi/lindi/cgi-bin/openmoko-bugs.py Unofficial search to bugs.openmoko.org]. You can type the keyword or bug number on text box , then press "search", the result will list below the text box.<br />
<br />
==Community ==<br />
* Openmoko autobuilder is back online. It is generating images for gta01 and gta02 devices. You can check images status on this site :http://tinderbox.openembedded.net/builders/openmoko/. Unstable images will auto generate in http://downloads.openmoko.org/repository/unstable/ . There are some packages that are failing consistently, Openmoko distribution maintainer is going to try and debug these and send some fixes upstream.<br />
* Openmoko started migrating content from the Om wiki to [http://en.flossmanuals.net/bin/view/NeoFreeRunner/WebHome FLOSS Manuals]. Basis for the manual will be derived from [[Getting_Started_with_your_Neo_FreeRunner|Getting Started With Your Neo FreeRunner]] and [[Openmoko_developer_guide|Openmoko Developer Guide]].<br />
* Wiki news! As per [http://lists.openmoko.org/pipermail/documentation/2009-February/001079.html documentation mailing list] justification, I reverted my previous revert of main page. People missing the old multitude of links should look at the improved left side navigation choices. I also combined "Openmoko:Community Portal" into "Development resources" and renamed the whole thing to "[[Community Resources]]". -[[User:TimoJyrinki|Timo]]<br />
* the second Italian National NeoMeeting @ Milano (13/03/09) [info @ http://wiki.telefoninux.org/doku.php?id=neomeeting]<br />
* A first OM meeting took place in Karlsruhe, a second one is being planned. See [[Openmoko_Local_Groups:_Karlsruhe#Meetings.2C_Events|Local Groups Section]] in this wiki.</div>Lokomokohttp://openmoko.org/wiki/Openmoko_Local_Groups:_KarlsruheOpenmoko Local Groups: Karlsruhe2009-02-18T16:59:52Z<p>Lokomoko: /* Meetings, Events */</p>
<hr />
<div>It would be great to have a local user group also in Karlsruhe. According this list [[GroupSales#Karlsruhe]] many people of the beatyful city of Karlsruhe were interested in the Moko Project. We could meet informally at one of Karlsruhes many bars.<br />
<br />
Just add your name to the list and we will see if there is any interest in a Karlsruhe User Group.<br />
<br />
=== People ===<br />
{|border="1" cellspacing="0" cellpadding="5" <br />
!Name<br />
!Skills<br />
!Level of Interest<br />
!Location<br />
!Other<br />
!Has Device<br />
!Has Debug Board<br />
|-<br />
|[[User:Poseidon|Poseidon]]<br />
|C++/python and Linux<br />
|multimedia, outdoor usage, gps<br />
|Karlsruhe<br />
|<br />
|[[Image: Moko.jpg|center]]<br />
|<br />
|-<br />
|[[User:Digmig|Dan]]<br />
|C/C++/Python and Linux<br />
|PIM, Multimedia, gps<br />
|Karlsruhe<br />
|<br />
|Neo<br />
|no. But can solder 0402:-)<br />
|}<br />
<br />
<br />
=== Meetings, Events ===<br />
Meeting language is German ;-)<br />
{|border="1" cellspacing="0" cellpadding="5" align="left"<br />
!<br />
!Date<br />
!Location<br />
!Topic<br />
!Who<br />
|-<br />
|1<br />
|2009-02-12<br />
|[https://entropia.de/wiki/OpenMoko_User_Meet entropia e.V.]<br />
|[https://www.joachim-breitner.de/blog/archives/318-Openmoko-User-Meeting-in-Karlsruhe.html various, pyneo, mokopedia]<br />
|<br />
|-<br />
|2<br />
|[http://doodle.com/participation.html?pollId=25cmwambxt2pihaq doodle]<br />
|entropia e.V. ?<br />
|<br />
|}<br />
<br />
[[Category:Openmoko Local Groups]]</div>Lokomokohttp://openmoko.org/wiki/Openmoko_Local_Groups:_KarlsruheOpenmoko Local Groups: Karlsruhe2009-02-15T22:55:46Z<p>Lokomoko: /* Meetings, Events */</p>
<hr />
<div>It would be great to have a local user group also in Karlsruhe. According this list [[GroupSales#Karlsruhe]] many people of the beatyful city of Karlsruhe were interested in the Moko Project. We could meet informally at one of Karlsruhes many bars.<br />
<br />
Just add your name to the list and we will see if there is any interest in a Karlsruhe User Group.<br />
<br />
=== People ===<br />
{|border="1" cellspacing="0" cellpadding="5" <br />
!Name<br />
!Skills<br />
!Level of Interest<br />
!Location<br />
!Other<br />
!Has Device<br />
!Has Debug Board<br />
|-<br />
|[[User:Poseidon|Poseidon]]<br />
|C++/python and Linux<br />
|multimedia, outdoor usage, gps<br />
|Karlsruhe<br />
|<br />
|[[Image: Moko.jpg|center]]<br />
|<br />
|-<br />
|[[User:Digmig|Dan]]<br />
|C/C++/Python and Linux<br />
|PIM, Multimedia, gps<br />
|Karlsruhe<br />
|<br />
|Neo<br />
|no. But can solder 0402:-)<br />
|}<br />
<br />
<br />
=== Meetings, Events ===<br />
Meeting language is German ;-)<br />
{|border="1" cellspacing="0" cellpadding="5" align="left"<br />
!Date<br />
!Location<br />
!Topic<br />
!Who<br />
|-<br />
|2009-02-12<br />
|[https://entropia.de/wiki/OpenMoko_User_Meet entropia e.V.]<br />
|[https://www.joachim-breitner.de/blog/archives/318-Openmoko-User-Meeting-in-Karlsruhe.html various, pyneo, mokopedia]<br />
|<br />
|-<br />
|[http://doodle.com/participation.html?pollId=25cmwambxt2pihaq doodle]<br />
|entropia e.V. ?<br />
|<br />
|}<br />
<br />
[[Category:Openmoko Local Groups]]</div>Lokomokohttp://openmoko.org/wiki/Openmoko_Local_Groups:_KarlsruheOpenmoko Local Groups: Karlsruhe2009-02-14T16:26:23Z<p>Lokomoko: </p>
<hr />
<div>It would be great to have a local user group also in Karlsruhe. According this list [[GroupSales#Karlsruhe]] many people of the beatyful city of Karlsruhe were interested in the Moko Project. We could meet informally at one of Karlsruhes many bars.<br />
<br />
Just add your name to the list and we will see if there is any interest in a Karlsruhe User Group.<br />
<br />
=== People ===<br />
{|border="1" cellspacing="0" cellpadding="5" <br />
!Name<br />
!Skills<br />
!Level of Interest<br />
!Location<br />
!Other<br />
!Has Device<br />
!Has Debug Board<br />
|-<br />
|[[User:Poseidon|Poseidon]]<br />
|C++/python and Linux<br />
|multimedia, outdoor usage, gps<br />
|Karlsruhe<br />
|<br />
|[[Image: Moko.jpg|center]]<br />
|<br />
|-<br />
|[[User:Digmig|Dan]]<br />
|C/C++/Python and Linux<br />
|PIM, Multimedia, gps<br />
|Karlsruhe<br />
|<br />
|Neo<br />
|no. But can solder 0402:-)<br />
|}<br />
<br />
<br />
=== Meetings, Events ===<br />
Meeting language is German ;-)<br />
{|border="1" cellspacing="0" cellpadding="5" align="left"<br />
!Date<br />
!Location<br />
!Topic<br />
!Who<br />
|-<br />
|2009-02-12<br />
|[https://entropia.de/wiki/OpenMoko_User_Meet entropia e.V.]<br />
|[https://www.joachim-breitner.de/blog/archives/318-Openmoko-User-Meeting-in-Karlsruhe.html various]<br />
|<br />
|}<br />
<br />
[[Category:Openmoko Local Groups]]</div>Lokomokohttp://openmoko.org/wiki/Booting_from_SD/deBooting from SD/de2009-01-12T16:49:55Z<p>Lokomoko: /* Hinweise zur Partitionierung */</p>
<hr />
<div>{{Languages}}<br />
Diese Seite beschreibt, wie man mit dem FreeRunner von einer [[Supported_microSD_cards|(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.<br />
<br />
{{Note| Das Booten von SDHC kann derzeit noch zu Problemen führen (siehe unten).}}<br />
<br />
== Booten von SDHC ==<br />
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.<br />
Ticket: [https://docs.openmoko.org/trac/ticket/1802 #1802].<br />
Thread: [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281]<br />
Am Besten legt man sich ein Backup der Partitionstabelle an, um sie im Notfall schnell wieder zur Verfügung zu haben.<br />
<br />
== So funktionierts ==<br />
<br />
[[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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
=== U-Boot-Menü-Einträge ===<br />
<br />
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 "<MenüName>:<Befehle>", wobei <MenüName> der Text ist, der auf dem Display angezeigt wird und <Befehle> eine Abfolge der U-boot-Befehle welche ausgeführt werden, wenn der Menüpunkt auswählt wird. Die einzelnen Befehle werden hierbei durch ';' getrennt.<br />
Beim Eingeben der Befehlsabfolge müssen ';' durch "\;" und '$' durch "\$" ersetzt werden.<br />
<br />
=== Laden des Kernels ===<br />
<br />
Zum Laden des Kernels von der SD-Karte müssen folgende U-Boot-Befehle ausgeführt werden:<br />
Die SD-Karte mit "mmcinit" initialisieren.<br />
Den Kernel in den Arbeitsspeicher laden:<br />
<br />
Kernel befindet sich auf einem FAT-Filesystem:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
Kernel befindet sich auf einem ext2/ext3-Filesystem:<br />
<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
Hierbei entspricht &lt;p&gt; der Partitionsnummer und &lt;filepath&gt; dem Pfad zu dem zu ladendem Kernel.<br />
<br />
{{Note| Der "ext2load"-Befehl funktioniert nicht bei U-boot-Versionen kleiner "20080723". Diese sind vom folgendem Bug betroffen: [http://docs.openmoko.org/trac/ticket/799 #799]<br />
Nach einem Update der U-Boot und Kernel Pakete kann man direkt von ext2/ext3 booten.}}<br />
<br />
{{Warning | Beim U-Boot-Update auf dem NEO1973 ist Vorsicht geboten! Es besteht die Gefahr sich aus dem NEO auszuschließen, wenn man kein Debug-Board zur Verfügung hat. Dies betrifft nicht den Freerunner, da dieser eine Kopie von U-Boot im NOR-Flasch hat!}}<br />
<br />
{{Note| U-Boot unterstützt das SDHC-Protocol nur auf dem FreeRunner: Auf dem Neo1973, ist U-Boot nicht in der Lage mit SDHC-Karten (4G oder größer) zu arbeiten. Der Kernel unterstützt SDHC auf dem NEO1973, dadurch ist es möglich den Kernel auf dem NAND-Flash und das Root-Filesystem auf der SDHC-Karte laufen zu lassen. }}<br />
<br />
=== Root-Filesystem Parameter ===<br />
<br />
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".<br />
<br />
Beispiel: Folgende Parameter veranlassen den Kernel die dritte Partition der SD-Karte zu mounten:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5<br />
<br />
Der "rootdelay"-Parameter gibt der SD-Karte die nötige Zeit um sich zu initialisieren bevor auf sie zugegriffen wird.<br />
<br />
Wichtig ist, daß der Kernel das Root-Filesystem auch unterstützt.<br />
Der Default-Openmoko-Kernel [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] unterstützt ext2 und ext3. Überprüfen kann man die unterstützten Filesysteme mit folgendem Linux-Befehl:<br />
<br />
less /proc/filesystems<br />
<br />
Es ist nicht möglich, VFAT als Root-Filesystem zu benutzen.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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).<br />
<br />
<br />
== Rootfs ==<br />
<br />
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.<br />
<br />
=== Möglichkeit 1: Rootfs.tar und Kernel.tar vom Openmoko buildhost downloaden ===<br />
<br />
Aktuelles Rootfs und Kernel einfach unter [[Latest Images]] downloaden.<br />
<br />
=== Möglichkeit 2: Mit OpenEmbedded selber ein tar-File erstellen ===<br />
<br />
Eine weitere Möglichkeit besteht darin, sich selber mit der OpenEmbedded Umgebung ein Rootfs-tar-Archiv zu erstellen.<br />
<br />
Um OM-2007.2 zu erstellen, muss man "tar" zu den Image-Typen in seiner ''local.conf'' hinzudügen:<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
Jetzt kann man das neue Image erstellen:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
oder mit MokoMakefile:<br />
<br />
make openmoko-devel-image<br />
<br />
Das ''Openmoko-....tar'' findet sich anschließend im Out-Pfad.<br />
<br />
=== Möglichkeit 3 : Ein jff2-Image in ein tar-File konvertieren ===<br />
<br />
Siehe [[Userspace root image]].<br />
<br />
== Vorbereiten der SD-Karte ==<br />
<br />
=== Partitionieren der SD-Karte ===<br />
<br />
Das Beispiel zeigt wie man mit fdisk Partitionen erstellt (siehe auch weitere [[#Hinweise_zur_Partitionierung| Hinweise zum Festlegung von Partition]]).<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
'''''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''.<br />
Jetzt erstellt man eine 8MB Partition für den Kernel und eine Partition mit dem restlichen Speicherplatz für das Root-Filesystem.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
Bei folgender Fehlermeldung:<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
einfach das Gerät aushängen:<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
und anschließend die Partitionstabellen nocheinmal schreiben:<br />
<br />
fdisk /dev/mmcblk0<br />
Command (m for help): w<br />
<br />
=== Formatieren der SD-Karte ===<br />
<br />
Folgender Befehl formatiert die erste Partition der SD-Karte mit dem FAT-Filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
<br />
{{Note| Sollte mkfs.vfat nicht installiert sein, muss das "dosfstools"-Packet nachinstalliert werden. Dieses Paket ist zwar nicht in der offiziellen Software enthalten, kann aber unter http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk heruntergeladen werden.}}<br />
<br />
Die zweite Partition wird mit dem ext3-Filesystem formatiert:<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Bespielen der SD-Karte ==<br />
<br />
Die SD-Karte ist jetzt bereit mit dem Rootfs und dem Kernel bespielt zuwerden.<br />
<br />
Zuerst wird die zweite Patrtition der SD-Karte gemountet und das Rootfs-Image aufgespielt:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
'''''Achtung:''''' Die Pfade und Dateinamen müssen entsprechend angepasst werden.<br />
<br />
Als nächstes wird die erste Partition der SD-Karte gemountet und der Kernel darauf installiert:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Bei einigen Versionen des NOR U-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Ja, kleines i und keine Dateierweiterung.)<br />
<br />
Es ist sicherzustellen, daß der Kernel ''uImage.bin'' (oder ''uimage'' bei einigen Versionen des NOR U-boot) heisst. Sollte U-Boot das Kernel-Image nicht finden: [[Bootloader#Using usbtty from Linux|im Bootloader anmelden]] mit ''[http://www.airs.com/ian/uucp.html cu]''<br />
Die Partition mit mmcinit mounten und prüfen, ob der Kernel vorhanden und richtig benannt ist:<br />
Das geht mit ''fatls mmc 1:1'' bei FAT-Filesystemen oder ''ext2ls mmc 1:1'' bei ext2-Filesystemen.<br />
<br />
Anschließend mit dem Ergebnis von ''printenv sd_image_name'' vergleichen. Es ist zu beachten, daß das die Umgebungsvariable im NAND-Flash aber nicht im NOR-Flash geändert werden kann. Wenn also aus dem NOR-Flash gebootet werden soll muss der Dateiname an die Umgebungsvariable angepasst werden.<br />
<br />
Jetzt beide Partitionen aushängen und sicherstellen, daß alle Buffer geschrieben wurden:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== U-Boot-Menü-Eintrag hinzufügen ==<br />
<br />
Je nach Revision des NEO und des verwendeten Partitionstyps (ext2/ext3) kann es notwendig sein, daß ein dem BootMenü ein Eintraghinzugefügt werden muss, um das System von der SD-Karte booten zu können.<br />
<br />
Beim einem FreeRunner mit einer FAT-Partition (Kernel) und einer ext2-Partition (rootfs) sollte es möglich sein direkt von der SD-Karte zu booten, da der Boot-Menü-Eintrag für bereits im NOR- und NAND-Boot-Menü enthalten ist.<br />
In allen anderen Fällen muss der benötigte Menü-Eintrag erst hinzugefügt werden.<br />
<br />
Eine Beschreibung dazu findet sich hier: [[Bootloader/de#Bootlader_Kommandozeile]]<br />
<br />
Wie man in das Bootmenü gelangt steht hier: [[Getting_Started_with_your_Neo_FreeRunner/de#Anschalten_des_Neo_FreeRunner]].<br />
<br />
Als erstes empfiehlt es sich, das U-Boot-TimeOut(60s) auf einen realistischen Wert zu setzen. Hierzu aus der UBoot-Kommandoeile folgenden Befehl ausführen:<br />
<br />
setenv boot_menu_timeout 99999<br />
<br />
Der TimeOut-Wert wird so auf 99999s gesetzt, was für alle weiteren Vorhaben ausreichen sollte.:-)<br />
<br />
<br />
Jetzt wird geprüft, ob ein geeigneter Menü-Eintrag zum booten von der SD-Karte vorhanden ist:<br />
<br />
printenv<br />
<br />
Wenn eine Zeile existiert, die mit ''menu_'' beginnt und auch die folgende Befehle enthält braucht kein neuer Menü-Eintrag erstellt werden.<br />
<br />
{{Note| Die Backslashs (\) sind wichtig für UBoot um den Befehl als neue Umgebungsvariable (menu_9) einzutragen. Durch einfaches drücken der Enter-Taste würde der Befehl lediglich ausgeführt werden.}}<br />
<br />
{{Note| Kopieren und Einfügen funktioniert bei einigen Emulatoren nicht.<br />
Copy and paste may not work depending on your terminal emulator. Commi funktioniert alternativ kann auch der Terminal-Emulator [[NeoCon|NeoCon]]. Ansonsten muss alles manuell in die Kommandozeile eingetippt werden.}}<br />
<br />
An dieser Stelle ist es wichtig zwischen FAT- und ext2-Kernel und zwischen ext2- und ext3-rootfs zu unterscheiden.<br />
<br />
Möglicherweise müssen die Nummern in root=/dev/mmcblk0p'''#''' (rootfs) und fatload mmc '''#''' oder ext2load mmc '''#''' (Kernel) geändert werden.<br />
<br />
'''Boot-Eintrag für FAT-Kernel mit ext3-Rootfs Partition:'''<br />
<br />
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<br />
<br />
'''Boot-Eintrag für FAT-Kernel mit ext2-Rootfs Partition:'''<br />
<br />
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<br />
<br />
or : with additional 'init=/sbin/init' kernel parameter (may be needed for some images) :<br />
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<br />
<br />
'''Boot-Eintrag für ext2-Kernel mit ext2-Rootfs Partition: (requires newer u-boot)'''<br />
<br />
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<br />
<br />
'''Boot-Eintrag für Kernel und Rootfs auf der gleichen ext2 Partition (getestet mit Qtopia/ benötigt ein neues U-boot)'''<br />
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<br />
<br />
Jetzt nur noch prüfen, ob der neue Menü-Eintrag richtig angezeigt wird.:<br />
<br />
printenv<br />
<br />
Wenn alles passt dann speichern:<br />
<br />
saveenv<br />
<br />
Die neue Konfiguration wird jetzt im NAND gespeichert.<br />
<br />
Herunterfahren des NEO:<br />
<br />
neo1973 power-off<br />
<br />
Nach dem Neustart in das NAND-Boot-Menü gehen und den neu erstellten Menü-Eintrag wählen um von der SD-Karte zu booten.<br />
<br />
----<br />
<br />
Siehe auch unter [[Moving current system from flash to SD]] wo gezeigt wird, wie das System vom Flash auf die SD-Karte verschoben wird.<br />
<br />
----<br />
<br />
== Sonstiges ==<br />
<br />
=== Booten von SDHC ===<br />
<br />
{{Note|Der folgende Abschnitt wurde für das Neo1973 geschrieben. SDHC und SD beide im FreeRunner laufen wenn ein U-boot ab 2008-07-23 verwendet wird.}}<br />
<br />
Das Booten von SDHC-Karten wird von älteren U-Boot-Versionen nicht unterstützt.<br />
Es gibt eine Mögichkeit dies zu umgehen indem man nur das Rootfs auf der SDHC-Karte installiert.<br />
<br />
Folgen sie Schritt 1, um einen Kernel-Image mit MMC-und ext2-Unterstützung zu bekommen. Doch statt das Image auf die Rootfs zu kopieren, kopieren sie es in den internen NAND-Flash.(mit [[DFÜ-util]]).<br />
Jetzt können Sie mit Schritt 2 fortfahren (wie schon erwähnt, nicht das uImage auf die Rootfs kopieren) und den Anweisungen bis zu Schritt 3 folgen.<br />
Anstelle der setenv-Befehle in Schritt 3 führen Sie die folgenden Schritte aus: <br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
Jetzt kann der neue Menü-Eintrag "Boot from SDHC" benutzt werden um den interen kernel zu booten und dabei das Root-Filesystem auf der SDHC-Karte zu laden.<br />
<br />
=== Autoboot von SDHC ===<br />
<br />
Wenn automatisch von der SDHC-Karte gebootet werden soll: <br />
Zuerst einen neue Bootmenü Eintrag für das Booten von NAND erstellen:<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
Danach neustarten und im Bootmenü den neuen Eintrag testen. Wenn dieser funktioniert wieder herrunterfahren, das Bootmenü starten, Bootloader verbinden und das autoboot-Komando zum booten von der SDHC-Karte erstellen:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
Jetzt wird immer von der SDHC-Karte gebootetwenn der Power-Knopf gedrückt oder reboot ausgeführt wird. Wenn vom NAND gebootet werden soll muss das Bootmenü benutzt werden.<br />
<br />
===Hinweise zur Partitionierung===<br />
<br />
U-Boot vor 2008-07-23 kann ausschließlich von FAT-Filesystemen booten. Neuere Versionen unterstützen auch ext2/ext3.<br />
<br />
Weil SD-Karten als mmc-Geräteknoten (unter Major 179, siehe [http://www.lanana.org/docs/device-list/devices-2.6+.txt Linux Allocated Devices]) eingebunden werden, is folgendes zu beachten:<br />
<br />
* Das [http://www.lanana.org/docs/device-list/devices-2.6+.txt Numerierungsschema für Geräte] sieht für mmc-Geräte die minor numbers 1 bis 7 (/dev/mmcblk0p1 ... /dev/mmcblk0p7). Minor number 8 ist bereits der nächsten physikalischen SD-Karte (/dev/mmcblk1) vorbehalten. Daher sind maimal 7 Partitionen verfügbar.<br />
<br />
* Die rootfs aktueller Distributionen bringen die Geräteknoten mmcblk0p1 bis mmcblk0p4 schon mit. Um erweiterete Partitions (5 ...) zu verwenden, müssen weitere Knoten angelegt in /lib/udev/devices/ werden. Nach einem Neustart stehen sie in /dev zur Verfügung:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
<br />
<br />
Weil uboot einen Kernel nur im unteren Bereich (2GB-Grenze) einer SD-Karte lesen kann, empfiehlt es sich alle Kernel in der ersten Partition unterzubringen. Bewährt hat sich auch, dort zentral die PIM-Daten abzulegen, um von allen installierten Distributionen per symlink darauf zuzugreifen.<br />
<br />
Die Kernel können ein rootfs auch von einer erweiterten Partition einbinden.<br />
<br />
=== Udev automount fixen ===<br />
<br />
Udev mountet die SD-Karte automatisch unter /media/mmcblk0p1/ .<br />
Dies kann geändert werden:<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Bemerkung zu Kernel Parametern ===<br />
<br />
==== loglevel ====<br />
<br />
Einige Leute empfehlen folgendes zur KernelBefehlsZeile hinzuzufügen:<br />
<br />
loglevel=8<br />
<br />
Wenn Sie "console=tty0" in der KernelBefehlsZeile aufrufen verlangsamt das den Bootprozess extrem da der Framebuffer (Neo-Display im Text-Modus) unmengen von DebugInformationen schreiben muss. <br />
<br />
{{Languages|Booting_from_SD}}</div>Lokomokohttp://openmoko.org/wiki/Booting_the_Neo_FreeRunner_from_SD_via_U-BootBooting the Neo FreeRunner from SD via U-Boot2009-01-12T16:37:35Z<p>Lokomoko: /* Partioning the SD card */</p>
<hr />
<div>{{Languages|Booting from SD}}<br />
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.<br />
<br />
{{Warning | Booting from SDHC may cause problems at this time (see below).}} <br />
<br />
== Booting from SDHC / suspend problems ==<br />
<br />
First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| 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.<br />
<br />
== How it Works ==<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
The following sections provide additional details.<br />
<br />
=== Menu Entries ===<br />
<br />
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 "\$"). <br />
<br />
=== Loading the Kernel ===<br />
<br />
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.<br />
<br />
The command syntax is:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
where &lt;p&gt; is the partition number, and &lt;filepath&gt; is the path to the file that is to be loaded.<br />
<br />
{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}<br />
<br />
{{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 }}<br />
<br />
{{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. }}<br />
<br />
=== Root Filesystem Parameters ===<br />
<br />
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". <br />
<br />
For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5 <br />
<br />
The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed. <br />
<br />
Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command<br />
<br />
less /proc/filesystems<br />
<br />
It is not possible to use VFAT for the root filesystem.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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.<br />
<br />
<br />
== Acquiring a tarfile rootfs ==<br />
<br />
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 [http://downloads.openmoko.org downloads].<br />
<br />
<br />
=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===<br />
<br />
Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].<br />
<br />
=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===<br />
<br />
Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.<br />
<br />
To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
After that build a new image by issuing:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
or if you are using the MokoMakefile: <br />
<br />
make openmoko-devel-image<br />
<br />
After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive<br />
<br />
=== Possibility 3 : Convert a jff2 image to a tarfile ===<br />
<br />
See [[Userspace root image]] for more details on how to access contents of a jffs2 image.<br />
<br />
== Prepare the SD card ==<br />
<br />
=== Partioning the SD card ===<br />
<br />
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.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
''Should probably need to change type of first partition to FAT 16 too ?''<br />
<br />
''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''<br />
<br />
''How about a swap partition also?''<br />
<br />
if it exits with something like<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
do<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
on another shell and try again.<br />
<br />
=== Formatting the SD card ===<br />
<br />
Just issue the following command to create at FAT filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
{{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 />
<br />
<br />
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):<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Populate SD card ==<br />
<br />
Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.<br />
<br />
Mount the second partition of your SD card somewhere and put the image on it:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
Or directly from the host via USB network:<br />
<br />
cat openmoko-image-*.tar.gz |ssh root@192.168.0.202 "tar -C /mnt/moko/ -xzf -"<br />
<br />
'''''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<br />
<br />
'''''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.<br />
<br />
The next step is to mount the first partition of the sd card and install the kernel on it.<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Or, for some versions of NOR u-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Yes, lower case i and no extension.)<br />
<br />
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.<br />
<br />
Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== Add uboot boot entry ==<br />
*See also" [[Qi]]<br />
<br />
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.<br />
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.<br />
In any other case you should at least make sure the needed entry exists in your menu before proceeding.<br />
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]].<br />
<br />
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:<br />
<br />
<pre><br />
setenv boot_menu_timeout 99999<br />
</pre><br />
<br />
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.<br />
<br />
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:<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
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.<br />
<br />
Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see<br />
* help<br />
* help <command><br />
* and [[Bootloader]] and [[Bootloader commands]].<br />
<br />
{{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.}}<br />
<br />
{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}<br />
<br />
It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.<br />
<br />
Please watch partition numbers in the following commands. In particular, you may need to change some of<br />
<pre><br />
root=/dev/mmcblk0p#<br />
fatload mmc#<br />
ext2load mmc#<br />
</pre><br />
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.<br />
<br />
'''Boot entry for FAT kernel+ext3 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for FAT kernel+ext2 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):<br />
<br />
<pre><br />
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
You are nearly done. Just issue a<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).<br />
<br />
If everything looks fine enter<br />
<br />
<pre><br />
saveenv<br />
</pre><br />
<br />
into the prompt and press enter. The new configuration should now be saved to the NAND.<br />
<br />
Shutdown your neo with the following command:<br />
<br />
<pre><br />
neo1973 power-off<br />
</pre><br />
<br />
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.<br />
<br />
<br />
If you got error when loading kernel, add sleep to boot entry.<br />
<br />
Before:<br />
<pre><br />
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
After:<br />
<pre><br />
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
<br />
----<br />
<br />
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.<br />
<br />
----<br />
<br />
== Appendix ==<br />
<br />
=== Boot from SDHC ===<br />
<br />
{{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.}}<br />
<br />
As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.<br />
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:<br />
<br />
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]]).<br />
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.<br />
Instead of the setenv commands in Step 3 you have to enter the following:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
And that's it!<br />
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.<br />
<br />
=== Autoboot from SDHC ===<br />
<br />
Maybe you want to Boot automatically from SDHC: <br />
Set a new Bootmenu Entry for booting from NAND first<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
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:<br />
<br />
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 <br />
GTA01Bv4 # saveenv<br />
<br />
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.<br />
<br />
<br />
=== Fixing udev automount ===<br />
<br />
Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
===Partitioning Hints===<br />
<br />
u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.<br />
<br />
Since SD-cards are accessed as mmc device nodes (Major 179 of [http://www.lanana.org/docs/device-list/devices-2.6+.txt Linux Allocated Devices]) there are some things you should be aware of:<br />
<br />
* The [http://www.lanana.org/docs/device-list/devices-2.6+.txt 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.<br />
<br />
* 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/:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
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.<br />
<br />
Booting a rootfs from an extended partition with uboot has been tested successfully.<br />
<br />
=== Remarks on Kernel Parameters ===<br />
<br />
==== loglevel ====<br />
<br />
Some people suggested adding:<br />
<br />
loglevel=8<br />
<br />
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:<br />
<br />
s3c2410-sdi s3c2410-sdi: ......<br />
mmc0: ....<br />
<br />
{{Languages|Booting_from_SD}}<br />
<br />
[[Category:Advanced End User]]<br />
[[Category:Flashing Openmoko]]<br />
[[Category:System Developers]]</div>Lokomokohttp://openmoko.org/wiki/Booting_the_Neo_FreeRunner_from_SD_via_U-BootBooting the Neo FreeRunner from SD via U-Boot2009-01-12T16:35:30Z<p>Lokomoko: /* Partitioning Limitations */</p>
<hr />
<div>{{Languages|Booting from SD}}<br />
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.<br />
<br />
{{Warning | Booting from SDHC may cause problems at this time (see below).}} <br />
<br />
== Booting from SDHC / suspend problems ==<br />
<br />
First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| 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.<br />
<br />
== How it Works ==<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
The following sections provide additional details.<br />
<br />
=== Menu Entries ===<br />
<br />
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 "\$"). <br />
<br />
=== Loading the Kernel ===<br />
<br />
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.<br />
<br />
The command syntax is:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
where &lt;p&gt; is the partition number, and &lt;filepath&gt; is the path to the file that is to be loaded.<br />
<br />
{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}<br />
<br />
{{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 }}<br />
<br />
{{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. }}<br />
<br />
=== Root Filesystem Parameters ===<br />
<br />
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". <br />
<br />
For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5 <br />
<br />
The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed. <br />
<br />
Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command<br />
<br />
less /proc/filesystems<br />
<br />
It is not possible to use VFAT for the root filesystem.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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.<br />
<br />
<br />
== Acquiring a tarfile rootfs ==<br />
<br />
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 [http://downloads.openmoko.org downloads].<br />
<br />
<br />
=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===<br />
<br />
Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].<br />
<br />
=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===<br />
<br />
Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.<br />
<br />
To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
After that build a new image by issuing:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
or if you are using the MokoMakefile: <br />
<br />
make openmoko-devel-image<br />
<br />
After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive<br />
<br />
=== Possibility 3 : Convert a jff2 image to a tarfile ===<br />
<br />
See [[Userspace root image]] for more details on how to access contents of a jffs2 image.<br />
<br />
== Prepare the SD card ==<br />
<br />
=== Partioning the SD card ===<br />
<br />
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 [[#Partition_Hints| Partitioning Hints]] before defining your partition layout.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
''Should probably need to change type of first partition to FAT 16 too ?''<br />
<br />
''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''<br />
<br />
''How about a swap partition also?''<br />
<br />
if it exits with something like<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
do<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
on another shell and try again.<br />
<br />
=== Formatting the SD card ===<br />
<br />
Just issue the following command to create at FAT filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
{{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 />
<br />
<br />
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):<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Populate SD card ==<br />
<br />
Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.<br />
<br />
Mount the second partition of your SD card somewhere and put the image on it:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
Or directly from the host via USB network:<br />
<br />
cat openmoko-image-*.tar.gz |ssh root@192.168.0.202 "tar -C /mnt/moko/ -xzf -"<br />
<br />
'''''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<br />
<br />
'''''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.<br />
<br />
The next step is to mount the first partition of the sd card and install the kernel on it.<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Or, for some versions of NOR u-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Yes, lower case i and no extension.)<br />
<br />
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.<br />
<br />
Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== Add uboot boot entry ==<br />
*See also" [[Qi]]<br />
<br />
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.<br />
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.<br />
In any other case you should at least make sure the needed entry exists in your menu before proceeding.<br />
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]].<br />
<br />
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:<br />
<br />
<pre><br />
setenv boot_menu_timeout 99999<br />
</pre><br />
<br />
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.<br />
<br />
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:<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
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.<br />
<br />
Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see<br />
* help<br />
* help <command><br />
* and [[Bootloader]] and [[Bootloader commands]].<br />
<br />
{{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.}}<br />
<br />
{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}<br />
<br />
It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.<br />
<br />
Please watch partition numbers in the following commands. In particular, you may need to change some of<br />
<pre><br />
root=/dev/mmcblk0p#<br />
fatload mmc#<br />
ext2load mmc#<br />
</pre><br />
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.<br />
<br />
'''Boot entry for FAT kernel+ext3 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for FAT kernel+ext2 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):<br />
<br />
<pre><br />
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
You are nearly done. Just issue a<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).<br />
<br />
If everything looks fine enter<br />
<br />
<pre><br />
saveenv<br />
</pre><br />
<br />
into the prompt and press enter. The new configuration should now be saved to the NAND.<br />
<br />
Shutdown your neo with the following command:<br />
<br />
<pre><br />
neo1973 power-off<br />
</pre><br />
<br />
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.<br />
<br />
<br />
If you got error when loading kernel, add sleep to boot entry.<br />
<br />
Before:<br />
<pre><br />
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
After:<br />
<pre><br />
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
<br />
----<br />
<br />
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.<br />
<br />
----<br />
<br />
== Appendix ==<br />
<br />
=== Boot from SDHC ===<br />
<br />
{{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.}}<br />
<br />
As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.<br />
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:<br />
<br />
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]]).<br />
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.<br />
Instead of the setenv commands in Step 3 you have to enter the following:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
And that's it!<br />
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.<br />
<br />
=== Autoboot from SDHC ===<br />
<br />
Maybe you want to Boot automatically from SDHC: <br />
Set a new Bootmenu Entry for booting from NAND first<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
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:<br />
<br />
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 <br />
GTA01Bv4 # saveenv<br />
<br />
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.<br />
<br />
<br />
=== Fixing udev automount ===<br />
<br />
Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
===Partitioning Hints===<br />
<br />
u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.<br />
<br />
Since SD-cards are accessed as mmc device nodes (Major 179 of [http://www.lanana.org/docs/device-list/devices-2.6+.txt Linux Allocated Devices]) there are some things you should be aware of:<br />
<br />
* The [http://www.lanana.org/docs/device-list/devices-2.6+.txt 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.<br />
<br />
* 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/:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
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.<br />
<br />
Booting a rootfs from an extended partition with uboot has been tested successfully.<br />
<br />
=== Remarks on Kernel Parameters ===<br />
<br />
==== loglevel ====<br />
<br />
Some people suggested adding:<br />
<br />
loglevel=8<br />
<br />
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:<br />
<br />
s3c2410-sdi s3c2410-sdi: ......<br />
mmc0: ....<br />
<br />
{{Languages|Booting_from_SD}}<br />
<br />
[[Category:Advanced End User]]<br />
[[Category:Flashing Openmoko]]<br />
[[Category:System Developers]]</div>Lokomokohttp://openmoko.org/wiki/Booting_the_Neo_FreeRunner_from_SD_via_U-BootBooting the Neo FreeRunner from SD via U-Boot2009-01-12T16:16:33Z<p>Lokomoko: /* Partioning the SD card */</p>
<hr />
<div>{{Languages|Booting from SD}}<br />
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.<br />
<br />
{{Warning | Booting from SDHC may cause problems at this time (see below).}} <br />
<br />
== Booting from SDHC / suspend problems ==<br />
<br />
First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| 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.<br />
<br />
== How it Works ==<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
The following sections provide additional details.<br />
<br />
=== Menu Entries ===<br />
<br />
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 "\$"). <br />
<br />
=== Loading the Kernel ===<br />
<br />
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.<br />
<br />
The command syntax is:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
where &lt;p&gt; is the partition number, and &lt;filepath&gt; is the path to the file that is to be loaded.<br />
<br />
{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}<br />
<br />
{{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 }}<br />
<br />
{{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. }}<br />
<br />
=== Root Filesystem Parameters ===<br />
<br />
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". <br />
<br />
For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5 <br />
<br />
The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed. <br />
<br />
Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command<br />
<br />
less /proc/filesystems<br />
<br />
It is not possible to use VFAT for the root filesystem.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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.<br />
<br />
<br />
== Acquiring a tarfile rootfs ==<br />
<br />
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 [http://downloads.openmoko.org downloads].<br />
<br />
<br />
=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===<br />
<br />
Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].<br />
<br />
=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===<br />
<br />
Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.<br />
<br />
To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
After that build a new image by issuing:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
or if you are using the MokoMakefile: <br />
<br />
make openmoko-devel-image<br />
<br />
After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive<br />
<br />
=== Possibility 3 : Convert a jff2 image to a tarfile ===<br />
<br />
See [[Userspace root image]] for more details on how to access contents of a jffs2 image.<br />
<br />
== Prepare the SD card ==<br />
<br />
=== Partioning the SD card ===<br />
<br />
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 [[#Partition_Hints| Partitioning Hints]] before defining your partition layout.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
''Should probably need to change type of first partition to FAT 16 too ?''<br />
<br />
''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''<br />
<br />
''How about a swap partition also?''<br />
<br />
if it exits with something like<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
do<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
on another shell and try again.<br />
<br />
=== Formatting the SD card ===<br />
<br />
Just issue the following command to create at FAT filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
{{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 />
<br />
<br />
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):<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Populate SD card ==<br />
<br />
Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.<br />
<br />
Mount the second partition of your SD card somewhere and put the image on it:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
Or directly from the host via USB network:<br />
<br />
cat openmoko-image-*.tar.gz |ssh root@192.168.0.202 "tar -C /mnt/moko/ -xzf -"<br />
<br />
'''''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<br />
<br />
'''''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.<br />
<br />
The next step is to mount the first partition of the sd card and install the kernel on it.<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Or, for some versions of NOR u-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Yes, lower case i and no extension.)<br />
<br />
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.<br />
<br />
Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== Add uboot boot entry ==<br />
*See also" [[Qi]]<br />
<br />
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.<br />
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.<br />
In any other case you should at least make sure the needed entry exists in your menu before proceeding.<br />
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]].<br />
<br />
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:<br />
<br />
<pre><br />
setenv boot_menu_timeout 99999<br />
</pre><br />
<br />
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.<br />
<br />
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:<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
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.<br />
<br />
Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see<br />
* help<br />
* help <command><br />
* and [[Bootloader]] and [[Bootloader commands]].<br />
<br />
{{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.}}<br />
<br />
{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}<br />
<br />
It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.<br />
<br />
Please watch partition numbers in the following commands. In particular, you may need to change some of<br />
<pre><br />
root=/dev/mmcblk0p#<br />
fatload mmc#<br />
ext2load mmc#<br />
</pre><br />
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.<br />
<br />
'''Boot entry for FAT kernel+ext3 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for FAT kernel+ext2 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):<br />
<br />
<pre><br />
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
You are nearly done. Just issue a<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).<br />
<br />
If everything looks fine enter<br />
<br />
<pre><br />
saveenv<br />
</pre><br />
<br />
into the prompt and press enter. The new configuration should now be saved to the NAND.<br />
<br />
Shutdown your neo with the following command:<br />
<br />
<pre><br />
neo1973 power-off<br />
</pre><br />
<br />
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.<br />
<br />
<br />
If you got error when loading kernel, add sleep to boot entry.<br />
<br />
Before:<br />
<pre><br />
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
After:<br />
<pre><br />
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
<br />
----<br />
<br />
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.<br />
<br />
----<br />
<br />
== Appendix ==<br />
<br />
=== Boot from SDHC ===<br />
<br />
{{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.}}<br />
<br />
As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.<br />
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:<br />
<br />
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]]).<br />
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.<br />
Instead of the setenv commands in Step 3 you have to enter the following:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
And that's it!<br />
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.<br />
<br />
=== Autoboot from SDHC ===<br />
<br />
Maybe you want to Boot automatically from SDHC: <br />
Set a new Bootmenu Entry for booting from NAND first<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
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:<br />
<br />
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 <br />
GTA01Bv4 # saveenv<br />
<br />
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.<br />
<br />
<br />
=== Fixing udev automount ===<br />
<br />
Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Partitioning Limitations ===<br />
<br />
Since SD-cards are accessed as mmc device nodes (Major 179 of [http://www.lanana.org/docs/device-list/devices-2.6+.txt Linux Allocated Devices]) there are some things you should be aware of:<br />
<br />
* The [http://www.lanana.org/docs/device-list/devices-2.6+.txt 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.<br />
<br />
* 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/:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Booting a rootfs from an extended partition with uboot has been tested successfully.<br />
<br />
=== Remarks on Kernel Parameters ===<br />
<br />
==== loglevel ====<br />
<br />
Some people suggested adding:<br />
<br />
loglevel=8<br />
<br />
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:<br />
<br />
s3c2410-sdi s3c2410-sdi: ......<br />
mmc0: ....<br />
<br />
{{Languages|Booting_from_SD}}<br />
<br />
[[Category:Advanced End User]]<br />
[[Category:Flashing Openmoko]]<br />
[[Category:System Developers]]</div>Lokomokohttp://openmoko.org/wiki/Booting_the_Neo_FreeRunner_from_SD_via_U-BootBooting the Neo FreeRunner from SD via U-Boot2009-01-12T16:15:43Z<p>Lokomoko: /* Partioning the SD card */</p>
<hr />
<div>{{Languages|Booting from SD}}<br />
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.<br />
<br />
{{Warning | Booting from SDHC may cause problems at this time (see below).}} <br />
<br />
== Booting from SDHC / suspend problems ==<br />
<br />
First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| 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.<br />
<br />
== How it Works ==<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
The following sections provide additional details.<br />
<br />
=== Menu Entries ===<br />
<br />
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 "\$"). <br />
<br />
=== Loading the Kernel ===<br />
<br />
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.<br />
<br />
The command syntax is:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
where &lt;p&gt; is the partition number, and &lt;filepath&gt; is the path to the file that is to be loaded.<br />
<br />
{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}<br />
<br />
{{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 }}<br />
<br />
{{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. }}<br />
<br />
=== Root Filesystem Parameters ===<br />
<br />
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". <br />
<br />
For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5 <br />
<br />
The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed. <br />
<br />
Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command<br />
<br />
less /proc/filesystems<br />
<br />
It is not possible to use VFAT for the root filesystem.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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.<br />
<br />
<br />
== Acquiring a tarfile rootfs ==<br />
<br />
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 [http://downloads.openmoko.org downloads].<br />
<br />
<br />
=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===<br />
<br />
Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].<br />
<br />
=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===<br />
<br />
Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.<br />
<br />
To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
After that build a new image by issuing:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
or if you are using the MokoMakefile: <br />
<br />
make openmoko-devel-image<br />
<br />
After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive<br />
<br />
=== Possibility 3 : Convert a jff2 image to a tarfile ===<br />
<br />
See [[Userspace root image]] for more details on how to access contents of a jffs2 image.<br />
<br />
== Prepare the SD card ==<br />
<br />
=== Partioning the SD card ===<br />
<br />
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 [[#Partition_Hints Partitioning Hints]] before defining your partition layout.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
''Should probably need to change type of first partition to FAT 16 too ?''<br />
<br />
''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''<br />
<br />
''How about a swap partition also?''<br />
<br />
if it exits with something like<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
do<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
on another shell and try again.<br />
<br />
=== Formatting the SD card ===<br />
<br />
Just issue the following command to create at FAT filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
{{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 />
<br />
<br />
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):<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Populate SD card ==<br />
<br />
Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.<br />
<br />
Mount the second partition of your SD card somewhere and put the image on it:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
Or directly from the host via USB network:<br />
<br />
cat openmoko-image-*.tar.gz |ssh root@192.168.0.202 "tar -C /mnt/moko/ -xzf -"<br />
<br />
'''''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<br />
<br />
'''''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.<br />
<br />
The next step is to mount the first partition of the sd card and install the kernel on it.<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Or, for some versions of NOR u-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Yes, lower case i and no extension.)<br />
<br />
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.<br />
<br />
Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== Add uboot boot entry ==<br />
*See also" [[Qi]]<br />
<br />
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.<br />
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.<br />
In any other case you should at least make sure the needed entry exists in your menu before proceeding.<br />
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]].<br />
<br />
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:<br />
<br />
<pre><br />
setenv boot_menu_timeout 99999<br />
</pre><br />
<br />
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.<br />
<br />
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:<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
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.<br />
<br />
Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see<br />
* help<br />
* help <command><br />
* and [[Bootloader]] and [[Bootloader commands]].<br />
<br />
{{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.}}<br />
<br />
{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}<br />
<br />
It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.<br />
<br />
Please watch partition numbers in the following commands. In particular, you may need to change some of<br />
<pre><br />
root=/dev/mmcblk0p#<br />
fatload mmc#<br />
ext2load mmc#<br />
</pre><br />
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.<br />
<br />
'''Boot entry for FAT kernel+ext3 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for FAT kernel+ext2 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):<br />
<br />
<pre><br />
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
You are nearly done. Just issue a<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).<br />
<br />
If everything looks fine enter<br />
<br />
<pre><br />
saveenv<br />
</pre><br />
<br />
into the prompt and press enter. The new configuration should now be saved to the NAND.<br />
<br />
Shutdown your neo with the following command:<br />
<br />
<pre><br />
neo1973 power-off<br />
</pre><br />
<br />
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.<br />
<br />
<br />
If you got error when loading kernel, add sleep to boot entry.<br />
<br />
Before:<br />
<pre><br />
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
After:<br />
<pre><br />
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
<br />
----<br />
<br />
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.<br />
<br />
----<br />
<br />
== Appendix ==<br />
<br />
=== Boot from SDHC ===<br />
<br />
{{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.}}<br />
<br />
As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.<br />
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:<br />
<br />
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]]).<br />
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.<br />
Instead of the setenv commands in Step 3 you have to enter the following:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
And that's it!<br />
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.<br />
<br />
=== Autoboot from SDHC ===<br />
<br />
Maybe you want to Boot automatically from SDHC: <br />
Set a new Bootmenu Entry for booting from NAND first<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
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:<br />
<br />
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 <br />
GTA01Bv4 # saveenv<br />
<br />
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.<br />
<br />
<br />
=== Fixing udev automount ===<br />
<br />
Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Partitioning Limitations ===<br />
<br />
Since SD-cards are accessed as mmc device nodes (Major 179 of [http://www.lanana.org/docs/device-list/devices-2.6+.txt Linux Allocated Devices]) there are some things you should be aware of:<br />
<br />
* The [http://www.lanana.org/docs/device-list/devices-2.6+.txt 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.<br />
<br />
* 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/:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Booting a rootfs from an extended partition with uboot has been tested successfully.<br />
<br />
=== Remarks on Kernel Parameters ===<br />
<br />
==== loglevel ====<br />
<br />
Some people suggested adding:<br />
<br />
loglevel=8<br />
<br />
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:<br />
<br />
s3c2410-sdi s3c2410-sdi: ......<br />
mmc0: ....<br />
<br />
{{Languages|Booting_from_SD}}<br />
<br />
[[Category:Advanced End User]]<br />
[[Category:Flashing Openmoko]]<br />
[[Category:System Developers]]</div>Lokomokohttp://openmoko.org/wiki/Booting_the_Neo_FreeRunner_from_SD_via_U-BootBooting the Neo FreeRunner from SD via U-Boot2009-01-12T16:10:00Z<p>Lokomoko: /* Partitioning Limitations */</p>
<hr />
<div>{{Languages|Booting from SD}}<br />
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.<br />
<br />
{{Warning | Booting from SDHC may cause problems at this time (see below).}} <br />
<br />
== Booting from SDHC / suspend problems ==<br />
<br />
First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| 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.<br />
<br />
== How it Works ==<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
The following sections provide additional details.<br />
<br />
=== Menu Entries ===<br />
<br />
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 "\$"). <br />
<br />
=== Loading the Kernel ===<br />
<br />
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.<br />
<br />
The command syntax is:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
where &lt;p&gt; is the partition number, and &lt;filepath&gt; is the path to the file that is to be loaded.<br />
<br />
{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}<br />
<br />
{{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 }}<br />
<br />
{{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. }}<br />
<br />
=== Root Filesystem Parameters ===<br />
<br />
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". <br />
<br />
For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5 <br />
<br />
The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed. <br />
<br />
Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command<br />
<br />
less /proc/filesystems<br />
<br />
It is not possible to use VFAT for the root filesystem.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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.<br />
<br />
<br />
== Acquiring a tarfile rootfs ==<br />
<br />
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 [http://downloads.openmoko.org downloads].<br />
<br />
<br />
=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===<br />
<br />
Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].<br />
<br />
=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===<br />
<br />
Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.<br />
<br />
To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
After that build a new image by issuing:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
or if you are using the MokoMakefile: <br />
<br />
make openmoko-devel-image<br />
<br />
After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive<br />
<br />
=== Possibility 3 : Convert a jff2 image to a tarfile ===<br />
<br />
See [[Userspace root image]] for more details on how to access contents of a jffs2 image.<br />
<br />
== Prepare the SD card ==<br />
<br />
=== Partioning the SD card ===<br />
<br />
u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.<br />
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_Limitations|Partitioning Limitations]] before designing you partition layout.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
''Should probably need to change type of first partition to FAT 16 too ?''<br />
<br />
''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''<br />
<br />
''How about a swap partition also?''<br />
<br />
if it exits with something like<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
do<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
on another shell and try again.<br />
<br />
=== Formatting the SD card ===<br />
<br />
Just issue the following command to create at FAT filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
{{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 />
<br />
<br />
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):<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Populate SD card ==<br />
<br />
Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.<br />
<br />
Mount the second partition of your SD card somewhere and put the image on it:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
Or directly from the host via USB network:<br />
<br />
cat openmoko-image-*.tar.gz |ssh root@192.168.0.202 "tar -C /mnt/moko/ -xzf -"<br />
<br />
'''''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<br />
<br />
'''''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.<br />
<br />
The next step is to mount the first partition of the sd card and install the kernel on it.<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Or, for some versions of NOR u-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Yes, lower case i and no extension.)<br />
<br />
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.<br />
<br />
Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== Add uboot boot entry ==<br />
*See also" [[Qi]]<br />
<br />
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.<br />
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.<br />
In any other case you should at least make sure the needed entry exists in your menu before proceeding.<br />
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]].<br />
<br />
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:<br />
<br />
<pre><br />
setenv boot_menu_timeout 99999<br />
</pre><br />
<br />
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.<br />
<br />
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:<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
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.<br />
<br />
Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see<br />
* help<br />
* help <command><br />
* and [[Bootloader]] and [[Bootloader commands]].<br />
<br />
{{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.}}<br />
<br />
{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}<br />
<br />
It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.<br />
<br />
Please watch partition numbers in the following commands. In particular, you may need to change some of<br />
<pre><br />
root=/dev/mmcblk0p#<br />
fatload mmc#<br />
ext2load mmc#<br />
</pre><br />
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.<br />
<br />
'''Boot entry for FAT kernel+ext3 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for FAT kernel+ext2 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):<br />
<br />
<pre><br />
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
You are nearly done. Just issue a<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).<br />
<br />
If everything looks fine enter<br />
<br />
<pre><br />
saveenv<br />
</pre><br />
<br />
into the prompt and press enter. The new configuration should now be saved to the NAND.<br />
<br />
Shutdown your neo with the following command:<br />
<br />
<pre><br />
neo1973 power-off<br />
</pre><br />
<br />
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.<br />
<br />
<br />
If you got error when loading kernel, add sleep to boot entry.<br />
<br />
Before:<br />
<pre><br />
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
After:<br />
<pre><br />
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
<br />
----<br />
<br />
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.<br />
<br />
----<br />
<br />
== Appendix ==<br />
<br />
=== Boot from SDHC ===<br />
<br />
{{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.}}<br />
<br />
As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.<br />
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:<br />
<br />
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]]).<br />
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.<br />
Instead of the setenv commands in Step 3 you have to enter the following:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
And that's it!<br />
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.<br />
<br />
=== Autoboot from SDHC ===<br />
<br />
Maybe you want to Boot automatically from SDHC: <br />
Set a new Bootmenu Entry for booting from NAND first<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
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:<br />
<br />
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 <br />
GTA01Bv4 # saveenv<br />
<br />
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.<br />
<br />
<br />
=== Fixing udev automount ===<br />
<br />
Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Partitioning Limitations ===<br />
<br />
Since SD-cards are accessed as mmc device nodes (Major 179 of [http://www.lanana.org/docs/device-list/devices-2.6+.txt Linux Allocated Devices]) there are some things you should be aware of:<br />
<br />
* The [http://www.lanana.org/docs/device-list/devices-2.6+.txt 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.<br />
<br />
* 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/:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Booting a rootfs from an extended partition with uboot has been tested successfully.<br />
<br />
=== Remarks on Kernel Parameters ===<br />
<br />
==== loglevel ====<br />
<br />
Some people suggested adding:<br />
<br />
loglevel=8<br />
<br />
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:<br />
<br />
s3c2410-sdi s3c2410-sdi: ......<br />
mmc0: ....<br />
<br />
{{Languages|Booting_from_SD}}<br />
<br />
[[Category:Advanced End User]]<br />
[[Category:Flashing Openmoko]]<br />
[[Category:System Developers]]</div>Lokomokohttp://openmoko.org/wiki/Booting_from_SD/deBooting from SD/de2009-01-12T16:06:28Z<p>Lokomoko: /* Hinweise zur Partitionierung */</p>
<hr />
<div>{{Languages}}<br />
Diese Seite beschreibt, wie man mit dem FreeRunner von einer [[Supported_microSD_cards|(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.<br />
<br />
{{Note| Das Booten von SDHC kann derzeit noch zu Problemen führen (siehe unten).}}<br />
<br />
== Booten von SDHC ==<br />
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.<br />
Ticket: [https://docs.openmoko.org/trac/ticket/1802 #1802].<br />
Thread: [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281]<br />
Am Besten legt man sich ein Backup der Partitionstabelle an, um sie im Notfall schnell wieder zur Verfügung zu haben.<br />
<br />
== So funktionierts ==<br />
<br />
[[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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
=== U-Boot-Menü-Einträge ===<br />
<br />
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 "<MenüName>:<Befehle>", wobei <MenüName> der Text ist, der auf dem Display angezeigt wird und <Befehle> eine Abfolge der U-boot-Befehle welche ausgeführt werden, wenn der Menüpunkt auswählt wird. Die einzelnen Befehle werden hierbei durch ';' getrennt.<br />
Beim Eingeben der Befehlsabfolge müssen ';' durch "\;" und '$' durch "\$" ersetzt werden.<br />
<br />
=== Laden des Kernels ===<br />
<br />
Zum Laden des Kernels von der SD-Karte müssen folgende U-Boot-Befehle ausgeführt werden:<br />
Die SD-Karte mit "mmcinit" initialisieren.<br />
Den Kernel in den Arbeitsspeicher laden:<br />
<br />
Kernel befindet sich auf einem FAT-Filesystem:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
Kernel befindet sich auf einem ext2/ext3-Filesystem:<br />
<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
Hierbei entspricht &lt;p&gt; der Partitionsnummer und &lt;filepath&gt; dem Pfad zu dem zu ladendem Kernel.<br />
<br />
{{Note| Der "ext2load"-Befehl funktioniert nicht bei U-boot-Versionen kleiner "20080723". Diese sind vom folgendem Bug betroffen: [http://docs.openmoko.org/trac/ticket/799 #799]<br />
Nach einem Update der U-Boot und Kernel Pakete kann man direkt von ext2/ext3 booten.}}<br />
<br />
{{Warning | Beim U-Boot-Update auf dem NEO1973 ist Vorsicht geboten! Es besteht die Gefahr sich aus dem NEO auszuschließen, wenn man kein Debug-Board zur Verfügung hat. Dies betrifft nicht den Freerunner, da dieser eine Kopie von U-Boot im NOR-Flasch hat!}}<br />
<br />
{{Note| U-Boot unterstützt das SDHC-Protocol nur auf dem FreeRunner: Auf dem Neo1973, ist U-Boot nicht in der Lage mit SDHC-Karten (4G oder größer) zu arbeiten. Der Kernel unterstützt SDHC auf dem NEO1973, dadurch ist es möglich den Kernel auf dem NAND-Flash und das Root-Filesystem auf der SDHC-Karte laufen zu lassen. }}<br />
<br />
=== Root-Filesystem Parameter ===<br />
<br />
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".<br />
<br />
Beispiel: Folgende Parameter veranlassen den Kernel die dritte Partition der SD-Karte zu mounten:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5<br />
<br />
Der "rootdelay"-Parameter gibt der SD-Karte die nötige Zeit um sich zu initialisieren bevor auf sie zugegriffen wird.<br />
<br />
Wichtig ist, daß der Kernel das Root-Filesystem auch unterstützt.<br />
Der Default-Openmoko-Kernel [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] unterstützt ext2 und ext3. Überprüfen kann man die unterstützten Filesysteme mit folgendem Linux-Befehl:<br />
<br />
less /proc/filesystems<br />
<br />
Es ist nicht möglich, VFAT als Root-Filesystem zu benutzen.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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).<br />
<br />
<br />
== Rootfs ==<br />
<br />
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.<br />
<br />
=== Möglichkeit 1: Rootfs.tar und Kernel.tar vom Openmoko buildhost downloaden ===<br />
<br />
Aktuelles Rootfs und Kernel einfach unter [[Latest Images]] downloaden.<br />
<br />
=== Möglichkeit 2: Mit OpenEmbedded selber ein tar-File erstellen ===<br />
<br />
Eine weitere Möglichkeit besteht darin, sich selber mit der OpenEmbedded Umgebung ein Rootfs-tar-Archiv zu erstellen.<br />
<br />
Um OM-2007.2 zu erstellen, muss man "tar" zu den Image-Typen in seiner ''local.conf'' hinzudügen:<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
Jetzt kann man das neue Image erstellen:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
oder mit MokoMakefile:<br />
<br />
make openmoko-devel-image<br />
<br />
Das ''Openmoko-....tar'' findet sich anschließend im Out-Pfad.<br />
<br />
=== Möglichkeit 3 : Ein jff2-Image in ein tar-File konvertieren ===<br />
<br />
Siehe [[Userspace root image]].<br />
<br />
== Vorbereiten der SD-Karte ==<br />
<br />
=== Partitionieren der SD-Karte ===<br />
<br />
Das Beispiel zeigt wie man mit fdisk Partitionen erstellt (siehe auch weitere [[#Hinweise_zur_Partitionierung| Hinweise zum Festlegung von Partition]]).<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
'''''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''.<br />
Jetzt erstellt man eine 8MB Partition für den Kernel und eine Partition mit dem restlichen Speicherplatz für das Root-Filesystem.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
Bei folgender Fehlermeldung:<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
einfach das Gerät aushängen:<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
und anschließend die Partitionstabellen nocheinmal schreiben:<br />
<br />
fdisk /dev/mmcblk0<br />
Command (m for help): w<br />
<br />
=== Formatieren der SD-Karte ===<br />
<br />
Folgender Befehl formatiert die erste Partition der SD-Karte mit dem FAT-Filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
<br />
{{Note| Sollte mkfs.vfat nicht installiert sein, muss das "dosfstools"-Packet nachinstalliert werden. Dieses Paket ist zwar nicht in der offiziellen Software enthalten, kann aber unter http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk heruntergeladen werden.}}<br />
<br />
Die zweite Partition wird mit dem ext3-Filesystem formatiert:<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Bespielen der SD-Karte ==<br />
<br />
Die SD-Karte ist jetzt bereit mit dem Rootfs und dem Kernel bespielt zuwerden.<br />
<br />
Zuerst wird die zweite Patrtition der SD-Karte gemountet und das Rootfs-Image aufgespielt:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
'''''Achtung:''''' Die Pfade und Dateinamen müssen entsprechend angepasst werden.<br />
<br />
Als nächstes wird die erste Partition der SD-Karte gemountet und der Kernel darauf installiert:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Bei einigen Versionen des NOR U-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Ja, kleines i und keine Dateierweiterung.)<br />
<br />
Es ist sicherzustellen, daß der Kernel ''uImage.bin'' (oder ''uimage'' bei einigen Versionen des NOR U-boot) heisst. Sollte U-Boot das Kernel-Image nicht finden: [[Bootloader#Using usbtty from Linux|im Bootloader anmelden]] mit ''[http://www.airs.com/ian/uucp.html cu]''<br />
Die Partition mit mmcinit mounten und prüfen, ob der Kernel vorhanden und richtig benannt ist:<br />
Das geht mit ''fatls mmc 1:1'' bei FAT-Filesystemen oder ''ext2ls mmc 1:1'' bei ext2-Filesystemen.<br />
<br />
Anschließend mit dem Ergebnis von ''printenv sd_image_name'' vergleichen. Es ist zu beachten, daß das die Umgebungsvariable im NAND-Flash aber nicht im NOR-Flash geändert werden kann. Wenn also aus dem NOR-Flash gebootet werden soll muss der Dateiname an die Umgebungsvariable angepasst werden.<br />
<br />
Jetzt beide Partitionen aushängen und sicherstellen, daß alle Buffer geschrieben wurden:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== U-Boot-Menü-Eintrag hinzufügen ==<br />
<br />
Je nach Revision des NEO und des verwendeten Partitionstyps (ext2/ext3) kann es notwendig sein, daß ein dem BootMenü ein Eintraghinzugefügt werden muss, um das System von der SD-Karte booten zu können.<br />
<br />
Beim einem FreeRunner mit einer FAT-Partition (Kernel) und einer ext2-Partition (rootfs) sollte es möglich sein direkt von der SD-Karte zu booten, da der Boot-Menü-Eintrag für bereits im NOR- und NAND-Boot-Menü enthalten ist.<br />
In allen anderen Fällen muss der benötigte Menü-Eintrag erst hinzugefügt werden.<br />
<br />
Eine Beschreibung dazu findet sich hier: [[Bootloader/de#Bootlader_Kommandozeile]]<br />
<br />
Wie man in das Bootmenü gelangt steht hier: [[Getting_Started_with_your_Neo_FreeRunner/de#Anschalten_des_Neo_FreeRunner]].<br />
<br />
Als erstes empfiehlt es sich, das U-Boot-TimeOut(60s) auf einen realistischen Wert zu setzen. Hierzu aus der UBoot-Kommandoeile folgenden Befehl ausführen:<br />
<br />
setenv boot_menu_timeout 99999<br />
<br />
Der TimeOut-Wert wird so auf 99999s gesetzt, was für alle weiteren Vorhaben ausreichen sollte.:-)<br />
<br />
<br />
Jetzt wird geprüft, ob ein geeigneter Menü-Eintrag zum booten von der SD-Karte vorhanden ist:<br />
<br />
printenv<br />
<br />
Wenn eine Zeile existiert, die mit ''menu_'' beginnt und auch die folgende Befehle enthält braucht kein neuer Menü-Eintrag erstellt werden.<br />
<br />
{{Note| Die Backslashs (\) sind wichtig für UBoot um den Befehl als neue Umgebungsvariable (menu_9) einzutragen. Durch einfaches drücken der Enter-Taste würde der Befehl lediglich ausgeführt werden.}}<br />
<br />
{{Note| Kopieren und Einfügen funktioniert bei einigen Emulatoren nicht.<br />
Copy and paste may not work depending on your terminal emulator. Commi funktioniert alternativ kann auch der Terminal-Emulator [[NeoCon|NeoCon]]. Ansonsten muss alles manuell in die Kommandozeile eingetippt werden.}}<br />
<br />
An dieser Stelle ist es wichtig zwischen FAT- und ext2-Kernel und zwischen ext2- und ext3-rootfs zu unterscheiden.<br />
<br />
Möglicherweise müssen die Nummern in root=/dev/mmcblk0p'''#''' (rootfs) und fatload mmc '''#''' oder ext2load mmc '''#''' (Kernel) geändert werden.<br />
<br />
'''Boot-Eintrag für FAT-Kernel mit ext3-Rootfs Partition:'''<br />
<br />
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<br />
<br />
'''Boot-Eintrag für FAT-Kernel mit ext2-Rootfs Partition:'''<br />
<br />
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<br />
<br />
or : with additional 'init=/sbin/init' kernel parameter (may be needed for some images) :<br />
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<br />
<br />
'''Boot-Eintrag für ext2-Kernel mit ext2-Rootfs Partition: (requires newer u-boot)'''<br />
<br />
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<br />
<br />
'''Boot-Eintrag für Kernel und Rootfs auf der gleichen ext2 Partition (getestet mit Qtopia/ benötigt ein neues U-boot)'''<br />
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<br />
<br />
Jetzt nur noch prüfen, ob der neue Menü-Eintrag richtig angezeigt wird.:<br />
<br />
printenv<br />
<br />
Wenn alles passt dann speichern:<br />
<br />
saveenv<br />
<br />
Die neue Konfiguration wird jetzt im NAND gespeichert.<br />
<br />
Herunterfahren des NEO:<br />
<br />
neo1973 power-off<br />
<br />
Nach dem Neustart in das NAND-Boot-Menü gehen und den neu erstellten Menü-Eintrag wählen um von der SD-Karte zu booten.<br />
<br />
----<br />
<br />
Siehe auch unter [[Moving current system from flash to SD]] wo gezeigt wird, wie das System vom Flash auf die SD-Karte verschoben wird.<br />
<br />
----<br />
<br />
== Sonstiges ==<br />
<br />
=== Booten von SDHC ===<br />
<br />
{{Note|Der folgende Abschnitt wurde für das Neo1973 geschrieben. SDHC und SD beide im FreeRunner laufen wenn ein U-boot ab 2008-07-23 verwendet wird.}}<br />
<br />
Das Booten von SDHC-Karten wird von älteren U-Boot-Versionen nicht unterstützt.<br />
Es gibt eine Mögichkeit dies zu umgehen indem man nur das Rootfs auf der SDHC-Karte installiert.<br />
<br />
Folgen sie Schritt 1, um einen Kernel-Image mit MMC-und ext2-Unterstützung zu bekommen. Doch statt das Image auf die Rootfs zu kopieren, kopieren sie es in den internen NAND-Flash.(mit [[DFÜ-util]]).<br />
Jetzt können Sie mit Schritt 2 fortfahren (wie schon erwähnt, nicht das uImage auf die Rootfs kopieren) und den Anweisungen bis zu Schritt 3 folgen.<br />
Anstelle der setenv-Befehle in Schritt 3 führen Sie die folgenden Schritte aus: <br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
Jetzt kann der neue Menü-Eintrag "Boot from SDHC" benutzt werden um den interen kernel zu booten und dabei das Root-Filesystem auf der SDHC-Karte zu laden.<br />
<br />
=== Autoboot von SDHC ===<br />
<br />
Wenn automatisch von der SDHC-Karte gebootet werden soll: <br />
Zuerst einen neue Bootmenü Eintrag für das Booten von NAND erstellen:<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
Danach neustarten und im Bootmenü den neuen Eintrag testen. Wenn dieser funktioniert wieder herrunterfahren, das Bootmenü starten, Bootloader verbinden und das autoboot-Komando zum booten von der SDHC-Karte erstellen:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
Jetzt wird immer von der SDHC-Karte gebootetwenn der Power-Knopf gedrückt oder reboot ausgeführt wird. Wenn vom NAND gebootet werden soll muss das Bootmenü benutzt werden.<br />
<br />
===Hinweise zur Partitionierung===<br />
<br />
U-Boot vor 2008-07-23 kann ausschließlich von FAT-Filesystemen booten. Neuere Versionen unterstützen auch ext2/ext3.<br />
<br />
Weil SD-Karten als mmc-Geräteknoten (unter Major 179, siehe [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Linux Allocated Devices]) eingebunden werden, is folgendes zu beachten:<br />
<br />
* Das [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Numerierungsschema für Geräte] sieht für mmc-Geräte die minor numbers 1 bis 7 (/dev/mmcblk0p1 ... /dev/mmcblk0p7). Minor number 8 ist bereits der nächsten physikalischen SD-Karte (/dev/mmcblk1) vorbehalten. Daher sind maimal 7 Partitionen verfügbar.<br />
<br />
* Die rootfs aktueller Distributionen bringen die Geräteknoten mmcblk0p1 bis mmcblk0p4 schon mit. Um erweiterete Partitions (5 ...) zu verwenden, müssen weitere Knoten angelegt in /lib/udev/devices/ werden:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Weil uboot einen Kernel nur im unteren Bereich (2GB-Grenze) einer SD-Karte lesen kann, empfiehlt es sich alle Kernel in der ersten Partition unterzubringen. Bewährt hat sich auch, dort zentral die PIM-Daten abzulegen, um von allen installierten Distributionen per symlink darauf zuzugreifen.<br />
<br />
Die Kernel können ein rootfs auch von einer erweiterten Partition einbinden.<br />
<br />
=== Udev automount fixen ===<br />
<br />
Udev mountet die SD-Karte automatisch unter /media/mmcblk0p1/ .<br />
Dies kann geändert werden:<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Bemerkung zu Kernel Parametern ===<br />
<br />
==== loglevel ====<br />
<br />
Einige Leute empfehlen folgendes zur KernelBefehlsZeile hinzuzufügen:<br />
<br />
loglevel=8<br />
<br />
Wenn Sie "console=tty0" in der KernelBefehlsZeile aufrufen verlangsamt das den Bootprozess extrem da der Framebuffer (Neo-Display im Text-Modus) unmengen von DebugInformationen schreiben muss. <br />
<br />
{{Languages|Booting_from_SD}}</div>Lokomokohttp://openmoko.org/wiki/Booting_from_SD/deBooting from SD/de2009-01-12T16:03:23Z<p>Lokomoko: /* Partitionieren der SD-Karte */</p>
<hr />
<div>{{Languages}}<br />
Diese Seite beschreibt, wie man mit dem FreeRunner von einer [[Supported_microSD_cards|(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.<br />
<br />
{{Note| Das Booten von SDHC kann derzeit noch zu Problemen führen (siehe unten).}}<br />
<br />
== Booten von SDHC ==<br />
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.<br />
Ticket: [https://docs.openmoko.org/trac/ticket/1802 #1802].<br />
Thread: [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281]<br />
Am Besten legt man sich ein Backup der Partitionstabelle an, um sie im Notfall schnell wieder zur Verfügung zu haben.<br />
<br />
== So funktionierts ==<br />
<br />
[[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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
=== U-Boot-Menü-Einträge ===<br />
<br />
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 "<MenüName>:<Befehle>", wobei <MenüName> der Text ist, der auf dem Display angezeigt wird und <Befehle> eine Abfolge der U-boot-Befehle welche ausgeführt werden, wenn der Menüpunkt auswählt wird. Die einzelnen Befehle werden hierbei durch ';' getrennt.<br />
Beim Eingeben der Befehlsabfolge müssen ';' durch "\;" und '$' durch "\$" ersetzt werden.<br />
<br />
=== Laden des Kernels ===<br />
<br />
Zum Laden des Kernels von der SD-Karte müssen folgende U-Boot-Befehle ausgeführt werden:<br />
Die SD-Karte mit "mmcinit" initialisieren.<br />
Den Kernel in den Arbeitsspeicher laden:<br />
<br />
Kernel befindet sich auf einem FAT-Filesystem:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
Kernel befindet sich auf einem ext2/ext3-Filesystem:<br />
<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
Hierbei entspricht &lt;p&gt; der Partitionsnummer und &lt;filepath&gt; dem Pfad zu dem zu ladendem Kernel.<br />
<br />
{{Note| Der "ext2load"-Befehl funktioniert nicht bei U-boot-Versionen kleiner "20080723". Diese sind vom folgendem Bug betroffen: [http://docs.openmoko.org/trac/ticket/799 #799]<br />
Nach einem Update der U-Boot und Kernel Pakete kann man direkt von ext2/ext3 booten.}}<br />
<br />
{{Warning | Beim U-Boot-Update auf dem NEO1973 ist Vorsicht geboten! Es besteht die Gefahr sich aus dem NEO auszuschließen, wenn man kein Debug-Board zur Verfügung hat. Dies betrifft nicht den Freerunner, da dieser eine Kopie von U-Boot im NOR-Flasch hat!}}<br />
<br />
{{Note| U-Boot unterstützt das SDHC-Protocol nur auf dem FreeRunner: Auf dem Neo1973, ist U-Boot nicht in der Lage mit SDHC-Karten (4G oder größer) zu arbeiten. Der Kernel unterstützt SDHC auf dem NEO1973, dadurch ist es möglich den Kernel auf dem NAND-Flash und das Root-Filesystem auf der SDHC-Karte laufen zu lassen. }}<br />
<br />
=== Root-Filesystem Parameter ===<br />
<br />
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".<br />
<br />
Beispiel: Folgende Parameter veranlassen den Kernel die dritte Partition der SD-Karte zu mounten:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5<br />
<br />
Der "rootdelay"-Parameter gibt der SD-Karte die nötige Zeit um sich zu initialisieren bevor auf sie zugegriffen wird.<br />
<br />
Wichtig ist, daß der Kernel das Root-Filesystem auch unterstützt.<br />
Der Default-Openmoko-Kernel [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] unterstützt ext2 und ext3. Überprüfen kann man die unterstützten Filesysteme mit folgendem Linux-Befehl:<br />
<br />
less /proc/filesystems<br />
<br />
Es ist nicht möglich, VFAT als Root-Filesystem zu benutzen.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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).<br />
<br />
<br />
== Rootfs ==<br />
<br />
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.<br />
<br />
=== Möglichkeit 1: Rootfs.tar und Kernel.tar vom Openmoko buildhost downloaden ===<br />
<br />
Aktuelles Rootfs und Kernel einfach unter [[Latest Images]] downloaden.<br />
<br />
=== Möglichkeit 2: Mit OpenEmbedded selber ein tar-File erstellen ===<br />
<br />
Eine weitere Möglichkeit besteht darin, sich selber mit der OpenEmbedded Umgebung ein Rootfs-tar-Archiv zu erstellen.<br />
<br />
Um OM-2007.2 zu erstellen, muss man "tar" zu den Image-Typen in seiner ''local.conf'' hinzudügen:<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
Jetzt kann man das neue Image erstellen:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
oder mit MokoMakefile:<br />
<br />
make openmoko-devel-image<br />
<br />
Das ''Openmoko-....tar'' findet sich anschließend im Out-Pfad.<br />
<br />
=== Möglichkeit 3 : Ein jff2-Image in ein tar-File konvertieren ===<br />
<br />
Siehe [[Userspace root image]].<br />
<br />
== Vorbereiten der SD-Karte ==<br />
<br />
=== Partitionieren der SD-Karte ===<br />
<br />
Das Beispiel zeigt wie man mit fdisk Partitionen erstellt (siehe auch weitere [[#Hinweise_zur_Partitionierung| Hinweise zum Festlegung von Partition]]).<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
'''''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''.<br />
Jetzt erstellt man eine 8MB Partition für den Kernel und eine Partition mit dem restlichen Speicherplatz für das Root-Filesystem.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
Bei folgender Fehlermeldung:<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
einfach das Gerät aushängen:<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
und anschließend die Partitionstabellen nocheinmal schreiben:<br />
<br />
fdisk /dev/mmcblk0<br />
Command (m for help): w<br />
<br />
=== Formatieren der SD-Karte ===<br />
<br />
Folgender Befehl formatiert die erste Partition der SD-Karte mit dem FAT-Filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
<br />
{{Note| Sollte mkfs.vfat nicht installiert sein, muss das "dosfstools"-Packet nachinstalliert werden. Dieses Paket ist zwar nicht in der offiziellen Software enthalten, kann aber unter http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk heruntergeladen werden.}}<br />
<br />
Die zweite Partition wird mit dem ext3-Filesystem formatiert:<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Bespielen der SD-Karte ==<br />
<br />
Die SD-Karte ist jetzt bereit mit dem Rootfs und dem Kernel bespielt zuwerden.<br />
<br />
Zuerst wird die zweite Patrtition der SD-Karte gemountet und das Rootfs-Image aufgespielt:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
'''''Achtung:''''' Die Pfade und Dateinamen müssen entsprechend angepasst werden.<br />
<br />
Als nächstes wird die erste Partition der SD-Karte gemountet und der Kernel darauf installiert:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Bei einigen Versionen des NOR U-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Ja, kleines i und keine Dateierweiterung.)<br />
<br />
Es ist sicherzustellen, daß der Kernel ''uImage.bin'' (oder ''uimage'' bei einigen Versionen des NOR U-boot) heisst. Sollte U-Boot das Kernel-Image nicht finden: [[Bootloader#Using usbtty from Linux|im Bootloader anmelden]] mit ''[http://www.airs.com/ian/uucp.html cu]''<br />
Die Partition mit mmcinit mounten und prüfen, ob der Kernel vorhanden und richtig benannt ist:<br />
Das geht mit ''fatls mmc 1:1'' bei FAT-Filesystemen oder ''ext2ls mmc 1:1'' bei ext2-Filesystemen.<br />
<br />
Anschließend mit dem Ergebnis von ''printenv sd_image_name'' vergleichen. Es ist zu beachten, daß das die Umgebungsvariable im NAND-Flash aber nicht im NOR-Flash geändert werden kann. Wenn also aus dem NOR-Flash gebootet werden soll muss der Dateiname an die Umgebungsvariable angepasst werden.<br />
<br />
Jetzt beide Partitionen aushängen und sicherstellen, daß alle Buffer geschrieben wurden:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== U-Boot-Menü-Eintrag hinzufügen ==<br />
<br />
Je nach Revision des NEO und des verwendeten Partitionstyps (ext2/ext3) kann es notwendig sein, daß ein dem BootMenü ein Eintraghinzugefügt werden muss, um das System von der SD-Karte booten zu können.<br />
<br />
Beim einem FreeRunner mit einer FAT-Partition (Kernel) und einer ext2-Partition (rootfs) sollte es möglich sein direkt von der SD-Karte zu booten, da der Boot-Menü-Eintrag für bereits im NOR- und NAND-Boot-Menü enthalten ist.<br />
In allen anderen Fällen muss der benötigte Menü-Eintrag erst hinzugefügt werden.<br />
<br />
Eine Beschreibung dazu findet sich hier: [[Bootloader/de#Bootlader_Kommandozeile]]<br />
<br />
Wie man in das Bootmenü gelangt steht hier: [[Getting_Started_with_your_Neo_FreeRunner/de#Anschalten_des_Neo_FreeRunner]].<br />
<br />
Als erstes empfiehlt es sich, das U-Boot-TimeOut(60s) auf einen realistischen Wert zu setzen. Hierzu aus der UBoot-Kommandoeile folgenden Befehl ausführen:<br />
<br />
setenv boot_menu_timeout 99999<br />
<br />
Der TimeOut-Wert wird so auf 99999s gesetzt, was für alle weiteren Vorhaben ausreichen sollte.:-)<br />
<br />
<br />
Jetzt wird geprüft, ob ein geeigneter Menü-Eintrag zum booten von der SD-Karte vorhanden ist:<br />
<br />
printenv<br />
<br />
Wenn eine Zeile existiert, die mit ''menu_'' beginnt und auch die folgende Befehle enthält braucht kein neuer Menü-Eintrag erstellt werden.<br />
<br />
{{Note| Die Backslashs (\) sind wichtig für UBoot um den Befehl als neue Umgebungsvariable (menu_9) einzutragen. Durch einfaches drücken der Enter-Taste würde der Befehl lediglich ausgeführt werden.}}<br />
<br />
{{Note| Kopieren und Einfügen funktioniert bei einigen Emulatoren nicht.<br />
Copy and paste may not work depending on your terminal emulator. Commi funktioniert alternativ kann auch der Terminal-Emulator [[NeoCon|NeoCon]]. Ansonsten muss alles manuell in die Kommandozeile eingetippt werden.}}<br />
<br />
An dieser Stelle ist es wichtig zwischen FAT- und ext2-Kernel und zwischen ext2- und ext3-rootfs zu unterscheiden.<br />
<br />
Möglicherweise müssen die Nummern in root=/dev/mmcblk0p'''#''' (rootfs) und fatload mmc '''#''' oder ext2load mmc '''#''' (Kernel) geändert werden.<br />
<br />
'''Boot-Eintrag für FAT-Kernel mit ext3-Rootfs Partition:'''<br />
<br />
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<br />
<br />
'''Boot-Eintrag für FAT-Kernel mit ext2-Rootfs Partition:'''<br />
<br />
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<br />
<br />
or : with additional 'init=/sbin/init' kernel parameter (may be needed for some images) :<br />
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<br />
<br />
'''Boot-Eintrag für ext2-Kernel mit ext2-Rootfs Partition: (requires newer u-boot)'''<br />
<br />
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<br />
<br />
'''Boot-Eintrag für Kernel und Rootfs auf der gleichen ext2 Partition (getestet mit Qtopia/ benötigt ein neues U-boot)'''<br />
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<br />
<br />
Jetzt nur noch prüfen, ob der neue Menü-Eintrag richtig angezeigt wird.:<br />
<br />
printenv<br />
<br />
Wenn alles passt dann speichern:<br />
<br />
saveenv<br />
<br />
Die neue Konfiguration wird jetzt im NAND gespeichert.<br />
<br />
Herunterfahren des NEO:<br />
<br />
neo1973 power-off<br />
<br />
Nach dem Neustart in das NAND-Boot-Menü gehen und den neu erstellten Menü-Eintrag wählen um von der SD-Karte zu booten.<br />
<br />
----<br />
<br />
Siehe auch unter [[Moving current system from flash to SD]] wo gezeigt wird, wie das System vom Flash auf die SD-Karte verschoben wird.<br />
<br />
----<br />
<br />
== Sonstiges ==<br />
<br />
=== Booten von SDHC ===<br />
<br />
{{Note|Der folgende Abschnitt wurde für das Neo1973 geschrieben. SDHC und SD beide im FreeRunner laufen wenn ein U-boot ab 2008-07-23 verwendet wird.}}<br />
<br />
Das Booten von SDHC-Karten wird von älteren U-Boot-Versionen nicht unterstützt.<br />
Es gibt eine Mögichkeit dies zu umgehen indem man nur das Rootfs auf der SDHC-Karte installiert.<br />
<br />
Folgen sie Schritt 1, um einen Kernel-Image mit MMC-und ext2-Unterstützung zu bekommen. Doch statt das Image auf die Rootfs zu kopieren, kopieren sie es in den internen NAND-Flash.(mit [[DFÜ-util]]).<br />
Jetzt können Sie mit Schritt 2 fortfahren (wie schon erwähnt, nicht das uImage auf die Rootfs kopieren) und den Anweisungen bis zu Schritt 3 folgen.<br />
Anstelle der setenv-Befehle in Schritt 3 führen Sie die folgenden Schritte aus: <br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
Jetzt kann der neue Menü-Eintrag "Boot from SDHC" benutzt werden um den interen kernel zu booten und dabei das Root-Filesystem auf der SDHC-Karte zu laden.<br />
<br />
=== Autoboot von SDHC ===<br />
<br />
Wenn automatisch von der SDHC-Karte gebootet werden soll: <br />
Zuerst einen neue Bootmenü Eintrag für das Booten von NAND erstellen:<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
Danach neustarten und im Bootmenü den neuen Eintrag testen. Wenn dieser funktioniert wieder herrunterfahren, das Bootmenü starten, Bootloader verbinden und das autoboot-Komando zum booten von der SDHC-Karte erstellen:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
Jetzt wird immer von der SDHC-Karte gebootetwenn der Power-Knopf gedrückt oder reboot ausgeführt wird. Wenn vom NAND gebootet werden soll muss das Bootmenü benutzt werden.<br />
<br />
===Hinweise zur Partitionierung===<br />
<br />
Weil SD-Karten als mmc-Geräteknoten (unter Major 179, siehe [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Linux Allocated Devices]) eingebunden werden, gibt es einiges zu beachten:<br />
<br />
* Das [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Numerierungsschema für Geräte] sieht für mmc-Geräte die minor numbers 1 bis 7 (/dev/mmcblk0p1 ... /dev/mmcblk0p7). Minor number 8 ist bereits der nächsten physikalischen SD-Karte (/dev/mmcblk1) vorbehalten. Daher sind maimal 7 Partitionen verfügbar.<br />
<br />
* Die rootfs aktueller Distributionen bringen die Geräteknoten mmcblk0p1 bis mmcblk0p4 schon mit. Um erweiterete Partitions (5 ...) zu verwenden, müssen weitere Knoten angelegt in /lib/udev/devices/ werden:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Weil uboot einen Kernel nur im unteren Bereich (2GB-Grenze) einer SD-Karte lesen kann, empfiehlt es sich alle Kernel in der ersten Partition unterzubringen. Bewährt hat sich auch, dort zentral die PIM-Daten abzulegen, um von allen installierten Distributionen per symlink darauf zuzugreifen.<br />
<br />
Die Kernel können ein rootfs auch von einer erweiterten Partition einbinden.<br />
<br />
=== Udev automount fixen ===<br />
<br />
Udev mountet die SD-Karte automatisch unter /media/mmcblk0p1/ .<br />
Dies kann geändert werden:<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Bemerkung zu Kernel Parametern ===<br />
<br />
==== loglevel ====<br />
<br />
Einige Leute empfehlen folgendes zur KernelBefehlsZeile hinzuzufügen:<br />
<br />
loglevel=8<br />
<br />
Wenn Sie "console=tty0" in der KernelBefehlsZeile aufrufen verlangsamt das den Bootprozess extrem da der Framebuffer (Neo-Display im Text-Modus) unmengen von DebugInformationen schreiben muss. <br />
<br />
{{Languages|Booting_from_SD}}</div>Lokomokohttp://openmoko.org/wiki/Booting_from_SD/deBooting from SD/de2009-01-12T15:54:05Z<p>Lokomoko: /* Autoboot von SDHC */</p>
<hr />
<div>{{Languages}}<br />
Diese Seite beschreibt, wie man mit dem FreeRunner von einer [[Supported_microSD_cards|(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.<br />
<br />
{{Note| Das Booten von SDHC kann derzeit noch zu Problemen führen (siehe unten).}}<br />
<br />
== Booten von SDHC ==<br />
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.<br />
Ticket: [https://docs.openmoko.org/trac/ticket/1802 #1802].<br />
Thread: [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281]<br />
Am Besten legt man sich ein Backup der Partitionstabelle an, um sie im Notfall schnell wieder zur Verfügung zu haben.<br />
<br />
== So funktionierts ==<br />
<br />
[[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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
=== U-Boot-Menü-Einträge ===<br />
<br />
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 "<MenüName>:<Befehle>", wobei <MenüName> der Text ist, der auf dem Display angezeigt wird und <Befehle> eine Abfolge der U-boot-Befehle welche ausgeführt werden, wenn der Menüpunkt auswählt wird. Die einzelnen Befehle werden hierbei durch ';' getrennt.<br />
Beim Eingeben der Befehlsabfolge müssen ';' durch "\;" und '$' durch "\$" ersetzt werden.<br />
<br />
=== Laden des Kernels ===<br />
<br />
Zum Laden des Kernels von der SD-Karte müssen folgende U-Boot-Befehle ausgeführt werden:<br />
Die SD-Karte mit "mmcinit" initialisieren.<br />
Den Kernel in den Arbeitsspeicher laden:<br />
<br />
Kernel befindet sich auf einem FAT-Filesystem:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
Kernel befindet sich auf einem ext2/ext3-Filesystem:<br />
<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
Hierbei entspricht &lt;p&gt; der Partitionsnummer und &lt;filepath&gt; dem Pfad zu dem zu ladendem Kernel.<br />
<br />
{{Note| Der "ext2load"-Befehl funktioniert nicht bei U-boot-Versionen kleiner "20080723". Diese sind vom folgendem Bug betroffen: [http://docs.openmoko.org/trac/ticket/799 #799]<br />
Nach einem Update der U-Boot und Kernel Pakete kann man direkt von ext2/ext3 booten.}}<br />
<br />
{{Warning | Beim U-Boot-Update auf dem NEO1973 ist Vorsicht geboten! Es besteht die Gefahr sich aus dem NEO auszuschließen, wenn man kein Debug-Board zur Verfügung hat. Dies betrifft nicht den Freerunner, da dieser eine Kopie von U-Boot im NOR-Flasch hat!}}<br />
<br />
{{Note| U-Boot unterstützt das SDHC-Protocol nur auf dem FreeRunner: Auf dem Neo1973, ist U-Boot nicht in der Lage mit SDHC-Karten (4G oder größer) zu arbeiten. Der Kernel unterstützt SDHC auf dem NEO1973, dadurch ist es möglich den Kernel auf dem NAND-Flash und das Root-Filesystem auf der SDHC-Karte laufen zu lassen. }}<br />
<br />
=== Root-Filesystem Parameter ===<br />
<br />
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".<br />
<br />
Beispiel: Folgende Parameter veranlassen den Kernel die dritte Partition der SD-Karte zu mounten:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5<br />
<br />
Der "rootdelay"-Parameter gibt der SD-Karte die nötige Zeit um sich zu initialisieren bevor auf sie zugegriffen wird.<br />
<br />
Wichtig ist, daß der Kernel das Root-Filesystem auch unterstützt.<br />
Der Default-Openmoko-Kernel [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] unterstützt ext2 und ext3. Überprüfen kann man die unterstützten Filesysteme mit folgendem Linux-Befehl:<br />
<br />
less /proc/filesystems<br />
<br />
Es ist nicht möglich, VFAT als Root-Filesystem zu benutzen.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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).<br />
<br />
<br />
== Rootfs ==<br />
<br />
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.<br />
<br />
=== Möglichkeit 1: Rootfs.tar und Kernel.tar vom Openmoko buildhost downloaden ===<br />
<br />
Aktuelles Rootfs und Kernel einfach unter [[Latest Images]] downloaden.<br />
<br />
=== Möglichkeit 2: Mit OpenEmbedded selber ein tar-File erstellen ===<br />
<br />
Eine weitere Möglichkeit besteht darin, sich selber mit der OpenEmbedded Umgebung ein Rootfs-tar-Archiv zu erstellen.<br />
<br />
Um OM-2007.2 zu erstellen, muss man "tar" zu den Image-Typen in seiner ''local.conf'' hinzudügen:<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
Jetzt kann man das neue Image erstellen:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
oder mit MokoMakefile:<br />
<br />
make openmoko-devel-image<br />
<br />
Das ''Openmoko-....tar'' findet sich anschließend im Out-Pfad.<br />
<br />
=== Möglichkeit 3 : Ein jff2-Image in ein tar-File konvertieren ===<br />
<br />
Siehe [[Userspace root image]].<br />
<br />
== Vorbereiten der SD-Karte ==<br />
<br />
=== Partitionieren der SD-Karte ===<br />
<br />
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.<br />
Dieses Beispiel zeigt wie man mit fdisk Partitionen erstellt.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
'''''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''.<br />
Jetzt erstellt man eine 8MB Partition für den Kernel und eine Partition mit dem restlichen Speicherplatz für das Root-Filesystem.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
Bei folgender Fehlermeldung:<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
einfach das Gerät aushängen:<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
und anschließend die Partitionstabellen nocheinmal schreiben:<br />
<br />
fdisk /dev/mmcblk0<br />
Command (m for help): w<br />
<br />
=== Formatieren der SD-Karte ===<br />
<br />
Folgender Befehl formatiert die erste Partition der SD-Karte mit dem FAT-Filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
<br />
{{Note| Sollte mkfs.vfat nicht installiert sein, muss das "dosfstools"-Packet nachinstalliert werden. Dieses Paket ist zwar nicht in der offiziellen Software enthalten, kann aber unter http://members.shaw.ca/mmontour/neo/dosfstools_2.11-r0_armv4t.ipk heruntergeladen werden.}}<br />
<br />
Die zweite Partition wird mit dem ext3-Filesystem formatiert:<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Bespielen der SD-Karte ==<br />
<br />
Die SD-Karte ist jetzt bereit mit dem Rootfs und dem Kernel bespielt zuwerden.<br />
<br />
Zuerst wird die zweite Patrtition der SD-Karte gemountet und das Rootfs-Image aufgespielt:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
'''''Achtung:''''' Die Pfade und Dateinamen müssen entsprechend angepasst werden.<br />
<br />
Als nächstes wird die erste Partition der SD-Karte gemountet und der Kernel darauf installiert:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Bei einigen Versionen des NOR U-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Ja, kleines i und keine Dateierweiterung.)<br />
<br />
Es ist sicherzustellen, daß der Kernel ''uImage.bin'' (oder ''uimage'' bei einigen Versionen des NOR U-boot) heisst. Sollte U-Boot das Kernel-Image nicht finden: [[Bootloader#Using usbtty from Linux|im Bootloader anmelden]] mit ''[http://www.airs.com/ian/uucp.html cu]''<br />
Die Partition mit mmcinit mounten und prüfen, ob der Kernel vorhanden und richtig benannt ist:<br />
Das geht mit ''fatls mmc 1:1'' bei FAT-Filesystemen oder ''ext2ls mmc 1:1'' bei ext2-Filesystemen.<br />
<br />
Anschließend mit dem Ergebnis von ''printenv sd_image_name'' vergleichen. Es ist zu beachten, daß das die Umgebungsvariable im NAND-Flash aber nicht im NOR-Flash geändert werden kann. Wenn also aus dem NOR-Flash gebootet werden soll muss der Dateiname an die Umgebungsvariable angepasst werden.<br />
<br />
Jetzt beide Partitionen aushängen und sicherstellen, daß alle Buffer geschrieben wurden:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== U-Boot-Menü-Eintrag hinzufügen ==<br />
<br />
Je nach Revision des NEO und des verwendeten Partitionstyps (ext2/ext3) kann es notwendig sein, daß ein dem BootMenü ein Eintraghinzugefügt werden muss, um das System von der SD-Karte booten zu können.<br />
<br />
Beim einem FreeRunner mit einer FAT-Partition (Kernel) und einer ext2-Partition (rootfs) sollte es möglich sein direkt von der SD-Karte zu booten, da der Boot-Menü-Eintrag für bereits im NOR- und NAND-Boot-Menü enthalten ist.<br />
In allen anderen Fällen muss der benötigte Menü-Eintrag erst hinzugefügt werden.<br />
<br />
Eine Beschreibung dazu findet sich hier: [[Bootloader/de#Bootlader_Kommandozeile]]<br />
<br />
Wie man in das Bootmenü gelangt steht hier: [[Getting_Started_with_your_Neo_FreeRunner/de#Anschalten_des_Neo_FreeRunner]].<br />
<br />
Als erstes empfiehlt es sich, das U-Boot-TimeOut(60s) auf einen realistischen Wert zu setzen. Hierzu aus der UBoot-Kommandoeile folgenden Befehl ausführen:<br />
<br />
setenv boot_menu_timeout 99999<br />
<br />
Der TimeOut-Wert wird so auf 99999s gesetzt, was für alle weiteren Vorhaben ausreichen sollte.:-)<br />
<br />
<br />
Jetzt wird geprüft, ob ein geeigneter Menü-Eintrag zum booten von der SD-Karte vorhanden ist:<br />
<br />
printenv<br />
<br />
Wenn eine Zeile existiert, die mit ''menu_'' beginnt und auch die folgende Befehle enthält braucht kein neuer Menü-Eintrag erstellt werden.<br />
<br />
{{Note| Die Backslashs (\) sind wichtig für UBoot um den Befehl als neue Umgebungsvariable (menu_9) einzutragen. Durch einfaches drücken der Enter-Taste würde der Befehl lediglich ausgeführt werden.}}<br />
<br />
{{Note| Kopieren und Einfügen funktioniert bei einigen Emulatoren nicht.<br />
Copy and paste may not work depending on your terminal emulator. Commi funktioniert alternativ kann auch der Terminal-Emulator [[NeoCon|NeoCon]]. Ansonsten muss alles manuell in die Kommandozeile eingetippt werden.}}<br />
<br />
An dieser Stelle ist es wichtig zwischen FAT- und ext2-Kernel und zwischen ext2- und ext3-rootfs zu unterscheiden.<br />
<br />
Möglicherweise müssen die Nummern in root=/dev/mmcblk0p'''#''' (rootfs) und fatload mmc '''#''' oder ext2load mmc '''#''' (Kernel) geändert werden.<br />
<br />
'''Boot-Eintrag für FAT-Kernel mit ext3-Rootfs Partition:'''<br />
<br />
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<br />
<br />
'''Boot-Eintrag für FAT-Kernel mit ext2-Rootfs Partition:'''<br />
<br />
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<br />
<br />
or : with additional 'init=/sbin/init' kernel parameter (may be needed for some images) :<br />
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<br />
<br />
'''Boot-Eintrag für ext2-Kernel mit ext2-Rootfs Partition: (requires newer u-boot)'''<br />
<br />
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<br />
<br />
'''Boot-Eintrag für Kernel und Rootfs auf der gleichen ext2 Partition (getestet mit Qtopia/ benötigt ein neues U-boot)'''<br />
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<br />
<br />
Jetzt nur noch prüfen, ob der neue Menü-Eintrag richtig angezeigt wird.:<br />
<br />
printenv<br />
<br />
Wenn alles passt dann speichern:<br />
<br />
saveenv<br />
<br />
Die neue Konfiguration wird jetzt im NAND gespeichert.<br />
<br />
Herunterfahren des NEO:<br />
<br />
neo1973 power-off<br />
<br />
Nach dem Neustart in das NAND-Boot-Menü gehen und den neu erstellten Menü-Eintrag wählen um von der SD-Karte zu booten.<br />
<br />
----<br />
<br />
Siehe auch unter [[Moving current system from flash to SD]] wo gezeigt wird, wie das System vom Flash auf die SD-Karte verschoben wird.<br />
<br />
----<br />
<br />
== Sonstiges ==<br />
<br />
=== Booten von SDHC ===<br />
<br />
{{Note|Der folgende Abschnitt wurde für das Neo1973 geschrieben. SDHC und SD beide im FreeRunner laufen wenn ein U-boot ab 2008-07-23 verwendet wird.}}<br />
<br />
Das Booten von SDHC-Karten wird von älteren U-Boot-Versionen nicht unterstützt.<br />
Es gibt eine Mögichkeit dies zu umgehen indem man nur das Rootfs auf der SDHC-Karte installiert.<br />
<br />
Folgen sie Schritt 1, um einen Kernel-Image mit MMC-und ext2-Unterstützung zu bekommen. Doch statt das Image auf die Rootfs zu kopieren, kopieren sie es in den internen NAND-Flash.(mit [[DFÜ-util]]).<br />
Jetzt können Sie mit Schritt 2 fortfahren (wie schon erwähnt, nicht das uImage auf die Rootfs kopieren) und den Anweisungen bis zu Schritt 3 folgen.<br />
Anstelle der setenv-Befehle in Schritt 3 führen Sie die folgenden Schritte aus: <br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
Jetzt kann der neue Menü-Eintrag "Boot from SDHC" benutzt werden um den interen kernel zu booten und dabei das Root-Filesystem auf der SDHC-Karte zu laden.<br />
<br />
=== Autoboot von SDHC ===<br />
<br />
Wenn automatisch von der SDHC-Karte gebootet werden soll: <br />
Zuerst einen neue Bootmenü Eintrag für das Booten von NAND erstellen:<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
Danach neustarten und im Bootmenü den neuen Eintrag testen. Wenn dieser funktioniert wieder herrunterfahren, das Bootmenü starten, Bootloader verbinden und das autoboot-Komando zum booten von der SDHC-Karte erstellen:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
Jetzt wird immer von der SDHC-Karte gebootetwenn der Power-Knopf gedrückt oder reboot ausgeführt wird. Wenn vom NAND gebootet werden soll muss das Bootmenü benutzt werden.<br />
<br />
===Hinweise zur Partitionierung===<br />
<br />
Weil SD-Karten als mmc-Geräteknoten (unter Major 179, siehe [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Linux Allocated Devices]) eingebunden werden, gibt es einiges zu beachten:<br />
<br />
* Das [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Numerierungsschema für Geräte] sieht für mmc-Geräte die minor numbers 1 bis 7 (/dev/mmcblk0p1 ... /dev/mmcblk0p7). Minor number 8 ist bereits der nächsten physikalischen SD-Karte (/dev/mmcblk1) vorbehalten. Daher sind maimal 7 Partitionen verfügbar.<br />
<br />
* Die rootfs aktueller Distributionen bringen die Geräteknoten mmcblk0p1 bis mmcblk0p4 schon mit. Um erweiterete Partitions (5 ...) zu verwenden, müssen weitere Knoten angelegt in /lib/udev/devices/ werden:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Weil uboot einen Kernel nur im unteren Bereich (2GB-Grenze) einer SD-Karte lesen kann, empfiehlt es sich alle Kernel in der ersten Partition unterzubringen. Bewährt hat sich auch, dort zentral die PIM-Daten abzulegen, um von allen installierten Distributionen per symlink darauf zuzugreifen.<br />
<br />
Die Kernel können ein rootfs auch von einer erweiterten Partition einbinden.<br />
<br />
=== Udev automount fixen ===<br />
<br />
Udev mountet die SD-Karte automatisch unter /media/mmcblk0p1/ .<br />
Dies kann geändert werden:<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Bemerkung zu Kernel Parametern ===<br />
<br />
==== loglevel ====<br />
<br />
Einige Leute empfehlen folgendes zur KernelBefehlsZeile hinzuzufügen:<br />
<br />
loglevel=8<br />
<br />
Wenn Sie "console=tty0" in der KernelBefehlsZeile aufrufen verlangsamt das den Bootprozess extrem da der Framebuffer (Neo-Display im Text-Modus) unmengen von DebugInformationen schreiben muss. <br />
<br />
{{Languages|Booting_from_SD}}</div>Lokomokohttp://openmoko.org/wiki/Booting_the_Neo_FreeRunner_from_SD_via_U-BootBooting the Neo FreeRunner from SD via U-Boot2009-01-12T14:18:39Z<p>Lokomoko: /* Partitioning Limitations */</p>
<hr />
<div>{{Languages|Booting from SD}}<br />
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.<br />
<br />
{{Warning | Booting from SDHC may cause problems at this time (see below).}} <br />
<br />
== Booting from SDHC / suspend problems ==<br />
<br />
First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| 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.<br />
<br />
== How it Works ==<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
The following sections provide additional details.<br />
<br />
=== Menu Entries ===<br />
<br />
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 "\$"). <br />
<br />
=== Loading the Kernel ===<br />
<br />
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.<br />
<br />
The command syntax is:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
where &lt;p&gt; is the partition number, and &lt;filepath&gt; is the path to the file that is to be loaded.<br />
<br />
{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}<br />
<br />
{{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 }}<br />
<br />
{{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. }}<br />
<br />
=== Root Filesystem Parameters ===<br />
<br />
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". <br />
<br />
For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5 <br />
<br />
The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed. <br />
<br />
Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command<br />
<br />
less /proc/filesystems<br />
<br />
It is not possible to use VFAT for the root filesystem.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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.<br />
<br />
<br />
== Acquiring a tarfile rootfs ==<br />
<br />
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 [http://downloads.openmoko.org downloads].<br />
<br />
<br />
=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===<br />
<br />
Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].<br />
<br />
=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===<br />
<br />
Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.<br />
<br />
To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
After that build a new image by issuing:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
or if you are using the MokoMakefile: <br />
<br />
make openmoko-devel-image<br />
<br />
After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive<br />
<br />
=== Possibility 3 : Convert a jff2 image to a tarfile ===<br />
<br />
See [[Userspace root image]] for more details on how to access contents of a jffs2 image.<br />
<br />
== Prepare the SD card ==<br />
<br />
=== Partioning the SD card ===<br />
<br />
u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.<br />
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_Limitations|Partitioning Limitations]] before designing you partition layout.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
''Should probably need to change type of first partition to FAT 16 too ?''<br />
<br />
''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''<br />
<br />
''How about a swap partition also?''<br />
<br />
if it exits with something like<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
do<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
on another shell and try again.<br />
<br />
=== Formatting the SD card ===<br />
<br />
Just issue the following command to create at FAT filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
{{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 />
<br />
<br />
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):<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Populate SD card ==<br />
<br />
Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.<br />
<br />
Mount the second partition of your SD card somewhere and put the image on it:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
Or directly from the host via USB network:<br />
<br />
cat openmoko-image-*.tar.gz |ssh root@192.168.0.202 "tar -C /mnt/moko/ -xzf -"<br />
<br />
'''''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<br />
<br />
'''''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.<br />
<br />
The next step is to mount the first partition of the sd card and install the kernel on it.<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Or, for some versions of NOR u-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Yes, lower case i and no extension.)<br />
<br />
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.<br />
<br />
Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== Add uboot boot entry ==<br />
*See also" [[Qi]]<br />
<br />
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.<br />
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.<br />
In any other case you should at least make sure the needed entry exists in your menu before proceeding.<br />
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]].<br />
<br />
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:<br />
<br />
<pre><br />
setenv boot_menu_timeout 99999<br />
</pre><br />
<br />
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.<br />
<br />
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:<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
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.<br />
<br />
Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see<br />
* help<br />
* help <command><br />
* and [[Bootloader]] and [[Bootloader commands]].<br />
<br />
{{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.}}<br />
<br />
{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}<br />
<br />
It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.<br />
<br />
Please watch partition numbers in the following commands. In particular, you may need to change some of<br />
<pre><br />
root=/dev/mmcblk0p#<br />
fatload mmc#<br />
ext2load mmc#<br />
</pre><br />
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.<br />
<br />
'''Boot entry for FAT kernel+ext3 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for FAT kernel+ext2 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):<br />
<br />
<pre><br />
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
You are nearly done. Just issue a<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).<br />
<br />
If everything looks fine enter<br />
<br />
<pre><br />
saveenv<br />
</pre><br />
<br />
into the prompt and press enter. The new configuration should now be saved to the NAND.<br />
<br />
Shutdown your neo with the following command:<br />
<br />
<pre><br />
neo1973 power-off<br />
</pre><br />
<br />
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.<br />
<br />
<br />
If you got error when loading kernel, add sleep to boot entry.<br />
<br />
Before:<br />
<pre><br />
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
After:<br />
<pre><br />
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
<br />
----<br />
<br />
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.<br />
<br />
----<br />
<br />
== Appendix ==<br />
<br />
=== Boot from SDHC ===<br />
<br />
{{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.}}<br />
<br />
As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.<br />
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:<br />
<br />
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]]).<br />
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.<br />
Instead of the setenv commands in Step 3 you have to enter the following:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
And that's it!<br />
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.<br />
<br />
=== Autoboot from SDHC ===<br />
<br />
Maybe you want to Boot automatically from SDHC: <br />
Set a new Bootmenu Entry for booting from NAND first<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
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:<br />
<br />
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 <br />
GTA01Bv4 # saveenv<br />
<br />
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.<br />
<br />
<br />
=== Fixing udev automount ===<br />
<br />
Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Partitioning Limitations ===<br />
<br />
Since SD-cards are accessed as mmc device nodes (Major 179 of [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Linux Allocated Devices]) there are some things you should be aware of:<br />
<br />
* [http://www.lanana.org/docs/device-list/devices-2.6+.txt|mmc 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.<br />
<br />
* 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/:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Booting a rootfs from an extended partition with uboot has been tested successfully.<br />
<br />
=== Remarks on Kernel Parameters ===<br />
<br />
==== loglevel ====<br />
<br />
Some people suggested adding:<br />
<br />
loglevel=8<br />
<br />
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:<br />
<br />
s3c2410-sdi s3c2410-sdi: ......<br />
mmc0: ....<br />
<br />
{{Languages|Booting_from_SD}}<br />
<br />
[[Category:Advanced End User]]<br />
[[Category:Flashing Openmoko]]<br />
[[Category:System Developers]]</div>Lokomokohttp://openmoko.org/wiki/Booting_the_Neo_FreeRunner_from_SD_via_U-BootBooting the Neo FreeRunner from SD via U-Boot2009-01-12T13:51:37Z<p>Lokomoko: /* Partioning the SD card */</p>
<hr />
<div>{{Languages|Booting from SD}}<br />
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.<br />
<br />
{{Warning | Booting from SDHC may cause problems at this time (see below).}} <br />
<br />
== Booting from SDHC / suspend problems ==<br />
<br />
First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| 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.<br />
<br />
== How it Works ==<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
The following sections provide additional details.<br />
<br />
=== Menu Entries ===<br />
<br />
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 "\$"). <br />
<br />
=== Loading the Kernel ===<br />
<br />
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.<br />
<br />
The command syntax is:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
where &lt;p&gt; is the partition number, and &lt;filepath&gt; is the path to the file that is to be loaded.<br />
<br />
{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}<br />
<br />
{{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 }}<br />
<br />
{{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. }}<br />
<br />
=== Root Filesystem Parameters ===<br />
<br />
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". <br />
<br />
For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5 <br />
<br />
The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed. <br />
<br />
Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command<br />
<br />
less /proc/filesystems<br />
<br />
It is not possible to use VFAT for the root filesystem.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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.<br />
<br />
<br />
== Acquiring a tarfile rootfs ==<br />
<br />
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 [http://downloads.openmoko.org downloads].<br />
<br />
<br />
=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===<br />
<br />
Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].<br />
<br />
=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===<br />
<br />
Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.<br />
<br />
To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
After that build a new image by issuing:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
or if you are using the MokoMakefile: <br />
<br />
make openmoko-devel-image<br />
<br />
After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive<br />
<br />
=== Possibility 3 : Convert a jff2 image to a tarfile ===<br />
<br />
See [[Userspace root image]] for more details on how to access contents of a jffs2 image.<br />
<br />
== Prepare the SD card ==<br />
<br />
=== Partioning the SD card ===<br />
<br />
u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.<br />
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_Limitations|Partitioning Limitations]] before designing you partition layout.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
{{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.}}<br />
<br />
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.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
''Should probably need to change type of first partition to FAT 16 too ?''<br />
<br />
''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''<br />
<br />
''How about a swap partition also?''<br />
<br />
if it exits with something like<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
do<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
on another shell and try again.<br />
<br />
=== Formatting the SD card ===<br />
<br />
Just issue the following command to create at FAT filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
{{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 />
<br />
<br />
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):<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Populate SD card ==<br />
<br />
Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.<br />
<br />
Mount the second partition of your SD card somewhere and put the image on it:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
Or directly from the host via USB network:<br />
<br />
cat openmoko-image-*.tar.gz |ssh root@192.168.0.202 "tar -C /mnt/moko/ -xzf -"<br />
<br />
'''''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<br />
<br />
'''''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.<br />
<br />
The next step is to mount the first partition of the sd card and install the kernel on it.<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Or, for some versions of NOR u-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Yes, lower case i and no extension.)<br />
<br />
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.<br />
<br />
Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== Add uboot boot entry ==<br />
*See also" [[Qi]]<br />
<br />
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.<br />
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.<br />
In any other case you should at least make sure the needed entry exists in your menu before proceeding.<br />
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]].<br />
<br />
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:<br />
<br />
<pre><br />
setenv boot_menu_timeout 99999<br />
</pre><br />
<br />
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.<br />
<br />
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:<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
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.<br />
<br />
Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see<br />
* help<br />
* help <command><br />
* and [[Bootloader]] and [[Bootloader commands]].<br />
<br />
{{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.}}<br />
<br />
{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}<br />
<br />
It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.<br />
<br />
Please watch partition numbers in the following commands. In particular, you may need to change some of<br />
<pre><br />
root=/dev/mmcblk0p#<br />
fatload mmc#<br />
ext2load mmc#<br />
</pre><br />
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.<br />
<br />
'''Boot entry for FAT kernel+ext3 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for FAT kernel+ext2 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):<br />
<br />
<pre><br />
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
You are nearly done. Just issue a<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).<br />
<br />
If everything looks fine enter<br />
<br />
<pre><br />
saveenv<br />
</pre><br />
<br />
into the prompt and press enter. The new configuration should now be saved to the NAND.<br />
<br />
Shutdown your neo with the following command:<br />
<br />
<pre><br />
neo1973 power-off<br />
</pre><br />
<br />
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.<br />
<br />
<br />
If you got error when loading kernel, add sleep to boot entry.<br />
<br />
Before:<br />
<pre><br />
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
After:<br />
<pre><br />
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
<br />
----<br />
<br />
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.<br />
<br />
----<br />
<br />
== Appendix ==<br />
<br />
=== Boot from SDHC ===<br />
<br />
{{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.}}<br />
<br />
As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.<br />
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:<br />
<br />
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]]).<br />
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.<br />
Instead of the setenv commands in Step 3 you have to enter the following:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
And that's it!<br />
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.<br />
<br />
=== Autoboot from SDHC ===<br />
<br />
Maybe you want to Boot automatically from SDHC: <br />
Set a new Bootmenu Entry for booting from NAND first<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
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:<br />
<br />
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 <br />
GTA01Bv4 # saveenv<br />
<br />
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.<br />
<br />
<br />
=== Fixing udev automount ===<br />
<br />
Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Partitioning Limitations ===<br />
<br />
Since SD-Cards are accessed via mmc device nodes (Major 179 of [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Linux Allocated Devices]) there are some things you should be aware of:<br />
<br />
* [http://www.lanana.org/docs/device-list/devices-2.6+.txt|mmc device nodes numbering schema] provides minor numbers from 1 to 7 (/dev/mmcblk0p1 ... /dev/mmcblk0p7). Minor number 8 is the next raw device (/dev/mmcblk1). So we're restricted to a maximum of 7 accessible partitions.<br />
<br />
* 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/:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Booting a rootfs from an extended partition with uboot has been tested successfully.<br />
<br />
=== Remarks on Kernel Parameters ===<br />
<br />
==== loglevel ====<br />
<br />
Some people suggested adding:<br />
<br />
loglevel=8<br />
<br />
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:<br />
<br />
s3c2410-sdi s3c2410-sdi: ......<br />
mmc0: ....<br />
<br />
{{Languages|Booting_from_SD}}<br />
<br />
[[Category:Advanced End User]]<br />
[[Category:Flashing Openmoko]]<br />
[[Category:System Developers]]</div>Lokomokohttp://openmoko.org/wiki/Booting_the_Neo_FreeRunner_from_SD_via_U-BootBooting the Neo FreeRunner from SD via U-Boot2009-01-12T13:43:12Z<p>Lokomoko: /* Remarks on Kernel Parameters */</p>
<hr />
<div>{{Languages|Booting from SD}}<br />
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.<br />
<br />
{{Warning | Booting from SDHC may cause problems at this time (see below).}} <br />
<br />
== Booting from SDHC / suspend problems ==<br />
<br />
First, a warning. There is a longstanding bug, probably somewhere in the Linux kernel, that tends to eat the partition table of high-capacity SD cards when the system suspends. This is ticket [https://docs.openmoko.org/trac/ticket/1802 #1802]. See [http://thread.gmane.org/gmane.comp.handhelds.openmoko.community/19154/focus=19281| 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.<br />
<br />
== How it Works ==<br />
<br />
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.<br />
<br />
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).<br />
<br />
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.<br />
<br />
The following sections provide additional details.<br />
<br />
=== Menu Entries ===<br />
<br />
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 "\$"). <br />
<br />
=== Loading the Kernel ===<br />
<br />
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.<br />
<br />
The command syntax is:<br />
<br />
fatload mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
ext2load mmc 1:&lt;p&gt; 0x32000000 &lt;filepath&gt;<br />
<br />
where &lt;p&gt; is the partition number, and &lt;filepath&gt; is the path to the file that is to be loaded.<br />
<br />
{{Note| The "ext2load" command is broken on u-boot binary earlier than "20080723", including the one shipped with the first batch of FreeRunners, are affected by bug [http://docs.openmoko.org/trac/ticket/799 #799]. If you update your U-Boot and kernel packages you can use direct ext2 / 3 boot all in one partition.}}<br />
<br />
{{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 }}<br />
<br />
{{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. }}<br />
<br />
=== Root Filesystem Parameters ===<br />
<br />
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". <br />
<br />
For example, the following parameters would tell the kernel to mount the third partition of the SD-card as an ext3 filesystem:<br />
<br />
root=/dev/mmcblk0p3 rootfstype=ext3 rootdelay=5 <br />
<br />
The "rootdelay" parameter allows time for the card to be properly initialized before it is accessed. <br />
<br />
Note that the kernel must have built-in support (i.e. not a module) for the filesystem specified in "rootfstype". The default Openmoko kernel configs as of [http://git.openmoko.org/?p=kernel.git;a=commit;h=642cbda5f3b7e7a61512426e1d30a41ab4691123| 2008-07-17] have built-in support for both ext2 and ext3. You can check the available filesystems with the Linux command<br />
<br />
less /proc/filesystems<br />
<br />
It is not possible to use VFAT for the root filesystem.<br />
<br />
==== ext2 vs. ext3 ====<br />
<br />
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.<br />
<br />
<br />
== Acquiring a tarfile rootfs ==<br />
<br />
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 [http://downloads.openmoko.org downloads].<br />
<br />
<br />
=== Possibility 1: Downloading the rootfs/kernel tar from the Openmoko buildhost ===<br />
<br />
Choose and find the rootfs/kernel combo you would like to install at [[Latest Images]].<br />
<br />
=== Possibility 2: Building a tarfile distribution using OpenEmbedded ===<br />
<br />
Another possibility to get a tar archive of your rootfs is to build it on your own with the OpenEmbedded environment.<br />
<br />
To build OM-2007.2 you need to add "tar" to the image types in your ''local.conf'':<br />
<br />
IMAGE_FSTYPES = "jffs2 tar"<br />
<br />
After that build a new image by issuing:<br />
<br />
bitbake openmoko-devel-image<br />
<br />
or if you are using the MokoMakefile: <br />
<br />
make openmoko-devel-image<br />
<br />
After the process finished there will be a ''Openmoko-....tar'' in the deploy directory, which is your newly created rootfs archive<br />
<br />
=== Possibility 3 : Convert a jff2 image to a tarfile ===<br />
<br />
See [[Userspace root image]] for more details on how to access contents of a jffs2 image.<br />
<br />
== Prepare the SD card ==<br />
<br />
=== Partioning the SD card ===<br />
<br />
u-boot pre-2008-07-23 can only boot from FAT filesystems; if you update u-boot, you can boot from FAT or ext2.<br />
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.<br />
<br />
fdisk /dev/mmcblk0<br />
<br />
'''''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.<br />
<br />
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.<br />
<br />
Command (m for help): d<br />
Selected partition 1<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 1<br />
First cylinder (1-983, default 1):<br />
Using default value 1<br />
Last cylinder or +size or +sizeM or +sizeK (1-983, default 983): +8M<br />
Command (m for help): n<br />
Command action<br />
e extended<br />
p primary partition (1-4)<br />
p<br />
Partition number (1-4): 2<br />
First cylinder (18-983, default 18):<br />
Using default value 18<br />
Last cylinder or +size or +sizeM or +sizeK (18-983, default 983):<br />
Using default value 983<br />
Command (m for help): w<br />
The partition table has been altered!<br />
Calling ioctl() to re-read partition table.<br />
Syncing disks.<br />
<br />
''Should probably need to change type of first partition to FAT 16 too ?''<br />
<br />
''(type "t" in fdisk, choose the partition 1 and type "6" for FAT16. Check with "p", then type "w" to write)''<br />
<br />
''How about a swap partition also?''<br />
<br />
if it exits with something like<br />
<br />
Calling ioctl() to re-read partition table<br />
fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy<br />
<br />
do<br />
<br />
umount /dev/mmcblk0p1<br />
<br />
on another shell and try again.<br />
<br />
=== Formatting the SD card ===<br />
<br />
Just issue the following command to create at FAT filesystem:<br />
<br />
mkfs.vfat /dev/mmcblk0p1<br />
{{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 />
<br />
<br />
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):<br />
<br />
mkfs.ext3 /dev/mmcblk0p2<br />
<br />
== Populate SD card ==<br />
<br />
Your sd card is now ready to be filled up with the rootfs and the needed kernel to boot.<br />
<br />
Mount the second partition of your SD card somewhere and put the image on it:<br />
<br />
mount /dev/mmcblk0p2 /mnt/moko<br />
tar -C /mnt/moko/ -xzvf openmoko-devel-image-fic-gta01-20070313022035.rootfs.tar.gz<br />
<br />
Or directly from the host via USB network:<br />
<br />
cat openmoko-image-*.tar.gz |ssh root@192.168.0.202 "tar -C /mnt/moko/ -xzf -"<br />
<br />
'''''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<br />
<br />
'''''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.<br />
<br />
The next step is to mount the first partition of the sd card and install the kernel on it.<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uImage.bin<br />
<br />
Or, for some versions of NOR u-boot:<br />
<br />
mount /dev/mmcblk0p1 /mnt/mokokernel<br />
cp uImage-fic-gta01-latest.bin /mnt/mokokernel/uimage<br />
<br />
(Yes, lower case i and no extension.)<br />
<br />
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.<br />
<br />
Unmount both the rootfs partition and the kernel partition and make sure all remaining buffers are written to it:<br />
<br />
umount /mnt/moko<br />
umount /mnt/mokokernel<br />
sync<br />
<br />
== Add uboot boot entry ==<br />
*See also" [[Qi]]<br />
<br />
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.<br />
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.<br />
In any other case you should at least make sure the needed entry exists in your menu before proceeding.<br />
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]].<br />
<br />
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:<br />
<br />
<pre><br />
setenv boot_menu_timeout 99999<br />
</pre><br />
<br />
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.<br />
<br />
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:<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
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.<br />
<br />
Please make sure you are using the correct configuration based on the decisions you made earlier. For more information on the uboot prompt, see<br />
* help<br />
* help <command><br />
* and [[Bootloader]] and [[Bootloader commands]].<br />
<br />
{{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.}}<br />
<br />
{{Note| Copy and paste may not work depending on your terminal emulator. Commi just works or you can use [[NeoCon|neocon]] terminal emulator and add a per-character delay. Otherwise, you will have to type in the commandline manually.}}<br />
<br />
It is important to distinguish between FAT or ext2 kernel partitions and ext2 or ext3 root partitions at this point.<br />
<br />
Please watch partition numbers in the following commands. In particular, you may need to change some of<br />
<pre><br />
root=/dev/mmcblk0p#<br />
fatload mmc#<br />
ext2load mmc#<br />
</pre><br />
depending on which partition number your root and kernel, respectively, are located. Number starts from unity.<br />
<br />
'''Boot entry for FAT kernel+ext3 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext3): setenv bootargs \${bootargs_base} rootfstype=ext3 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for FAT kernel+ext2 rootfs partitions:'''<br />
<br />
<pre><br />
setenv menu_9 Boot from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
or: with additional 'init=/sbin/init' kernel parameter (may be needed for some images):<br />
<br />
<pre><br />
setenv menu_9 Boot 200808 from microSD (FAT+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts} init=/sbin/init\; mmcinit\; fatload mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for ext2 kernel+ext2 rootfs partitions: (requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_2 Boot from microSD part2 (ext2+ext2): setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p2 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
'''Boot entry for kernel and rootfs on same ext2 partition (tested with Qtopia/requires newer u-boot)'''<br />
<br />
<pre><br />
setenv menu_3 QTopia: setenv bootargs \${bootargs_base} rootfstype=ext2 root=/dev/mmcblk0p1 rootdelay=5 \${mtdparts}\; mmcinit\; ext2load mmc 1:1 0x32000000 \${sd_image_name}\; bootm 0x32000000<br />
</pre><br />
<br />
You are nearly done. Just issue a<br />
<br />
<pre><br />
printenv<br />
</pre><br />
<br />
and verify that your newly created entry is correctly displayed (This time the backslashes are not displayed anymore).<br />
<br />
If everything looks fine enter<br />
<br />
<pre><br />
saveenv<br />
</pre><br />
<br />
into the prompt and press enter. The new configuration should now be saved to the NAND.<br />
<br />
Shutdown your neo with the following command:<br />
<br />
<pre><br />
neo1973 power-off<br />
</pre><br />
<br />
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.<br />
<br />
<br />
If you got error when loading kernel, add sleep to boot entry.<br />
<br />
Before:<br />
<pre><br />
mmcinit\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
After:<br />
<pre><br />
mmcinit\; sleep 1\; ext2load mmc 1 0x32000000 \${sd_image_name}\;<br />
</pre><br />
<br />
----<br />
<br />
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.<br />
<br />
----<br />
<br />
== Appendix ==<br />
<br />
=== Boot from SDHC ===<br />
<br />
{{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.}}<br />
<br />
As SDHC is not supported in older u-boot versions you can't use the Booting from SD guide.<br />
But there's a kind of workaround that is a good option to have at least your rootfs on the microSDHC:<br />
<br />
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]]).<br />
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.<br />
Instead of the setenv commands in Step 3 you have to enter the following:<br />
<br />
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<br />
GTA01Bv4 # saveenv<br />
<br />
And that's it!<br />
Now you can use the newly created menu option "Boot from SDHC" to boot the internal kernel, using the root-filesystem on the microSDHC.<br />
<br />
=== Autoboot from SDHC ===<br />
<br />
Maybe you want to Boot automatically from SDHC: <br />
Set a new Bootmenu Entry for booting from NAND first<br />
<br />
GTA01Bv4 # setenv menu_6 Boot from NAND: setenv bootargs \${bootargs_base} \${mtdparts}\; nand read.e 0x32000000 kernel\; bootm 0x32000000<br />
GTA01Bv4 # saveenv<br />
<br />
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:<br />
<br />
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 <br />
GTA01Bv4 # saveenv<br />
<br />
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.<br />
<br />
<br />
=== Fixing udev automount ===<br />
<br />
Udev automatically mounts the SD Card in /media/mmcblk0p1/ you can disable this with<br />
<br />
echo /dev/mmcblk >> /etc/udev/mount.blacklist<br />
<br />
=== Partitioning Limitations ===<br />
<br />
Since SD-Cards are accessed via mmc device nodes (Major 179 of [http://www.lanana.org/docs/device-list/devices-2.6+.txt| Linux Allocated Devices]) there are some things you should be aware of:<br />
<br />
* [http://www.lanana.org/docs/device-list/devices-2.6+.txt|mmc device nodes numbering schema] provides minor numbers from 1 to 7 (/dev/mmcblk0p1 ... /dev/mmcblk0p7). Minor number 8 is the next raw device (/dev/mmcblk1). So we're restricted to a maximum of 7 accessible partitions.<br />
<br />
* 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/:<br />
<br />
mknod -m 640 /lib/udev/devices/mmcblk0p5 b 179 5<br />
mknod -m 640 /lib/udev/devices/mmcblk0p6 b 179 6<br />
mknod -m 640 /lib/udev/devices/mmcblk0p7 b 179 7<br />
<br />
Booting a rootfs from an extended partition with uboot has been tested successfully.<br />
<br />
=== Remarks on Kernel Parameters ===<br />
<br />
==== loglevel ====<br />
<br />
Some people suggested adding:<br />
<br />
loglevel=8<br />
<br />
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:<br />
<br />
s3c2410-sdi s3c2410-sdi: ......<br />
mmc0: ....<br />
<br />
{{Languages|Booting_from_SD}}<br />
<br />
[[Category:Advanced End User]]<br />
[[Category:Flashing Openmoko]]<br />
[[Category:System Developers]]</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-30T01:24:48Z<p>Lokomoko: </p>
<hr />
<div>== Overview ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. It determines all differences between two directory trees and lets the user decide, how to proceed with every differing file.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
<br />
For syncing desktop machine and Neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
<br />
We start unison or unison-gtk on the desktop PC. The program will connect to the Neo via ssh and start a text-only instance of unison on the Neo to retrieve new files or deltas and to modify files on the Neo.<br />
<br />
{{note|The following deals with Unsion on '''Linux'''. It should apply for a [http://wiki.openmoko.org/wiki/Neo1973_and_Windows#USB_Ethernet_emulation network connection from a Windows machine] as well. Check [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#ssh-win unison manual] for details!}}<br />
<br />
<br />
== SSH Setup ==<br />
<br />
For this to work, ssh must not output any text itself, because unison parses the first line of console output to determine the version of unison on the remote computer: <br />
<br />
* So we should setup ssh for public key authentication as described under [http://wiki.openmoko.org/wiki/USB_Networking#SSH_Keys USB Networking].<br />
* If you are working with more than one distribution to boot from or even with more than one device, I found it convenient to make them all use the same host key (/etc/dropbear/dropbear_rsa_host_key).<br />
<br />
== Installation ==<br />
<br />
On the Neo we use the text version of unison. Since there's no native opkg file available currently, we take the [http://packages.debian.org/lenny/armel/unison/download debian package]. Extract the file unison-2.27.57, copy it to /usr/bin on neo and create a symlink by the name of unison! <br />
<br />
When calling Unison via ssh, the console must only show the unison version information:<br />
<pre><br />
user@desktoppc:~$ ssh moko unison -version<br />
unison version 2.27.57<br />
</pre><br />
<br />
== Configuration ==<br />
<br />
Unison allows for multiple configuration profiles on the desktop PC. My ~/.unison/moko.prf looks like this:<br />
<pre><br />
# Unison preferences file<br />
<br />
label = Syncing Openmoko<br />
<br />
# the directories on the desktop and on the neo<br />
root = /home/user/Openmoko/data<br />
root = ssh://root@moko//media/mmc4<br />
<br />
# common options (You can 'outsource' settings as include file. Comment out, if not needed! )<br />
include Common.opt<br />
<br />
<br />
# Do not compare modification time<br />
times = false<br />
<br />
########### Music ##############<br />
path = music<br />
<br />
########### GPS Data ###########<br />
path = gps<br />
ignore = Path gps/Maps/*<br />
ignorenot = Path gps/Maps/OSM<br />
<br />
</pre><br />
<br />
== Using Unison ==<br />
<br />
On first execution of unison on the desktop with the above profile<br />
<pre><br />
unison-gtk moko<br />
</pre><br />
unison will ask you to create a new hash archive. Depending on your directory tree, this may take a while. After that you may choose how to proceed with differences.<br />
<br />
On the second call unison is actually able to detect changes and will automatically suggest appropriate actions on how to sync the directory trees:<br />
<br />
[[Image:UnisonScreenshot1.png|thumb|908px|center|Unison-GTK syncing with the Neo]]<br />
<br />
Unison can integrate programs for comparing and merging files during synchronization and offers a great number of other usefull options (see the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual]).<br />
<br />
[[Category:Applications]]</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T15:24:57Z<p>Lokomoko: </p>
<hr />
<div>== Overview ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. It determines all differences between two directory trees and lets the user decide, how to proceed with every differing file.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
<br />
For syncing desktop machine and Neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
<br />
We start unison or unison-gtk on the desktop PC. The program will connect to the Neo via ssh and start a text-only instance of unison on the Neo to retrieve new files or deltas and to modify files on the Neo.<br />
<br />
{{note|The following deals with Unsion on '''Linux'''. It should apply for a [http://wiki.openmoko.org/wiki/Neo1973_and_Windows#USB_Ethernet_emulation network connection from a Windows machine] as well. Check [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#ssh-win unison manual] for details!}}<br />
<br />
<br />
== SSH Setup ==<br />
<br />
For this to work, ssh must not output any text itself, because unison parses the first line of console output to determine the version of unison on the remote computer: <br />
<br />
* So we should setup ssh for public key authentication as described under [http://wiki.openmoko.org/wiki/USB_Networking#SSH_Keys USB Networking].<br />
* If you are working with more than one distribution to boot from or even with more than one device, I found it convenient to make them all use the same host key (/etc/dropbear/dropbear_rsa_host_key).<br />
<br />
== Installation ==<br />
<br />
On the Neo we use the text version of unison. Since there's no native opkg file available currently, we take the [http://packages.debian.org/lenny/armel/unison/download debian package]. Extract the file unison-2.27.57, copy it to /usr/bin on neo and create a symlink by the name of unison! <br />
<br />
When calling Unison via ssh, the console must only show the unison version information:<br />
<pre><br />
user@desktoppc:~$ ssh moko unison -version<br />
unison version 2.27.57<br />
</pre><br />
<br />
== Configuration ==<br />
<br />
Unison allows for multiple configuration profiles on the desktop PC. My ~/.unison/moko.prf looks like this:<br />
<pre><br />
# Unison preferences file<br />
<br />
label = Syncing Openmoko<br />
<br />
# the directories on the desktop and on the neo<br />
root = /home/user/Openmoko/data<br />
root = ssh://root@moko//media/mmc4<br />
<br />
# common options<br />
include Common.opt<br />
<br />
<br />
# Do not compare modification time<br />
times = false<br />
<br />
########### Music ##############<br />
path = music<br />
<br />
########### GPS Data ###########<br />
path = gps<br />
ignore = Path gps/Maps/*<br />
ignorenot = Path gps/Maps/OSM<br />
<br />
</pre><br />
<br />
== Using Unison ==<br />
<br />
On first execution of unison on the desktop with the above profile<br />
<pre><br />
unison-gtk moko<br />
</pre><br />
unison will ask you to create a new hash archive. Depending on your directory tree, this may take a while. After that you may choose how to proceed with differences.<br />
<br />
On the second call unison is actually able to detect changes an will automatically suggest appropriate actions on how to sync the directory trees:<br />
<br />
[[Image:UnisonScreenshot1.png|thumb|908px|center|Unison-GTK syncing with the Neo]]<br />
<br />
Unison can integrate programs for comparing and merging files during synchronization and offers a great number of other usefull options (see the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual]).</div>Lokomokohttp://openmoko.org/wiki/File:UnisonScreenshot1.pngFile:UnisonScreenshot1.png2008-11-25T14:39:25Z<p>Lokomoko: Screenshot of Unison</p>
<hr />
<div>Screenshot of Unison</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T14:37:02Z<p>Lokomoko: </p>
<hr />
<div>== Overview ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. It determines all differences between two directory trees and lets the user decide, how to proceed with every differing file.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
<br />
For syncing desktop machine and Neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
<br />
We start unison or unison-gtk on the desktop PC. The program will connect to the Neo via ssh and start a text-only instance of unison on the Neo to retrieve new files or deltas and to modify files on the Neo.<br />
<br />
{{note|The following deals with Unsion on '''Linux'''. It should apply for a [http://wiki.openmoko.org/wiki/Neo1973_and_Windows#USB_Ethernet_emulation network connection from a Windows machine] as well. Check [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#ssh-win unison manual] for details!}}<br />
<br />
<br />
== SSH Setup ==<br />
<br />
For this to work, ssh must not output any text itself, because unison parses the first line of console output to determine the version of unison on the remote computer: <br />
<br />
* So we should setup ssh for public key authentication as described under [http://wiki.openmoko.org/wiki/USB_Networking#SSH_Keys USB Networking].<br />
* If you are working with more than one distribution to boot from or even with more than one device, I found it convenient to make them all use the same host key (/etc/dropbear/dropbear_rsa_host_key).<br />
<br />
== Installation ==<br />
<br />
On the Neo we use the text version of unison. Since there's no native opkg file available currently, we take the [http://packages.debian.org/lenny/armel/unison/download debian package]. Extract the file unison-2.27.57, copy it to /usr/bin on neo and create a symlink by the name of unison! <br />
<br />
When calling Unison via ssh, the console must only show the unison version information:<br />
<pre><br />
user@desktoppc:~$ ssh moko unison -version<br />
unison version 2.27.57<br />
</pre><br />
<br />
== Configuration ==<br />
<br />
Unison allows for multiple configuration profiles on the desktop PC. My ~/.unison/moko.prf looks like this:<br />
<pre><br />
# Unison preferences file<br />
<br />
label = Syncing Openmoko<br />
<br />
# the directories on the desktop and on the neo<br />
root = /home/user/Openmoko/data<br />
root = ssh://root@moko//media/mmc4<br />
<br />
# common options<br />
include Common.opt<br />
<br />
<br />
# Do not compare modification time<br />
times = false<br />
<br />
########### Music ##############<br />
path = music<br />
<br />
########### GPS Data ###########<br />
path = gps<br />
ignore = Path gps/Maps/*<br />
ignorenot = Path gps/Maps/OSM<br />
<br />
</pre><br />
<br />
== Using Unison ==<br />
<br />
On first execution of unison on the desktop with the above profile<br />
<pre><br />
unison-gtk moko<br />
</pre><br />
unison will create hashes for the entire directory tree. This may take a while.<br />
<br />
Unison can integrate programs for comparing and merging files during synchronization and offers a great number of other usefull options (see the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual]).</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T13:34:47Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. It determines all differences between two directory trees and lets the user decide, how to proceed with every differing file.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
For syncing desktop machine and Neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
<br />
We start unison or unison-gtk on the desktop PC. The program will connect to the Neo via ssh and start a text-only instance of unison on the Neo to retrieve new files or deltas and to modify files on the Neo.<br />
<br />
For this to work, ssh must not output any text itself, because unison parses the first line of console output to determine the version of unison on the remote computer: <br />
<br />
* So we should setup ssh for public key authentication as described under [http://wiki.openmoko.org/wiki/USB_Networking#SSH_Keys USB Networking].<br />
* If you are working with more than one distribution to boot from or even with more than one device, I found it convenient to make them all use the same host key (/etc/dropbear/dropbear_rsa_host_key).<br />
<br />
On the Neo we use the text version of unison. Since there's no native opkg file available currently, we take the [http://packages.debian.org/lenny/armel/unison/download debian package]. Extract the file unison-2.27.57, copy it to /usr/bin on neo and create a symlink by the name of unison! <br />
<br />
When calling Unison via ssh, the console must only show the unison version information:<br />
<pre><br />
user@desktoppc:~$ ssh moko unison -version<br />
unison version 2.27.57<br />
</pre><br />
<br />
Unison allows for multiple configuration profiles on the desktop PC (~/.unison/Openmoko.prf). Mine look like this:<br />
<pre><br />
# Unison preferences file<br />
<br />
label = Syncing Openmoko<br />
<br />
# the directories on the desktop and on the neo<br />
root = /home/user/Openmoko/data<br />
root = ssh://root@moko//media/mmc4<br />
<br />
# common options<br />
include Common.opt<br />
<br />
<br />
# Do not compare modification time<br />
times = false<br />
<br />
########### Music ##############<br />
path = music<br />
<br />
########### GPS Data ###########<br />
path = gps<br />
ignore = Path gps/Maps/*<br />
ignorenot = Path gps/Maps/OSM<br />
<br />
</pre><br />
<br />
On first execution of unison on the desktop, unison will create hashes for the entire directory tree. This may take a while.<br />
<br />
Unison supports various preferences to interactively include programs for comparing and merging files during synchronization (see the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual]).</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T04:21:19Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. It determines all differences between two directory trees and lets the user decide, how to proceed with every differing file.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
For syncing desktop machine and Neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
We start unison or unison-gtk on the desktop PC. The program will connect to the Neo via ssh and start a text-only instance of unison on the Neo to retrieve new files or deltas and to modify files on the Neo.<br />
<br />
For this to work, ssh may not output any text itself, because unison parses the first line of console output to determine the version of unison on the remote computer. So we setup ssh for public key authentication:<br />
<br />
* Create a key pair on the desktop PC<br />
* Configure the desktop PC for public key authentication<br />
* Add the public key of the desktop PC to ~/.ssh/authorized_keys on the Neo<br />
<br />
We need to install the text version of unison on the neo. Since there's no native opkg file available currently, we take the [http://packages.debian.org/lenny/armel/unison/download debian package]. Extract the file unison-2.27.57 and copy it to /usr/bin on neo! Create a symlink by the name of unison!<br />
<br />
A unison configuration on the desktop PC (~/.unison/Openmoko.prf) might look like this<br />
<pre><br />
# Unison preferences file<br />
<br />
label = Syncing Openmoko<br />
<br />
# the directories on the desktop and on the neo<br />
root = /home/user/Openmoko/data<br />
root = ssh://root@192.168.0.202//media/mmc4<br />
<br />
# common options<br />
include Common.opt<br />
<br />
<br />
# Do not compare modification time<br />
times = false<br />
<br />
########### Music ##############<br />
path = music<br />
<br />
########### GPS Data ###########<br />
path = gps<br />
ignore = Path gps/Maps/*<br />
ignorenot = Path gps/Maps/OSM<br />
<br />
</pre><br />
<br />
On first execution of unison on the desktop, unison will create hashes for the entire directory tree. This may take a while.<br />
<br />
Unison supports various preferences to interactively include programs for comparing and merging files during synchronization (see the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual]).</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T04:07:12Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual] for a detailed look at it's capabilities.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
For syncing desktop machine and Neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
We start unison or unison-gtk on the desktop PC. The program will connect to the Neo via ssh and start a text-only instance of unison on the Neo to retrieve new files or deltas and to modify files on the Neo.<br />
<br />
For this to work, ssh may not output any text itself, because unison parses the first line of console output to determine the version of unison on the remote computer. So we setup ssh for public key authentication:<br />
<br />
* Create a key pair on the desktop PC<br />
* Configure the desktop PC for public key authentication<br />
* Add the public key of the desktop PC to ~/.ssh/authorized_keys on the Neo<br />
<br />
We need to install the text version of unison on the neo. Since there's no native opkg file available currently, we take the [http://packages.debian.org/lenny/armel/unison/download debian package]. Extract the file unison-2.27.57 and copy it to /usr/bin on neo. Create a symlink by the name of unison.<br />
<br />
A unison configuration on the desktop PC (~/.unison/Openmoko.prf) might look like this<br />
<pre><br />
# Unison preferences file<br />
<br />
label = Syncing Openmoko<br />
<br />
# the directories on the desktop and on the neo<br />
root = /home/user/Openmoko/data<br />
root = ssh://root@192.168.0.202//media/mmc4<br />
<br />
# common options<br />
include Common.opt<br />
<br />
<br />
# Do not compare modification time<br />
times = false<br />
<br />
########### Music ##############<br />
path = music<br />
<br />
########### GPS Data ###########<br />
path = gps<br />
ignore = Path gps/Maps/*<br />
ignorenot = Path gps/Maps/OSM<br />
ignore = Path gps/log/*<br />
<br />
</pre><br />
<br />
On first execution of unison on the desktop, unison will create hashes for the entire directory tree. This may take a while.<br />
<br />
Unison supports various preferences to interactively include programs for comparing and merging files during synchronization (see the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual]).</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T03:23:47Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual] for a detailed look at it's capabilities.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
For syncing desktop machine and Neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
We start unison or unison-gtk on the desktop PC. The program will connect to the Neo via ssh and start a text-only instance of unison on the Neo to retrieve new files or deltas and to modify files on the Neo.<br />
<br />
For this to work, ssh may not output any text itself, because unison parses the first line of console output to determine the version of unison on the remote computer. So we setup ssh for public key authentication:<br />
<br />
* Create a key pair on the desktop PC<br />
* Configure the desktop PC for public key authentication<br />
* Add the public key of the desktop PC to ~/.ssh/authorized_keys on the Neo</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T03:20:57Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual] for a detailed look at it's capabilities.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
For syncing desktop machine and Neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
We start unison or unison-gtk on the desktop pc. The program will connect to the Neo via ssh an start a text-only unison on the Neo to retrieve new files or deltas and to modify files on the Neo.<br />
<br />
For this to work, ssh may not output any text itself, because unison parses the first line of console output to determine the version of unison on the remote computer. So we setup ssh for public key authentication:<br />
<br />
* Create a key pair on the desktop PC<br />
* Configure the desktop PC for public key authentication<br />
* Add the public key of the desktop PC to ~/.ssh/authorized_keys on the Neo</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T03:09:08Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual] for a detailed look at it's capabilities.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based graphical version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
For syncing desktop machine and neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
We start unison or unison-gtk on the desktop pc. The program will connect to the neo via ssh an start a text-only unison on the neo to retrieve new files or deltas and to modify files on the neo.</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T03:08:13Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual] for a detailed look at it's capabilities.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based visual version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
For syncing desktop machine and neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method]:<br />
We start unison or unison-gtk on the desktop pc. The program will connect to the neo via ssh an start a text-only unison on the neo to retrieve new files or deltas and to modify files on the neo.</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T03:02:32Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual] for a detailed look at it's capabilities.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based visual version (debian package name: unison-gtk)<br />
<br />
Unison can sync <br />
* between two directory trees on the same computer or <br />
* between directory trees on two separate machines.<br />
For syncing desktop machine and neo we use the latter. The recommended way to do this is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth remote shell method].</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T02:59:59Z<p>Lokomoko: /* Unison File Synchronizer */</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual] for a detailed look at it's capabilities.<br />
<br />
Unison comes in two flavors:<br />
* Text mode only version (debian package name: unison)<br />
* GTK-based visual version (debian package name: unison-gtk)<br />
<br />
Unison can sync between two directory trees on the same computer or between two separate machines. <br />
For syncing desktop machine and neo we use the latter. The recommended way to is the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html#rshmeth Remote shell method].</div>Lokomokohttp://openmoko.org/wiki/UnisonUnison2008-11-25T02:49:48Z<p>Lokomoko: New page: == Unison File Synchronizer == [http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/...</p>
<hr />
<div>== Unison File Synchronizer ==<br />
<br />
[http://www.cis.upenn.edu/~bcpierce/unison Unison] is a file-synchronization tool for Unix and Windows. See the [http://www.cis.upenn.edu/~bcpierce/unison/download/releases/stable/unison-manual.html manual] for a detailed look at it's capabilities.</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-05-20T21:56:09Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy serial console utility (not only) for [[Bootloader|u-boot]].<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be <code>root</code> to access <code>/dev/ttyACM0</code> with '''neocon'''. Beeing member of <code>dialout</code> should give you sufficient privileges. <br />
* '''neocon''' can be started without <code>/dev/ttyACM0</code> being available. It will automatically connect as soon as you start [[Bootloader|u-boot]] on the Neo. <br />
* by specifying a delay on keyboard input(as shown below), '''neocon''' will allow you to paste commands directly from clipboard without making [[Bootloader|u-boot]] choke on it. <br />
<br />
Download the source from http://svn.openmoko.org/developers/werner/neocon/ to a directory of your choice and build '''neocon''' by issuing <br />
<br />
make<br />
<br />
To connect to the [[bootloader]] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
To quit neocon type:<br />
<br />
~.</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:46:40Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy serial console utility (not only) for [[Bootloader|u-boot]].<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be <code>root</code> to access <code>/dev/ttyACM0</code> with '''neocon'''. Beeing member of <code>dialout</code> should give you sufficient privileges. <br />
* '''neocon''' can be started without <code>/dev/ttyACM0</code> being available. It will automatically connect as soon as you start [[Bootloader|u-boot]] on the Neo. <br />
* by specifying a delay on keyboard input(as shown below), '''neocon''' will allow you to paste commands directly from clipboard without making [[Bootloader|u-boot]] choke on it. <br />
<br />
Download the source from http://svn.openmoko.org/developers/werner/neocon/ to a directory of your choice and build '''neocon''' by issuing <br />
<br />
make<br />
<br />
To connect to the [[bootloader]] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
To get rid of neocon, just issue a<br />
<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:35:20Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy terminal application (not only) for [[Bootloader|u-boot]].<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be <code>root</code> to access <code>/dev/ttyACM0</code> with '''neocon'''. Beeing member of <code>dialout</code> should give you sufficient privileges. <br />
* '''neocon''' can be started without <code>/dev/ttyACM0</code> being available. It will automatically connect as soon as you start [[Bootloader|u-boot]] on the Neo. <br />
* by specifying a delay on keyboard input(as shown below), '''neocon''' will allow you to paste commands directly from clipboard without making [[Bootloader|u-boot]] choke on it. <br />
<br />
Download the source from http://svn.openmoko.org/developers/werner/neocon/ to a directory of your choice and build '''neocon''' by issuing <br />
<br />
make<br />
<br />
To connect to the [[bootloader]] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
To get rid of neocon, just issue a<br />
<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:32:19Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy terminal application (not only) for [[Bootloader|u-boot]].<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be <code>root</code> to access <code>/dev/ttyACM0</code> with '''neocon'''. Beeing member of <code>dialout</code> should give you sufficient privileges. <br />
* '''neocon''' can be started without <code>/dev/ttyACM0</code> beeing available. It will automatically connect as soon as you start [[Bootloader|u-boot]] on the Neo. <br />
* due to the delay it puts on keyboard input, neocon will allow you to paste commands directly from clipboard without making [[Bootloader|u-boot]] choke on it. <br />
<br />
Download the source from http://svn.openmoko.org/developers/werner/neocon/ to a directory of your choice and build '''neocon''' by issuing <br />
<br />
make<br />
<br />
To connect to the [[bootloader]] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
To getrid of neocon, just issue a<br />
<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/U-BootU-Boot2008-02-27T22:31:28Z<p>Lokomoko: /* Using usbtty from Linux */</p>
<hr />
<div>[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]<br />
<br />
The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[OpenMoko]] is booted. This includes [[USB DFU]] for [[flashing openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]]. <br />
<br />
There are various [[bootloader versions]] available.<br />
<br />
== Phase0 Quick Start ==<br />
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.<br />
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.<br />
* Hold in the AUX button on power-up to access the boot menu.<br />
* Set the console to USB.<br />
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )<br />
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.<br />
* You're now at the bootloader prompt.<br />
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.<br />
<br />
== General ==<br />
<br />
The GTA01 uses the [http://u-boot.sourceforge.net/ u-boot] bootloader.<br />
<br />
More information on u-boot can be found at <br />
* http://www.denx.de/wiki/DULG<br />
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot<br />
* http://linuxdevices.com/articles/AT5085702347.html<br />
<br />
Additions to the vanilla u-boot already implemented include: <br />
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]<br />
* Support for S3C2410 NAND flash<br />
* Support for downloading programs via S3C2410 USB Device Controller<br />
* Support to display bootup logo / status on S3C2410 Framebuffer<br />
<br />
However, u-boot still doesn't support many of the features that GTA01 needs, such as<br />
* Support for reading kernel/initrd from SD/Transflash<br />
<br />
[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.<br />
<br />
== Bootloader source code ==<br />
<br />
The current bootloader patches can be found at http://svn.openmoko.org/trunk/src/target/u-boot/patches/. <br />
<br />
Untar the sources, apply the patch, run "make gta01bv3_config" (or gta01bv2_config, or whatever hardware revision you have), run "make". You will get a resulting "u-boot.bin" image, which you can directly flash (either using existing bootloader or [[sjf2410-linux]]) into NAND.<br />
<br />
== Bootloader binary ==<br />
<br />
The latest bootloader binary builds can be found under http://buildhost.openmoko.org/snapshots in the subdirectory 200X.XX/images/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).<br />
<br />
== Bootloader development ==<br />
<br />
=== QT2410 ===<br />
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.<br />
<br />
To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".<br />
<br />
The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.<br />
<br />
=== GTA01 ===<br />
<br />
Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.<br />
<br />
The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this<br />
<br />
==== Using JTAG to boot from RAM ====<br />
<br />
So how can we boot from RAM? We use JTAG / OpenOCD to<br />
<br />
* Reset and halt the cpu at PC=0<br />
<pre><br />
> reset halt<br />
target halted in ARM state due to debug request, current mode: Supervisor<br />
cpsr: 0x400000d3 pc: 0x00000000<br />
MMU: disabled, D-Cache: disabled, I-Cache: disabled<br />
</pre><br />
<br />
* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)<br />
<pre><br />
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0 <br />
downloaded 332 byte in 0s 21899us<br />
</pre><br />
<br />
* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)<br />
<pre><br />
> bp 0x33f80000 4 hw<br />
breakpoint added at address 0x33f80000<br />
</pre><br />
<br />
* Run the code up to the break point<br />
<pre><br />
> resume<br />
Target 0 resumed<br />
> Target 0 halted<br />
target halted in ARM state due to breakpoint, current mode: Supervisor<br />
cpsr: 0x600000d3 pc: 0x33f80000<br />
MMU: disabled, D-Cache: disabled, I-Cache: enabled<br />
</pre><br />
<br />
* Download the u-boot RAM image to 0x33f80000<br />
<pre><br />
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000<br />
downloaded 135692 byte in 6s 567264us<br />
</pre><br />
<br />
* Resume processing<br />
<pre><br />
> resume<br />
Target 0 resumed<br />
</pre><br />
<br />
At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:<br />
<pre><br />
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)<br />
<br />
DRAM: 128 MB<br />
NAND: 64 MiB<br />
*** Warning - bad CRC or NAND, using default environment<br />
<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
Hit any key to stop autoboot: 0 <br />
GTA01Bv2 # <br />
</pre><br />
<br />
== Creating bootable images ==<br />
<br />
u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:<br />
<br />
<pre><br />
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin<br />
gzip -9 linux.bin<br />
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage<br />
</pre><br />
<br />
== Boot menu ==<br />
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]<br />
<br />
As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].<br />
<br />
=== Accessing the boot menu ===<br />
<br />
You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.<br />
<br />
=== Using the boot menu ===<br />
<br />
By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item. <br />
<br />
== Bootloader prompt ==<br />
<br />
=== Accessing the bootloader prompt ===<br />
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).<br />
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.<br />
<br />
Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.<br />
<br />
The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.<br />
<br />
==== Using usbtty from Linux ====<br />
<br />
Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])<br />
<br />
Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)<br />
cu -l /dev/ttyACM0<br />
<br />
You might need to <br />
chown uucp.uucp /dev/ttyACM0<br />
<br />
to get the necessary right (even as root).<br />
<br />
A nice alternative for cu is Werner Almesberger's [[NeoCon|neocon]].<br />
<br />
First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:<br />
<br />
# lsusb -d 1457:5119<br />
Bus 005 Device 079: ID 1457:5119 <br />
<br />
Second, lets see some more details about the available endpoints and configurations:<br />
<br />
<pre><br />
# lsusb -v -d 1457:5119<br />
Bus 005 Device 079: ID 1457:5119 <br />
Device Descriptor:<br />
bLength 18<br />
bDescriptorType 1<br />
bcdUSB 1.10<br />
bDeviceClass 2 Communications<br />
bDeviceSubClass 0 <br />
bDeviceProtocol 0 <br />
bMaxPacketSize0 16<br />
idVendor 0x1457 <br />
idProduct 0x5119 <br />
bcdDevice 0.00<br />
iManufacturer 1 OpenMoko, Inc<br />
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3<br />
iSerial 3 0000000<br />
bNumConfigurations 1<br />
Configuration Descriptor:<br />
bLength 9<br />
bDescriptorType 2<br />
wTotalLength 85<br />
bNumInterfaces 3<br />
bConfigurationValue 1<br />
iConfiguration 4 TTY via USB<br />
bmAttributes 0xc0<br />
Self Powered<br />
MaxPower 0mA<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 0<br />
bAlternateSetting 0<br />
bNumEndpoints 1<br />
bInterfaceClass 2 Communications<br />
bInterfaceSubClass 2 Abstract (modem)<br />
bInterfaceProtocol 1 AT-commands (v.25ter)<br />
iInterface 6 Control Interface<br />
CDC Header:<br />
bcdCDC 0.6e<br />
CDC Call Management:<br />
bmCapabilities 0x00<br />
bDataInterface 1<br />
CDC ACM:<br />
bmCapabilities 0x00<br />
CDC Union:<br />
bMasterInterface 0<br />
bSlaveInterface 1 <br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x81 EP 1 IN<br />
bmAttributes 3<br />
Transfer Type Interrupt<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 1<br />
bAlternateSetting 0<br />
bNumEndpoints 2<br />
bInterfaceClass 10 CDC Data<br />
bInterfaceSubClass 0 Unused<br />
bInterfaceProtocol 0 <br />
iInterface 5 Bulk Data Interface<br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x02 EP 2 OUT<br />
bmAttributes 2<br />
Transfer Type Bulk<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x83 EP 3 IN<br />
bmAttributes 2<br />
Transfer Type Bulk<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 2<br />
bAlternateSetting 0<br />
bNumEndpoints 0<br />
bInterfaceClass 254 Application Specific Interface<br />
bInterfaceSubClass 1 Device Firmware Update<br />
bInterfaceProtocol 1 <br />
iInterface 7 USB Device Firmware Upgrade<br />
Device Status: 0x0001<br />
Self Powered<br />
</pre><br />
<br />
Next, you can access it using your favourite terminal program.<br />
<br />
Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:<br />
<pre><br />
GTA01Bv2 # setenv stderr usbtty<br />
GTA01Bv2 # setenv stdout usbtty<br />
GTA01Bv2 # setenv stdin usbtty<br />
</pre><br />
<br />
==== Typical u-boot prompt ====<br />
<br />
<pre><br />
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)<br />
<br />
DRAM: 128 MB<br />
NAND: 64 MiB<br />
Found Environment offset in OOB..<br />
Video: 640x480x8 31kHz 59Hz<br />
USB: S3C2410 USB Deviced<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
Hit any key to stop autoboot: 0 <br />
GTA01Bv3 #<br />
</pre><br />
<br />
=== Commands on the bootloader prompt ===<br />
<br />
:''See [[bootloader commands]].''<br />
<br />
<br />
== Device Firmware Upgrade ==<br />
<br />
Our version of u-boot also implements [[USB DFU]]. This can be useful to<br />
load files and kernel for quick testing.<br />
<br />
To find out whether your version of u-boot supports this, use the output of<br />
$ lsusb -v -d 1457:5119<br />
while the phone is in u-boot mode.<br />
<br />
If it supports DFU, you should see the following snippet towards the end of the output:<br />
<pre><br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 2<br />
bAlternateSetting 0<br />
bNumEndpoints 0<br />
bInterfaceClass 254 Application Specific Interface<br />
bInterfaceSubClass 1 Device Firmware Update<br />
bInterfaceProtocol 1 <br />
iInterface 0 <br />
</pre><br />
<br />
For information on how to do firmware upgrades, please see [[dfu-util]].<br />
<br />
=== Booting files over DFU ===<br />
<br />
To load a file at memory address 0x32000000:<br />
<pre><br />
dfu-util -a 0 -D fileToLoad -R<br />
</pre><br />
<br />
After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if<br />
its an elf file.<br />
<br />
Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.<br />
<br />
<pre><br />
#!/usr/bin/python<br />
import sys<br />
import os<br />
import time<br />
<br />
cmd1 = "neo backlight off\n"<br />
cmd2 = "bootelf 0x32000000\n"<br />
<br />
def output(tty, str):<br />
for x in str:<br />
tty.write(x)<br />
tty.flush()<br />
<br />
if len(sys.argv) == 2:<br />
print "Loading %s..." % sys.argv[1]<br />
<br />
loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]<br />
<br />
os.system(loadfile)<br />
<br />
time.sleep(3)<br />
<br />
tty = open("/dev/ttyACM0", "a")<br />
<br />
output(tty, cmd1)<br />
output(tty, cmd2)<br />
<br />
tty.close()<br />
else:<br />
print "Usage: %s elffile" % sys.argv[0]<br />
print ""<br />
sys.exit(2)<br />
</pre><br />
<br />
== Troubleshooting ==<br />
<br />
=== USB connectivity problems ===<br />
<br />
I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:<br />
<br />
usb 2-1: device descriptor read/64, error -110<br />
usb usb2: Controller not stopped yet!<br />
<br />
The problem disappeared at least for me by the command below on the host side. Please note that if you have usb keyboard or mouse then the command might cause trouble.. I only have PS/2 so I couldn't test it.<br />
<br />
rmmod uhci_hcd ; modprobe uhci_hcd<br />
<br />
{{Languages|Bootloader}}<br />
<br />
[[Category:Software]]<br />
[[Category:Guides]]</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:26:52Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy terminal application (not only) for [[Bootloader|u-boot]].<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be <code>root</code> to access /dev/ttyACM0 with '''neocon'''. Beeing member of <code>dialout</code> should give you sufficient privileges. <br />
* '''neocon''' can be started without /dev/ttyACM0 beeing available. It will automatically connect as soon as you start [[Bootloader|u-boot]] on the Neo. <br />
* due to the delay it puts on keyboard input, neocon will allow you to paste commands directly from clipboard without making [[Bootloader|u-boot]] choke on it. <br />
<br />
Download the source from http://svn.openmoko.org/developers/werner/neocon/ to a directory of your choice and build '''neocon''' by issuing <br />
<br />
make<br />
<br />
To connect to the [[bootloader]] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
To getrid of neocon, just issue a<br />
<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:16:03Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy terminal application (not only) for [[Bootloader|u-boot]].<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be ''root'' to access /dev/ttyACM0 with '''neocon'''. Beeing member of ''dialout'' should give you sufficient privileges. <br />
* '''neocon''' can be started without /dev/ttyACM0 beeing available. It will automatically connect as soon as you start [[Bootloader|u-boot]] on the Neo. <br />
* due to the delay it puts on keyboard input, neocon will allow you to paste commands directly from clipboard without making [[Bootloader|u-boot]] choke on it. <br />
<br />
Download the source from http://svn.openmoko.org/developers/werner/neocon/ to a directory of your choice and build '''neocon''' by issuing <br />
<br />
make<br />
<br />
To connect to the [[bootloader|Bootloader]] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
To getrid of neocon, just issue a<br />
<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:13:06Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy terminal application (not only) for [[Bootloader|u-boot]].<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be root to access /dev/ttyACM0 with '''neocon'''. Beeing member of ''dialout'' should give you sufficient privileges. <br />
* '''neocon''' can be started without /dev/ttyACM0 beeing available. It will automatically connect as soon as you start u-boot on the Neo. <br />
* due to the delay it puts on keyboard input, neocon will allow you to paste commands directly from clipboard without making u-boot choke on it. <br />
<br />
You can download the source at http://svn.openmoko.org/developers/werner/neocon/. Build ''neocon'' by issuing <br />
<br />
make<br />
<br />
To connect to the [bootloader|Bootloader] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
To getrid of neocon, just issue a<br />
<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:12:37Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy terminal application (not only) for [[u-boot|Bootloader]].<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be root to access /dev/ttyACM0 with '''neocon'''. Beeing member of ''dialout'' should give you sufficient privileges. <br />
* '''neocon''' can be started without /dev/ttyACM0 beeing available. It will automatically connect as soon as you start u-boot on the Neo. <br />
* due to the delay it puts on keyboard input, neocon will allow you to paste commands directly from clipboard without making u-boot choke on it. <br />
<br />
You can download the source at http://svn.openmoko.org/developers/werner/neocon/. Build ''neocon'' by issuing <br />
<br />
make<br />
<br />
To connect to the [bootloader|Bootloader] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
To getrid of neocon, just issue a<br />
<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:10:15Z<p>Lokomoko: </p>
<hr />
<div>'''neocon''' is a handy terminal application (not only) for using with u-boot.<br />
<br />
'''neocon''' has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be root to access /dev/ttyACM0 with '''neocon'''. Beeing member of ''dialout'' should give you sufficient privileges. <br />
* '''neocon''' can be started without /dev/ttyACM0 beeing available. It will automatically connect as soon as you start u-boot on the Neo. <br />
* due to the delay it puts on keyboard input, neocon will allow you to paste commands directly from clipboard without making u-boot choke on it. <br />
<br />
You can download the source at http://svn.openmoko.org/developers/werner/neocon/. Build ''neocon'' by issuing <br />
<br />
make<br />
<br />
To connect to the [bootloader|Bootloader] use<br />
<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
To getrid of neocon, just issue a<br />
<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/NeoConNeoCon2008-02-27T22:03:38Z<p>Lokomoko: </p>
<hr />
<div>neocon is a handy terminal application for using with u-boot.<br />
<br />
You can download the source at http://svn.openmoko.org/developers/werner/neocon/.<br />
<br />
wget http://svn.openmoko.org/developers/werner/neocon/README<br />
wget http://svn.openmoko.org/developers/werner/neocon/Makefile<br />
wget http://svn.openmoko.org/developers/werner/neocon/neocon<br />
make<br />
<br />
To connect to the [bootloader|Bootloader] use<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
<br />
For use with u-boot neocon has a few graving advantages over some other terminal apps:<br />
<br />
* You don't have to be root to access /dev/ttyACM0 with '''neocon'''. Beeing member of ''dialout'' should give you sufficient privileges. <br />
* neocon an be started without /dev/ttyACM0 beeing available. It will automatically connect as soon as you start u-boot on the Neo. <br />
* due to the delay it can put on keyboard input, neocon will allow you to paste commands directly from clipboard without making u-boot choke on it. <br />
<br />
To getrid of neocon, just issue a<br />
killall neocon</div>Lokomokohttp://openmoko.org/wiki/U-BootU-Boot2008-02-27T21:41:32Z<p>Lokomoko: /* Using usbtty from Linux */</p>
<hr />
<div>[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]<br />
<br />
The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[OpenMoko]] is booted. This includes [[USB DFU]] for [[flashing openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]]. <br />
<br />
There are various [[bootloader versions]] available.<br />
<br />
== Phase0 Quick Start ==<br />
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.<br />
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.<br />
* Hold in the AUX button on power-up to access the boot menu.<br />
* Set the console to USB.<br />
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )<br />
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.<br />
* You're now at the bootloader prompt.<br />
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.<br />
<br />
== General ==<br />
<br />
The GTA01 uses the [http://u-boot.sourceforge.net/ u-boot] bootloader.<br />
<br />
More information on u-boot can be found at <br />
* http://www.denx.de/wiki/DULG<br />
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot<br />
* http://linuxdevices.com/articles/AT5085702347.html<br />
<br />
Additions to the vanilla u-boot already implemented include: <br />
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]<br />
* Support for S3C2410 NAND flash<br />
* Support for downloading programs via S3C2410 USB Device Controller<br />
* Support to display bootup logo / status on S3C2410 Framebuffer<br />
<br />
However, u-boot still doesn't support many of the features that GTA01 needs, such as<br />
* Support for reading kernel/initrd from SD/Transflash<br />
<br />
[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.<br />
<br />
== Bootloader source code ==<br />
<br />
The current bootloader patches can be found at http://svn.openmoko.org/trunk/src/target/u-boot/patches/. <br />
<br />
Untar the sources, apply the patch, run "make gta01bv3_config" (or gta01bv2_config, or whatever hardware revision you have), run "make". You will get a resulting "u-boot.bin" image, which you can directly flash (either using existing bootloader or [[sjf2410-linux]]) into NAND.<br />
<br />
== Bootloader binary ==<br />
<br />
The latest bootloader binary builds can be found under http://buildhost.openmoko.org/snapshots in the subdirectory 200X.XX/images/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).<br />
<br />
== Bootloader development ==<br />
<br />
=== QT2410 ===<br />
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.<br />
<br />
To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".<br />
<br />
The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.<br />
<br />
=== GTA01 ===<br />
<br />
Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.<br />
<br />
The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this<br />
<br />
==== Using JTAG to boot from RAM ====<br />
<br />
So how can we boot from RAM? We use JTAG / OpenOCD to<br />
<br />
* Reset and halt the cpu at PC=0<br />
<pre><br />
> reset halt<br />
target halted in ARM state due to debug request, current mode: Supervisor<br />
cpsr: 0x400000d3 pc: 0x00000000<br />
MMU: disabled, D-Cache: disabled, I-Cache: disabled<br />
</pre><br />
<br />
* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)<br />
<pre><br />
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0 <br />
downloaded 332 byte in 0s 21899us<br />
</pre><br />
<br />
* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)<br />
<pre><br />
> bp 0x33f80000 4 hw<br />
breakpoint added at address 0x33f80000<br />
</pre><br />
<br />
* Run the code up to the break point<br />
<pre><br />
> resume<br />
Target 0 resumed<br />
> Target 0 halted<br />
target halted in ARM state due to breakpoint, current mode: Supervisor<br />
cpsr: 0x600000d3 pc: 0x33f80000<br />
MMU: disabled, D-Cache: disabled, I-Cache: enabled<br />
</pre><br />
<br />
* Download the u-boot RAM image to 0x33f80000<br />
<pre><br />
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000<br />
downloaded 135692 byte in 6s 567264us<br />
</pre><br />
<br />
* Resume processing<br />
<pre><br />
> resume<br />
Target 0 resumed<br />
</pre><br />
<br />
At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:<br />
<pre><br />
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)<br />
<br />
DRAM: 128 MB<br />
NAND: 64 MiB<br />
*** Warning - bad CRC or NAND, using default environment<br />
<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
Hit any key to stop autoboot: 0 <br />
GTA01Bv2 # <br />
</pre><br />
<br />
== Creating bootable images ==<br />
<br />
u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:<br />
<br />
<pre><br />
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin<br />
gzip -9 linux.bin<br />
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage<br />
</pre><br />
<br />
== Boot menu ==<br />
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]<br />
<br />
As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].<br />
<br />
=== Accessing the boot menu ===<br />
<br />
You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.<br />
<br />
=== Using the boot menu ===<br />
<br />
By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item. <br />
<br />
== Bootloader prompt ==<br />
<br />
=== Accessing the bootloader prompt ===<br />
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).<br />
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.<br />
<br />
Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.<br />
<br />
The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.<br />
<br />
==== Using usbtty from Linux ====<br />
<br />
Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])<br />
<br />
Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)<br />
cu -l /dev/ttyACM0<br />
<br />
You might need to <br />
chown uucp.uucp /dev/ttyACM0<br />
<br />
to get the necessary right (even as root).<br />
<br />
A better alternative for cu is Werner Almesbergers neocon at http://svn.openmoko.org/developers/werner/neocon/.<br />
Just download the source code into a direcory of your choice and compile with <br />
make<br />
<br />
Use<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
to connect to the bootloader. As opposed to cu, neocon will allow you to paste commands directly from clipboard without making u-boot choke on it. neocon an be started without /dev/ttyACM0 beeing available. It willa automatically connect as soon as you start u-boot on the Neo. You don't have to be root either to access /dev/ttyACM0 with neocon. Beeing member of dialout should give you sufficient privileges. To getrid of neocon issue a<br />
killall neocon<br />
<br />
First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:<br />
<br />
# lsusb -d 1457:5119<br />
Bus 005 Device 079: ID 1457:5119 <br />
<br />
Second, lets see some more details about the available endpoints and configurations:<br />
<br />
<pre><br />
# lsusb -v -d 1457:5119<br />
Bus 005 Device 079: ID 1457:5119 <br />
Device Descriptor:<br />
bLength 18<br />
bDescriptorType 1<br />
bcdUSB 1.10<br />
bDeviceClass 2 Communications<br />
bDeviceSubClass 0 <br />
bDeviceProtocol 0 <br />
bMaxPacketSize0 16<br />
idVendor 0x1457 <br />
idProduct 0x5119 <br />
bcdDevice 0.00<br />
iManufacturer 1 OpenMoko, Inc<br />
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3<br />
iSerial 3 0000000<br />
bNumConfigurations 1<br />
Configuration Descriptor:<br />
bLength 9<br />
bDescriptorType 2<br />
wTotalLength 85<br />
bNumInterfaces 3<br />
bConfigurationValue 1<br />
iConfiguration 4 TTY via USB<br />
bmAttributes 0xc0<br />
Self Powered<br />
MaxPower 0mA<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 0<br />
bAlternateSetting 0<br />
bNumEndpoints 1<br />
bInterfaceClass 2 Communications<br />
bInterfaceSubClass 2 Abstract (modem)<br />
bInterfaceProtocol 1 AT-commands (v.25ter)<br />
iInterface 6 Control Interface<br />
CDC Header:<br />
bcdCDC 0.6e<br />
CDC Call Management:<br />
bmCapabilities 0x00<br />
bDataInterface 1<br />
CDC ACM:<br />
bmCapabilities 0x00<br />
CDC Union:<br />
bMasterInterface 0<br />
bSlaveInterface 1 <br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x81 EP 1 IN<br />
bmAttributes 3<br />
Transfer Type Interrupt<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 1<br />
bAlternateSetting 0<br />
bNumEndpoints 2<br />
bInterfaceClass 10 CDC Data<br />
bInterfaceSubClass 0 Unused<br />
bInterfaceProtocol 0 <br />
iInterface 5 Bulk Data Interface<br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x02 EP 2 OUT<br />
bmAttributes 2<br />
Transfer Type Bulk<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x83 EP 3 IN<br />
bmAttributes 2<br />
Transfer Type Bulk<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 2<br />
bAlternateSetting 0<br />
bNumEndpoints 0<br />
bInterfaceClass 254 Application Specific Interface<br />
bInterfaceSubClass 1 Device Firmware Update<br />
bInterfaceProtocol 1 <br />
iInterface 7 USB Device Firmware Upgrade<br />
Device Status: 0x0001<br />
Self Powered<br />
</pre><br />
<br />
Next, you can access it using your favourite terminal program.<br />
<br />
Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:<br />
<pre><br />
GTA01Bv2 # setenv stderr usbtty<br />
GTA01Bv2 # setenv stdout usbtty<br />
GTA01Bv2 # setenv stdin usbtty<br />
</pre><br />
<br />
==== Typical u-boot prompt ====<br />
<br />
<pre><br />
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)<br />
<br />
DRAM: 128 MB<br />
NAND: 64 MiB<br />
Found Environment offset in OOB..<br />
Video: 640x480x8 31kHz 59Hz<br />
USB: S3C2410 USB Deviced<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
Hit any key to stop autoboot: 0 <br />
GTA01Bv3 #<br />
</pre><br />
<br />
=== Commands on the bootloader prompt ===<br />
<br />
:''See [[bootloader commands]].''<br />
<br />
<br />
== Device Firmware Upgrade ==<br />
<br />
Our version of u-boot also implements [[USB DFU]]. This can be useful to<br />
load files and kernel for quick testing.<br />
<br />
To find out whether your version of u-boot supports this, use the output of<br />
$ lsusb -v -d 1457:5119<br />
while the phone is in u-boot mode.<br />
<br />
If it supports DFU, you should see the following snippet towards the end of the output:<br />
<pre><br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 2<br />
bAlternateSetting 0<br />
bNumEndpoints 0<br />
bInterfaceClass 254 Application Specific Interface<br />
bInterfaceSubClass 1 Device Firmware Update<br />
bInterfaceProtocol 1 <br />
iInterface 0 <br />
</pre><br />
<br />
For information on how to do firmware upgrades, please see [[dfu-util]].<br />
<br />
=== Booting files over DFU ===<br />
<br />
To load a file at memory address 0x32000000:<br />
<pre><br />
dfu-util -a 0 -D fileToLoad -R<br />
</pre><br />
<br />
After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if<br />
its an elf file.<br />
<br />
Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.<br />
<br />
<pre><br />
#!/usr/bin/python<br />
import sys<br />
import os<br />
import time<br />
<br />
cmd1 = "neo backlight off\n"<br />
cmd2 = "bootelf 0x32000000\n"<br />
<br />
def output(tty, str):<br />
for x in str:<br />
tty.write(x)<br />
tty.flush()<br />
<br />
if len(sys.argv) == 2:<br />
print "Loading %s..." % sys.argv[1]<br />
<br />
loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]<br />
<br />
os.system(loadfile)<br />
<br />
time.sleep(3)<br />
<br />
tty = open("/dev/ttyACM0", "a")<br />
<br />
output(tty, cmd1)<br />
output(tty, cmd2)<br />
<br />
tty.close()<br />
else:<br />
print "Usage: %s elffile" % sys.argv[0]<br />
print ""<br />
sys.exit(2)<br />
</pre><br />
<br />
== Troubleshooting ==<br />
<br />
=== USB connectivity problems ===<br />
<br />
I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:<br />
<br />
usb 2-1: device descriptor read/64, error -110<br />
usb usb2: Controller not stopped yet!<br />
<br />
The problem disappeared at least for me by the command below on the host side. Please note that if you have usb keyboard or mouse then the command might cause trouble.. I only have PS/2 so I couldn't test it.<br />
<br />
rmmod uhci_hcd ; modprobe uhci_hcd<br />
<br />
{{Languages|Bootloader}}<br />
<br />
[[Category:Software]]<br />
[[Category:Guides]]</div>Lokomokohttp://openmoko.org/wiki/U-BootU-Boot2008-02-27T21:34:34Z<p>Lokomoko: /* Using usbtty from Linux */</p>
<hr />
<div>[[Image:GTA01-U-Boot.JPG|thumb|300px|u-boot menu on Neo1973]] [[Image:Neo1973 uboot splash closeup.jpg|thumb|300px|u-boot splash screen on Neo1973]]<br />
<br />
The bootloader on the [[Neo1973]], '''U-Boot''', takes care of device functionality until [[OpenMoko]] is booted. This includes [[USB DFU]] for [[flashing openmoko]], a splash screen, a boot menu, a console for [[bootloader commands]], configuration via [[bootloader environment]], and loading a [[kernel]]. <br />
<br />
There are various [[bootloader versions]] available.<br />
<br />
== Phase0 Quick Start ==<br />
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.<br />
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.<br />
* Hold in the AUX button on power-up to access the boot menu.<br />
* Set the console to USB.<br />
* Connect to /dev/ttyACM0 with a terminal program on the Linux host (you might need to chown uucp.uucp /dev/ttyACM0 )<br />
* Note that the cdc_acm /dev/ttyACM0 access disappears as soon as the Neo boots, and is replaced by the cdc_ether usb0 network access.<br />
* You're now at the bootloader prompt.<br />
* Set the bootdelay uboot environment variable to -1 if you want it to always halt at the bootloader on power-up.<br />
<br />
== General ==<br />
<br />
The GTA01 uses the [http://u-boot.sourceforge.net/ u-boot] bootloader.<br />
<br />
More information on u-boot can be found at <br />
* http://www.denx.de/wiki/DULG<br />
* http://www.gumstix.org/tikiwiki/tiki-index.php?page=U-Boot<br />
* http://linuxdevices.com/articles/AT5085702347.html<br />
<br />
Additions to the vanilla u-boot already implemented include: <br />
* Support for boot from NAND flash using [[S3C2410 Steppingstone]]<br />
* Support for S3C2410 NAND flash<br />
* Support for downloading programs via S3C2410 USB Device Controller<br />
* Support to display bootup logo / status on S3C2410 Framebuffer<br />
<br />
However, u-boot still doesn't support many of the features that GTA01 needs, such as<br />
* Support for reading kernel/initrd from SD/Transflash<br />
<br />
[[User:HaraldWelte|HaraldWelte]] is working on those issues, and in fact most of them have already been implemented.<br />
<br />
== Bootloader source code ==<br />
<br />
The current bootloader patches can be found at http://svn.openmoko.org/trunk/src/target/u-boot/patches/. <br />
<br />
Untar the sources, apply the patch, run "make gta01bv3_config" (or gta01bv2_config, or whatever hardware revision you have), run "make". You will get a resulting "u-boot.bin" image, which you can directly flash (either using existing bootloader or [[sjf2410-linux]]) into NAND.<br />
<br />
== Bootloader binary ==<br />
<br />
The latest bootloader binary builds can be found under http://buildhost.openmoko.org/snapshots in the subdirectory 200X.XX/images/. It should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[partition]]).<br />
<br />
== Bootloader development ==<br />
<br />
=== QT2410 ===<br />
If you want to do bootloader development on the QT2410, it's easier to work with a bootloader image that can be downloaded via USB into RAM instead of flashing.<br />
<br />
To do so, you need to edit the u-boot/include/configs/qt2410.h file, and change the "if 0" in Line 32 into a "if 1", then recompile with "make".<br />
<br />
The resulting "u-boot.bin" is _NOT SUITABLE_ for NAND flash, but only for direct execution from within ram, e.g. by using the [[s3c2410_boot_usb]] program.<br />
<br />
=== GTA01 ===<br />
<br />
Doing bootloader development on the GTA01 is a bit more tricky. first, we don't have any NOR flash. Second, there is no other way to boot _but_ from NAND. Therefore, we also don't have a USB downloader like the QT2410.<br />
<br />
The main problem is: The [[S3C2410 Steppingstone]] unconditionally copies the first 4k of flash into its internal SRAM. That SRAM segment stays unconditionally mapped at physical address zero. How do we get around this<br />
<br />
==== Using JTAG to boot from RAM ====<br />
<br />
So how can we boot from RAM? We use JTAG / OpenOCD to<br />
<br />
* Reset and halt the cpu at PC=0<br />
<pre><br />
> reset halt<br />
target halted in ARM state due to debug request, current mode: Supervisor<br />
cpsr: 0x400000d3 pc: 0x00000000<br />
MMU: disabled, D-Cache: disabled, I-Cache: disabled<br />
</pre><br />
<br />
* Download a small piece of code for low-level SDRAM timing initialization (overwrite 4k SRAM of steppingstone)<br />
<pre><br />
> load_binary /space/misc/gta01/u-boot.git/board/gta01/lowlevel_foo.bin 0 <br />
downloaded 332 byte in 0s 21899us<br />
</pre><br />
<br />
* Assert a break point at address 0x33f80000 (which indicates that the low-level code has finished)<br />
<pre><br />
> bp 0x33f80000 4 hw<br />
breakpoint added at address 0x33f80000<br />
</pre><br />
<br />
* Run the code up to the break point<br />
<pre><br />
> resume<br />
Target 0 resumed<br />
> Target 0 halted<br />
target halted in ARM state due to breakpoint, current mode: Supervisor<br />
cpsr: 0x600000d3 pc: 0x33f80000<br />
MMU: disabled, D-Cache: disabled, I-Cache: enabled<br />
</pre><br />
<br />
* Download the u-boot RAM image to 0x33f80000<br />
<pre><br />
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin 0x33f80000<br />
downloaded 135692 byte in 6s 567264us<br />
</pre><br />
<br />
* Resume processing<br />
<pre><br />
> resume<br />
Target 0 resumed<br />
</pre><br />
<br />
At this point, the display backlight gets bright and we see the following familiar prompt on the serial console:<br />
<pre><br />
U-Boot 1.1.6 (Jan 13 2007 - 23:44:23)<br />
<br />
DRAM: 128 MB<br />
NAND: 64 MiB<br />
*** Warning - bad CRC or NAND, using default environment<br />
<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
Hit any key to stop autoboot: 0 <br />
GTA01Bv2 # <br />
</pre><br />
<br />
== Creating bootable images ==<br />
<br />
u-boot needs bootable images (such as kernels, but also initrd and others) in form of a so-called ''uImage''. In order to create a ''uImage'' from e.g. a ''vmlinux'' kernel image, you can proceed as follows:<br />
<br />
<pre><br />
objcopy -O binary -R .note -R .comment -S vmlinux linux.bin<br />
gzip -9 linux.bin<br />
u-boot/tools/mkimage -A arm -O linux -T kernel -C gzip -a 30008000 -e 30008000 -n "Kernel Image QT2410" -d linux.bin.gz uImage<br />
</pre><br />
<br />
== Boot menu ==<br />
[[Image:Neo1973 uboot menu.jpg|thumb|400px|u-boot boot menu on Neo1973]]<br />
<br />
As of the Phase-0 release, our u-boot version now features an on-screen boot menu. The items are defined by [[bootloader environment#menu|menu entries in the environment]].<br />
<br />
=== Accessing the boot menu ===<br />
<br />
You can access the boot menu by pressing and holding the [[Neo1973 AUX Button]] together with the power button while switching the phone on.<br />
<br />
=== Using the boot menu ===<br />
<br />
By pressing the [[Neo1973 AUX Button]] you can cycle through the menu items. Use the ''POWER'' button to select one item. <br />
<br />
== Bootloader prompt ==<br />
<br />
=== Accessing the bootloader prompt ===<br />
The bootloader prompt is available either on the serial console (via [[Debug Board]]), or as virtual USB Serial device (USB CDC_ACM).<br />
Whether the serial port or usb is used depends on the u-boot environment variables '''stdin''', '''stdout''' and '''stderr'''.<br />
<br />
Whether or not you use usbtty, the first couple of messages will always be displayed on the serial console.<br />
<br />
The bootloader is currently configured to wait for three seconds. If a key press on the '''stdin''' is received within those three seconds, auto-boot is aborted.<br />
<br />
==== Using usbtty from Linux ====<br />
<br />
Just by connecting the phone in u-boot mode to your Linux pc should make it detect a [[CDC ACM]] device, and you should get a new tty device called /dev/ttyACM0. If not, enable the CONFIG_USB_ACM (Device Drivers -> USB support -> USB Modem (CDC ACM) support). (Instructions for MacOS users are [[MacOS_X#USB_Serial|here]])<br />
<br />
Use your favourite terminal emulator (minicom, cu, zc, screen ...) to access it like any other serial port. If you don't have a favorite, try just: (cu is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed)<br />
cu -l /dev/ttyACM0<br />
<br />
You might need to <br />
chown uucp.uucp /dev/ttyACM0<br />
<br />
to get the necessary right (even as root).<br />
<br />
A better alternative for cu is Werner Almesbergers neocon at http://svn.openmoko.org/developers/werner/neocon/.<br />
Just download the source code into a direcory of your choice and compile with <br />
make<br />
<br />
Use<br />
./neocon -t 30 /dev/ttyACM0<br />
<br />
to connect to the bootloader. As opposed to cu, neocon will allow you to paste commands directly from clipboard without making u-boot choke on it. You don't have to be root to access /dev/ttyACM0 with neocon. Beeing member of dialout should give you sufficient privileges.<br />
<br />
First, you should try to check whether the USB device shows up in 'lsusb' while you're running in u-boot mode:<br />
<br />
# lsusb -d 1457:5119<br />
Bus 005 Device 079: ID 1457:5119 <br />
<br />
Second, lets see some more details about the available endpoints and configurations:<br />
<br />
<pre><br />
# lsusb -v -d 1457:5119<br />
Bus 005 Device 079: ID 1457:5119 <br />
Device Descriptor:<br />
bLength 18<br />
bDescriptorType 1<br />
bcdUSB 1.10<br />
bDeviceClass 2 Communications<br />
bDeviceSubClass 0 <br />
bDeviceProtocol 0 <br />
bMaxPacketSize0 16<br />
idVendor 0x1457 <br />
idProduct 0x5119 <br />
bcdDevice 0.00<br />
iManufacturer 1 OpenMoko, Inc<br />
iProduct 2 Neo1973 Bootloader U-Boot 1.2.0-g6c7cac8c-dirty-moko3<br />
iSerial 3 0000000<br />
bNumConfigurations 1<br />
Configuration Descriptor:<br />
bLength 9<br />
bDescriptorType 2<br />
wTotalLength 85<br />
bNumInterfaces 3<br />
bConfigurationValue 1<br />
iConfiguration 4 TTY via USB<br />
bmAttributes 0xc0<br />
Self Powered<br />
MaxPower 0mA<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 0<br />
bAlternateSetting 0<br />
bNumEndpoints 1<br />
bInterfaceClass 2 Communications<br />
bInterfaceSubClass 2 Abstract (modem)<br />
bInterfaceProtocol 1 AT-commands (v.25ter)<br />
iInterface 6 Control Interface<br />
CDC Header:<br />
bcdCDC 0.6e<br />
CDC Call Management:<br />
bmCapabilities 0x00<br />
bDataInterface 1<br />
CDC ACM:<br />
bmCapabilities 0x00<br />
CDC Union:<br />
bMasterInterface 0<br />
bSlaveInterface 1 <br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x81 EP 1 IN<br />
bmAttributes 3<br />
Transfer Type Interrupt<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 1<br />
bAlternateSetting 0<br />
bNumEndpoints 2<br />
bInterfaceClass 10 CDC Data<br />
bInterfaceSubClass 0 Unused<br />
bInterfaceProtocol 0 <br />
iInterface 5 Bulk Data Interface<br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x02 EP 2 OUT<br />
bmAttributes 2<br />
Transfer Type Bulk<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Endpoint Descriptor:<br />
bLength 7<br />
bDescriptorType 5<br />
bEndpointAddress 0x83 EP 3 IN<br />
bmAttributes 2<br />
Transfer Type Bulk<br />
Synch Type None<br />
Usage Type Data<br />
wMaxPacketSize 0x0010 1x 16 bytes<br />
bInterval 255<br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 2<br />
bAlternateSetting 0<br />
bNumEndpoints 0<br />
bInterfaceClass 254 Application Specific Interface<br />
bInterfaceSubClass 1 Device Firmware Update<br />
bInterfaceProtocol 1 <br />
iInterface 7 USB Device Firmware Upgrade<br />
Device Status: 0x0001<br />
Self Powered<br />
</pre><br />
<br />
Next, you can access it using your favourite terminal program.<br />
<br />
Then, if the environment is not set correctly, you will need to use the current console (e.g. serial console) to change the [[bootloader environment#console|console entries in the environment]]:<br />
<pre><br />
GTA01Bv2 # setenv stderr usbtty<br />
GTA01Bv2 # setenv stdout usbtty<br />
GTA01Bv2 # setenv stdin usbtty<br />
</pre><br />
<br />
==== Typical u-boot prompt ====<br />
<br />
<pre><br />
U-Boot 1.2.0-moko1 (Feb 16 2007 - 00:36:13)<br />
<br />
DRAM: 128 MB<br />
NAND: 64 MiB<br />
Found Environment offset in OOB..<br />
Video: 640x480x8 31kHz 59Hz<br />
USB: S3C2410 USB Deviced<br />
In: serial<br />
Out: serial<br />
Err: serial<br />
Hit any key to stop autoboot: 0 <br />
GTA01Bv3 #<br />
</pre><br />
<br />
=== Commands on the bootloader prompt ===<br />
<br />
:''See [[bootloader commands]].''<br />
<br />
<br />
== Device Firmware Upgrade ==<br />
<br />
Our version of u-boot also implements [[USB DFU]]. This can be useful to<br />
load files and kernel for quick testing.<br />
<br />
To find out whether your version of u-boot supports this, use the output of<br />
$ lsusb -v -d 1457:5119<br />
while the phone is in u-boot mode.<br />
<br />
If it supports DFU, you should see the following snippet towards the end of the output:<br />
<pre><br />
Interface Descriptor:<br />
bLength 9<br />
bDescriptorType 4<br />
bInterfaceNumber 2<br />
bAlternateSetting 0<br />
bNumEndpoints 0<br />
bInterfaceClass 254 Application Specific Interface<br />
bInterfaceSubClass 1 Device Firmware Update<br />
bInterfaceProtocol 1 <br />
iInterface 0 <br />
</pre><br />
<br />
For information on how to do firmware upgrades, please see [[dfu-util]].<br />
<br />
=== Booting files over DFU ===<br />
<br />
To load a file at memory address 0x32000000:<br />
<pre><br />
dfu-util -a 0 -D fileToLoad -R<br />
</pre><br />
<br />
After that, send 'bootm 0x32000000' to u-boot or 'bootelf 0x32000000' if<br />
its an elf file.<br />
<br />
Simple python script that can boot an ELF image - avoiding a ACM bug that breaks on large packets.<br />
<br />
<pre><br />
#!/usr/bin/python<br />
import sys<br />
import os<br />
import time<br />
<br />
cmd1 = "neo backlight off\n"<br />
cmd2 = "bootelf 0x32000000\n"<br />
<br />
def output(tty, str):<br />
for x in str:<br />
tty.write(x)<br />
tty.flush()<br />
<br />
if len(sys.argv) == 2:<br />
print "Loading %s..." % sys.argv[1]<br />
<br />
loadfile = "dfu-util -a 0 -D %s -R" % sys.argv[1]<br />
<br />
os.system(loadfile)<br />
<br />
time.sleep(3)<br />
<br />
tty = open("/dev/ttyACM0", "a")<br />
<br />
output(tty, cmd1)<br />
output(tty, cmd2)<br />
<br />
tty.close()<br />
else:<br />
print "Usage: %s elffile" % sys.argv[0]<br />
print ""<br />
sys.exit(2)<br />
</pre><br />
<br />
== Troubleshooting ==<br />
<br />
=== USB connectivity problems ===<br />
<br />
I once got errors like this (in dmesg or /var/log/messages) on the host side while connecting the neo in u-boot:<br />
<br />
usb 2-1: device descriptor read/64, error -110<br />
usb usb2: Controller not stopped yet!<br />
<br />
The problem disappeared at least for me by the command below on the host side. Please note that if you have usb keyboard or mouse then the command might cause trouble.. I only have PS/2 so I couldn't test it.<br />
<br />
rmmod uhci_hcd ; modprobe uhci_hcd<br />
<br />
{{Languages|Bootloader}}<br />
<br />
[[Category:Software]]<br />
[[Category:Guides]]</div>Lokomokohttp://openmoko.org/wiki/Community_ResourcesCommunity Resources2007-11-13T23:13:03Z<p>Lokomoko: /* Project Resources */</p>
<hr />
<div>All resources listed here are available to the general public. Everyone is invited to participate.<br />
<br />
=== Mailing Lists ===<br />
<br />
There are a number of development related mailinglists at http://lists.openmoko.org/<br />
if you feel uncomfortable using mailing lists, you can use [http://gmane.org gmane] forum-like interface.<br />
<br />
<br />
<br />
==== announce@lists.openmoko.org ====<br />
<br />
A read-only list where the project does official announcements. <br />
<br />
We strongly recommend subscribing to this list if you want to stay up-to-date with the major project achievements.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/announce<br />
<br />
Gmane: http://news.gmane.org/gmane.comp.handhelds.openmoko.announce<br />
<br />
==== buglog@lists.openmoko.org ====<br />
<br />
A read-only list where every status update to a bug (bugzilla entry) will get posted. <br />
<br />
Nice to keep updated on the bug squashing progress.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/buglog<br />
<br />
Gmane: http://news.gmane.org/gmane.comp.handhelds.openmoko.buglog<br />
<br />
==== commitlog@lists.openmoko.org ====<br />
<br />
A read-only list where every source code change (commit to the subversion server) gets posted. <br />
<br />
Nice to keep posted on development progress.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/commitlog<br />
<br />
==== community@lists.openmoko.org ====<br />
<br />
This is a public mailinglist for generic discussion of our user + developer community.<br />
<br />
It acts as a place where people discuss their dreams/wishes/ideas about OpenMoko software and supported hardware, applications, and the like. It's an area of general talking and chatting.<br />
<br />
Please Do not post usage or development questions here.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/community<br />
<br />
Gmane: http://news.gmane.org/gmane.comp.handhelds.openmoko.community<br />
<br />
==== distro-devel@lists.openmoko.org ====<br />
<br />
This is a mailinglist on the OpenMoko Distribution. <br />
<br />
Here issues such as ipk packaging related and root fs image related topics should be discussed. Also, questions regarding the OpenEmbedded based build process go here.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/distro-devel<br />
<br />
Gmane: http://news.gmane.org/gmane.comp.handhelds.openmoko.distro<br />
<br />
==== framework-devel@lists.openmoko.org ====<br />
<br />
This is a mailinglist on the OpenMoko Framework.<br />
<br />
Please use this list to post questions with regard to the OpenMoko Framework, the API's, their usage, API change requests and the like.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/framework-devel<br />
<br />
Gmane: http://news.gmane.org/gmane.comp.handhelds.openmoko.framework<br />
<br />
==== gsmd-devel@lists.openmoko.org ====<br />
<br />
This is a mailinglist on the OpenMoko gsmd (GSM daemon) and the corresponding libgsmd.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/gsmd-devel<br />
<br />
Gmane: http://news.gmane.org/gmane.comp.handhelds.openmoko.gsmd<br />
<br />
==== openmoko-apps@lists.openmoko.org ====<br />
<br />
This is a public mailinglist about the development of the "official" OpenMoko applications, e.g. openmoko-dialer, openmoko-dates, openmoko-contacts, openmoko-mainmenu, openmoko-today.<br />
<br />
Please do not use this list for issues related to third party applications.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/openmoko-apps/<br />
<br />
Gmane: http://news.gmane.org/gmane.comp.handhelds.openmoko.apps<br />
<br />
==== openmoko-devel@lists.openmoko.org ====<br />
<br />
This is a public mailinglist for discussion of development of "third party applications". <br />
<br />
Developers who are writing applications using the OpenMoko framework should join this.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/openmoko-devel<br />
<br />
==== openmoko-kernel@lists.openmoko.org ====<br />
<br />
This is a public mailinglist for discussion of development of kernel.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/openmoko-kernel<br />
<br />
Gmane: http://news.gmane.org/gmane.comp.handhelds.openmoko.kernel<br />
<br />
<br />
==== device-owners@lists.openmoko.org ====<br />
<br />
This is a public mailinglist for discussion among actual owners of an OpenMoko based device.<br />
<br />
Here you can ask for assistance, share your experiences, etc.<br />
<br />
Please keep this list clean of any philosophical debates or general openmoko related discussion.<br />
That's what ''community@lists.openmoko.org'' is for!<br />
<br />
http://lists.openmoko.org/mailman/listinfo/device-owners<br />
<br />
==== webdesign-commitlog@lists.openmoko.org ====<br />
<br />
This is a public read-only mailinglist receiving commit log messages of our web designers. <br />
<br />
Subscribe to this list if you want to get notified if some of the static content or the templates/skins of our websites change.<br />
<br />
http://lists.openmoko.org/mailman/listinfo/webdesign-commitlog<br />
<br />
=== Wiki ===<br />
<br />
This Wiki is our public wiki, http://wiki.openmoko.org/. You're already in it, if you're reading this.<br><br />
Due to continued defacements/spam we were forced to limit editing in this wiki to registered users which provide a working email address. sorry for that.<br />
<br />
=== Bugzilla ===<br />
<br />
Our bug tracking system for software issues is available at http://bugzilla.openmoko.org/<br />
<br />
=== IRC ===<br />
<br />
There's a #openmoko channel on irc.freenode.net: irc://irc.freenode.net/openmoko<br />
<br />
If you experience any build problems and need help from other developers, it is important that you share your complete output log. To share your output log, just paste it to [http://www.pastebin.ca/ pastebin] or [http://celpaste.morb-design.com/ celpaste] (celpaste is especially for Openmoko) and after submitting it, paste the resulting URL to the IRC channel.<br />
<br />
Thanks to the NSLU2-Linux project, we also have the IRC logs available.<br />
Current 24h live log is always at: http://logs.nslu2-linux.org/livelogs/openmoko.txt<br />
<br />
Previous 24h log is always at: http://logs.nslu2-linux.org/livelogs/openmoko-prev.txt<br />
<br />
Archives back to 29 November 2006 at: http://logs.nslu2-linux.org/livelogs/openmoko/<br />
<br />
=== SVN ===<br />
<br />
There is a [http://subversion.tigris.org/ Subversion] server available at svn.openmoko.org. <br />
<br />
Read-only access is provided via http://svn.openmoko.org/.<br />
<br />
Read-write access for developers is provided via https://svn.openmoko.org/<br />
<br />
Web access for occasional browsing is available via http://svnweb.openmoko.org/<br />
<br />
If you need help, please read more about [[Using Subversion]].<br />
<br />
==== SVN Tree Layout ====<br />
<br />
The Subversion (svn) tree is laid out as follows:<br />
<br />
* trunk (main branch, similar to CVS "HEAD")<br />
** src (program source code)<br />
*** host (programs that work on the host PC)<br />
**** sjf2410-linux<br />
**** ...<br />
*** target (programs that work on the target device)<br />
**** dialer<br />
**** package_manager<br />
**** ...<br />
** doc (Documentation) <br />
*** ...<br />
* branches (branches, created by lead developers if required)<br />
** src<br />
*** host<br />
**** ...<br />
*** target<br />
**** ...<br />
* developers (private/experimental branches, created by individual developers)<br />
** laforge<br />
*** ...<br />
** sean<br />
** mickey<br />
*** ...<br />
** ...<br />
* releases (official 'releases' of code in 'trunk' or 'branches')<br />
** src<br />
*** host<br />
**** ...<br />
*** target<br />
**** ...<br />
<br />
=== Projects ===<br />
<br />
at http://projects.openmoko.org/ we have a GForge installation. Users can use this as hosting service for their contributed applications.<br />
<br />
== Internal resources ==<br />
<br />
There are some resources which are internal. This means that they are only available for internal developers of FIC / Openmoko Inc. The reason they are internal is either because they deal with information under NDA, or about business strategy. We kindly ask for your understanding that while we really try to be as open as possible, there are some topics which we have to discuss without public participation.<br />
<br />
The internal systems have the domain ''*.internal.openmoko.org''.<br />
<br />
=== IRC ===<br />
<br />
There's a #openmoko channel on irc.freenode.net.<br />
<br />
There's also a #openmoko-devel channel, which is for OpenMoko internal developers only, sorry.<br />
<br />
== Local Community ==<br />
<br />
See the [[OpenMoko_Local_Groups|OpenMoko Local Groups]]<br />
<br />
== Project Resources ==<br />
<br />
* [[Development resources]] - Describes the resources (lists, svn,&nbsp;...)<br />
** [[Development resources#Mailing_Lists|Mailing Lists]]<br />
** [[Development resources#Wiki|Wiki]]<br />
** [[Development resources#Bugzilla|Bugzilla]]<br />
** [[Development resources#IRC|IRC]]<br />
** [[Development resources#SVN|svn + svnweb]]<br />
** [[Development resources#Projects|Projects]]<br />
** Firmware images (see also [[Repositories]])<br />
*** [http://buildhost.openmoko.org/snapshots/ Snapshots]<br />
*** [http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/fic-gta01/ Unstable images (old location - currently not available)]<br />
*** [http://buildhost.openmoko.org/OM2007.2/tmp/deploy/glibc/images/neo1973/ Unstable images (new location)]<br />
*** Releases (none exist so far)<br />
<br />
{{Languages|Development_resources}}<br />
<br />
[[Category:Developer]]</div>Lokomoko