Looks like we all have different ways of gentoo, lets create page with description them all. It will be good examples for others.

  • Maksim 'max_posedon' Melnikau
  • tomboy64's section
  • Alon Bar-Lev
  • IKrabbe's geeks way to boot

Warning: This page contains old configurations. Please, consult cross-compiling and native-compiling pages for up-to-date information.

Maksim 'max_posedon' Melnikau

  1. etc/make.conf
  2. etc/portage env
    1. emerge-git-hack for storing rootfs in git, and pull every package one-by-one
    2. ~arm keywrod for dev-python/ctypes, dev-python/pyyaml
    3. mask for >dev-lang/python-2.5.2-r8
    4. use x11-base/xorg-server -minimal and net-misc/curl -ssl -gnutls http://bugs.gentoo.org/show_bug.cgi?id=262719
    5. package.provided for all development tools unneeded in cross env
    6. virtual for vim (didn't work)
    7. LDFLAGS=-Lhack for gnome-base/libglade, sys-apps/dbus and sys-apps/hal
  3. emerge
    USE="-X" emerge-armv4tl-softfloat-linux-gnueabi vim system         # emerging system p.1
    emerge-armv4tl-softfloat-linux-gnueabi x11-proto-meta              # hack: we need emerge many x11-protos before any x11 libs.
    emerge-armv4tl-softfloat-linux-gnueabi -uN system                  # emerging system p.2
    emerge-armv4tl-softfloat-linux-gnueabi xorg-server                 # I prever xorg-server for xglamo
    emerge-armv4tl-softfloat-linux-gnueabi efl-meta                    # E17
    
    emerge-armv4tl-softfloat-linux-gnueabi freesmartphone-framework \  # FSO5.1
    openmoko-dialer3 openmoko-messages3 openmoko-contacts3 \           # SHR apps
    pyphonelog shr-settings                                            # SHR extra apps
    
    emerge-armv4tl-softfloat-linux-gnueabi tangogps                    # GPS application
    

tomboy64's section

Note:

  • I'm using x86_64 to crosscompile for arm. I prefer to remain as sta(b)le as that is possible within arm.
  • For simplicity's sake i only note the (~)amd64s here; they seem to be fairly identical to the arm branch.
USE:
-* alsa apm arm dbus -doc dri -iconv jpeg make-symlinks minimal multicall -nls nptl pda -qt -qt3 -qt4 sdl threads threadsafe truetype tslib -unicode zlib

Dropbear:

a small SSH2 client/server i prefer over OpenSSH in such a crammed env.

  • did not build: 0.51
  • built: ~0.52
  • just dump "-g -s" into conf.d/dropbear and dump your pubkeys into /home/root/.ssh/accept_keywords and you're set

eix:

a fast cache for portage. Ultimately i plan to

  • setup a build-host
  • sync that build-host automatically with my home-router via rsync and set up a binary feed
  • build a package-database on that home router which gets sync'd with my moko in sqlite
  • use eix on my mobile to browse through packages, while feeding from my home-router upon install
Hack:
to cross-build eix you need to prepend the emerge-line with EXTRA_ECONF=--enable-unique[=no] (stuff in [ ] is optional).
TODO:
enable sqlite support, build the database automatically, update the database on sync
  • built: 0.15.2, ~0.15.3, ~0.15.4

bash:

  • did not build: 3.2_p39, ~3.2_p48-r1, ~4.0_p10
  • built: 3.2_p48

etk:

  • needs ecore (and in turn evas) both built with the directfb-flag and the fbcon flag
  • now has Ecore_DirectFb.h but still lacks Ecore_Fb.h
  • need to fix an appointment of etk with a ruthless proctologist

xglamo:

  • doesn't build as of now
  • needs libdrm installed

emotion:

  • depends on xine and/or gstreamer
  • produces this error with gstreamer ~0.10.21
  • gah! - gst-inspect-0.10 fixes it!

pygtk

  • pygtk-2.12.1-r2 fails - and upgrade triggers glib, gtl+ & pygobject - phew ...
  • ~pygtk-2.14.0 builds fine
  • need to clean up the dependencies of sunrise's version - that's awful!

pidgin

  • added perl and libperl to package provided - both won't build, plus we just need it at build-time.
  • set pidgin's use-flag to gnutls dbus gstreamer - gnutls helps us avoid nss (which fails to build)

fonts

  • media-libs/fontconfig must be installed in order to prevent sandbox violations from font-builds

"automatic keywording" (via openmoko overlay)

While i like the fact that the overlay provides me with the most current suggested keywords, I'd like to control at least a little which stuff is how keyworded. Imo, etc-update is suitable for that task.

Hence, TODO:
setup etc-update.conf to automatically sync the keywords downloaded from the openmoko overlay with my build-env. Probably combine this with a bash-hack in eix-sync.conf to shove the necessary files there.

suitable Kernel

We're Gentooers, right? So lets bake our own friggin' steamin' kernel. Though the Moko-folks made this more like a stroll in the park on a cool summer morning.

Before you start, get the mkimage-binary here and install (copy) it to ${PATH} and make it executable. (You might also want to read this.)

# clone the repo
   git clone git://git.openmoko.org/git/kernel.git linux-2.6
# Note: we're not using svn here. You can use what you want instead of linux-2.6.
# change to teh tree
   cd linux-2.6

# switch to the latest patches
   git checkout --track -b andy-tracking origin/andy-tracking
# Alternatives:
   # git checkout --track -b pending-tracking origin/pending-tracking   # ancient
   # git checkout --track -b stable-tracking origin/stable-tracking    # debian-style


# now here's a bit of fiddling required, since OM folks tailored this
# for their machinery

# Moko's provided us with an itsy-bitsy little build script.
# And now we're gonna fix it.
   sed -ie 's/\/usr\/local\/openmoko\/arm\/bin\/arm-angstrom-linux-gnueabi-/\/usr\/bin\/armv4tl-softfloat-linux-gnueabi-/' build
# and set PARALLEL from 16 (insane!) to 3
   sed -ie 's/PARALLEL=16/PARALLEL=3/' build

# proposed config for vendors --- see also
# http://lists.openmoko.org/nabble.html#nabble-td2398510
   cp arch/arm/configs/gta02_packaging_defconfig GTA02/.config
# Alternative: lots and lots of stuff, used for debugging et.al.
   # cp arch/arm/configs/gta02_moredrivers_defconfig GTA02/.config

# we want this in our kernel-root, so we can actually menu-/oldconfig
   ln -sf GTA02/.config ./

# verify that the .config is actually valid for this version
   make ARCH=arm oldconfig
# if you want to tailor it further to your needs, help yourself
   make ARCH=arm menuconfig

# especially the kernel-hacking part, but also the file-systems part can be
# customized.

# Here's a little caveat, though: when you're done editing with `make menuconfig`,
# the saved file will be named .config and your *link* will be renamed to .config.old.
# This means. your shiny new .config resides in the directory where you're supposed
# to perform `mrproper` - which will remove that stuff. And get the old .config back
# from ./GTA02. So:
   cp .config GTA02/

# The 'dummy' target provides us with a module-tarball.
# You don't care about no modules, don't use no dummy.
# So let's build the kernel.
   ./build GTA02 dummy

# Note: If this only gives you errors, then try
   export CROSS_COMPILE=armv4tl-softfloat-linux-gnueabi-
   make ARCH=arm modules
# If that works, try
   make mrproper
   ./build GTA02 dummy

# Here you should end up with a kernel-image and - if you so
# desired - the modules wrapped up tightly in a tarball.

# To update your kernel-stuff:
   cd somewhere/over/the/rainbow/linux-2.6
   make mrproper
   git pull
   make ARCH=arm oldconfig
   [make ARCH=arm menuconfig]
   ./build GTA02 [dummy]

# And if you did something stupid with a file, just erase it and type
   git checkout <file>
# or
   git checkout <dir>
# and the world is whole again.

boot splash:

http://wiki.openmoko.org/wiki/Configuring_the_boot_splash_screens

build the rootfs

I've written this handy little script for myself. Perhaps you can get some ideas or use it for yourself.

Alon Bar-Lev's implementation

Available here.

Ed's little corner

My rootfs is on a 8 GB uSD card.
/dev/mmcblk0p1 1 310 125545 b W95 FAT32 # kernel
/dev/mmcblk0p2 311 18000 7164450 83 Linux # rootfs
/dev/mmcblk0p3 18001 19165 471825 82 Linux swap / Solaris # swap

I couldn't get crosscompiling to work reliable, so i used distcc and native compiling.
Installed the the stage3 and portage tarball as usual.

messed up my make.profile. it should be:
/etc/make.profile -> /usr/local/portage/layman/openmoko/trunk/openmoko-target/profiles/openmoko
(assuming you have the overlay installed with layman in the usual place)
i added FEATURES="distcc buildpkg" to /etc/make.conf

After installing i ran
emerge --sync
emerge --verbose gentoolkit
emerge --verbose --update system
revdep-rebuild

This gave me a solid base to work on.
Be sure to install the right version of python (Python 2.5.2 atm) from the overlay.
I didn't and it cost me a day to figure out why the _ctags were missing...
After that is started installing xorg-server.
Couldn't install the glamo module, so X is running with the fbdev driver.
Installed twm
Now i had a graphical environment!
So I installed frameworkd and zhone 0.5 and was able to make my first phone call ;-)
Stability is less than i am used to with my gentoo desktops/laptops but very usable so far.
I did knit a script to restart X and twm if X crashes.
That will give me an xterm and keyboard again, so i can fix/break things.

