http://openmoko.org/api.php?action=feedcontributions&user=Johnny9&feedformat=atomOpenmoko - User contributions [en]2024-03-28T08:40:13ZUser contributionsMediaWiki 1.19.24http://openmoko.org/wiki/Qt_Extended_ImprovedQt Extended Improved2009-05-11T17:34:51Z<p>Johnny9: no need for temporary directory when unpacking the qtextended improved tarballs to the phone</p>
<hr />
<div><h2>Community Resources</h2><br />
<br />
Qt Software cancelled the Qt Extended project on 3 March 2009 ([http://www.qtsoftware.com/about/news/qt-software-discontinues-qt-extended Qt Software discontinues Qt Extended]). The community created a fork of it and called it Qt Extended Improved:<br />
<br />
* [http://trac.karadog.net/qt-extended-improved bug tracking system]<br />
* [http://dashi-x02.karadog.net/~lihouyu/qtextended/4.4.3/ prebuilt rootfs images for 4.4.3 and kernel]<br />
* [http://dashi-x02.karadog.net/~lihouyu/qtextended/snapbuild/ prebuilt tarballs of qt extended improved] (use kernel made for 4.4.3)<br />
* [http://git.karadog.net/qt-extended-improved.git git repository]<br />
<br />
<h2>Installing Qt Extended Improved on the FreeRunner</h2><br />
<br />
<h3>Install Qt Extended 4.4.3</h3><br />
<br />
There are no rootfs images for Qt Extended Improved, so first we need to install Qt Extended 4.4.3, then we can upgrade to Qt Extended Improved. Follow the instructions at [[Qt Extended 4.4.3]].<br />
<br />
<h3>Install Qt Extended Improved</h3><br />
<br />
Boot your FreeRunner into Qt Extended 4.4.3. Create a USB network connection between your workstation and the FreeRunner. Download the most recent [http://dashi-x02.karadog.net/~lihouyu/qtextended/snapbuild/ pre-built tarball]. Now you must unpack the tarball to a temporary directory and copy its contents to the FreeRunner's <tt>/opt/Trolltech/Qtopia</tt> directory:<br />
<br />
mkdir temp<br />
cd temp<br />
tar -xzvf ../qt-extended-improved-bin-only-20090316.tar.gz <br />
scp -r * 192.168.0.202:/opt/Trolltech/Qtopia/<br />
this can be resumed in a simpler and quicker operation:<br />
( dd if=../qt-extended-improved-bin-only-20090316.tar.gz ) | ( ssh 192.168.0.202 "cd /opt/Trolltech/Qtopia/ && tar xzv" )<br />
<br />
Reboot your FreeRunner and you should be running Qt Extended Improved.<br />
<br />
<h2>Building Qt Extended Improved</h2><br />
<br />
First download a source tar ball from the [http://git.karadog.net/qt-extended-improved.git git repository]. Then make the build directory and set the environment variables. In this example, I write the environment variables to a file then I source the file.<br />
<br />
mkdir -p /opt/QtExtended/build<br />
cd /opt/QtExtended<br />
tar -xzvf qt-extended-improved.tar.gz<br />
echo "export QTOPIA_DEPOT_PATH=/opt/QtExtended/qt-extended-improved" >> setpaths <br />
echo "export QPEDIR=/opt/QtExtended/build/" >> setpaths<br />
. setpaths<br />
<br />
Install the toolchain:<br />
<br />
cd /opt<br />
wget http://qtextended.org/downloads/toolchains/arm920t-eabi.tgz<br />
tar xzvf arm920t-eabi.tgz /<br />
<br />
Do the linux three-step: configure, make, make install. Plus we build the sdk so we can make our own apps later, if we want.<br />
<br />
cd $QPEDIR<br />
$QTOPIA_DEPOT_PATH/configure -device neo -D _FORTIFY_SOURCE=0<br />
make<br />
make install<br />
bin/qbuild sdk<br />
<br />
The binaries are in the $QPEDIR/image directory. You can copy these to your freerunner over usb like this:<br />
<br />
scp -r $QPEDIR/image/* 192.168.0.202:/opt/Trolltech/Qtopia/<br />
<br />
<h2>Compiling an Example Qt Extended App</h2><br />
<br />
First set those indispensable Qt environment variables:<br />
<br />
. /opt/QtExtended/setpaths<br />
<br />
Next create a directory <tt>/opt/Qtopia/build/myapps</tt>. Copy the example app. Rename the example app to something that makes sense (how about "example"!). Create the <tt>Makefile</tt> and build the example.<br />
<br />
desktop# mkdir /opt/QtExtended/build/myapps<br />
desktop# cd /opt/QtExtended/build/myapps<br />
desktop# cp -R $QTOPIA_DEPOT_PATH/examples/application .<br />
desktop# mv application example<br />
desktop# cd example<br />
desktop# $QPEDIR/bin/qbuild<br />
<br />
Now you have an executable <tt>example</tt>. It won't execute on your workstation - you must secure copy it to your FreeRunner. Then secure shell into the FreeRunner, import the Qtopia environment variables and execute the app:<br />
<br />
desktop# scp example root@freerunner:/home/root<br />
root@192.168.0.202's password: <br />
example 100% 33KB 33.4KB/s 00:00 <br />
desktop# ssh 192.168.0.202<br />
root@freerunner's password: <br />
freerunner:~# . /opt/Trolltech/Qtopia/qpe.env <br />
freerunner:~# ./example<br />
<br />
This is what you should see on the screen (click on image to zoom) : [[Image:Qt_extended_sdk_example_screenshot.png|100px]]<br />
<br />
<h2>Packaging</h2><br />
<br />
Create a .qpk file, an installable package:<br />
<br />
desktop# $QPEDIR/bin/qbuild packages<br />
<br />
Create a packages.list file for the software installer and put it in the http server root:<br />
<br />
desktop# sudo $QTOPIA_DEPOT_PATH/bin/mkPackages /srv/www/htdocs/<br />
<br />
Copy your new package to the http server root:<br />
<br />
desktop# sudo cp pkg/*.qpk /srv/www/htdocs/<br />
<br />
On your phone, find Settings > Software Packages; press the Downloads tab; go to Options > Edit Servers; Options > New; then enter a name and URL of http://192.168.0.200:80, or the URL for your web server. The software package manager should then be able to see $HTTPROOT/packages.list and install any packages you have.<br />
<br />
<h2>mp3 Support</h2><br />
<br />
If you compile your own version of Qt Extended Improved, you can add mp3 support using [http://radagast.bglug.ca/openmoko/qt-extended-4.4.3-libmad.tar.gz this patch]. Untar the file from your qt-extended-improved directory (it installs some files in the src tree) and patch using the patch file, eg:<br />
<br />
desktop# cd $QTOPIA_DEPOT_PATH<br />
desktop# tar -xzvf qt-extneded-4.4.3-libmad.tar.gz<br />
desktop# patch -p0 < qt-extended-4.4.3-libmad.patch<br />
<br />
Now configure, build, etc.<br />
<br />
<h2>Troubleshooting</h2><br />
<br />
If you encounter this error while compiling your example,<br />
<br />
<code><br />
In file included from /opt/QtExtended/build/sdk/qtopiacore/target/include/QtCore/qglobal.h:58,<br />
from /opt/QtExtended/build/sdk/qtopiacore/target/include/QtCore/qatomic.h:41,<br />
from /opt/QtExtended/build/sdk/qtopiacore/target/include/QtCore/qvariant.h:41,<br />
from /opt/QtExtended/build/sdk/qtopiacore/target/include/QtCore/QVariant:1,<br />
from /opt/QtExtended/build/myapps/example/.uic/ui_examplebase.h:13:<br />
/opt/QtExtended/build/sdk/qtopiacore/target/include/QtCore/qconfig.h:2:66: error: /opt/QtExtended/build/sdk/sdk/qtopiacore/qconfig-qpe.h: No such file or directory</code><br />
<br />
edit /opt/QtExtended/build/sdk/qtopiacore/target/include/QtCore/qconfig.h and remove one /sdk/ from /opt/QtExtended/build/sdk/sdk/qtopiacore/qconfig-qpe.h at the top of the file.<br />
<br />
<h2>Branches and Forks</h2><br />
There are various other branches and forks of qte/qtei that fix bugs or other things. List taken from http://lists.openmoko.org/pipermail/community/2009-April/046492.html<br />
<br />
<h3>Initial import of QTE 4.4.3 opensource release</h3><br />
[http://github.com/FilipBE/qtextended/tree/master Source]<br />
<br />
<h3>QT Moko</h3><br />
QTEI on Debian.<br />
<br />
[http://activationrecord.net/radekp/openmoko/qtmoko/ Homepage]<br />
<br />
[http://github.com/radekp/qtmoko/tree/master/ Source]<br />
<br />
[http://activationrecord.net/radekp/openmoko/qtmoko/download/ Rootfs/kernel]<br />
<br />
<h3>Latest and Greatest</h3><br />
Franky Van Liedekerke's branch.<br />
<br />
[http://github.com/liedekef/qtmoko/commits/master Source].<br />
<br />
[http://www.e-dynamics.be/openmoko/qt-issues.txt List of Issues].<br />
<br />
[http://www.e-dynamics.be/openmoko/qt-issues-fixed.txt Issues Fixed].<br />
<br />
[http://www.e-dynamics.be/openmoko/qtmoko_install.sh Install script and instructions]. Execute the script on the Neo.<br />
<br />
<h3>Lpotter's Branch</h3><br />
[http://github.com/lpotter/qtmoko/tree/master Source]<br />
<br />
[[Category:Advanced End User]]</div>Johnny9http://openmoko.org/wiki/Gentoo/huGentoo/hu2009-02-24T14:12:52Z<p>Johnny9: added hungarian translation</p>
<hr />
<div>= Gentoo az openmoko telefonokon =<br />
{{Languages|Gentoo}}<br />
<br />
A projectnek van egy honlapja: [http://gentoo.mindzoo.de/ http://gentoo.mindzoo.de/]<br />
<br />
A project egy openomoko-overlayt biztosit, vannak benne:<br />
* Telefon specifikus alkalmazàsok (zhone, xglamo, illume, freesmartphone-framework, stb.)<br />
* Javitàsok a keresztforditàshoz<br />
<br />
<br />
== Installàlàsi lehetoségek ==<br />
Currently, there are 2 ways how to install gentoo, both having advantages and disadvantages:<br />
Jelenleg két féle installàlàsi folyamat létezik, minddketto a sajàt problémàival és pozitivumaival<br />
* Keresztforditàs, ahol egy màsik (àltalàban nagyobb teljesitményu) szàmitogépen forditjuk az alkalmazàsokat<br />
* Nativ, ahol a telefonon forditjuk az egész rendszert<br />
<br />
Koszonet jàr torindelnek, aki elkezdte a gentoo rendszer openmoko telefonra portolàsàt, az o stage3 csomagjait hasznàljuk a mai napig.<br />
<br />
== A kezdet ==<br />
Ha az àltalànos gentoo installàlst szeretnéd kiprobàlni, ez nagyjàbol mukodik, és nagyjàbol egyszeru, viszont korulbelul 3 napig tart csak az Xorg installàlàsa, probàld ki ezt: [http://gentoo.mindzoo.de/index.cgi/wiki/native-compiling native installation instructions].<br />
<br />
Please note, unless you use distcc, it takes a long time to get a fully working system this way (About 3 days for xorg with fluxbox).<br />
[[category:Distributions]]</div>Johnny9http://openmoko.org/wiki/GentooGentoo2009-01-31T15:53:08Z<p>Johnny9: overlay seems dead, packages not updated since september 2008</p>
<hr />
<div>{{Languages|Gentoo}}<br />
== Overview ==<br />
Gentoo armv4tl-softfloat-linux-gnueabi optimalized for Openmoko (-Os -march=armv4t -mtune=arm920t) on 2008.0/arm profile (glibc based, sane bootstrapable toolchain)<br><br />
(embedded uclibc/arm profile armv4tl-softfloat-linux-uclibcgnueabi in plans)<br />
<br />
[http://img46.imageshack.us/img46/646/80330048oy9.jpg Screenshot (hosted at ImageShack)]<br />
<br />
== Read first ==<br />
'''http://www.gentoo.org/doc/en/handbook/handbook-arm.xml''' (Skip points 2 and 3)<br />
<br />
<br />
== Needed things ==<br />
<br />
*At least 2GB SD card<br />
*Gentoo stage: http://torindel.sezamkowa.net/openmoko/armv4tl-softfloat-linux-gnueabi/~arm/<br />
*Portage snapshot: look for mirror on: http://www.gentoo.org/main/en/mirrors2.xml and get snapshots/portage-DATE.tar.bz2<br />
*Kernel and modules<br />
*Any working Openmoko distro<br />
<br />
<br />
== Installation ==<br />
=== Be careful, the overlay seems to be dead, so you'll have to manually compile (please make ebuilds if you do) illume and anything openomoko-specific ===<br />
<ol><br />
<li>Partition your sd card if needed (don`t make swap partitions<br />
(but see [http://lists.openmoko.org/pipermail/community/2008-September/031106.html]), ensure card isn't mounted): </li> <br />
fdisk /dev/mmcblk0<br />
<br />
<li>Make ext2 or ext3 filesystem: </li> <br />
mkfs.ext2 /dev/mmcblk0p1<br />
<br />
<li>Mount partition: </li> <br />
mount /dev/mmcblk0p1 /media/card<br />
<br />
<li>Copy stage and portage from host to moko (e.g. on localhost): </li><br />
scp stage3-armv4tl-*.tar.bz2 portage-*.tar.bz2 root@openmoko:/media/card<br />
<br />
<li>Unpack stage and portage: </li> <br />
tar -xjpf /media/card/stage3-armv4tl-*.tar.bz2 -C /media/card<br />
tar -xjpf /media/card/portage-*.tar.bz2 -C /media/card/usr<br />
<br />
<li>Cleanup removing tar.bz2: </li> <br />
rm /media/card/stage3-armv4tl-*.tar.bz2 /media/card/portage-*.tar.bz2<br />
<br />
<li>Chroot: </li> <br />
chroot /media/card /bin/bash<br />
<br />
<li>Update chroot environment: </li> <br />
source /etc/profile; env-update<br />
<br />
<li>Set timezone: </li> <br />
cp /usr/share/zoneinfo/YOURZONE /etc/localtime<br />
<br />
<li>Set hostname: </li> <br />
nano /etc/conf.d/hostname<br />
<br />
<li>Remove console font changing (small is beautiful ;]): </li> <br />
rc-update del consolefont boot<br />
<br />
<li>Setup fstab: </li> <br />
nano /etc/fstab<br />
<br />
<li>Edit inittab (hash out c3, c4, c5, c6, s0, s1 lines): </li> <br />
nano /etc/inittab<br />
<br />
<li>Setup usb networking: </li> <br />
echo "modules=\"g_ether\"" >> /etc/conf.d/modules<br />
ln -s /etc/init.d/net.lo /etc/init.d/net.usb0<br />
echo "config_usb0=\"192.168.0.202 netmask 255.255.255.0\"" > /etc/conf.d/net<br />
echo "routes_usb0=\"default via 192.168.0.200\"" >> /etc/conf.d/net<br />
echo "nameserver 192.168.0.200" > /etc/resolv.conf<br />
<br />
<li>Enable sshd: </li> <br />
rc-update add sshd default<br />
<br />
<li>Change root password: </li> <br />
passwd<br />
<br />
<li>Leave chroot: </li> <br />
exit<br />
<br />
<li>Copy kernel. </li><br />
cp /boot/uImage-2.6.24 /media/card/boot/<br />
<br />
<li>Copy modules. </li><br />
cp -rpf /lib/modules /media/card/lib/<br />
<br />
<li>Setup uboot for booting from sd card. </li><br />
<li>Reboot. </li><br />
<li>Setup/emerge rest of the system. </li><br />
<br />
== Emerging binary packages ==<br />
*Binary package sites<br />
:http://tinderbox.dev.gentoo.org/embedded/openmoko/armv4tl-softfloat-linux-gnueabi/<br />
:http://torindel.sezamkowa.net/openmoko/armv4tl-softfloat-linux-gnueabi/~arm/packages/All<br />
*Add PORTAGE_BINHOST to make.conf<br />
:<tt>e.g.</tt> <pre>echo "PORTAGE_BINHOST=\"http://torindel.sezamkowa.net/openmoko/armv4tl-softfloat-linux-gnueabi/~arm/packages/All\"" >> /etc/make.conf</pre><br />
*Update environment<br />
:<tt>e.g.</tt> <pre>source /etc/profile; env-update</pre><br />
*Setup install mask if you don't want compiler headers/docs etc (mask headers only if you'll be always using binary packages)<br />
:<tt>e.g.</tt> <pre>export INSTALL_MASK="*.h"</pre><br />
*Add the following line to make.conf to tell portage to always use binary packages. <pre>EMERGE_DEFAULT_OPTS="-gK"</pre><br />
<br />
== Alternative: Squashed Portage ==<br />
An alternative to installing a full, writable, and uncompressed portage tree directly on the microSD card, is to compress portage using SquashFS and then to mount the resulting SquashFS file (usually compressed from about 500 MB to 50 MB) at /usr/portage. <br />
<br />
In this case, it is also suggested to set DISTDIR to /tmp/distfiles, because the default DISTDIR (/usr/portage/distfiles) is not writable. Similarly, PKGDIR can be set to /tmp/binpkgs instead of the default /usr/portage/packages.<br />
<br />
See [http://perpetual-notion.blogspot.com/2008/06/gentoo-on-eee-pc.html this] blog post for further details. If you are lacking in extra space on your flash device, or are concerned about extraneous write-cycles to your flash memory, then you should perform all of the steps on desktop linux machine and then finally copy the resulting squashfs image to the FreeRunner.<br />
<br />
== Openmoko Overlay ==<br />
Add svn://torindel.sezamkowa.net/openmoko to layman (emerge layman)<br />
<br />
== Binary package wishlist ==<br />
As i'll be adding some packages to ftp above you might want to ask for some package here: [[GentooPackageWishList]]<br><br />
Overlay with moko things and more packages coming soon.<br />
<br />
[[category:Distributions]]</div>Johnny9http://openmoko.org/wiki/Flashing_the_Neo_FreeRunnerFlashing the Neo FreeRunner2009-01-26T11:55:06Z<p>Johnny9: when nandwrite fails...</p>
<hr />
<div>{{Languages|Flashing_the_Neo_FreeRunner}}<br />
Openmoko regularly releases updated versions of the Openmoko root filesystem, the [[kernel]], and the [[Bootloader]] (called [http://www.denx.de/wiki/U-Boot/WebHome U-Boot]) as binary images. These may be programmed into the [[NAND_Flash|Flash memory (NAND)]] of Neo FreeRunner. For that, you can use the USB cable and another computer which will run an Openmoko-provided tool to flash the Neo FreeRunner "through" USB.<br />
<br />
== 3 software components and 2 kinds of storage ==<br />
<br />
Inside the FreeRunner 3 software components are working:<br />
* '''bootloader''': a small program that runs first and starts everything else when the FreeRunner is powered on or reset (depending on [[Booting the Neo FreeRunner|how you reset it]], the version from [[NOR_Flash|NOR]] or NAND is booted).<br />
* '''kernel''': the central component in the Linux operating system.<br />
* '''root filesystem''': contains all the files that make up the commands and applications that you can run.<br />
All software components in the FreeRunner are bundled together into binary images. <br />
<br />
The FreeRunner has two kinds of internal program storage: NOR flash and NAND flash. On a desktop computer when you want to replace the operating system (OS), you would boot it from a CD-ROM drive, then copy OS files from the CD to the internal hard drive. The FreeRunner does not have a CD-ROM drive and files must typically be re-written/flashed directly into internal storage (NAND flash). Alternatively, it is possible to boot from a microSD where all the files have been loaded onto.<br />
<br />
NOR flash is small and stores only a special boot program used when you need to re-write the contents of the NAND flash. Usually it is not necessary to re-write the NOR flash. Instructions to do so is here: [[Flashing NOR]].<br />
<br />
NAND flash acts more like a hard drive. It is divided into 3 partitions for the bootloader, kernel, and root filesystem. Being on different partitions, each component can be flashed separately. For example if you are trying to install a modified kernel, you only have to follow the steps to flash the kernel image.<br />
<br />
'''Before you start: Erasing the root filesystem or flashing the bootloader are radical measures. Take the time to ponder the necessity. Sometimes problems can be fixed by only updating the kernel.'''<br />
<br />
== Alternative : running from microSD card ==<br />
<br />
You may install this distribution on the microSD card, in order to [[Booting from SD | boot from microSD card]]. That allows you to keep another distribution installed in NAND (for instance to test 2008.08 while still having 2007.2 for default boot).<br />
<br />
== Software you need ==<br />
<br />
=== #1 Tools for flashing: DFU-util and NeoTool ===<br />
<br />
''Command-line''. DFU-util, the tool to flash the FreeRunner has to be installed on you laptop or desktop machine. It is available for Linux, MacOS X, and Windows (see links below). DFU-util allows you to connect to the FreeRunner through the USB cable and control its bootloader. That connection uses a special protocol which addresses the bootloader's interface, and differs from USB networking. For more details, see the separate [[dfu-util]] page.<br />
<br />
''GUI''. Instead of the command-line-based DFU-util, you can use NeoTool, a graphical tool for flashing the FreeRunner: see the [[NeoTool]] page.<br />
<br />
'''Linux:''' http://downloads.openmoko.org/releases/Om2008.9/dfu-util<br />
<br />
Make sure it is executable by setting the permissions with this command: chmod a+x dfu-util<br />
<br />
'''Linux 64-bit:''' You need 64-bit version of dfu-util, which usually can be found in your distribution repository.<br />
If your destribution does not provide 64-bit dfu-util, or it consistently fails with a "-62" error, you have two ways to go:<br />
# Seek for 32-bit machine and do flashing form it.<br />
# Use 32-bit chroot (on amd64 debian). Worked for me --[[User:Bubak|Bubak]] 16:54, 4 September 2008 (UTC).<br />
# Just try the 32-bit dfu-util. Worked fine on my x86_64 Fedora 10 --[[User:Pcfe|pcfe]] 2009-01-16.<br />
<br />
'''MacOS X:''' [[MacOS_X#Graphical_Flashing_with_Openmoko_Flasher]]<br />
<br />
'''Windows:''' http://projects.openmoko.org/frs/?group_id=166&release_id=162<br />
<br />
See additional driver installation instructions for Windows at [[Dfu-util-windows]]<br />
<br />
'''Virtual machines''' While there has been some limited success reported using dfu-util from within a Virtual Machine (such as VMware), in general it is not possible to use dfu-util in this fashion. You must use dfu-util on an operating system that has direct access to the physical USB device hardware.<br />
<br />
=== #2 Image files to flash into FreeRunner memory ===<br />
<br />
There are separate image files for all 3 software components and depending on what you want to install, you pick the respective image file. In most cases you will need to install a Kernel (uImage) and a Root Filesystem (rootfs). In rare cases, when there is a bug you need fixed, you will also install a new bootloader.<br />
<br />
Please read [[Distributions]] for choosing the distribution which fits your needs, and then see [[Download]] for downloading.<br />
<br />
== Boot the FreeRunner from NOR Flash ==<br />
<br />
[[Image:menu15.jpg|thumb|Booting from NOR Flash]]<br />
<br />
# Read the other sections of this page first, because you will have 30 seconds to enter the flashing commands, come back here when ready.<br />
# Do not connect the USB cable from the PC to your Neo FreeRunner yet (disconnect it).<br />
# Boot your Neo FreeRunner into the NOR uBoot menu for flashing.<br />
## Press and hold AUX button<br />
## Press the Power button until the boot menu comes up<br />
## This menu is labelled '''*** BOOT MENU (NOR) ***'''<br />
## See also [[Booting the Neo FreeRunner]]<br />
# Stay in NOR uBoot menu, do not select or enter any item in menu. Now you will be able to flash, make backups of your FreeRunner or query the FreeRunner with dfu-util.<br />
# The FreeRunner only stays at the NOR boot prompt for about 30 seconds and then shuts off unless you do something.<br />
# Connect your Neo to the GNU/Linux or Windows host via a USB cable.<br />
# Now you can enter the dfu-util commands on your PC as described below.<br />
# If the Neo FreeRunner turns off before you press start flashing ('''screen goes black'''), go back to step 2. If you start flashing in time, the phone will not turn off meanwhile.<br />
<br />
<!-- The following, upto dfu-util -l is taken from the thread "Re: FreeRunner (GTK2007.2) has suddenly become unbootable" on the Support list. --><br />
<br />
Note that the dfu-util connection does '''not''' use Ethernet over USB - that is, you should not attempt to set up a usb0 network interface on your GNU/Linux host desktop (on Windows, you need a DFU class driver, or you can use the LibUSB-Win32 driver described on the [[Dfu-util-windows]] page). The dfu-util utility sets up its own connection to the FreeRunner. In fact, you will not be able to make an Ethernet-over-USB connection to the FreeRunner when it is at the uBoot menu; this type of connection is only available when the FreeRunner has booted fully.<br />
<br />
After connecting the FreeRunner to your host via USB cable, you can test whether dfu-util "sees" the FreeRunner by executing:<br />
<br />
<pre>dfu-util -l</pre><br />
<br />
If you get error messages from the dfu-util command then try again. Often it works on the second try.<br />
<br />
dfu-util uses the DeviceFirmwareUpgrade protocol, and may list more than one device. If so, try unplugging the other device (e.g. a USB mouse) or using the -d switch to tell dfu-util which device it should talk to, as described at the relevant bug report [http://docs.openmoko.org/trac/ticket/2039].<br />
<br />
Also, please remember to execute the dfu-util command with sufficient privileges (ie. root) -- you will need complete control over the usb bus.<br />
<br />
== Do a backup ==<br />
<br />
If you have a working image that you're happy with but want to try something different, you should probably do a [[Backup]].<br />
<br />
== Using dfu-util ==<br />
<br />
dfu-util can be used to read flash memory, write memory, and get information from the device.<br />
<br />
This is the general command format to write an image file to a (predefined) "partition name" (referred to as ''altsetting'' in dfu-util help/manual) :<br />
<br />
dfu-util -a ''<altsetting>'' -R -D ''<file_name>''<br />
<br />
where:<br><br />
-a ''altsetting'' : Specify the altsetting of the DFU interface by name or by number<br><br />
-R : Issue USB Reset signalling once we're finished<br><br />
-D ''file_name'' : Write firmware from ''file_name'' into device<br />
<br />
On Linux, you run dfu-util from a command shell prompt. If you have not put it somewhere on your command path you probably need to prefix it with a "./" like this '''./dfu-util'''.<br />
On some systems you need to be root before this will work and on Ubuntu you must preface the command with "sudo" or you will get the following error: "Cannot claim interface: could not claim interface 2: Operation not permitted"<br />
<br />
On Windows, you need to open a command window and run from a command line. Use Start-Run Program and type "cmd" to open a Window.<br />
<br />
More detailed manual for dfu-util is available here : [[Dfu-util]]<br />
<br />
GUI frontend for dfu-util (and more): [[NeoTool]]<br />
<br />
== Flashing the Kernel ==<br />
<br />
Note: The phone needs to be in the U-boot bootup menu for this to work.<br />
Get there by holding down the aux button while powering up the device.<br />
<br />
The command format is <br />
<br />
dfu-util -a kernel -R -D ''/path/to/uImage''<br />
<br />
When flashing succeeds the following will be shown:<br />
<br />
status(0) = No error condition is present<br />
Done!<br />
<br />
Flashing may fail with an error -110. This indicates that the kernel is too big for the default kernel partition. uboot can be used to change the size of the default partitions on the device. It may also mean that you are trying to put the wrong thing in the kernel space.<br />
<br />
== Flashing the Root Filesystem ==<br />
<br />
The root filesystem has to be an image in jffs2 format. If the file you downloaded is zipped or compressed (has a .gz, bz2, .zip, tar, tar.gz or .tgz extension) you have to uncompress it first.<br />
<br />
The command format is<br />
<br />
<pre><br />
dfu-util -a rootfs -R -D rootfs_filename.jffs2<br />
</pre><br />
| U-Boot<br />
where ''rootfs_filename.jffs2'' is the name of the file containing the root file system.<br />
<br />
The flashing process can take up to 15 minutes for a ~70MB image. It is also wise to make sure that your Neo has enough battery charge prior to flashing.<br />
<br />
When flashing succeeds the following will be shown:<br />
<br />
<pre><br />
status(0) = No error condition is present<br />
Done!<br />
</pre><br />
<br />
== Flashing the boot loader to the NAND==<br />
<br />
{{Note|In most cases you don't need to flash your bootloader. Flash it only if you want to update for a specific feature or due to a specific problem.}}<br />
<br />
The boot loader (U-boot) file should have a .bin extension. As with the root filesystem, if the file you downloaded is zipped or compressed (has a .gz or .zip extension) you have to uncompress it first.<br />
<br />
The command format is <br />
<br />
dfu-util -a u-boot -R -D ''uboot.bin''<br />
<br />
where ''uboot.bin'' is the name of the boot loader binary image file.<br />
<br />
''Reminder'': You should have [[Flashing_the_Neo_FreeRunner#Boot_the_FreeRunner_from_NOR_Flash|boot from NOR first]], in order to flash the boot-loader in NAND. After flashing succesfully, make sure you reboot from NAND's newly flashed boot loader, to benefit from the updates.<br />
<br />
=== Optional: Verifying boot-loader version ===<br />
<br />
<!-- The following should probably be moved to [[Bootloader_versions]], IMHO --><br />
<br />
<!-- Taken from posts by Mikael Berthe <mikael.berthe@lilotux.net> and Torfinn Ingolfsen <tingox@gmail.com> to Support list, subject: Re: Upgrading u-boot needed ? --><br />
(Optional) After an upgrade, you may wish to check that the u-boot version matches the one you have just flashed. You can use 'grep Bootloader /dev/mtdblock1' from a shell on the FreeRunner (and possibly the 1973 as well) to get the '''NAND''' u-boot version, like this:<br />
root@om-gta02:~# grep Bootloader /dev/mtdblock1<br />
Neo1973 Bootloader U-Boot 1.3.2+gitr18+64eb10cab8055084ae25ea4e73b66dd03cc1a0cb<br />
<br />
You can grep for the same string in /dev/mtdblock0 to retrieve the '''NOR''' u-boot version:<br />
root@om-gta02:~# grep Bootloader /dev/mtdblock0<br />
Neo1973 Bootloader U-Boot 1.3.2-moko12<br />
<br />
<!-- ENDS ... subject: Re: Upgrading u-boot needed ? --><br />
<br />
== Reboot the FreeRunner from NAND ==<br />
<br />
You should now be able to boot into the new images.<br />
<br />
Pay attention '''to booting from the NAND flash this time''', in particular if you upgraded the boot-loader (in short: 1. press and hold ''power button'' down, and then 2. press ''aux button'')<br />
<br />
The boot menu should be labelled '''*** BOOT MENU (NAND) ***''' this time (see [[Booting#Log_into_U-Boot_in_the_NAND_Flash|booting from NAND]] for more detailed instructions).<br />
<br />
== A command line script to simplify dfu-util ==<br />
<br />
DFUScript developed to assist users who have multiple devices in using dfu-util via the command line. Information on where to download and use DFUScript can be found on [[DFUScript]]<br />
<br />
== Alternative: using nandwrite ==<br />
<br />
This approach involves writing the '''rootfs''' into nand directly on the phone from a system already running on it, not necessarily via usb from a computer.<br />
<br />
If you have a system running from a different partition that you intend to flash (for example sd card), you can use nandwrite to do the work, which is much faster (it takes about 30s to write a 59MB jffs2 image).<br />
<br />
Make sure you have nandwrite installed (on gentoo, it's in sys-fs/mtd-utils package)<br />
<br />
Also make sure that the host system has received correct partition list, for example for my stock Neo Freerunner partition list:<br />
<br />
<pre><br />
#cat /proc/mtd<br />
dev: size erasesize name<br />
mtd0: 00200000 00010000 "physmap-flash.0"<br />
mtd1: 00040000 00020000 "u-boot"<br />
mtd2: 00040000 00020000 "u-boot_env"<br />
mtd3: 00800000 00020000 "kernel"<br />
mtd4: 000a0000 00020000 "splash"<br />
mtd5: 00040000 00020000 "factory"<br />
mtd6: 0f6a0000 00020000 "rootfs"<br />
</pre><br />
<br />
In this case, we're looking for 'rootfs' which according to above is mtd6. If you have it somewhere else, substitute mtd6 with whatever you have in the remainder of this section.<br />
<br />
You can test your nand for bad blocks by issuing '''nandtest /dev/mtd6''' '''(this is a destructive test !)'''<br />
<br />
First, put your .jffs2 file somewhere the phone system can read it<br />
<br />
Second, write the desired image into the nand this way: <br />
'''nandwrite -m -p /dev/mtd6 /path/to/image.jffs2'''<br />
<br />
* this method seems to not always work, also the -m flag tells nandwrite to mark blocks it detects bad as bad, so if nandwrite is bugged, your entire partition will be marked as bad. See http://wiki.openmoko.org/wiki/NAND_bad_blocks#Clearing_BadBlocks if this happened to you.<br />
<br />
You're all done !<br />
<br />
== Troubleshooting ==<br />
<br />
Okay, so you just reflashed. The splash screen pops up, but uBoot fail to load the kernel, and return to boot menu. WTF?<br />
<br />
* It is likely that the wrong bits went to the wrong place. Try reflashing just the kernel, double checking that you select the uImage.bin kernel file, not the u-boot.bin bootloader file.<br />
* Try redownloading and reflashing the kernel, checking file integrity with the MD5 hash sums.<br />
<br />
==See also==<br />
*[[Qi]] alternative to uboot<br />
<br />
[[Category:Flashing Openmoko| ]]</div>Johnny9http://openmoko.org/wiki/NAND_bad_blocksNAND bad blocks2009-01-26T11:46:17Z<p>Johnny9: added clearing bad blocks method</p>
<hr />
<div>== NAND basics ==<br />
<br />
NAND memory has quite unique characteristics.<br />
<br />
* When it is erased, all bits are set to 1' (you will see 0xff on all bytes in a hexdump)<br />
* You can change as many bits as you want to '0'<br />
* You cannot set a bit back to '1' by using a regular write. You have to erase a whole '''erase block''' to do so<br />
* The number of erase cycles per block is limited. Once you have reached the limit, some bits will not get back to 0xff<br />
** In the case of the chip in the Neo1973, this is 100000 guaranteed per-block erase cycles.<br />
=== NAND page ===<br />
<br />
A NAND page consists of a number of data bytes (512 in the Neo1973 GTA01 case, 2048 in the GTA02 case) plus a number of out-of-band (OOB) bytes (GTA01: 16, GTA02: 64).<br />
<br />
Only the data bytes are used for application data. The OOB bytes are used for<br />
* Marking an erase block as bad (first or second page of erase block)<br />
* Storing ECC (error correction codes)<br />
* Storing filesystem specific information (JFFS2)<br />
<br />
=== NAND erase block ===<br />
<br />
A erase block consists of multiple pages. In the Neo1973 GTA01 case, every erase block has 32 pages, resulting in 16kBytes (hex: 0x4000) of data bytes (without OOB). GTA02 has 128kByte large erase blocks.<br />
<br />
== Problem ==<br />
<br />
=== Bad Blocks ===<br />
<br />
NAND memory apparently gets shipped with blocks that are already bad. The vendor just marks those blocks as bad, thus resulting in higher yield and lower per-unit cost.<br />
<br />
The flash contains four kinds of blocks (16kBytes):<br />
* Factory-Default bad blocks<br />
** Samsung marks the 6th OOB byte as non 0xFF in the first and/or second page in blocks that are bad<br />
* Worn-out bad blocks<br />
* Good blocks<br />
* The first block.<br />
**This block is guaranteed to not require error correction up to 1000 writes. This is needed as initial boot code can't do ECC.<br />
<br />
We are also guaranteed that a minimum of 4026 blocks (out of the total 4096) are good. This means up to 70 blocks (1.3MBytes) can be dead, resulting in a total guaranteed amount of working NAND storage of 65961984 bytes.<br />
<br />
==== Backup ====<br />
You may want to backup the "Factory-Default bad blocks" just in case you accidentally delete it.<br><br />
The u-boot command ''"nand bad"'' lists the offsets of the bad blocks.<br />
<br />
== Solution ==<br />
<br />
The solution is split into various pieces, one at each level.<br />
<br />
=== Boot loader ===<br />
<br />
==== first-stage ====<br />
<br />
The boot loader itself contains a small first-stage boot loader for the [[S3C2410 Steppingstone]].<br />
<br />
This code (mostly written in ARM assembly) was altered to detect and skip bad blocks. This means, the first stage bootloader can itself extend over bad blocks.<br />
<br />
This also means that the flashing routine needs to detect and skip bad blocks, resulting in a u-boot image that can have gaping holes ;) The existing "traditional" [[sjf2410-linux]] JTAG flashing program is not detecting bad blocks (Note: this might be changed through a compile option, see below)<br />
<br />
==== Environment ====<br />
<br />
The [[u-boot]] environment is traditionally stored at a fixed location within the NAND flash. This is not acceptable, since it could be a factory-set bad block.<br />
<br />
The solution that was implemented for Openmoko/Neo1973 was to put the in-flash address of the environment into the out-of-band (OOB) area of the first block (the one which is guaranteed to be good). Since the environment address is unlikely to change often, the 1000 erase cycles guaranteed for the first block are good enough.<br />
<br />
The exact location is byte 8..15 of the 16byte OOB area, starting with the four ASCII bytes '''ENVO''', followed by the little-endian 32bit unsigned integer of the NAND address where the environment is located.<br />
<br />
The u-boot "dynenv get" command can be used to read out a pre-programmed Environment offset from NAND, and the "dynenv set" can be used to write the offset (if the last eight bytes of OOB area are erased (0xff)).<br />
<br />
==== Partition Table ====<br />
<br />
:''See also [[Partitions]].''<br />
<br />
Since those up to 80 factory-bad blocks can be located about anywhere in NAND, we have to accomodate for this worst case. However, we cannot just make every partition 1.3MB larger than it needs to be, since this would waste a lot of otherwise good flash.<br />
<br />
The only solution to this (that Harald could think of) is to dynamically calculate a partition table for each device. Every NAND flash has different factory-bad blocks at different locations, thus the partition table on every NAND flash will look different.<br />
<br />
So as an example, let's assume we have a 0x30000 (196k) bytes sized partition for u-boot, starting at address 0 in NAND. If there were no bad blocks, it would extend from 0x00000 to 0x30000. From 0x30000 to 0x230000 (2MB) we have the kernel partition.<br />
<br />
Let's now assume that blocks 0x20000 and 0x28000 (each 0x4000 in size) are marked as factory-bad. Thus, in order to have 0x30000 bytes of usable storage, the uboot partition actually extends from 0x00000 to 0x38000. This shifts the start address of the kernel partition to 0x38000.<br />
<br />
If the kernel partition contains more bad blocks, the start address of the rootfs partition (following the e kernel partition) is further shifted down to the end.<br />
<br />
Those calculations have been implemented as u-boot "dynpart" command. Once you issue "dynpart", the partition configuration is put in the "mtdparts" environment variable. If you "saveenv" the environment, it is saved into the non-volatile environment partition.<br />
<br />
==== Bad Block Table (BBT) ====<br />
<br />
Since the usual bad block marker in the OOB area does not allow us to distinguish between factory-bad and worn-out-bad blocks, we need to store this information elsewhere. This place is called bad-block table (BBT) and is stored as a bitmap in the last two good blocks at the end of NAND. To increase security, a backup of those two blocks is kept in the two preceding good blocks as well.<br />
<br />
The BBT location itself is identified by special markers (BBT0/BBT1) in the OOB area of the first page of the respective erase blocks.<br />
<br />
The BBT consists of two bits per block which distinguish the three conditions (factory-bad/worn-out/good).<br />
<br />
Both u-boot and Linux implement the same BBT layout and thus interoperate quite well.<br />
<br />
===== BBT creation =====<br />
<br />
The BBT is created once a BBT-implementing u-boot is started for the first time. The BBT scanning code assumes that the NAND is '''completely erased''', i.e. only contains 0xff as content. Any block that contains bytes != 0xff in the OOB is marked as "factory bad" block.<br />
<br />
==== Flashing kernel/rootfs from u-boot ====<br />
<br />
The kernel is contained in its own [[Partitions|partition]]. We have to flash it using the<br />
nand write.e<br />
command, and read it later again via<br />
nand read.e<br />
command. Those two variants (as opposed to their non-".e"-postfixed versions) simply skip bad blocks<br />
<br />
As opposed to using fixed NAND flash addresses, we can use the mtd partition names. Thus, the magic of device-specific dynamic partition layout is all hidden neatly from the user. A flash command using a partiton name looks like:<br />
<br />
nand write.e 0x32000000 kernel<br />
<br />
Where 0x32000000 is the source address in RAM, and 'kernel' is the name of the kernel partition.<br />
<br />
=== Kernel ===<br />
<br />
==== Bad block table ====<br />
<br />
In order to maintain the BBT created by u-boot, the kernel needs to have BBT support enabled. Unfortunately the mainline kernel doesn't have a CONFIG option for it, so if you're not using the -moko kernel tree, you have to manually patch the s3c2410 nand driver to enable the BBT option.<br />
<br />
=== Flash Tool ===<br />
<br />
==== sjf2410 (during development) ====<br />
<br />
The [[sjf2410-linux]] tool has a compile-time option to check (and skip) bad blocks. If we use this for flashing u-boot, we will preserve the bad block info, once u-boot steppingstone code has been enhanced to skip bad blocks.<br />
<br />
However, even if the bad-block skipping works, sjf2410-linux only supports the extremely slow parallel-port based JTAG adaptors. Also, the overall flashing process is getting quite complicated. sjf2410-linux could thus only be used for flashing the bootloader. Everything else has to be done by some more intelligent software anyway.<br />
<br />
==== JTAG / OpenOCD / u-boot RAM based ====<br />
<br />
This method is actually quite neat, and based on [[Bootloader#Using_JTAG_to_boot_from_RAM]].<br />
<br />
The idea is to use JTAG to download and execute a special version of u-boot. This u-boot then automatically scans the whole NAND and creates the BBT. The process can be monitored and controlled by the developer (or some script). The chronological steps are<br />
<br />
# Make sure NAND flash is completely erased<br />
# Use JTAG to reset and halt the device<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 />
# Use JTAG to download lowlevel bootup code to address 0<br />
<pre><br />
> load_binary /space/misc/gta01/u-boot.git/foo.bin 0<br />
downloaded 332 byte in 0s 21899us<br />
</pre><br />
<br />
# Use JTAG to create breakpoint at 0x33f80000<br />
<pre><br />
> bp 0x33f80000 4 hw<br />
breakpoint added at address 0x33f80000<br />
</pre><br />
<br />
# Use JTAG to run up to that breakpoint<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 />
# Use JTAG to download u-boot-ram image to 0x33f80000<br />
<pre><br />
> load_binary /space/misc/gta01/u-boot.git/u-boot.bin.ram 0x33f80000<br />
downloaded 135692 byte in 6s 567264us<br />
</pre><br />
<br />
# Use JTAG to resume at 0x33f80000<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:<br />
</pre><br />
<br />
# Wait until u-boot has created BBT<br />
<pre><br />
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 />
# Execute 'dynpart' command to calculate [[Partitions|partition]] offsets<br />
<pre><br />
GTA01Bv2 # dynpart<br />
mtdparts mtdparts=gta01-0:0x00030000(u-boot),0x00004000(u-boot env),0x00208000(kernel),0x00400000(initrd),0x039c4000(rootfs)<br />
</pre><br />
<br />
# Execute 'dynenv set' command to write environment partition offset to OOB of block 0<br />
{{note|you MUST use the name of the u-boot environment partition from the output of 'dynpart' }}<br />
<pre><br />
GTA01Bv2 # dynenv set u-boot_env<br />
45 4e 56 30 - 00 00 03 00<br />
GTA01Bv2 #<br />
</pre><br />
<br />
# Execute 'saveenv' command to write environment into its partition<br />
<pre><br />
GTA01Bv2 # saveenv<br />
Saving Environment to NAND...<br />
Erasing Nand...Writing to Nand... done<br />
</pre><br />
<br />
# Use JTAG (or microSD) to read uboot-nand image into RAM<br />
# Use u-boot 'write.e' command to write uboot-nand image to uboot partition in NAND<br />
# Use JTAG (or microSD) to read kernel uImage into RAM<br />
# Use u-boot 'write.e' command to write uImage to kernel partition in NAND<br />
# Use JTAG (or microSD) to read JFFS2 rootfs image into RAM<br />
# Use u-boot 'write.jffs2' command to write jffs2 image to rootfs partition in NAND<br />
# Reset and boot<br />
<br />
=== Clearing BadBlocks ===<br />
# install a terminal application (for example minicom)<br />
# set up your terminal:<br />
## disable flow control<br />
## disable the modem initialisation string (-o flag for minicom)<br />
## the device to connect to will be /dev/ttyACM0 (if this is the only acm device connected to your machine)<br />
# make sure you have the cdc_acm driver compiled for your kernel (CONFIG_USB_ACM=m or y, see higher up on this page)<br />
# boot into the u-boot menu, the /dev/ttyACM0 should appear as soon as that happens<br />
# execute the following commands, in order (this will erase your entire flash):<br />
<pre><br />
nand bad<br />
nand scrub<br />
nand createbbt<br />
dynpart<br />
dynenv set u-boot_env<br />
saveenv<br />
</pre><br />
you should be set<br />
kudos to mmontour and PaulFertser for finding this method and sharing it with me<br />
[[Category:Flash]]</div>Johnny9