r687 - developers/werner
werner at sita.openmoko.org
werner at sita.openmoko.org
Tue Feb 6 02:52:13 CET 2007
Author: werner
Date: 2007-02-06 02:52:11 +0100 (Tue, 06 Feb 2007)
New Revision: 687
Modified:
developers/werner/WALK-THROUGH
Log:
- removed AUTH role (use https://buildhost... instead of SCP)
- added more material for later stages
- added oe symlink
- clarified how to use this file
Modified: developers/werner/WALK-THROUGH
===================================================================
--- developers/werner/WALK-THROUGH 2007-02-06 01:16:35 UTC (rev 686)
+++ developers/werner/WALK-THROUGH 2007-02-06 01:52:11 UTC (rev 687)
@@ -1,16 +1,20 @@
#
# OpenMoko Walk-Through
#
-# by Werner Almesberger <werner at openmoko.org>
+# according to Werner Almesberger <werner at openmoko.org>
#
+#
# This is a pseudo-shellscript describing how I set up a running OpenMoko
-# system from scratch. You can run this through a shell, but it's usually
-# better to
-# Do NOT run this through a shell ! Instead, look at each
-# step, read the instructions, and copy and paste what makes sense for you, and
-# adapt what you disagree with.
+# system from scratch.
#
+# Do NOT run this through a shell ! There are various configuration items you
+# need to set (or skip, as it may be), operations that depend on how your
+# host(s) are set up, and also on the revision of the target platform.
+#
+# Instead, look at each step, read the instructions, and copy and paste what
+# makes sense for you, and adapt what you disagree with.
+#
# Please note that this file isn't actively maintained and is guaranteed to
# suffer bit rot as I begin to use more and more shortcuts in the build
# process. Furthermore, naming and other preferences are my own, may have
@@ -19,7 +23,6 @@
#
-
### Roles ###################################################################
#
# The build process may spread over multiple machines. They have the following
@@ -27,7 +30,6 @@
#
# BUILD build host, with quick access to the files and CPU power. Must
# have Internet access.
-# AUTH host with access to the OpenMoko build host
# LAB lab machine connected to the debug board (serial and JTAG) and
# to USB on the Neo (since this will probably be just a single
# machine, the roles are not further divided)
@@ -71,7 +73,7 @@
export BBPATH=$OMDIR/build:$OMDIR/openmoko/trunk/oe:$OMDIR/openembedded
-### Permissions (BUILD, AUTH) ###############################################
+### Permissions (BUILD) #####################################################
#
# In order to perform the build process, you have to obtain the following
# permissions:
@@ -79,8 +81,8 @@
# - write access to the OpenMoko SVN repository (in principle, read access
# should be enough. However, there are some secondary repositories that want
# authentication. If you have write access, you'll be fine with these, too.)
-# - AUTH must have shell access to the OpenMoko buildhost (to grab files with
-# SCP)
+# - access to the OpenMoko Web sites, in particular
+# https://buildhost.openmoko.org/
#
@@ -201,7 +203,7 @@
EOF
-### OpenEmbedded build: fixes (BUILD or AUTH) ###############################
+### OpenEmbedded build: fixes (BUILD) #######################################
#
# There are unfortunately some problems in the build process. The following
# fixes work around them:
@@ -223,49 +225,56 @@
perl -pi.orig -e 's/ *$//;s/\r//g' \
../openembedded/packages/gcc/gcc-4.1.1/gcc-4.1.1-pr13685-1.patch
-#dos2unix <gcc/config/i386/i386.c.rej | sed 's/ *$//'
+# access requires authorization (edit user name and password)
-### OpenEmbedded build: fixes (AUTH) ########################################
-#
-# Some files are currently stored in private repositories that require further
-# authorization. (If you think you should be granted access, ask on IRC.) We
-# get the files from the buildhost.
-#
-
-cd $OMDIR/sources
-
-# access requires authorization
-
n=omoko_svn.o-hand.com_.repos.contacts.branches.private__now
-scp $BUILDHOST_SRC/$n.tar.gz .
+wget --http-user=werner --http-passwd=mumble \
+ https://buildhost.openmoko.org/sources/$n.tar.gz
touch ../build/tmp/stamps/armv4t-linux/openmoko-contacts-0.1+svnnow-r0.do_fetch
-# access requires authorization
+# access requires authorization (edit user name and password)
n=omoko_svn.o-hand.com_.repos.dates.branches.private__now
-scp $BUILDHOST_SRC/$n.tar.gz .
+wget --http-user=werner --http-passwd=mumble \
+ https://buildhost.openmoko.org/sources/$n.tar.gz
touch ../build/tmp/stamps/armv4t-linux/openmoko-dates-0.1+svnnow-r0.do_fetch
### OpenEmbedded build ######################################################
#
+
+# openmoko/trunk/oe/conf/site.conf expects the OpenMoko-specific OE packages in
+# $OMDIR/oe
+
+cd $OMDIR
+ln -s openmoko/trunk/oe .
+
# We're now ready to run the build. This will take a while.
-#
-cd $OMDIR/build
+cd build
bitbake openmoko-devel-image
# Note that the build will stop several times to ask for SVN access and whether
# to accept certificates. If you're not quick enough to respond, the underlying
# session may time out. In this case, just restart "bitbake
# openmoko-devel-image" and it pick up from where it left off.
+<*22:00> <22:26>
#
-# The whole build process takes about NNNN hours on an Athlon 64 3200+, and
-# ends with a message like this:
+# The whole build process involved numerous downloads, takes about NNNN hours
+# on an Athlon 64 3200+, and ends with a message like this:
#
#
+###############################################################################
+## THE INSTRUCTIONS BELOW YIELD A SETUP WITHOUT BAD BLOCK HANDLING ##
+###############################################################################
+#
+# We're in the process of migrating to a configuration of u-boot and kernel
+# that can skip bad blocks in the NAND Flash. If your NAND Flash has no bad
+# blocks, you can proceed safely, and migrate later.
+#
+
### Flash boot loader into NAND (LAB) #######################################
#
# As a first step, we transfer the u-boot bootloader into NAND Flash, through
@@ -317,26 +326,48 @@
cp openmoko-devel-image-fic-gta01-*.rootfs.jffs2 /mnt/tmp/rootfs.jffs2
umount /mnt/tmp
+# Now, insert the microSD card into the Neo, but don't power it on yet.
+# (If you did anyway, don't worry. We'll power cycle it later.)
-### Flash kernel and root FS into NAND (LAB) ################################
+
+### Serial console ##########################################################
#
+# We use a serial console connecting through the debug board. This example uses
+# "xc", which is a small and simple communications program. Many people prefer
+# the considerably more bloated "minicom", which will work as well.
+#
+# Prepare xc configuration
-###
-# make an ext2 file system on the microSD card
-sfdisk -c /dev/uba 1 83
-mke2fs -m0 /dev/uba1
-tune2fs -c0 -i0 /dev/uba1
+cat <<EOF >~/xc.init
+set bps 115200
+terminal
+EOF
-cd $OMDIR/build/tmp/deploy/images
+# Connect to the target
-mount /dev/uba1 /mnt/tmp
-tar xfzC openmoko-devel-image-fic-gta01-20070204161133.rootfs.tar.gz /mnt/tmp
-cp uImage-2.6-moko7-r1-fic-gta01-20070203211409.bin /mnt/tmp/boot/uImage
-cp openmoko-devel-image-fic-gta01-20070204161133.rootfs.jffs2 /mnt/tmp/rootfs.jffs2
-umount /mnt/tmp
+xc -l /dev/ttyS0 -t
+### Start the Neo and enter the boot prompt #################################
+#
+#
+# Disconnect power, wait a couple of minutes, then connect power. Some people
+# have observed stability issued if the device was reset without power cycling,
+# yet details aren't very clear yet.
+#
+# On the serial console, a message like this should appear:
+# U-Boot 1.2.0 (Feb 3 2007 - 13:07:21)
+#
+# Press any key to enter the boot prompt:
+# GTA01Bv2 #
+
+### Flash kernel and root FS into NAND (LAB) ################################
+#
+
+
+
+
### The kernel ################################################################
@@ -367,14 +398,8 @@
### Serial console ############################################################
-cat <<EOF >~/xc.init
-set bps 115200
-terminal
-EOF
-xc -l /dev/ttyS0 -t
-
mmc
ext2load mmc 0 0x32000000 boot/uImage
setenv bootargs root=/dev/mmcblk0p1 console=ttySAC0,115200 loglevel=8 rootdelay=10
More information about the commitlog
mailing list