Things that are working:
Wifi wpa psk+tkip
X

zhone
outgoing calls
incomming calls ( i needed libyaml for that otherwise rules.yaml was not used)
reading SMS
sending SMS
contacts
GPS. i need to issue

mdbus -s org.freedesktop.Gypsy /org/freedesktop/Gypsy org.freesmartphone.Resource.Resume

after starting fso-gpsd or starting zhone
GPRS. i needed to comment out replacedefaultroute in
/usr/lib/python2.5/site-packages/framework/subsystems/ogsmd/modems/abstract/modem.py
the pppd didn't know what to do with it and gave up.
usb, i used the openmoko 2.6.29-rc2 kernel to get that working.
Bluetooth.

Not yet woking:
xorg-server with the glamo driver

20090608 i updated to python-2.6.2-r1 from the overlay
The compile went fine, but python-updater complained about cython not being
installed.
Some things broke after the upgrade, so i needed to do by hand:
emerge --verbose dev-python/cython
emerge --verbose dev-python/pyrex
emerge --verbose dev-python/setuptools
emerge --verbose dev-python/python-evas
emerge --verbose dev-python/python-ecore

Revdep-rebuild want to install some things:
libframeworkd-phonegui-efl-20090506
But that broke because of a missing file.
So i did (butt ugly)
cd /usr/lib
ln -s libecore_job-ver-svn-02.so.0.9.9 libecore_job-ver-pre-01.so.0
ln -s libecore_evas-ver-svn-02.so.0.9.9 libecore_evas-ver-pre-01.so.0
ln -s libecore_x-ver-svn-02.so.0.9.9 libecore_x-ver-pre-01.so.0
ln -s libecore_input-ver-svn-02.so.0.9.9 libecore_input-ver-pre-01.so.0
ln -s libecore_txt-ver-svn-02.so.0.9.9 libecore_txt-ver-pre-01.so.0
ln -s libevas-ver-svn-02.so.0.9.9 libevas-ver-pre-01.so.0
ln -s libecore-ver-svn-02.so.0.9.9 libecore-ver-pre-01.so.0
ln -s libeina-ver-svn-02.so.0.0.2 libeina-ver-pre-01.so.0

IKrabbe's geeks way to boot

Maybe I'm a bit older or just more lazy than you, but I simply don't like to type in these long bootarg lines by hand on a terminal without being able to edit the lines really. When I fix environments I better like to open a text file with my beloved VIm. Actually I learned to type lines on 300Baud Terminals some years ago and sweared to never do so again.

Since I found out that I'm able to download u-boot_env I was eager to enter a `download, edit, upload' cycle to edit the environment. So first I did:

dfu-util -R -U boot.out -a u-boot_env

which is the upload dfu operation.

Looking at that boot.out file you see a very simple layout

[CRC32]{[{VARIABLE}={VALUE}][\0]}*
[FILLED with \0 bytes up to the length 262144]

So I wrote a small C Program to convert that format to a more simple to edit format

[{VARIABLE}={VALUE}\n]*

and back again. You can use upload_boot.c to simply build the upload_boot tool with

gcc -lz -o upload_boot upload_boot.c	# you will need libz for the crc32.

The Tool has two simple operation modes

  • host: convert from host to device
  • device: convert from device to host

So now I call

./upload_boot device <boot.out>boot.env

and edit the file boot.env with my favorite editor.

When done simply convert it back and upload to the device (which is called donwload for dfu-util of course).

./upload_boot host <boot.env>boot.out
dfu-util -R -D boot.out -a u-boot_env

That's all folks. See here some failures I made, that you don't need to do too in my personal area.

Thamos experiences

see ThamosSite

Attachments