http://wiki.openmoko.org/api.php?action=feedcontributions&user=TonyGarnockJones&feedformat=atomOpenmoko - User contributions [en]2013-05-24T01:59:46ZUser contributionsMediaWiki 1.19.6http://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2011-12-11T14:34:41Z<p>TonyGarnockJones: Updated my email address</p>
<hr />
<div>Tony Garnock-Jones, tonygarnockjones@gmail.com.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
== Erlang Userland ==<br />
<br />
I'm running [[Erlang]] with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
* "git clone git://github.com/tonyg/erlang-oe.git" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "git clone git://github.com/tonyg/erlang-serial.git" to track the serial-port erlang interface program<br />
* "git clone git://github.com/tonyg/erlang-openmoko.git" to track my userland (gsmd/dialer etc) code<br />
<br />
A screenshot, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://homepages.kcbbs.gen.nz/tonyg/pictures/openmoko-erlang-ui.png<br />
<br />
=== Status ===<br />
<br />
See the [http://github.com/tonyg/erlang-openmoko/blob/master/README README] for the current status, TODO and bugs. Currently 2090 non-blank, non-comment lines of code.<br />
<br />
Core (non-UI):<br />
<br />
* Clean(ish) API for scripting phone functionality (in Erlang)<br />
* Takes calls, makes calls, reliably enough for me to use as an everyday phone<br />
* Sends, receives, archives SMSes<br />
* DTMF send support during a call<br />
* Battery and charge-state monitoring<br />
* Detects when you might be connected to a dumb charger (no UI for forcing fast charge yet)<br />
* Powers GSM modem off when the phone is shut down<br />
* About 4-5 hours of battery life when idle - this will improve as general GTA01 power management improves<br />
<br />
Non-GUI user interface:<br />
<br />
* Plays an mp3/ogg file and vibrates when ringing<br />
* Vibrates on SMS receive<br />
* Switches ALSA profiles between in-call state (gsmhandset)/idle state (stereoout)<br />
* Press "power" to activate screen lock; press "aux" to release screen lock<br />
<br />
GUI user interface:<br />
<br />
* Really, really, really ugly.<br />
* Dims screen on user inactivity<br />
* Blanks screen and locks touchscreen on further inactivity<br />
* Very basic addressbook<br />
* Very basic SMS compose/display facility (no T9 yet)<br />
* Very basic dialer<br />
<br />
== gsmhandset.state echoes your own voice ==<br />
<br />
I've a tentative fix for this - here's the patch against gsmhandset.state. The alsamixer setting is labelled "Bypass" in the UI, and it's way over to the right, just after the "Amp ..." settings and just before "DAI Mode".<br />
<br />
<pre><br />
--- old/gsmhandset.state 2008-01-28 12:29:47.000000000 +0000<br />
+++ new/gsmhandset.state 2008-01-28 12:29:23.000000000 +0000<br />
@@ -55,8 +55,8 @@<br />
comment.range '0 - 7'<br />
iface MIXER<br />
name 'Bypass Playback Volume'<br />
- value.0 5<br />
- value.1 5<br />
+ value.0 0<br />
+ value.1 0<br />
}<br />
control.7 {<br />
comment.access 'read write'<br />
</pre></div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2011-12-11T14:31:44Z<p>TonyGarnockJones: Fixed link to screenshot</p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
== Erlang Userland ==<br />
<br />
I'm running [[Erlang]] with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
* "git clone git://github.com/tonyg/erlang-oe.git" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "git clone git://github.com/tonyg/erlang-serial.git" to track the serial-port erlang interface program<br />
* "git clone git://github.com/tonyg/erlang-openmoko.git" to track my userland (gsmd/dialer etc) code<br />
<br />
A screenshot, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://homepages.kcbbs.gen.nz/tonyg/pictures/openmoko-erlang-ui.png<br />
<br />
=== Status ===<br />
<br />
See the [http://github.com/tonyg/erlang-openmoko/blob/master/README README] for the current status, TODO and bugs. Currently 2090 non-blank, non-comment lines of code.<br />
<br />
Core (non-UI):<br />
<br />
* Clean(ish) API for scripting phone functionality (in Erlang)<br />
* Takes calls, makes calls, reliably enough for me to use as an everyday phone<br />
* Sends, receives, archives SMSes<br />
* DTMF send support during a call<br />
* Battery and charge-state monitoring<br />
* Detects when you might be connected to a dumb charger (no UI for forcing fast charge yet)<br />
* Powers GSM modem off when the phone is shut down<br />
* About 4-5 hours of battery life when idle - this will improve as general GTA01 power management improves<br />
<br />
Non-GUI user interface:<br />
<br />
* Plays an mp3/ogg file and vibrates when ringing<br />
* Vibrates on SMS receive<br />
* Switches ALSA profiles between in-call state (gsmhandset)/idle state (stereoout)<br />
* Press "power" to activate screen lock; press "aux" to release screen lock<br />
<br />
GUI user interface:<br />
<br />
* Really, really, really ugly.<br />
* Dims screen on user inactivity<br />
* Blanks screen and locks touchscreen on further inactivity<br />
* Very basic addressbook<br />
* Very basic SMS compose/display facility (no T9 yet)<br />
* Very basic dialer<br />
<br />
== gsmhandset.state echoes your own voice ==<br />
<br />
I've a tentative fix for this - here's the patch against gsmhandset.state. The alsamixer setting is labelled "Bypass" in the UI, and it's way over to the right, just after the "Amp ..." settings and just before "DAI Mode".<br />
<br />
<pre><br />
--- old/gsmhandset.state 2008-01-28 12:29:47.000000000 +0000<br />
+++ new/gsmhandset.state 2008-01-28 12:29:23.000000000 +0000<br />
@@ -55,8 +55,8 @@<br />
comment.range '0 - 7'<br />
iface MIXER<br />
name 'Bypass Playback Volume'<br />
- value.0 5<br />
- value.1 5<br />
+ value.0 0<br />
+ value.1 0<br />
}<br />
control.7 {<br />
comment.access 'read write'<br />
</pre></div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2011-05-11T15:20:46Z<p>TonyGarnockJones: </p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
== Erlang Userland ==<br />
<br />
I'm running [[Erlang]] with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
* "git clone git://github.com/tonyg/erlang-oe.git" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "git clone git://github.com/tonyg/erlang-serial.git" to track the serial-port erlang interface program<br />
* "git clone git://github.com/tonyg/erlang-openmoko.git" to track my userland (gsmd/dialer etc) code<br />
<br />
A few screenshots, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://eighty-twenty.org/~tonyg/erlang-openmoko-screenshots/<br />
<br />
=== Status ===<br />
<br />
See the [http://github.com/tonyg/erlang-openmoko/blob/master/README README] for the current status, TODO and bugs. Currently 2090 non-blank, non-comment lines of code.<br />
<br />
Core (non-UI):<br />
<br />
* Clean(ish) API for scripting phone functionality (in Erlang)<br />
* Takes calls, makes calls, reliably enough for me to use as an everyday phone<br />
* Sends, receives, archives SMSes<br />
* DTMF send support during a call<br />
* Battery and charge-state monitoring<br />
* Detects when you might be connected to a dumb charger (no UI for forcing fast charge yet)<br />
* Powers GSM modem off when the phone is shut down<br />
* About 4-5 hours of battery life when idle - this will improve as general GTA01 power management improves<br />
<br />
Non-GUI user interface:<br />
<br />
* Plays an mp3/ogg file and vibrates when ringing<br />
* Vibrates on SMS receive<br />
* Switches ALSA profiles between in-call state (gsmhandset)/idle state (stereoout)<br />
* Press "power" to activate screen lock; press "aux" to release screen lock<br />
<br />
GUI user interface:<br />
<br />
* Really, really, really ugly.<br />
* Dims screen on user inactivity<br />
* Blanks screen and locks touchscreen on further inactivity<br />
* Very basic addressbook<br />
* Very basic SMS compose/display facility (no T9 yet)<br />
* Very basic dialer<br />
<br />
== gsmhandset.state echoes your own voice ==<br />
<br />
I've a tentative fix for this - here's the patch against gsmhandset.state. The alsamixer setting is labelled "Bypass" in the UI, and it's way over to the right, just after the "Amp ..." settings and just before "DAI Mode".<br />
<br />
<pre><br />
--- old/gsmhandset.state 2008-01-28 12:29:47.000000000 +0000<br />
+++ new/gsmhandset.state 2008-01-28 12:29:23.000000000 +0000<br />
@@ -55,8 +55,8 @@<br />
comment.range '0 - 7'<br />
iface MIXER<br />
name 'Bypass Playback Volume'<br />
- value.0 5<br />
- value.1 5<br />
+ value.0 0<br />
+ value.1 0<br />
}<br />
control.7 {<br />
comment.access 'read write'<br />
</pre></div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2009-05-14T16:12:28Z<p>TonyGarnockJones: /* Erlang Userland */</p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
== Erlang Userland ==<br />
<br />
I'm running Erlang with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
* "git clone git://github.com/tonyg/erlang-oe.git" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "git clone git://github.com/tonyg/erlang-serial.git" to track the serial-port erlang interface program<br />
* "git clone git://github.com/tonyg/erlang-openmoko.git" to track my userland (gsmd/dialer etc) code<br />
<br />
A few screenshots, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://eighty-twenty.org/~tonyg/erlang-openmoko-screenshots/<br />
<br />
=== Status ===<br />
<br />
See the [http://github.com/tonyg/erlang-openmoko/blob/master/README README] for the current status, TODO and bugs. Currently 2090 non-blank, non-comment lines of code.<br />
<br />
Core (non-UI):<br />
<br />
* Clean(ish) API for scripting phone functionality (in Erlang)<br />
* Takes calls, makes calls, reliably enough for me to use as an everyday phone<br />
* Sends, receives, archives SMSes<br />
* DTMF send support during a call<br />
* Battery and charge-state monitoring<br />
* Detects when you might be connected to a dumb charger (no UI for forcing fast charge yet)<br />
* Powers GSM modem off when the phone is shut down<br />
* About 4-5 hours of battery life when idle - this will improve as general GTA01 power management improves<br />
<br />
Non-GUI user interface:<br />
<br />
* Plays an mp3/ogg file and vibrates when ringing<br />
* Vibrates on SMS receive<br />
* Switches ALSA profiles between in-call state (gsmhandset)/idle state (stereoout)<br />
* Press "power" to activate screen lock; press "aux" to release screen lock<br />
<br />
GUI user interface:<br />
<br />
* Really, really, really ugly.<br />
* Dims screen on user inactivity<br />
* Blanks screen and locks touchscreen on further inactivity<br />
* Very basic addressbook<br />
* Very basic SMS compose/display facility (no T9 yet)<br />
* Very basic dialer<br />
<br />
== gsmhandset.state echoes your own voice ==<br />
<br />
I've a tentative fix for this - here's the patch against gsmhandset.state. The alsamixer setting is labelled "Bypass" in the UI, and it's way over to the right, just after the "Amp ..." settings and just before "DAI Mode".<br />
<br />
<pre><br />
--- old/gsmhandset.state 2008-01-28 12:29:47.000000000 +0000<br />
+++ new/gsmhandset.state 2008-01-28 12:29:23.000000000 +0000<br />
@@ -55,8 +55,8 @@<br />
comment.range '0 - 7'<br />
iface MIXER<br />
name 'Bypass Playback Volume'<br />
- value.0 5<br />
- value.1 5<br />
+ value.0 0<br />
+ value.1 0<br />
}<br />
control.7 {<br />
comment.access 'read write'<br />
</pre></div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2009-05-14T16:00:13Z<p>TonyGarnockJones: /* Erlang Userland */</p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
== Erlang Userland ==<br />
<br />
I'm running Erlang with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
* "git clone git://github.com/tonyg/erlang-oe.git" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-serial/" to track the serial-port erlang interface program<br />
* "git clone git://github.com/tonyg/erlang-openmoko.git" to track my userland (gsmd/dialer etc) code<br />
<br />
A few screenshots, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://eighty-twenty.org/~tonyg/erlang-openmoko-screenshots/<br />
<br />
=== Status ===<br />
<br />
See the [http://github.com/tonyg/erlang-openmoko/blob/master/README README] for the current status, TODO and bugs. Currently 2090 non-blank, non-comment lines of code.<br />
<br />
Core (non-UI):<br />
<br />
* Clean(ish) API for scripting phone functionality (in Erlang)<br />
* Takes calls, makes calls, reliably enough for me to use as an everyday phone<br />
* Sends, receives, archives SMSes<br />
* DTMF send support during a call<br />
* Battery and charge-state monitoring<br />
* Detects when you might be connected to a dumb charger (no UI for forcing fast charge yet)<br />
* Powers GSM modem off when the phone is shut down<br />
* About 4-5 hours of battery life when idle - this will improve as general GTA01 power management improves<br />
<br />
Non-GUI user interface:<br />
<br />
* Plays an mp3/ogg file and vibrates when ringing<br />
* Vibrates on SMS receive<br />
* Switches ALSA profiles between in-call state (gsmhandset)/idle state (stereoout)<br />
* Press "power" to activate screen lock; press "aux" to release screen lock<br />
<br />
GUI user interface:<br />
<br />
* Really, really, really ugly.<br />
* Dims screen on user inactivity<br />
* Blanks screen and locks touchscreen on further inactivity<br />
* Very basic addressbook<br />
* Very basic SMS compose/display facility (no T9 yet)<br />
* Very basic dialer<br />
<br />
== gsmhandset.state echoes your own voice ==<br />
<br />
I've a tentative fix for this - here's the patch against gsmhandset.state. The alsamixer setting is labelled "Bypass" in the UI, and it's way over to the right, just after the "Amp ..." settings and just before "DAI Mode".<br />
<br />
<pre><br />
--- old/gsmhandset.state 2008-01-28 12:29:47.000000000 +0000<br />
+++ new/gsmhandset.state 2008-01-28 12:29:23.000000000 +0000<br />
@@ -55,8 +55,8 @@<br />
comment.range '0 - 7'<br />
iface MIXER<br />
name 'Bypass Playback Volume'<br />
- value.0 5<br />
- value.1 5<br />
+ value.0 0<br />
+ value.1 0<br />
}<br />
control.7 {<br />
comment.access 'read write'<br />
</pre></div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/U-BootU-Boot2009-05-14T12:21:04Z<p>TonyGarnockJones: /* Using usbtty from Linux */</p>
<hr />
<div>{{Languages|Bootloader}}<br />
<br />
[[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 used on the smartphones is called '''U-Boot'''. It takes care of device functionality until Openmoko is booted. This includes [[USB DFU]] for [[Flashing the Neo FreeRunner]], 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. Newer yet is [[Qi]].<br />
<br />
== Booting into U-boot ==<br />
<br />
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.<br />
* Hold in the AUX button on power-up to access the boot menu.<br />
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.<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; see also below)<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 />
All versions of the OM smartphone use 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 source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .<br />
<br />
To get u-boot by git:<br />
<br />
git clone git://git.openmoko.org/git/u-boot.git openmoko/u-boot<br />
<br />
To build u-boot:<br />
* Clone the git tree and check out the stable branch<br />
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries<br />
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)<br />
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)<br />
<br />
== Bootloader binary ==<br />
<br />
The latest bootloader binary builds can be found under http://downloads.openmoko.org/distro/unstable/daily/ .<br />
<br />
All versions of the GTA02 (Neo FreeRunner) that have been sold to the public are version 5 hardware, so look for a file with "gta02" and "v5" in the name, for example:<br />
uboot-gta02v5-latest.bin<br />
<br />
The file should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[Partitions|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 />
=== Neo 1973 ===<br />
<br />
Doing bootloader development on the [[Neo 1973]] 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 />
=== Neo FreeRunner ===<br />
{{main|Neo_FreeRunner_Memory_Mapping}}<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, check that module cdc_acm is loaded or CONFIG_USB_ACM=y (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. Clear any modem intialisation strings (minicom).<br />
<br />
You can adapt the instructions for USB-serial from the [[MacOS_X#USB_Serial|Mac OS]] page.<br />
If you don't have a favorite, try just "cu -l dev/ttyACM0". It is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed<br />
<br />
Enter Bootprompt with:<br />
<pre><br />
cu -l /dev/ttyACM0<br />
</pre><br />
You might need to<br />
chown uucp.uucp /dev/ttyACM0<br />
to get the necessary rights (even as root, must be done each time). For example, if cu prints "cu: /dev/ttyACM0: Line in use", then try chowning /dev/ttyACM0 to uucp.uucp; apparently cu can be pretty picky about permissions.<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 />
<pre><br />
# lsusb -d 1457:5119<br />
Bus 005 Device 079: ID 1457:5119<br />
</pre><br />
'''Note''': The Neo Freerunner (GTA02) has the ID 1d50:5119<br />
<br />
Second, let's 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 />
=== What if I borked my bootloader environment and don't get a prompt anymore? ===<br />
{{Note|This solution applies to a changed u-boot environment which prevents NAND u-boot to successfully boot. The Debian u-boot configuration script may be a cause of this issue.}}<br />
Found a solution here:<br />
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]<br />
<br />
It works the following way:<br />
* Get the devirginator:<br />
svn co http://svn.openmoko.org/trunk/src/host/devirginator<br />
cd devirginator<br />
* Read the u-boot environment from the device:<br />
dfu-util -a u-boot_env -R -U env.in<br />
* Create a file that contains everything you want to change in your u-boot environment or get it by issuing the following command:<br />
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in<br />
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo FreeRunner only, and has to come before the other options.<br />
./envedit.pl -D GTA02 -i env.in -f environment.in -o env.out<br />
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:<br />
warning: environment is 262144 bytes, expected 16384<br />
CRC error: expected 0xc33e35fc, got 0x93097bfb<br />
* In this case jut add an additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:<br />
./envedit.pl -s 262144 -D GTA02 -i env.in -f environment.in -o env.out<br />
* Now the perl script should produce no more output anything but write a new u-boot_env partition that we can upload to the device by:<br />
dfu-util -a u-boot_env -R -D env.out<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]]. For neo 1973 you may see [[Flashing the Neo 1973#Actually_flashing_things_into_the_device]], and for the FreeRunner : [[Flashing the Neo FreeRunner]].<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 />
or<br />
<br />
hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...<br />
usb 4-1: USB disconnect, address 2<br />
<br />
A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.<br />
<br />
rmmod uhci_hcd ; modprobe uhci_hcd<br />
<br />
Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.<br />
<br />
Disconnecting the Neo's USB while powering up may prevent this problem in the future.<br />
<br />
== Related pages ==<br />
<br />
See [[Flashing the Neo 1973]] and [[Flashing the Neo FreeRunner]] for instructions on using dfu-util to install a new bootloader in your phone.<br />
<br />
[[Category:System Developers]]<br />
[[Category:Flashing Openmoko]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/U-BootU-Boot2009-05-14T12:20:00Z<p>TonyGarnockJones: /* Booting into U-boot */</p>
<hr />
<div>{{Languages|Bootloader}}<br />
<br />
[[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 used on the smartphones is called '''U-Boot'''. It takes care of device functionality until Openmoko is booted. This includes [[USB DFU]] for [[Flashing the Neo FreeRunner]], 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. Newer yet is [[Qi]].<br />
<br />
== Booting into U-boot ==<br />
<br />
* Make sure that your phone has had the battery and USB cable removed for at least 30 seconds.<br />
* Hold in the AUX button on power-up to access the boot menu.<br />
* Connect the Neo (ie not Debug Board) to a Linux host with the USB cable.<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; see also below)<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 />
All versions of the OM smartphone use 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 source can be found at http://git.openmoko.org/?p=u-boot.git;a=shortlog;h=stable .<br />
<br />
To get u-boot by git:<br />
<br />
git clone git://git.openmoko.org/git/u-boot.git openmoko/u-boot<br />
<br />
To build u-boot:<br />
* Clone the git tree and check out the stable branch<br />
* Set the CROSS_COMPILE environment variable to specify the prefix to your toolchain binaries<br />
* Run "make gta02v5_config" (or gta01bv4_config, or whatever hardware revision you have)<br />
* Run "make u-boot.udfu". This will give you an image which you can install with dfu-util, or which you can upload into memory via JTAG (with a debug board)<br />
<br />
== Bootloader binary ==<br />
<br />
The latest bootloader binary builds can be found under http://downloads.openmoko.org/distro/unstable/daily/ .<br />
<br />
All versions of the GTA02 (Neo FreeRunner) that have been sold to the public are version 5 hardware, so look for a file with "gta02" and "v5" in the name, for example:<br />
uboot-gta02v5-latest.bin<br />
<br />
The file should be written to the NAND flash address 0x00000000 (size 0x30000) (the first [[Partitions|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 />
=== Neo 1973 ===<br />
<br />
Doing bootloader development on the [[Neo 1973]] 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 />
=== Neo FreeRunner ===<br />
{{main|Neo_FreeRunner_Memory_Mapping}}<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, check that module cdc_acm is loaded or CONFIG_USB_ACM=y (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. Clear any modem intialisation strings (minicom).<br />
<br />
You can adapt the instructions for USB-serial from the [[MacOS_X#USB_Serial|Mac OS]] page.<br />
If you don't have a favorite, try just "cu -l dev/ttyACM0". It is in the taylor-uucp package, use "apt-get install cu" if it is not yet installed<br />
<br />
Enter Bootprompt with:<br />
<pre><br />
cu -l /dev/ttyACM0<br />
</pre><br />
You might need to<br />
chown uucp.uucp /dev/ttyACM0<br />
to get the necessary rights (even as root, must be done each time).<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 />
<pre><br />
# lsusb -d 1457:5119<br />
Bus 005 Device 079: ID 1457:5119<br />
</pre><br />
'''Note''': The Neo Freerunner (GTA02) has the ID 1d50:5119<br />
<br />
Second, let's 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 />
=== What if I borked my bootloader environment and don't get a prompt anymore? ===<br />
{{Note|This solution applies to a changed u-boot environment which prevents NAND u-boot to successfully boot. The Debian u-boot configuration script may be a cause of this issue.}}<br />
Found a solution here:<br />
[[http://markmail.org/message/gqypwiohdet6x4am?q=almesberger+partition&page=1&refer=xbamkzwwsaobv7wa]]<br />
<br />
It works the following way:<br />
* Get the devirginator:<br />
svn co http://svn.openmoko.org/trunk/src/host/devirginator<br />
cd devirginator<br />
* Read the u-boot environment from the device:<br />
dfu-util -a u-boot_env -R -U env.in<br />
* Create a file that contains everything you want to change in your u-boot environment or get it by issuing the following command:<br />
wget http://svn.openmoko.org/trunk/src/host/devirginator/environment.in<br />
* Now let devirginator generate a new u-boot_env partition for us, - that contains the partition table from our u-boot_env, - and all changes we wanted to make; Note that the -D GTA02 is needed for the neo FreeRunner only, and has to come before the other options.<br />
./envedit.pl -D GTA02 -i env.in -f environment.in -o env.out<br />
* On my box the partition layout didn't seem to match the idea of envedit.pl, so it issued 2 warnings:<br />
warning: environment is 262144 bytes, expected 16384<br />
CRC error: expected 0xc33e35fc, got 0x93097bfb<br />
* In this case jut add an additional argument to the command line - that has to be the 1st argument, though, and that contains the size information we got from the warning:<br />
./envedit.pl -s 262144 -D GTA02 -i env.in -f environment.in -o env.out<br />
* Now the perl script should produce no more output anything but write a new u-boot_env partition that we can upload to the device by:<br />
dfu-util -a u-boot_env -R -D env.out<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]]. For neo 1973 you may see [[Flashing the Neo 1973#Actually_flashing_things_into_the_device]], and for the FreeRunner : [[Flashing the Neo FreeRunner]].<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 />
or<br />
<br />
hub 4-0:1.0: port 1 disabled by hub (EMI?), re-enabling...<br />
usb 4-1: USB disconnect, address 2<br />
<br />
A possible solution is given below. Please note that if you have a usb keyboard or mouse then the command might cause trouble.<br />
<br />
rmmod uhci_hcd ; modprobe uhci_hcd<br />
<br />
Another option is to plug the FR into a different USB port on the host, preferably one on the Motherboard not the hub.<br />
<br />
Disconnecting the Neo's USB while powering up may prevent this problem in the future.<br />
<br />
== Related pages ==<br />
<br />
See [[Flashing the Neo 1973]] and [[Flashing the Neo FreeRunner]] for instructions on using dfu-util to install a new bootloader in your phone.<br />
<br />
[[Category:System Developers]]<br />
[[Category:Flashing Openmoko]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/OpenEmbeddedOpenEmbedded2009-05-13T23:49:24Z<p>TonyGarnockJones: /* ${OE_HOME} */</p>
<hr />
<div>{{Languages|OpenEmbedded}}<br />
<br />
Openmoko, our distribution, is built using OpenEmbedded. OpenEmbedded will:<br />
<br />
* Generate (cross-compile) software packages for multiple embedded targets.<br />
* Handle different hardware architectures, and support multiple releases across those architectures. <br />
<br />
For more information please see the [http://www.openembedded.org/ Open Embedded] website.<br />
<br />
== Building the Openmoko Distribution with OpenEmbedded ==<br />
<br />
'''Note:''' If you are an application developer, you probably do not want to build OpenEmbedded from scratch. For compiling simple applications with few library dependencies (including boot-loader and kernel), consider using our prebuilt [[Toolchain]]. For more complex applications with many library dependencies, download a prebuilt [[OpenEmbedded Torrent]]. <br />
<br />
Building Openmoko from scratch is a time-, cpu- and diskspace-consuming process which should only be done if you are a system integrator and want to customize your Openmoko distribution.<br />
<br />
=== Simplified Instructions: MokoMakefile ===<br />
<br />
For beginners who wish to customize their Openmoko distribution, the facility called [[MokoMakefile]] simplifies building OpenEmbedded.<br />
<br />
=== Quick Start: OpenEmbedded Torrent ===<br />
<br />
If you are a system developer and would like to get up-to-speed as quickly as possible, then download an [[OpenEmbedded Torrent]].<br />
<br />
== From Scratch: OpenEmbedded ==<br />
<br />
Beginner Openmoko developers who would prefer to have full control over their OpenEmbedded build environment should follow the instructions below.<br />
<br />
=== Preparations ===<br />
<br />
Several prerequisite software components are necessary in order to have a fully functional OpenEmbedded build environment. However, setup and installation varies depending on the operating system installed on your workstation. The [http://wiki.openembedded.net/index.php OpenEmbedded Wiki] provides [http://wiki.openembedded.net/index.php/OEandYourDistro setup instructions] for FreeBSD, Mac OS X, and most major Linux distributions, of course.<br />
<br />
For OpenEmbedded installation instructions please refer to [http://wiki.openembedded.net/index.php/OEandYourDistro OEandYourDistro]. <br />
<br />
=== ${OE_HOME} ===<br />
<br />
Assuming that you have installed all prerequisite software, you are now ready to create a directory for all of your OpenEmbedded (OE) related work. We will refer to OE_HOME in a generic way, but for argument's sake, assume that it is equal to ${HOME}/oe. You should expect ${OE_HOME} to grow tremendously in size, up to approximately 8GB or larger in some cases. Also be aware, that a full OE build could require several hours of constant building, which may inhibit the performance of your computer while performing other tasks. Replace ${HOME}/oe with your preferred location.<br />
<br />
For Bash users:<br />
export OE_HOME=${HOME}/oe<br />
<br />
For Tcsh users:<br />
setenv OE_HOME ${HOME}/oe<br />
<br />
Next, run 'mkdir -p ${OE_HOME}' to create the directory.<br />
<br />
Beware of symlinks: make sure that your ${OE_HOME} variable is set to the true path to the directory, and does not involve any symbolic links. See also http://wiki.openembedded.net/index.php/Category_talk:FAQ#3._Error:_Building_libtool-native_dies_with_.22configure:_error:_source_directory_already_configured.3B_run_.22make_distclean.22_there_first.22<br />
<br />
=== Synchronizing OpenEmbedded With Git ===<br />
<br />
Just like any tree, OpenEmbedded has several branches. In this case they are called 'development branches'. Some noteworthy ones include org.openembedded.dev (the default) and org.openembedded.stable . <br />
<br />
To syncronize the OpenEmbedded tree, run<br />
<pre><br />
git clone git://git.openembedded.net/openembedded ${OE_HOME}/org.openembedded.dev <br />
</pre><br />
<br />
Note that last argument could be any directory name (git will create the directory if it doesn't exist). Sticking to 'good convention', the directory name was chosen to reflect the default development branch, org.openembedded.dev . See the [http://wiki.openembedded.net/index.php/GitPhraseBook OE GitPhraseBook] for more info on checking out different branches. <br />
<br />
To update the tree, run<br />
<pre><br />
cd ${OE_HOME}/org.openembedded.dev<br />
git pull<br />
</pre><br />
<br />
You probably also want to use an fso branch<br />
<br />
<pre><br />
git checkout -b fso/milestone5.5 origin/fso/milestone5.5<br />
</pre><br />
<br />
For further information on Git, see [http://git-scm.com The Git Homepage].<br />
<br />
Also, please explore the directory structure of the OpenEmbedded build tree. Take a few moments to inspect the different types of BitBake files (.bbclass, .bb, .inc, etc). This helps one to become familiar with recipe syntax and the inheritance system. Of particular note, please read the file 'local.conf.sample'. <br />
<pre><br />
org.openembedded.dev<br />
|-- classes<br />
| |-- rootfs_ipk.bbclass<br />
| `-- xorg-module.bbclass<br />
|-- conf<br />
| `-- local.conf.sample<br />
| |-- distro<br />
| | `-- angstrom-2008.1.conf<br />
| |-- machine<br />
| | |-- om-gta01.conf<br />
| | `-- om-gta02.conf<br />
`-- packages<br />
|-- tangogps<br />
| |-- tangogps.inc<br />
| `-- tangogps_0.9.3.bb<br />
`-- images<br />
|-- console-image.bb<br />
|-- fso-console-image.bb<br />
|-- fso-image.bb<br />
|-- openmoko-image.bb<br />
|-- opie-image.bb<br />
`-- x11-image.bb<br />
</pre><br />
<br />
=== local.conf ===<br />
<br />
If you explored local.conf.example, then you would be aware that there are some very important variables to be set like MACHINE, DISTRO, and BBFILES, among many others. This is done in a configuration file (local.conf) inside the build directory. <br />
<br />
'''Note:''' Using BitBake and OE for cross-compilation require that each target-distro combination is built in a separate directory, so that no version collisions occur. Concurrent builds may safely share the same DL_DIR though. This would suggest that a safe name for build directories is of the form ${OE_HOME}/build-${MACHINE}-${DISTRO}. Of course, if you don't plan on building for more than one machine-distro combination, then the naming of this directory is arbitrary. For the purpose of this example, we will use the convention ${OE_HOME}/build-${MACHINE} . <br />
<br />
Now, create the 'local.conf' configuration file. Notice that the CACHE and TMPDIR variables are neatly kept within the build directory while the DL_DIR variable is outside of the build directory, so that concurrent builds may reuse the same source packages. <br />
<pre><br />
OE_HOME ?= "${HOME}/oe"<br />
<br />
MACHINE = "om-gta02"<br />
DISTRO = "openmoko"<br />
<br />
DL_DIR = "${OE_HOME}/downloads"<br />
<br />
BBFILES := "${OE_HOME}/org.openembedded.dev/recipes/*/*.bb"<br />
<br />
BBMASK = ""<br />
<br />
TMPDIR = "${OE_HOME}/build-${MACHINE}/tmp"<br />
CACHE = "${TMPDIR}/cache"<br />
<br />
IMAGE_FSTYPES = "jffs2 tar.gz"<br />
<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
</pre><br />
<br />
The BBFILES variable is also of prime importance! It tells bitbake where to locate all available recipes for a build. The OpenEmbedded build environment is almost completely ready to go, with just one more minor step left.<br />
<br />
If you're not using a distro-provided makefile setup, and your site.conf (or local.conf) doesn't include the line<br />
<pre><br />
SRCPV = "${@bb.fetch.get_srcrev(d)}"<br />
</pre><br />
then you may find bitbake complaining along the lines of<br />
<pre><br />
ERROR: EOL while scanning string literal (<string>, line 1) while parsing .../openmoko/org.openembedded.dev/recipes/freesmartphone/frameworkd_git.bb<br />
</pre><br />
According to mwester on irc #openmoko-cdevel, referring to the use of the SRCPV line, "That's a temporary hack, we hope -- if all goes well that should end up 'upstream'."<br />
<br />
=== setup-env ===<br />
<br />
For quick and easy initialization of the OpenEmbedded build environment, it is often suggested that the developer create a 'setup-env' script to source from the command line. This script can be called to initialize the most important of environment variables. Below is a very basic example of a setup-env script. <br />
<br />
setup-env for Bash users:<br />
<pre><br />
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe<br />
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02<br />
export BBPATH=${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
setup-env for Tcsh users:<br />
<pre><br />
[[ -z ${OE_HOME} ]] && setenv OE_HOME ${HOME}/oe<br />
[[ -z ${MACHINE} ]] && setenv MACHINE om-gta02<br />
setenv BBPATH ${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
To invoke the setup-env script in bash, run 'source setup-env'. In tcsh, run '. setup-env'.<br />
<br />
See the section entitled [http://wiki.openmoko.org/wiki/OpenEmbedded#BitBake_Overlays BitBake Overlays] for an example of a more complicated setup-env script.<br />
<br />
=== Testing the OE Build Environment ===<br />
<br />
That's it! Now you should be prepared to bake your first BitBake recipe. <br />
<br />
bitbake helloworld<br />
<br />
=== Building an Image ===<br />
<br />
There are several full filesystem images which can be built directly with OpenEmbedded using a single command. These include openmoko-image, fso-image, and so on. The image definitions can be found under ${OE_HOME}/org.openembedded.dev/packages/images<br />
<br />
A good place to start is with <br />
<br />
bitbake fso-image<br />
<br />
That concludes this introduction to BitBake and OpenEmbedded. Good luck!<br />
<br />
=== Other References ===<br />
<br />
Please feel free to refer to other online sources of information for [http://bitbake.berlios.de BitBake], [http://www.openembedded.org OpenEmbedded], and the [http://www.angstrom-distribution.org Angstrom Distribution] to name a few.<br />
<br />
== Broken Builds and Bug Reporting ==<br />
<br />
Using the org.openembedded.dev branch can often result in broken builds. For that reason, it is usually a good idea to limit synchronizing with the repository only after successfully building an image. Some may even want to archive the tree and build directory after an image is built.<br />
<br />
Now in the case that an image does not successfully build, it is not always necessarily a bug or a new bug. The problem might have to do with some conflicting software on the workstation, and it could be a bug that is already know and being fixed.<br />
<br />
Below are a few useful steps to follow when a build does not successfully complete:<br />
<br />
* Identify the package that failed to build<br />
** Find a line near the bottom of your output that matches "ERROR: ... failed" or "NOTE: ... failed". The name of the package should be contained in the '...'<br />
* If there is a similar, more stable version in ${OE_HOME}/org.openembedded.dev/packages, then try to use that instead<br />
** bitbake -c clean somepackage && bitbake -b ${OE_HOME}/org.openembedded.dev/packages/somepackage/somepackage_0.1.bb<br />
** add PREFERRED_VERSION_somepackage = "0.1" to local.conf<br />
* Read the BitBake log, as well as config.log if it exists<br />
** Find the log file. There should be a line near the bottom of your output that matches "ERROR: see log in ...", where '...' contains the log file name. These are usually of the form log.do_compile.12345 or log.do_configure.12345, etc. <br />
* Try to identify the root cause of the error<br />
** In many cases, if one examines log.do_configure, only the error is reported, but not the cause of the error<br />
** Most packages that build with autotools will also have a config.log file that contains the exact cause of the error<br />
* If you can fix the error, and the error is local to your workstation, and not really a bug, then fix the error yourself.<br />
* Otherwise, check the [http://bugs.openembedded.net OpenEmbedded Bugzilla] to see if the error is known.<br />
* If a solution is already available, then try it out. If you can fix the error, then do so. If your solution is correct, please post all relevent patches to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]<br />
<br />
=== Where to Report Bugs ===<br />
<br />
Authentic bugs should be reported to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Setting the PREFERRED_VERSION for a package ===<br />
<br />
If a certain package is known to not build, and there is a less recent / more stable version of that package, then a good way to avoid repetitive encounters with known build failures is to use preferred versions of packages. <br />
<br />
For example, if building gcc-4.2.4 constantly failed, then it would be wise to edit local.conf and set PREFERRED_VERSION_gcc = "4.1.2".<br />
<br />
=== Screen is Your Friend ===<br />
<br />
If you happen to be building all of your packages remotely on a server, using an ssh session, the session might occasionally be interrupted and the connection could be terminated. A similar event could occur if your X server suddenly craches. If in the process of building an image with bitbake, this means that the build process will terminate as well. <br />
<br />
In order to ensure that a build continues in the presence of communication failures, it is advisable to use the [http://www.gnu.org/software/screen GNU Screen] utility. Screen is also very useful when performing several concurrent OpenEmbedded builds for different machine-distro combinations.<br />
<br />
Screen installation varies with your OS and distribution.<br />
<br />
=== BitBake Overlays ===<br />
<br />
Bitbake overlays are useful for OpenEmbedded developers to eliminate bugs or package software without disturbiing the OpenEmbedded tree itself. Overlays are very similar in structure to the OpenEmbedded tree, but are usually only sparsely populated. Non-sparsely poplulated overlays are actually more closely related to separate development branches. Good convention would suggest to always name the overlay appropriately. <br />
<br />
Below is an example of two overlays, three build directories, a setup-env script, and a local.conf where the developer has multiple build targets as well as multiple BitBake overlays.<br />
<pre><br />
oe<br />
|-- build-beagleboard<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- build-om-gta02<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- build-ts72xx<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- com.somecompany.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| |-- images<br />
| | `-- console-image.bb<br />
| `-- rxtx<br />
| |-- files<br />
| |-- rxtx-fixes-from-debian.patch<br />
| `-- rxtx_2.1-7r2.bb<br />
|-- org.openembedded.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| `-- images<br />
|-- org.openmoko.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| `-- tangogps<br />
| |-- tangogps.inc<br />
| `-- tangogps_0.9.3.bb<br />
`-- setup-env<br />
</pre><br />
<br />
An example of the setup-env script with multiple overlays and multiple build targets is below. <br />
<br />
<pre><br />
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe<br />
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02<br />
<br />
unset BBPATH<br />
<br />
case "${MACHINE}" in<br />
"beagleboard" | "ts72xx" ) <br />
BBPATH="${OE_HOME}/com.somecompany.dev"<br />
;;<br />
"om-gta02")<br />
BBPATH="${OE_HOME}/org.openmoko.dev"<br />
;;<br />
*)<br />
echo -e "error: unsupported machine"<br />
exit -1<br />
;;<br />
esac<br />
<br />
export BBPATH=${BBPATH}:${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
<br />
Note that the overlay-specific BBPATH entry ''precedes'' the default BBPATH entries.<br />
<br />
Next, observe the changes necessary for local.conf in order to use a specific overlay (in this case org.openmoko.dev).<br />
<br />
<pre><br />
...<br />
BBFILES := "${OE_HOME}/org.openembedded.dev/packages/*/*.bb"<br />
BBFILES += " ${OE_HOME}/org.openmoko.dev/packages/*/*.bb"<br />
<br />
BBFILE_COLLECTIONS = "upstream moko"<br />
BBFILE_PATTERN_upstream = "${OE_HOME}/org.openembedded.dev"<br />
BBFILE_PRIORITY_upstream = "0"<br />
BBFILE_PATTERN_moko = "${OE_HOME}/org.openmoko.dev"<br />
BBFILE_PRIORITY_moko = "1"<br />
...<br />
</pre><br />
<br />
In order for the overlay to be detected by BitBake, the above variables need to be defined in the local.conf file. It is possible to include more than one overlay. For each overlay, add a separate BBFILES += statement, an entry in BBFILE_COLLECTIONS, a BBFILE_PATTERN, and BBFILE_PRIORITY. Remember to include at least one space (' ') between each BBFILES entry.<br />
<br />
=== Useful BitBake Commands ===<br />
<br />
<pre><br />
# list all of the tasks defined for a given package_name<br />
bitbake -c listtasks <package_name><br />
<br />
# clean the work directory for a specific package<br />
bitbake -c clean <package_name><br />
<br />
# build a specific recipe<br />
bitbake -b <path/to/some/recipe.bb><br />
<br />
# if files or variables not found debug with<br />
bitbake -D -D -D<br />
</pre><br />
<br />
[[Category:Application Developer]]<br />
[[Category:System Developers]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/OpenEmbeddedOpenEmbedded2009-05-13T20:20:36Z<p>TonyGarnockJones: /* local.conf */</p>
<hr />
<div>{{Languages|OpenEmbedded}}<br />
<br />
Openmoko, our distribution, is built using OpenEmbedded. OpenEmbedded will:<br />
<br />
* Generate (cross-compile) software packages for multiple embedded targets.<br />
* Handle different hardware architectures, and support multiple releases across those architectures. <br />
<br />
For more information please see the [http://www.openembedded.org/ Open Embedded] website.<br />
<br />
== Building the Openmoko Distribution with OpenEmbedded ==<br />
<br />
'''Note:''' If you are an application developer, you probably do not want to build OpenEmbedded from scratch. For compiling simple applications with few library dependencies (including boot-loader and kernel), consider using our prebuilt [[Toolchain]]. For more complex applications with many library dependencies, download a prebuilt [[OpenEmbedded Torrent]]. <br />
<br />
Building Openmoko from scratch is a time-, cpu- and diskspace-consuming process which should only be done if you are a system integrator and want to customize your Openmoko distribution.<br />
<br />
=== Simplified Instructions: MokoMakefile ===<br />
<br />
For beginners who wish to customize their Openmoko distribution, the facility called [[MokoMakefile]] simplifies building OpenEmbedded.<br />
<br />
=== Quick Start: OpenEmbedded Torrent ===<br />
<br />
If you are a system developer and would like to get up-to-speed as quickly as possible, then download an [[OpenEmbedded Torrent]].<br />
<br />
== From Scratch: OpenEmbedded ==<br />
<br />
Beginner Openmoko developers who would prefer to have full control over their OpenEmbedded build environment should follow the instructions below.<br />
<br />
=== Preparations ===<br />
<br />
Several prerequisite software components are necessary in order to have a fully functional OpenEmbedded build environment. However, setup and installation varies depending on the operating system installed on your workstation. The [http://wiki.openembedded.net/index.php OpenEmbedded Wiki] provides [http://wiki.openembedded.net/index.php/OEandYourDistro setup instructions] for FreeBSD, Mac OS X, and most major Linux distributions, of course.<br />
<br />
For OpenEmbedded installation instructions please refer to [http://wiki.openembedded.net/index.php/OEandYourDistro OEandYourDistro]. <br />
<br />
=== ${OE_HOME} ===<br />
<br />
Assuming that you have installed all prerequisite software, you are now ready to create a directory for all of your OpenEmbedded (OE) related work. We will refer to OE_HOME in a generic way, but for argument's sake, assume that it is equal to ${HOME}/oe. You should expect ${OE_HOME} to grow tremendously in size, up to approximately 8GB or larger in some cases. Also be aware, that a full OE build could require several hours of constant building, which may inhibit the performance of your computer while performing other tasks. Replace ${HOME}/oe with your preferred location.<br />
<br />
For Bash users:<br />
export OE_HOME=${HOME}/oe<br />
<br />
For Tcsh users:<br />
setenv OE_HOME ${HOME}/oe<br />
<br />
Next, run 'mkdir -p ${OE_HOME}' to create the directory. <br />
<br />
=== Synchronizing OpenEmbedded With Git ===<br />
<br />
Just like any tree, OpenEmbedded has several branches. In this case they are called 'development branches'. Some noteworthy ones include org.openembedded.dev (the default) and org.openembedded.stable . <br />
<br />
To syncronize the OpenEmbedded tree, run<br />
<pre><br />
git clone git://git.openembedded.net/openembedded ${OE_HOME}/org.openembedded.dev <br />
</pre><br />
<br />
Note that last argument could be any directory name (git will create the directory if it doesn't exist). Sticking to 'good convention', the directory name was chosen to reflect the default development branch, org.openembedded.dev . See the [http://wiki.openembedded.net/index.php/GitPhraseBook OE GitPhraseBook] for more info on checking out different branches. <br />
<br />
To update the tree, run<br />
<pre><br />
cd ${OE_HOME}/org.openembedded.dev<br />
git pull<br />
</pre><br />
<br />
You probably also want to use an fso branch<br />
<br />
<pre><br />
git checkout -b fso/milestone5.5 origin/fso/milestone5.5<br />
</pre><br />
<br />
For further information on Git, see [http://git-scm.com The Git Homepage].<br />
<br />
Also, please explore the directory structure of the OpenEmbedded build tree. Take a few moments to inspect the different types of BitBake files (.bbclass, .bb, .inc, etc). This helps one to become familiar with recipe syntax and the inheritance system. Of particular note, please read the file 'local.conf.sample'. <br />
<pre><br />
org.openembedded.dev<br />
|-- classes<br />
| |-- rootfs_ipk.bbclass<br />
| `-- xorg-module.bbclass<br />
|-- conf<br />
| `-- local.conf.sample<br />
| |-- distro<br />
| | `-- angstrom-2008.1.conf<br />
| |-- machine<br />
| | |-- om-gta01.conf<br />
| | `-- om-gta02.conf<br />
`-- packages<br />
|-- tangogps<br />
| |-- tangogps.inc<br />
| `-- tangogps_0.9.3.bb<br />
`-- images<br />
|-- console-image.bb<br />
|-- fso-console-image.bb<br />
|-- fso-image.bb<br />
|-- openmoko-image.bb<br />
|-- opie-image.bb<br />
`-- x11-image.bb<br />
</pre><br />
<br />
=== local.conf ===<br />
<br />
If you explored local.conf.example, then you would be aware that there are some very important variables to be set like MACHINE, DISTRO, and BBFILES, among many others. This is done in a configuration file (local.conf) inside the build directory. <br />
<br />
'''Note:''' Using BitBake and OE for cross-compilation require that each target-distro combination is built in a separate directory, so that no version collisions occur. Concurrent builds may safely share the same DL_DIR though. This would suggest that a safe name for build directories is of the form ${OE_HOME}/build-${MACHINE}-${DISTRO}. Of course, if you don't plan on building for more than one machine-distro combination, then the naming of this directory is arbitrary. For the purpose of this example, we will use the convention ${OE_HOME}/build-${MACHINE} . <br />
<br />
Now, create the 'local.conf' configuration file. Notice that the CACHE and TMPDIR variables are neatly kept within the build directory while the DL_DIR variable is outside of the build directory, so that concurrent builds may reuse the same source packages. <br />
<pre><br />
OE_HOME ?= "${HOME}/oe"<br />
<br />
MACHINE = "om-gta02"<br />
DISTRO = "openmoko"<br />
<br />
DL_DIR = "${OE_HOME}/downloads"<br />
<br />
BBFILES := "${OE_HOME}/org.openembedded.dev/recipes/*/*.bb"<br />
<br />
BBMASK = ""<br />
<br />
TMPDIR = "${OE_HOME}/build-${MACHINE}/tmp"<br />
CACHE = "${TMPDIR}/cache"<br />
<br />
IMAGE_FSTYPES = "jffs2 tar.gz"<br />
<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
</pre><br />
<br />
The BBFILES variable is also of prime importance! It tells bitbake where to locate all available recipes for a build. The OpenEmbedded build environment is almost completely ready to go, with just one more minor step left.<br />
<br />
If you're not using a distro-provided makefile setup, and your site.conf (or local.conf) doesn't include the line<br />
<pre><br />
SRCPV = "${@bb.fetch.get_srcrev(d)}"<br />
</pre><br />
then you may find bitbake complaining along the lines of<br />
<pre><br />
ERROR: EOL while scanning string literal (<string>, line 1) while parsing .../openmoko/org.openembedded.dev/recipes/freesmartphone/frameworkd_git.bb<br />
</pre><br />
According to mwester on irc #openmoko-cdevel, referring to the use of the SRCPV line, "That's a temporary hack, we hope -- if all goes well that should end up 'upstream'."<br />
<br />
=== setup-env ===<br />
<br />
For quick and easy initialization of the OpenEmbedded build environment, it is often suggested that the developer create a 'setup-env' script to source from the command line. This script can be called to initialize the most important of environment variables. Below is a very basic example of a setup-env script. <br />
<br />
setup-env for Bash users:<br />
<pre><br />
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe<br />
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02<br />
export BBPATH=${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
setup-env for Tcsh users:<br />
<pre><br />
[[ -z ${OE_HOME} ]] && setenv OE_HOME ${HOME}/oe<br />
[[ -z ${MACHINE} ]] && setenv MACHINE om-gta02<br />
setenv BBPATH ${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
To invoke the setup-env script in bash, run 'source setup-env'. In tcsh, run '. setup-env'.<br />
<br />
See the section entitled [http://wiki.openmoko.org/wiki/OpenEmbedded#BitBake_Overlays BitBake Overlays] for an example of a more complicated setup-env script.<br />
<br />
=== Testing the OE Build Environment ===<br />
<br />
That's it! Now you should be prepared to bake your first BitBake recipe. <br />
<br />
bitbake helloworld<br />
<br />
=== Building an Image ===<br />
<br />
There are several full filesystem images which can be built directly with OpenEmbedded using a single command. These include openmoko-image, fso-image, and so on. The image definitions can be found under ${OE_HOME}/org.openembedded.dev/packages/images<br />
<br />
A good place to start is with <br />
<br />
bitbake fso-image<br />
<br />
That concludes this introduction to BitBake and OpenEmbedded. Good luck!<br />
<br />
=== Other References ===<br />
<br />
Please feel free to refer to other online sources of information for [http://bitbake.berlios.de BitBake], [http://www.openembedded.org OpenEmbedded], and the [http://www.angstrom-distribution.org Angstrom Distribution] to name a few.<br />
<br />
== Broken Builds and Bug Reporting ==<br />
<br />
Using the org.openembedded.dev branch can often result in broken builds. For that reason, it is usually a good idea to limit synchronizing with the repository only after successfully building an image. Some may even want to archive the tree and build directory after an image is built.<br />
<br />
Now in the case that an image does not successfully build, it is not always necessarily a bug or a new bug. The problem might have to do with some conflicting software on the workstation, and it could be a bug that is already know and being fixed.<br />
<br />
Below are a few useful steps to follow when a build does not successfully complete:<br />
<br />
* Identify the package that failed to build<br />
** Find a line near the bottom of your output that matches "ERROR: ... failed" or "NOTE: ... failed". The name of the package should be contained in the '...'<br />
* If there is a similar, more stable version in ${OE_HOME}/org.openembedded.dev/packages, then try to use that instead<br />
** bitbake -c clean somepackage && bitbake -b ${OE_HOME}/org.openembedded.dev/packages/somepackage/somepackage_0.1.bb<br />
** add PREFERRED_VERSION_somepackage = "0.1" to local.conf<br />
* Read the BitBake log, as well as config.log if it exists<br />
** Find the log file. There should be a line near the bottom of your output that matches "ERROR: see log in ...", where '...' contains the log file name. These are usually of the form log.do_compile.12345 or log.do_configure.12345, etc. <br />
* Try to identify the root cause of the error<br />
** In many cases, if one examines log.do_configure, only the error is reported, but not the cause of the error<br />
** Most packages that build with autotools will also have a config.log file that contains the exact cause of the error<br />
* If you can fix the error, and the error is local to your workstation, and not really a bug, then fix the error yourself.<br />
* Otherwise, check the [http://bugs.openembedded.net OpenEmbedded Bugzilla] to see if the error is known.<br />
* If a solution is already available, then try it out. If you can fix the error, then do so. If your solution is correct, please post all relevent patches to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]<br />
<br />
=== Where to Report Bugs ===<br />
<br />
Authentic bugs should be reported to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Setting the PREFERRED_VERSION for a package ===<br />
<br />
If a certain package is known to not build, and there is a less recent / more stable version of that package, then a good way to avoid repetitive encounters with known build failures is to use preferred versions of packages. <br />
<br />
For example, if building gcc-4.2.4 constantly failed, then it would be wise to edit local.conf and set PREFERRED_VERSION_gcc = "4.1.2".<br />
<br />
=== Screen is Your Friend ===<br />
<br />
If you happen to be building all of your packages remotely on a server, using an ssh session, the session might occasionally be interrupted and the connection could be terminated. A similar event could occur if your X server suddenly craches. If in the process of building an image with bitbake, this means that the build process will terminate as well. <br />
<br />
In order to ensure that a build continues in the presence of communication failures, it is advisable to use the [http://www.gnu.org/software/screen GNU Screen] utility. Screen is also very useful when performing several concurrent OpenEmbedded builds for different machine-distro combinations.<br />
<br />
Screen installation varies with your OS and distribution.<br />
<br />
=== BitBake Overlays ===<br />
<br />
Bitbake overlays are useful for OpenEmbedded developers to eliminate bugs or package software without disturbiing the OpenEmbedded tree itself. Overlays are very similar in structure to the OpenEmbedded tree, but are usually only sparsely populated. Non-sparsely poplulated overlays are actually more closely related to separate development branches. Good convention would suggest to always name the overlay appropriately. <br />
<br />
Below is an example of two overlays, three build directories, a setup-env script, and a local.conf where the developer has multiple build targets as well as multiple BitBake overlays.<br />
<pre><br />
oe<br />
|-- build-beagleboard<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- build-om-gta02<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- build-ts72xx<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- com.somecompany.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| |-- images<br />
| | `-- console-image.bb<br />
| `-- rxtx<br />
| |-- files<br />
| |-- rxtx-fixes-from-debian.patch<br />
| `-- rxtx_2.1-7r2.bb<br />
|-- org.openembedded.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| `-- images<br />
|-- org.openmoko.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| `-- tangogps<br />
| |-- tangogps.inc<br />
| `-- tangogps_0.9.3.bb<br />
`-- setup-env<br />
</pre><br />
<br />
An example of the setup-env script with multiple overlays and multiple build targets is below. <br />
<br />
<pre><br />
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe<br />
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02<br />
<br />
unset BBPATH<br />
<br />
case "${MACHINE}" in<br />
"beagleboard" | "ts72xx" ) <br />
BBPATH="${OE_HOME}/com.somecompany.dev"<br />
;;<br />
"om-gta02")<br />
BBPATH="${OE_HOME}/org.openmoko.dev"<br />
;;<br />
*)<br />
echo -e "error: unsupported machine"<br />
exit -1<br />
;;<br />
esac<br />
<br />
export BBPATH=${BBPATH}:${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
<br />
Note that the overlay-specific BBPATH entry ''precedes'' the default BBPATH entries.<br />
<br />
Next, observe the changes necessary for local.conf in order to use a specific overlay (in this case org.openmoko.dev).<br />
<br />
<pre><br />
...<br />
BBFILES := "${OE_HOME}/org.openembedded.dev/packages/*/*.bb"<br />
BBFILES += " ${OE_HOME}/org.openmoko.dev/packages/*/*.bb"<br />
<br />
BBFILE_COLLECTIONS = "upstream moko"<br />
BBFILE_PATTERN_upstream = "${OE_HOME}/org.openembedded.dev"<br />
BBFILE_PRIORITY_upstream = "0"<br />
BBFILE_PATTERN_moko = "${OE_HOME}/org.openmoko.dev"<br />
BBFILE_PRIORITY_moko = "1"<br />
...<br />
</pre><br />
<br />
In order for the overlay to be detected by BitBake, the above variables need to be defined in the local.conf file. It is possible to include more than one overlay. For each overlay, add a separate BBFILES += statement, an entry in BBFILE_COLLECTIONS, a BBFILE_PATTERN, and BBFILE_PRIORITY. Remember to include at least one space (' ') between each BBFILES entry.<br />
<br />
=== Useful BitBake Commands ===<br />
<br />
<pre><br />
# list all of the tasks defined for a given package_name<br />
bitbake -c listtasks <package_name><br />
<br />
# clean the work directory for a specific package<br />
bitbake -c clean <package_name><br />
<br />
# build a specific recipe<br />
bitbake -b <path/to/some/recipe.bb><br />
<br />
# if files or variables not found debug with<br />
bitbake -D -D -D<br />
</pre><br />
<br />
[[Category:Application Developer]]<br />
[[Category:System Developers]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/OpenEmbeddedOpenEmbedded2009-05-13T20:18:53Z<p>TonyGarnockJones: /* local.conf */ note on SRCPV in site.conf</p>
<hr />
<div>{{Languages|OpenEmbedded}}<br />
<br />
Openmoko, our distribution, is built using OpenEmbedded. OpenEmbedded will:<br />
<br />
* Generate (cross-compile) software packages for multiple embedded targets.<br />
* Handle different hardware architectures, and support multiple releases across those architectures. <br />
<br />
For more information please see the [http://www.openembedded.org/ Open Embedded] website.<br />
<br />
== Building the Openmoko Distribution with OpenEmbedded ==<br />
<br />
'''Note:''' If you are an application developer, you probably do not want to build OpenEmbedded from scratch. For compiling simple applications with few library dependencies (including boot-loader and kernel), consider using our prebuilt [[Toolchain]]. For more complex applications with many library dependencies, download a prebuilt [[OpenEmbedded Torrent]]. <br />
<br />
Building Openmoko from scratch is a time-, cpu- and diskspace-consuming process which should only be done if you are a system integrator and want to customize your Openmoko distribution.<br />
<br />
=== Simplified Instructions: MokoMakefile ===<br />
<br />
For beginners who wish to customize their Openmoko distribution, the facility called [[MokoMakefile]] simplifies building OpenEmbedded.<br />
<br />
=== Quick Start: OpenEmbedded Torrent ===<br />
<br />
If you are a system developer and would like to get up-to-speed as quickly as possible, then download an [[OpenEmbedded Torrent]].<br />
<br />
== From Scratch: OpenEmbedded ==<br />
<br />
Beginner Openmoko developers who would prefer to have full control over their OpenEmbedded build environment should follow the instructions below.<br />
<br />
=== Preparations ===<br />
<br />
Several prerequisite software components are necessary in order to have a fully functional OpenEmbedded build environment. However, setup and installation varies depending on the operating system installed on your workstation. The [http://wiki.openembedded.net/index.php OpenEmbedded Wiki] provides [http://wiki.openembedded.net/index.php/OEandYourDistro setup instructions] for FreeBSD, Mac OS X, and most major Linux distributions, of course.<br />
<br />
For OpenEmbedded installation instructions please refer to [http://wiki.openembedded.net/index.php/OEandYourDistro OEandYourDistro]. <br />
<br />
=== ${OE_HOME} ===<br />
<br />
Assuming that you have installed all prerequisite software, you are now ready to create a directory for all of your OpenEmbedded (OE) related work. We will refer to OE_HOME in a generic way, but for argument's sake, assume that it is equal to ${HOME}/oe. You should expect ${OE_HOME} to grow tremendously in size, up to approximately 8GB or larger in some cases. Also be aware, that a full OE build could require several hours of constant building, which may inhibit the performance of your computer while performing other tasks. Replace ${HOME}/oe with your preferred location.<br />
<br />
For Bash users:<br />
export OE_HOME=${HOME}/oe<br />
<br />
For Tcsh users:<br />
setenv OE_HOME ${HOME}/oe<br />
<br />
Next, run 'mkdir -p ${OE_HOME}' to create the directory. <br />
<br />
=== Synchronizing OpenEmbedded With Git ===<br />
<br />
Just like any tree, OpenEmbedded has several branches. In this case they are called 'development branches'. Some noteworthy ones include org.openembedded.dev (the default) and org.openembedded.stable . <br />
<br />
To syncronize the OpenEmbedded tree, run<br />
<pre><br />
git clone git://git.openembedded.net/openembedded ${OE_HOME}/org.openembedded.dev <br />
</pre><br />
<br />
Note that last argument could be any directory name (git will create the directory if it doesn't exist). Sticking to 'good convention', the directory name was chosen to reflect the default development branch, org.openembedded.dev . See the [http://wiki.openembedded.net/index.php/GitPhraseBook OE GitPhraseBook] for more info on checking out different branches. <br />
<br />
To update the tree, run<br />
<pre><br />
cd ${OE_HOME}/org.openembedded.dev<br />
git pull<br />
</pre><br />
<br />
You probably also want to use an fso branch<br />
<br />
<pre><br />
git checkout -b fso/milestone5.5 origin/fso/milestone5.5<br />
</pre><br />
<br />
For further information on Git, see [http://git-scm.com The Git Homepage].<br />
<br />
Also, please explore the directory structure of the OpenEmbedded build tree. Take a few moments to inspect the different types of BitBake files (.bbclass, .bb, .inc, etc). This helps one to become familiar with recipe syntax and the inheritance system. Of particular note, please read the file 'local.conf.sample'. <br />
<pre><br />
org.openembedded.dev<br />
|-- classes<br />
| |-- rootfs_ipk.bbclass<br />
| `-- xorg-module.bbclass<br />
|-- conf<br />
| `-- local.conf.sample<br />
| |-- distro<br />
| | `-- angstrom-2008.1.conf<br />
| |-- machine<br />
| | |-- om-gta01.conf<br />
| | `-- om-gta02.conf<br />
`-- packages<br />
|-- tangogps<br />
| |-- tangogps.inc<br />
| `-- tangogps_0.9.3.bb<br />
`-- images<br />
|-- console-image.bb<br />
|-- fso-console-image.bb<br />
|-- fso-image.bb<br />
|-- openmoko-image.bb<br />
|-- opie-image.bb<br />
`-- x11-image.bb<br />
</pre><br />
<br />
=== local.conf ===<br />
<br />
If you explored local.conf.example, then you would be aware that there are some very important variables to be set like MACHINE, DISTRO, and BBFILES, among many others. This is done in a configuration file (local.conf) inside the build directory. <br />
<br />
'''Note:''' Using BitBake and OE for cross-compilation require that each target-distro combination is built in a separate directory, so that no version collisions occur. Concurrent builds may safely share the same DL_DIR though. This would suggest that a safe name for build directories is of the form ${OE_HOME}/build-${MACHINE}-${DISTRO}. Of course, if you don't plan on building for more than one machine-distro combination, then the naming of this directory is arbitrary. For the purpose of this example, we will use the convention ${OE_HOME}/build-${MACHINE} . <br />
<br />
Now, create the 'local.conf' configuration file. Notice that the CACHE and TMPDIR variables are neatly kept within the build directory while the DL_DIR variable is outside of the build directory, so that concurrent builds may reuse the same source packages. <br />
<pre><br />
OE_HOME ?= "${HOME}/oe"<br />
<br />
MACHINE = "om-gta02"<br />
DISTRO = "openmoko"<br />
<br />
DL_DIR = "${OE_HOME}/downloads"<br />
<br />
BBFILES := "${OE_HOME}/org.openembedded.dev/recipes/*/*.bb"<br />
<br />
BBMASK = ""<br />
<br />
TMPDIR = "${OE_HOME}/build-${MACHINE}/tmp"<br />
CACHE = "${TMPDIR}/cache"<br />
<br />
IMAGE_FSTYPES = "jffs2 tar.gz"<br />
<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
</pre><br />
<br />
The BBFILES variable is also of prime importance! It tells bitbake where to locate all available recipes for a build. The OpenEmbedded build environment is almost completely ready to go, with just one more minor step left.<br />
<br />
If you're not using a distro-provided makefile setup, and your site.conf (or local.conf) doesn't include the line<br />
<pre><br />
SRCPV = "${@bb.fetch.get_srcrev(d)}"<br />
</pre><br />
then you may find bitbake complaining along the lines of<br />
<pre><br />
ERROR: EOL while scanning string literal (<string>, line 1) while parsing .../openmoko/org.openembedded.dev/recipes/freesmartphone/frameworkd_git.bb<br />
</pre><br />
<br />
=== setup-env ===<br />
<br />
For quick and easy initialization of the OpenEmbedded build environment, it is often suggested that the developer create a 'setup-env' script to source from the command line. This script can be called to initialize the most important of environment variables. Below is a very basic example of a setup-env script. <br />
<br />
setup-env for Bash users:<br />
<pre><br />
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe<br />
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02<br />
export BBPATH=${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
setup-env for Tcsh users:<br />
<pre><br />
[[ -z ${OE_HOME} ]] && setenv OE_HOME ${HOME}/oe<br />
[[ -z ${MACHINE} ]] && setenv MACHINE om-gta02<br />
setenv BBPATH ${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
To invoke the setup-env script in bash, run 'source setup-env'. In tcsh, run '. setup-env'.<br />
<br />
See the section entitled [http://wiki.openmoko.org/wiki/OpenEmbedded#BitBake_Overlays BitBake Overlays] for an example of a more complicated setup-env script.<br />
<br />
=== Testing the OE Build Environment ===<br />
<br />
That's it! Now you should be prepared to bake your first BitBake recipe. <br />
<br />
bitbake helloworld<br />
<br />
=== Building an Image ===<br />
<br />
There are several full filesystem images which can be built directly with OpenEmbedded using a single command. These include openmoko-image, fso-image, and so on. The image definitions can be found under ${OE_HOME}/org.openembedded.dev/packages/images<br />
<br />
A good place to start is with <br />
<br />
bitbake fso-image<br />
<br />
That concludes this introduction to BitBake and OpenEmbedded. Good luck!<br />
<br />
=== Other References ===<br />
<br />
Please feel free to refer to other online sources of information for [http://bitbake.berlios.de BitBake], [http://www.openembedded.org OpenEmbedded], and the [http://www.angstrom-distribution.org Angstrom Distribution] to name a few.<br />
<br />
== Broken Builds and Bug Reporting ==<br />
<br />
Using the org.openembedded.dev branch can often result in broken builds. For that reason, it is usually a good idea to limit synchronizing with the repository only after successfully building an image. Some may even want to archive the tree and build directory after an image is built.<br />
<br />
Now in the case that an image does not successfully build, it is not always necessarily a bug or a new bug. The problem might have to do with some conflicting software on the workstation, and it could be a bug that is already know and being fixed.<br />
<br />
Below are a few useful steps to follow when a build does not successfully complete:<br />
<br />
* Identify the package that failed to build<br />
** Find a line near the bottom of your output that matches "ERROR: ... failed" or "NOTE: ... failed". The name of the package should be contained in the '...'<br />
* If there is a similar, more stable version in ${OE_HOME}/org.openembedded.dev/packages, then try to use that instead<br />
** bitbake -c clean somepackage && bitbake -b ${OE_HOME}/org.openembedded.dev/packages/somepackage/somepackage_0.1.bb<br />
** add PREFERRED_VERSION_somepackage = "0.1" to local.conf<br />
* Read the BitBake log, as well as config.log if it exists<br />
** Find the log file. There should be a line near the bottom of your output that matches "ERROR: see log in ...", where '...' contains the log file name. These are usually of the form log.do_compile.12345 or log.do_configure.12345, etc. <br />
* Try to identify the root cause of the error<br />
** In many cases, if one examines log.do_configure, only the error is reported, but not the cause of the error<br />
** Most packages that build with autotools will also have a config.log file that contains the exact cause of the error<br />
* If you can fix the error, and the error is local to your workstation, and not really a bug, then fix the error yourself.<br />
* Otherwise, check the [http://bugs.openembedded.net OpenEmbedded Bugzilla] to see if the error is known.<br />
* If a solution is already available, then try it out. If you can fix the error, then do so. If your solution is correct, please post all relevent patches to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]<br />
<br />
=== Where to Report Bugs ===<br />
<br />
Authentic bugs should be reported to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Setting the PREFERRED_VERSION for a package ===<br />
<br />
If a certain package is known to not build, and there is a less recent / more stable version of that package, then a good way to avoid repetitive encounters with known build failures is to use preferred versions of packages. <br />
<br />
For example, if building gcc-4.2.4 constantly failed, then it would be wise to edit local.conf and set PREFERRED_VERSION_gcc = "4.1.2".<br />
<br />
=== Screen is Your Friend ===<br />
<br />
If you happen to be building all of your packages remotely on a server, using an ssh session, the session might occasionally be interrupted and the connection could be terminated. A similar event could occur if your X server suddenly craches. If in the process of building an image with bitbake, this means that the build process will terminate as well. <br />
<br />
In order to ensure that a build continues in the presence of communication failures, it is advisable to use the [http://www.gnu.org/software/screen GNU Screen] utility. Screen is also very useful when performing several concurrent OpenEmbedded builds for different machine-distro combinations.<br />
<br />
Screen installation varies with your OS and distribution.<br />
<br />
=== BitBake Overlays ===<br />
<br />
Bitbake overlays are useful for OpenEmbedded developers to eliminate bugs or package software without disturbiing the OpenEmbedded tree itself. Overlays are very similar in structure to the OpenEmbedded tree, but are usually only sparsely populated. Non-sparsely poplulated overlays are actually more closely related to separate development branches. Good convention would suggest to always name the overlay appropriately. <br />
<br />
Below is an example of two overlays, three build directories, a setup-env script, and a local.conf where the developer has multiple build targets as well as multiple BitBake overlays.<br />
<pre><br />
oe<br />
|-- build-beagleboard<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- build-om-gta02<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- build-ts72xx<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- com.somecompany.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| |-- images<br />
| | `-- console-image.bb<br />
| `-- rxtx<br />
| |-- files<br />
| |-- rxtx-fixes-from-debian.patch<br />
| `-- rxtx_2.1-7r2.bb<br />
|-- org.openembedded.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| `-- images<br />
|-- org.openmoko.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| `-- tangogps<br />
| |-- tangogps.inc<br />
| `-- tangogps_0.9.3.bb<br />
`-- setup-env<br />
</pre><br />
<br />
An example of the setup-env script with multiple overlays and multiple build targets is below. <br />
<br />
<pre><br />
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe<br />
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02<br />
<br />
unset BBPATH<br />
<br />
case "${MACHINE}" in<br />
"beagleboard" | "ts72xx" ) <br />
BBPATH="${OE_HOME}/com.somecompany.dev"<br />
;;<br />
"om-gta02")<br />
BBPATH="${OE_HOME}/org.openmoko.dev"<br />
;;<br />
*)<br />
echo -e "error: unsupported machine"<br />
exit -1<br />
;;<br />
esac<br />
<br />
export BBPATH=${BBPATH}:${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
<br />
Note that the overlay-specific BBPATH entry ''precedes'' the default BBPATH entries.<br />
<br />
Next, observe the changes necessary for local.conf in order to use a specific overlay (in this case org.openmoko.dev).<br />
<br />
<pre><br />
...<br />
BBFILES := "${OE_HOME}/org.openembedded.dev/packages/*/*.bb"<br />
BBFILES += " ${OE_HOME}/org.openmoko.dev/packages/*/*.bb"<br />
<br />
BBFILE_COLLECTIONS = "upstream moko"<br />
BBFILE_PATTERN_upstream = "${OE_HOME}/org.openembedded.dev"<br />
BBFILE_PRIORITY_upstream = "0"<br />
BBFILE_PATTERN_moko = "${OE_HOME}/org.openmoko.dev"<br />
BBFILE_PRIORITY_moko = "1"<br />
...<br />
</pre><br />
<br />
In order for the overlay to be detected by BitBake, the above variables need to be defined in the local.conf file. It is possible to include more than one overlay. For each overlay, add a separate BBFILES += statement, an entry in BBFILE_COLLECTIONS, a BBFILE_PATTERN, and BBFILE_PRIORITY. Remember to include at least one space (' ') between each BBFILES entry.<br />
<br />
=== Useful BitBake Commands ===<br />
<br />
<pre><br />
# list all of the tasks defined for a given package_name<br />
bitbake -c listtasks <package_name><br />
<br />
# clean the work directory for a specific package<br />
bitbake -c clean <package_name><br />
<br />
# build a specific recipe<br />
bitbake -b <path/to/some/recipe.bb><br />
<br />
# if files or variables not found debug with<br />
bitbake -D -D -D<br />
</pre><br />
<br />
[[Category:Application Developer]]<br />
[[Category:System Developers]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/OpenEmbeddedOpenEmbedded2009-05-13T20:06:23Z<p>TonyGarnockJones: /* local.conf */ It's recipes, these days, not packages</p>
<hr />
<div>{{Languages|OpenEmbedded}}<br />
<br />
Openmoko, our distribution, is built using OpenEmbedded. OpenEmbedded will:<br />
<br />
* Generate (cross-compile) software packages for multiple embedded targets.<br />
* Handle different hardware architectures, and support multiple releases across those architectures. <br />
<br />
For more information please see the [http://www.openembedded.org/ Open Embedded] website.<br />
<br />
== Building the Openmoko Distribution with OpenEmbedded ==<br />
<br />
'''Note:''' If you are an application developer, you probably do not want to build OpenEmbedded from scratch. For compiling simple applications with few library dependencies (including boot-loader and kernel), consider using our prebuilt [[Toolchain]]. For more complex applications with many library dependencies, download a prebuilt [[OpenEmbedded Torrent]]. <br />
<br />
Building Openmoko from scratch is a time-, cpu- and diskspace-consuming process which should only be done if you are a system integrator and want to customize your Openmoko distribution.<br />
<br />
=== Simplified Instructions: MokoMakefile ===<br />
<br />
For beginners who wish to customize their Openmoko distribution, the facility called [[MokoMakefile]] simplifies building OpenEmbedded.<br />
<br />
=== Quick Start: OpenEmbedded Torrent ===<br />
<br />
If you are a system developer and would like to get up-to-speed as quickly as possible, then download an [[OpenEmbedded Torrent]].<br />
<br />
== From Scratch: OpenEmbedded ==<br />
<br />
Beginner Openmoko developers who would prefer to have full control over their OpenEmbedded build environment should follow the instructions below.<br />
<br />
=== Preparations ===<br />
<br />
Several prerequisite software components are necessary in order to have a fully functional OpenEmbedded build environment. However, setup and installation varies depending on the operating system installed on your workstation. The [http://wiki.openembedded.net/index.php OpenEmbedded Wiki] provides [http://wiki.openembedded.net/index.php/OEandYourDistro setup instructions] for FreeBSD, Mac OS X, and most major Linux distributions, of course.<br />
<br />
For OpenEmbedded installation instructions please refer to [http://wiki.openembedded.net/index.php/OEandYourDistro OEandYourDistro]. <br />
<br />
=== ${OE_HOME} ===<br />
<br />
Assuming that you have installed all prerequisite software, you are now ready to create a directory for all of your OpenEmbedded (OE) related work. We will refer to OE_HOME in a generic way, but for argument's sake, assume that it is equal to ${HOME}/oe. You should expect ${OE_HOME} to grow tremendously in size, up to approximately 8GB or larger in some cases. Also be aware, that a full OE build could require several hours of constant building, which may inhibit the performance of your computer while performing other tasks. Replace ${HOME}/oe with your preferred location.<br />
<br />
For Bash users:<br />
export OE_HOME=${HOME}/oe<br />
<br />
For Tcsh users:<br />
setenv OE_HOME ${HOME}/oe<br />
<br />
Next, run 'mkdir -p ${OE_HOME}' to create the directory. <br />
<br />
=== Synchronizing OpenEmbedded With Git ===<br />
<br />
Just like any tree, OpenEmbedded has several branches. In this case they are called 'development branches'. Some noteworthy ones include org.openembedded.dev (the default) and org.openembedded.stable . <br />
<br />
To syncronize the OpenEmbedded tree, run<br />
<pre><br />
git clone git://git.openembedded.net/openembedded ${OE_HOME}/org.openembedded.dev <br />
</pre><br />
<br />
Note that last argument could be any directory name (git will create the directory if it doesn't exist). Sticking to 'good convention', the directory name was chosen to reflect the default development branch, org.openembedded.dev . See the [http://wiki.openembedded.net/index.php/GitPhraseBook OE GitPhraseBook] for more info on checking out different branches. <br />
<br />
To update the tree, run<br />
<pre><br />
cd ${OE_HOME}/org.openembedded.dev<br />
git pull<br />
</pre><br />
<br />
You probably also want to use an fso branch<br />
<br />
<pre><br />
git checkout -b fso/milestone5.5 origin/fso/milestone5.5<br />
</pre><br />
<br />
For further information on Git, see [http://git-scm.com The Git Homepage].<br />
<br />
Also, please explore the directory structure of the OpenEmbedded build tree. Take a few moments to inspect the different types of BitBake files (.bbclass, .bb, .inc, etc). This helps one to become familiar with recipe syntax and the inheritance system. Of particular note, please read the file 'local.conf.sample'. <br />
<pre><br />
org.openembedded.dev<br />
|-- classes<br />
| |-- rootfs_ipk.bbclass<br />
| `-- xorg-module.bbclass<br />
|-- conf<br />
| `-- local.conf.sample<br />
| |-- distro<br />
| | `-- angstrom-2008.1.conf<br />
| |-- machine<br />
| | |-- om-gta01.conf<br />
| | `-- om-gta02.conf<br />
`-- packages<br />
|-- tangogps<br />
| |-- tangogps.inc<br />
| `-- tangogps_0.9.3.bb<br />
`-- images<br />
|-- console-image.bb<br />
|-- fso-console-image.bb<br />
|-- fso-image.bb<br />
|-- openmoko-image.bb<br />
|-- opie-image.bb<br />
`-- x11-image.bb<br />
</pre><br />
<br />
=== local.conf ===<br />
<br />
If you explored local.conf.example, then you would be aware that there are some very important variables to be set like MACHINE, DISTRO, and BBFILES, among many others. This is done in a configuration file (local.conf) inside the build directory. <br />
<br />
'''Note:''' Using BitBake and OE for cross-compilation require that each target-distro combination is built in a separate directory, so that no version collisions occur. Concurrent builds may safely share the same DL_DIR though. This would suggest that a safe name for build directories is of the form ${OE_HOME}/build-${MACHINE}-${DISTRO}. Of course, if you don't plan on building for more than one machine-distro combination, then the naming of this directory is arbitrary. For the purpose of this example, we will use the convention ${OE_HOME}/build-${MACHINE} . <br />
<br />
Now, create the 'local.conf' configuration file. Notice that the CACHE and TMPDIR variables are neatly kept within the build directory while the DL_DIR variable is outside of the build directory, so that concurrent builds may reuse the same source packages. <br />
<pre><br />
OE_HOME ?= "${HOME}/oe"<br />
<br />
MACHINE = "om-gta02"<br />
DISTRO = "openmoko"<br />
<br />
DL_DIR = "${OE_HOME}/downloads"<br />
<br />
BBFILES := "${OE_HOME}/org.openembedded.dev/recipes/*/*.bb"<br />
<br />
BBMASK = ""<br />
<br />
TMPDIR = "${OE_HOME}/build-${MACHINE}/tmp"<br />
CACHE = "${TMPDIR}/cache"<br />
<br />
IMAGE_FSTYPES = "jffs2 tar.gz"<br />
<br />
ENABLE_BINARY_LOCALE_GENERATION = "0"<br />
</pre><br />
<br />
The BBFILES variable is also of prime importance! It tells bitbake where to locate all available recipes for a build. The OpenEmbedded build environment is almost completely ready to go, with just one more minor step left.<br />
<br />
=== setup-env ===<br />
<br />
For quick and easy initialization of the OpenEmbedded build environment, it is often suggested that the developer create a 'setup-env' script to source from the command line. This script can be called to initialize the most important of environment variables. Below is a very basic example of a setup-env script. <br />
<br />
setup-env for Bash users:<br />
<pre><br />
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe<br />
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02<br />
export BBPATH=${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
setup-env for Tcsh users:<br />
<pre><br />
[[ -z ${OE_HOME} ]] && setenv OE_HOME ${HOME}/oe<br />
[[ -z ${MACHINE} ]] && setenv MACHINE om-gta02<br />
setenv BBPATH ${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
To invoke the setup-env script in bash, run 'source setup-env'. In tcsh, run '. setup-env'.<br />
<br />
See the section entitled [http://wiki.openmoko.org/wiki/OpenEmbedded#BitBake_Overlays BitBake Overlays] for an example of a more complicated setup-env script.<br />
<br />
=== Testing the OE Build Environment ===<br />
<br />
That's it! Now you should be prepared to bake your first BitBake recipe. <br />
<br />
bitbake helloworld<br />
<br />
=== Building an Image ===<br />
<br />
There are several full filesystem images which can be built directly with OpenEmbedded using a single command. These include openmoko-image, fso-image, and so on. The image definitions can be found under ${OE_HOME}/org.openembedded.dev/packages/images<br />
<br />
A good place to start is with <br />
<br />
bitbake fso-image<br />
<br />
That concludes this introduction to BitBake and OpenEmbedded. Good luck!<br />
<br />
=== Other References ===<br />
<br />
Please feel free to refer to other online sources of information for [http://bitbake.berlios.de BitBake], [http://www.openembedded.org OpenEmbedded], and the [http://www.angstrom-distribution.org Angstrom Distribution] to name a few.<br />
<br />
== Broken Builds and Bug Reporting ==<br />
<br />
Using the org.openembedded.dev branch can often result in broken builds. For that reason, it is usually a good idea to limit synchronizing with the repository only after successfully building an image. Some may even want to archive the tree and build directory after an image is built.<br />
<br />
Now in the case that an image does not successfully build, it is not always necessarily a bug or a new bug. The problem might have to do with some conflicting software on the workstation, and it could be a bug that is already know and being fixed.<br />
<br />
Below are a few useful steps to follow when a build does not successfully complete:<br />
<br />
* Identify the package that failed to build<br />
** Find a line near the bottom of your output that matches "ERROR: ... failed" or "NOTE: ... failed". The name of the package should be contained in the '...'<br />
* If there is a similar, more stable version in ${OE_HOME}/org.openembedded.dev/packages, then try to use that instead<br />
** bitbake -c clean somepackage && bitbake -b ${OE_HOME}/org.openembedded.dev/packages/somepackage/somepackage_0.1.bb<br />
** add PREFERRED_VERSION_somepackage = "0.1" to local.conf<br />
* Read the BitBake log, as well as config.log if it exists<br />
** Find the log file. There should be a line near the bottom of your output that matches "ERROR: see log in ...", where '...' contains the log file name. These are usually of the form log.do_compile.12345 or log.do_configure.12345, etc. <br />
* Try to identify the root cause of the error<br />
** In many cases, if one examines log.do_configure, only the error is reported, but not the cause of the error<br />
** Most packages that build with autotools will also have a config.log file that contains the exact cause of the error<br />
* If you can fix the error, and the error is local to your workstation, and not really a bug, then fix the error yourself.<br />
* Otherwise, check the [http://bugs.openembedded.net OpenEmbedded Bugzilla] to see if the error is known.<br />
* If a solution is already available, then try it out. If you can fix the error, then do so. If your solution is correct, please post all relevent patches to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]<br />
<br />
=== Where to Report Bugs ===<br />
<br />
Authentic bugs should be reported to the [http://bugs.openembedded.net OpenEmbedded Bugzilla]<br />
<br />
== Tips & Tricks ==<br />
<br />
=== Setting the PREFERRED_VERSION for a package ===<br />
<br />
If a certain package is known to not build, and there is a less recent / more stable version of that package, then a good way to avoid repetitive encounters with known build failures is to use preferred versions of packages. <br />
<br />
For example, if building gcc-4.2.4 constantly failed, then it would be wise to edit local.conf and set PREFERRED_VERSION_gcc = "4.1.2".<br />
<br />
=== Screen is Your Friend ===<br />
<br />
If you happen to be building all of your packages remotely on a server, using an ssh session, the session might occasionally be interrupted and the connection could be terminated. A similar event could occur if your X server suddenly craches. If in the process of building an image with bitbake, this means that the build process will terminate as well. <br />
<br />
In order to ensure that a build continues in the presence of communication failures, it is advisable to use the [http://www.gnu.org/software/screen GNU Screen] utility. Screen is also very useful when performing several concurrent OpenEmbedded builds for different machine-distro combinations.<br />
<br />
Screen installation varies with your OS and distribution.<br />
<br />
=== BitBake Overlays ===<br />
<br />
Bitbake overlays are useful for OpenEmbedded developers to eliminate bugs or package software without disturbiing the OpenEmbedded tree itself. Overlays are very similar in structure to the OpenEmbedded tree, but are usually only sparsely populated. Non-sparsely poplulated overlays are actually more closely related to separate development branches. Good convention would suggest to always name the overlay appropriately. <br />
<br />
Below is an example of two overlays, three build directories, a setup-env script, and a local.conf where the developer has multiple build targets as well as multiple BitBake overlays.<br />
<pre><br />
oe<br />
|-- build-beagleboard<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- build-om-gta02<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- build-ts72xx<br />
| |-- conf<br />
| | `-- local.conf<br />
| `-- tmp<br />
|-- com.somecompany.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| |-- images<br />
| | `-- console-image.bb<br />
| `-- rxtx<br />
| |-- files<br />
| |-- rxtx-fixes-from-debian.patch<br />
| `-- rxtx_2.1-7r2.bb<br />
|-- org.openembedded.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| `-- images<br />
|-- org.openmoko.dev<br />
| |-- conf<br />
| | `-- machine<br />
| `-- packages<br />
| `-- tangogps<br />
| |-- tangogps.inc<br />
| `-- tangogps_0.9.3.bb<br />
`-- setup-env<br />
</pre><br />
<br />
An example of the setup-env script with multiple overlays and multiple build targets is below. <br />
<br />
<pre><br />
[[ -z ${OE_HOME} ]] && export OE_HOME=${HOME}/oe<br />
[[ -z ${MACHINE} ]] && export MACHINE=om-gta02<br />
<br />
unset BBPATH<br />
<br />
case "${MACHINE}" in<br />
"beagleboard" | "ts72xx" ) <br />
BBPATH="${OE_HOME}/com.somecompany.dev"<br />
;;<br />
"om-gta02")<br />
BBPATH="${OE_HOME}/org.openmoko.dev"<br />
;;<br />
*)<br />
echo -e "error: unsupported machine"<br />
exit -1<br />
;;<br />
esac<br />
<br />
export BBPATH=${BBPATH}:${OE_HOME}/build-${MACHINE}:${OE_HOME}/org.openembedded.dev<br />
</pre><br />
<br />
Note that the overlay-specific BBPATH entry ''precedes'' the default BBPATH entries.<br />
<br />
Next, observe the changes necessary for local.conf in order to use a specific overlay (in this case org.openmoko.dev).<br />
<br />
<pre><br />
...<br />
BBFILES := "${OE_HOME}/org.openembedded.dev/packages/*/*.bb"<br />
BBFILES += " ${OE_HOME}/org.openmoko.dev/packages/*/*.bb"<br />
<br />
BBFILE_COLLECTIONS = "upstream moko"<br />
BBFILE_PATTERN_upstream = "${OE_HOME}/org.openembedded.dev"<br />
BBFILE_PRIORITY_upstream = "0"<br />
BBFILE_PATTERN_moko = "${OE_HOME}/org.openmoko.dev"<br />
BBFILE_PRIORITY_moko = "1"<br />
...<br />
</pre><br />
<br />
In order for the overlay to be detected by BitBake, the above variables need to be defined in the local.conf file. It is possible to include more than one overlay. For each overlay, add a separate BBFILES += statement, an entry in BBFILE_COLLECTIONS, a BBFILE_PATTERN, and BBFILE_PRIORITY. Remember to include at least one space (' ') between each BBFILES entry.<br />
<br />
=== Useful BitBake Commands ===<br />
<br />
<pre><br />
# list all of the tasks defined for a given package_name<br />
bitbake -c listtasks <package_name><br />
<br />
# clean the work directory for a specific package<br />
bitbake -c clean <package_name><br />
<br />
# build a specific recipe<br />
bitbake -b <path/to/some/recipe.bb><br />
<br />
# if files or variables not found debug with<br />
bitbake -D -D -D<br />
</pre><br />
<br />
[[Category:Application Developer]]<br />
[[Category:System Developers]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2008-01-29T00:18:21Z<p>TonyGarnockJones: /* Status */</p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
== Erlang Userland ==<br />
<br />
I'm running Erlang with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-oe/" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-serial/" to track the serial-port erlang interface program<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-openmoko/" to track my userland (gsmd/dialer etc) code<br />
<br />
A few screenshots, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://eighty-twenty.org/~tonyg/erlang-openmoko-screenshots/<br />
<br />
=== Status ===<br />
<br />
See the [http://www.eighty-twenty.org/~tonyg/Darcs/erlang-openmoko/README README] for the current status, TODO and bugs. Currently 2090 non-blank, non-comment lines of code.<br />
<br />
Core (non-UI):<br />
<br />
* Clean(ish) API for scripting phone functionality (in Erlang)<br />
* Takes calls, makes calls, reliably enough for me to use as an everyday phone<br />
* Sends, receives, archives SMSes<br />
* DTMF send support during a call<br />
* Battery and charge-state monitoring<br />
* Detects when you might be connected to a dumb charger (no UI for forcing fast charge yet)<br />
* Powers GSM modem off when the phone is shut down<br />
* About 4-5 hours of battery life when idle - this will improve as general GTA01 power management improves<br />
<br />
Non-GUI user interface:<br />
<br />
* Plays an mp3/ogg file and vibrates when ringing<br />
* Vibrates on SMS receive<br />
* Switches ALSA profiles between in-call state (gsmhandset)/idle state (stereoout)<br />
* Press "power" to activate screen lock; press "aux" to release screen lock<br />
<br />
GUI user interface:<br />
<br />
* Really, really, really ugly.<br />
* Dims screen on user inactivity<br />
* Blanks screen and locks touchscreen on further inactivity<br />
* Very basic addressbook<br />
* Very basic SMS compose/display facility (no T9 yet)<br />
* Very basic dialer<br />
<br />
== gsmhandset.state echoes your own voice ==<br />
<br />
I've a tentative fix for this - here's the patch against gsmhandset.state. The alsamixer setting is labelled "Bypass" in the UI, and it's way over to the right, just after the "Amp ..." settings and just before "DAI Mode".<br />
<br />
<pre><br />
--- old/gsmhandset.state 2008-01-28 12:29:47.000000000 +0000<br />
+++ new/gsmhandset.state 2008-01-28 12:29:23.000000000 +0000<br />
@@ -55,8 +55,8 @@<br />
comment.range '0 - 7'<br />
iface MIXER<br />
name 'Bypass Playback Volume'<br />
- value.0 5<br />
- value.1 5<br />
+ value.0 0<br />
+ value.1 0<br />
}<br />
control.7 {<br />
comment.access 'read write'<br />
</pre></div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2008-01-29T00:13:26Z<p>TonyGarnockJones: </p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
== Erlang Userland ==<br />
<br />
I'm running Erlang with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-oe/" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-serial/" to track the serial-port erlang interface program<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-openmoko/" to track my userland (gsmd/dialer etc) code<br />
<br />
A few screenshots, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://eighty-twenty.org/~tonyg/erlang-openmoko-screenshots/<br />
<br />
=== Status ===<br />
<br />
See the [http://www.eighty-twenty.org/~tonyg/Darcs/erlang-openmoko/README README] for the current status, TODO and bugs. Currently 2090 non-blank, non-comment lines of code.<br />
<br />
Core (non-GUI):<br />
<br />
* Clean(ish) API for scripting phone functionality (in Erlang)<br />
* Takes calls, makes calls, reliably enough for me to use as an everyday phone<br />
* Sends, receives, archives SMSes<br />
* DTMF send support during a call<br />
* Battery and charge-state monitoring<br />
* Detects when you might be connected to a dumb charger (no UI for forcing fast charge yet)<br />
* Powers GSM modem off when the phone is shut down<br />
* About 4-5 hours of battery life when idle - this will improve as general GTA01 power management improves<br />
<br />
Non-GUI user interface:<br />
<br />
* Plays an mp3/ogg file and vibrates when ringing<br />
* Vibrates on SMS receive<br />
* Switches ALSA profiles between in-call state (gsmhandset)/idle state (stereoout)<br />
* Press "power" to activate screen lock; press "aux" to release screen lock<br />
<br />
GUI user interface:<br />
<br />
* Really, really, really ugly.<br />
* Dims screen on user inactivity<br />
* Blanks screen and locks touchscreen on further inactivity<br />
* Very basic addressbook<br />
* Very basic SMS compose/display facility (no T9 yet)<br />
* Very basic dialer<br />
<br />
== gsmhandset.state echoes your own voice ==<br />
<br />
I've a tentative fix for this - here's the patch against gsmhandset.state. The alsamixer setting is labelled "Bypass" in the UI, and it's way over to the right, just after the "Amp ..." settings and just before "DAI Mode".<br />
<br />
<pre><br />
--- old/gsmhandset.state 2008-01-28 12:29:47.000000000 +0000<br />
+++ new/gsmhandset.state 2008-01-28 12:29:23.000000000 +0000<br />
@@ -55,8 +55,8 @@<br />
comment.range '0 - 7'<br />
iface MIXER<br />
name 'Bypass Playback Volume'<br />
- value.0 5<br />
- value.1 5<br />
+ value.0 0<br />
+ value.1 0<br />
}<br />
control.7 {<br />
comment.access 'read write'<br />
</pre></div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/Openmoko_Local_Groups:_LondonOpenmoko Local Groups: London2008-01-28T16:04:27Z<p>TonyGarnockJones: </p>
<hr />
<div>Welcome to OpenMoko London!<br />
<br />
Beer and Neo anyone?<br />
<br />
{|border=1<br />
!Name (IRC nick)<br />
!Skills<br />
!Interest<br />
!Location<br />
!Device owned<br />
|-<br />
|[[User:jptmoore|John Moore]]<br />
|C/Scheme<br />
|Application development<br />
|Pinner<br />
|[[Image: Moko.jpg|center]]<br />
|-<br />
|Alex<br />
|Java,Perl,Python<br />
|User & developer<br />
|Hampshire<br />
|<br />
|-<br />
|[[User:Phlash|Phil Ashby]]<br />
|C/C++/Java /Embedded/Hardware<br />
|Kernel & Application development<br />
|Felixstowe<br />
|[[Image: Moko.jpg|center]]<br />
|-<br />
|John Cass<br />
|Java,C<br />
|User & developer<br />
|London<br />
|[[Image: Moko.jpg|center]]<br />
|-<br />
|[[User:TonyGarnockJones|Tony Garnock-Jones]] (tonyg)<br />
|C, assembly, Erlang, Scheme, ML, Haskell, Smalltalk, ...<br />
|User & developer<br />
|London<br />
|[[Image: Moko.jpg|center]]<br />
|-<br />
|[[User:ThomasWood|Thomas Wood/OpenedHand]]<br />
|C, GTK+ developer<br />
|User & developer<br />
|London<br />
|[[Image: Moko.jpg|center]] [[Image: MokoBox.jpg|center]] + GTA02<br />
|-<br />
|[[User:Stephmw|Steph Meslin-Weber]]<br />
|Java (J2ME), C, User Experience, Interface prototyping<br />
|User, developer and general busybody<br />
|London<br />
|}<br />
<br />
<br />
Key:<br />
[[Image: Moko.jpg]] = GTA01<br />
[[Image: MokoBox.jpg]] = Debug board<br />
<br />
See [[Talk:OpenMoko_Local_Groups:_London|discussion]]<br />
<br />
[[Category:Community]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2008-01-28T12:39:02Z<p>TonyGarnockJones: </p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
I'm running Erlang with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-oe/" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-serial/" to track the serial-port erlang interface program<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-openmoko/" to track my userland (gsmd/dialer etc) code<br />
<br />
A few screenshots, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://eighty-twenty.org/~tonyg/erlang-openmoko-screenshots/<br />
<br />
== gsmhandset.state echoes your own voice ==<br />
<br />
I've a tentative fix for this - here's the patch against gsmhandset.state. The alsamixer setting is labelled "Bypass" in the UI, and it's way over to the right, just after the "Amp ..." settings and just before "DAI Mode".<br />
<br />
<pre><br />
--- old/gsmhandset.state 2008-01-28 12:29:47.000000000 +0000<br />
+++ new/gsmhandset.state 2008-01-28 12:29:23.000000000 +0000<br />
@@ -55,8 +55,8 @@<br />
comment.range '0 - 7'<br />
iface MIXER<br />
name 'Bypass Playback Volume'<br />
- value.0 5<br />
- value.1 5<br />
+ value.0 0<br />
+ value.1 0<br />
}<br />
control.7 {<br />
comment.access 'read write'<br />
</pre></div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2007-12-07T15:22:00Z<p>TonyGarnockJones: </p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
I'm running Erlang with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-oe/" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-serial/" to track the serial-port erlang interface program<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-openmoko/" to track my userland (gsmd/dialer etc) code<br />
<br />
A few screenshots, not that the GUI is worth anything - the value of the approach is in the lower-level "model"/business-logic part (the gsmd/neod equivalent): http://eighty-twenty.org/~tonyg/erlang-openmoko-screenshots/</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/Hardware:AT_CommandsHardware:AT Commands2007-12-06T13:16:48Z<p>TonyGarnockJones: </p>
<hr />
<div>The protocol used to access the [[GSM]] chip is part of the GSM standard.<br />
<br />
Harald wrote on 2007-01-31 on the list http://lists.openmoko.org/pipermail/community/2007-January/002708.html<br />
"The chipset supports all of the mandatory [http://www.ctiforum.com/standard/standard/etsi/0707.pdf ETSI GSM TS 07.07] commands (use<br />
http://pda.etsi.org/pda/queryform.asp to get it), plus some of the<br />
optional ones. This GSM standard even has a command that lists the list of available<br />
commands (AT+CLAC)."<br />
<br />
On [[OpenMoko]], the commands should be used via [[gsmd]].<br />
<br />
See also:<br />
<br />
* http://wiki.openezx.org/AT_commands<br />
* http://www.3gpp.org/ftp/Specs/latest/Rel-7/27_series/27007-740.zip contains 27.007, "AT command set for User Equipment (UE)"<br />
* http://www.3gpp.org/ftp/Specs/latest/Rel-7/27_series/27005-700.zip contains 27.005, "Use of Data Terminal Equipment - Data Circuit terminating Equipment (DTE - DCE) interface for Short Message Service (SMS) and Cell Broadcast Service (CBS)"<br />
<br />
German Link for AT explainations: http://www.nobbi.com/atgsm.htm<br />
<br />
= On the Neo1973 =<br />
<br />
== Uncommented List of AT Commands ==<br />
(AT+CLAC) on the Neo1973 gives this list:<br />
<br />
<pre><br />
AT+CACM<br />
AT+CAMM<br />
AT+CAOC<br />
AT+CBC<br />
AT+CBST<br />
AT+CCFC<br />
AT+CCUG<br />
AT+CCWA<br />
AT+CCWE<br />
AT+CEER<br />
AT+CFUN<br />
AT+CGACT<br />
AT+CGANS<br />
AT+CGATT<br />
AT+CGAUTO<br />
AT+CGCLASS<br />
AT+CGDATA<br />
AT+CGDCONT<br />
AT+CGEREP<br />
AT+CGMI<br />
AT+CGMM<br />
AT+CGMR<br />
AT+CGPADDR<br />
AT+CGQMIN<br />
AT+CGQREQ<br />
AT+CGREG<br />
AT+CGSMS<br />
AT+CGSN<br />
AT+CHLD<br />
AT+CHUP<br />
AT+CIMI<br />
AT+CLAC<br />
AT+CLAE<br />
AT+CLAN<br />
AT+CLCC<br />
AT+CLCK<br />
AT+CLIP<br />
AT+CDIP<br />
AT+CLIR<br />
AT+CLVL<br />
AT+CMEE<br />
AT+CMGC<br />
AT+CMGD<br />
AT+CMGF<br />
AT+CMGL<br />
AT+CMGR<br />
AT+CMGS<br />
AT+CMGW<br />
AT+CMOD<br />
AT+CMSS<br />
AT+CMMS<br />
AT+CMUT<br />
AT+CMUX<br />
AT+CNMA<br />
AT+CNMI<br />
AT+CNUM<br />
AT+COLP<br />
AT+COPN<br />
AT+COPS<br />
AT+CPAS<br />
AT+CPBF<br />
AT+CPBR<br />
AT+CPBS<br />
AT+CPBW<br />
AT+CPIN<br />
AT+CPMS<br />
AT+CPOL<br />
AT+CPUC<br />
AT+CPWD<br />
AT+CR<br />
AT+CRC<br />
AT+CREG<br />
AT+CRES<br />
AT+CRLP<br />
AT+CRSL<br />
AT+CRSM<br />
AT+CSAS<br />
AT+CSCA<br />
AT+CSCB<br />
AT+CSCS<br />
AT+CSDH<br />
AT+CSIM<br />
AT+CSMP<br />
AT+CSMS<br />
AT+CSNS<br />
AT+CSQ<br />
AT%CSQ<br />
AT+CSSN<br />
AT+CSTA<br />
AT+CSVM<br />
AT+CTFR<br />
AT+CUSD<br />
AT+DR<br />
AT+FAP<br />
AT+FBO<br />
AT+FBS<br />
AT+FBU<br />
AT+FCC<br />
AT+FCLASS<br />
AT+FCQ<br />
AT+FCR<br />
AT+FCS<br />
AT+FCT<br />
AT+FDR<br />
AT+FDT<br />
AT+FEA<br />
AT+FFC<br />
AT+FHS<br />
AT+FIE<br />
AT+FIP<br />
AT+FIS<br />
AT+FIT<br />
AT+FKS<br />
AT+FLI<br />
AT+FLO<br />
AT+FLP<br />
AT+FMI<br />
AT+FMM<br />
AT+FMR<br />
AT+FMS<br />
AT+FND<br />
AT+FNR<br />
AT+FNS<br />
AT+FPA<br />
AT+FPI<br />
AT+FPS<br />
AT+FPW<br />
AT+FRQ<br />
AT+FSA<br />
AT+FSP<br />
AT+GCAP<br />
AT+GCI<br />
AT+GMI<br />
AT+GMM<br />
AT+GMR<br />
AT+GSN<br />
AT+ICF<br />
AT+IFC<br />
AT+ILRR<br />
AT+IPR<br />
AT+VTS<br />
AT+WS46<br />
AT%ALS<br />
AT%ATR<br />
AT%BAND<br />
AT%CACM<br />
AT%CAOC<br />
AT%CCBS<br />
AT%STDR<br />
AT%CGAATT<br />
AT%CGMM<br />
AT%CGREG<br />
AT%CNAP<br />
AT%CPI<br />
AT%COLR<br />
AT%CPRIM<br />
AT%CTV<br />
AT%CUNS<br />
AT%NRG<br />
AT%SATC<br />
AT%SATE<br />
AT%SATR<br />
AT%SATT<br />
AT%SNCNT<br />
AT%VER<br />
AT%CGCLASS<br />
AT%CGPCO<br />
AT%CGPPP<br />
AT%EM<br />
AT%EMET<br />
AT%EMETS<br />
AT%CBHZ<br />
AT%CPHS<br />
AT%CPNUMS<br />
AT%CPALS<br />
AT%CPVWI<br />
AT%CPOPN<br />
AT%CPCFU<br />
AT%CPINF<br />
AT%CPMB<br />
AT%CPRI<br />
AT%DATA<br />
AT%DINF<br />
AT%CLCC<br />
AT%DBGINFO<br />
AT%VTS<br />
AT%CHPL<br />
AT%CREG<br />
AT+CTZR<br />
AT+CTZU<br />
AT%CTZV<br />
AT%CNIV<br />
AT%PVRF<br />
AT%CWUP<br />
AT%DAR<br />
AT+CIND<br />
AT+CMER<br />
AT%CSCN<br />
AT%RDL<br />
AT%RDLB<br />
AT%CSTAT<br />
AT%CPRSM<br />
AT%CHLD<br />
AT%SIMIND<br />
AT%SECP<br />
AT%SECS<br />
AT%CSSN<br />
AT+CCLK<br />
AT%CSSD<br />
AT%COPS<br />
AT%CPMBW<br />
AT%CUST<br />
AT%SATCC<br />
AT%COPN<br />
AT%CGEREP<br />
AT%CUSCFG<br />
AT%CUSDR<br />
AT%CPBS<br />
AT%PBCF<br />
AT%SIMEF<br />
AT%EFRSLT<br />
AT%CMGMDU<br />
AT%CMGL<br />
AT%CMGR<br />
ATA<br />
ATB<br />
AT&C<br />
ATD<br />
AT&D<br />
ATE<br />
ATF<br />
AT&F<br />
ATH<br />
ATI<br />
AT&K<br />
ATL<br />
ATM<br />
ATO<br />
ATP<br />
ATQ<br />
ATS<br />
ATT<br />
ATV<br />
ATW<br />
AT&W<br />
ATX<br />
ATZ<br />
</pre><br />
<br />
== Results of AT Commands ==<br />
<br />
Taken from "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; AT command set for User Equipment (UE) (Release 7)" - 3GPP TS 27.007 V7.2.0 (2006-09)<br />
<br />
== Section 5, General Commands ==<br />
<br />
Request manufacturer identification +CGMI<br />
<br />
AT+CGMI<br />
<manufacturer><br />
<br />
OK<br />
<br />
Request model identification +CGMM<br />
<br />
AT+CGMM<br />
<model><br />
<br />
OK<br />
<br />
Request revision identification +CGMR<br />
<br />
AT+CGMR<br />
<revision><br />
<br />
OK<br />
<br />
Request product serial number identification +CGSN<br />
<br />
AT+CGSN<br />
<serial number><br />
<br />
OK<br />
<br />
Select TE character set +CSCS<br />
<br />
AT+CSCS?<br />
+CSCS: "IRA"<br />
<br />
OK<br />
<br />
AT+CSCS=?<br />
+CSCS: "GSM","IRA","PCCP437","PCDN","8859-1","HEX","UCS2"<br />
<br />
OK<br />
<br />
Request international mobile subscriber identity +CIMI<br />
<br />
AT+CIMI<br />
*************** (I'm not giving you my IMSI!)<br />
<br />
OK<br />
<br />
Request subscriber number +CNUM<br />
<br />
AT+CNUM<br />
+CNUM: ,"0123456789",122<br />
<br />
OK<br />
<br />
Multiplexing mode +CMUX <br />
<br />
AT+CMUX?<br />
ERROR<br />
AT+CMUX=?<br />
+CMUX: (1),(0),(1-5),(10-100),(1-255),(0-100),(2-255),(1-255),(1-7)<br />
<br />
OK<br />
<br />
PCCA STD 101 [17] select wireless network +WS46<br />
<br />
AT+WS46=?<br />
+WS46: (12)<br />
<br />
OK<br />
<br />
== Section 6, Call control commands and methods ==<br />
<br />
Select type of address +CSTA<br />
<br />
AT+CSTA?<br />
+CSTA: 129<br />
<br />
OK<br />
AT+CSTA=?<br />
+CSTA: (129,145)<br />
<br />
OK<br />
<br />
Call mode +CMOD<br />
<br />
AT+CMOD=?<br />
+CMOD: (0-3)<br />
<br />
OK<br />
<br />
Select bearer service type +CBST<br />
<br />
AT+CBST?<br />
+CBST: 7,0,1<br />
<br />
OK<br />
AT+CBST=?<br />
+CBST: (0-7,12,14,65,66,68,70,71,75),(0),(0-3)<br />
<br />
OK<br />
<br />
Radio link protocol +CRLP<br />
<br />
AT+CRLP?<br />
+CRLP: 61,61,48,6<br />
<br />
OK<br />
AT+CRLP=?<br />
+CRLP: (0-61),(0-61),(39-255),(1-255)<br />
<br />
OK<br />
<br />
Service reporting control +CR<br />
<br />
AT+CR?<br />
+CR: 0<br />
<br />
OK<br />
AT+CR=?<br />
+CR: (0,1)<br />
<br />
OK<br />
<br />
Extended error report +CEER<br />
<br />
AT+CEER<br />
+CEER: 0,0,5,16,normal call clearing<br />
<br />
OK<br />
<br />
Cellular result codes +CRC<br />
<br />
AT+CRC=1<br />
OK<br />
<br />
+CRING: VOICE<br />
<br />
Single numbering scheme +CSNS<br />
<br />
AT+CSNS=?<br />
+CSNS: (0-7)<br />
<br />
OK<br />
<br />
== Section 7, Network service related commands ==<br />
<br />
7.2 Network registration +CREG<br />
<br />
AT+CREG?<br />
+CREG: 0,0<br />
<br />
OK<br />
AT+CREG=?<br />
+CREG: (0-2)<br />
<br />
OK<br />
<br />
7.3 PLMN selection +COPS<br />
<br />
AT+CREG=1<br />
OK<br />
<br />
AT+COPS=0<br />
OK<br />
<br />
+CREG: 2<br />
<br />
+CREG: 1<br />
<br />
== Section 8, Mobile Termination control and status commands ==<br />
<br />
8.1 Phone activity status +CPAS<br />
<br />
AT+CPAS<br />
+CPAS: 0<br />
<br />
OK<br />
AT+CPAS=?<br />
+CPAS: (0-5)<br />
<br />
OK<br />
<br />
8.2 Set phone functionality +CFUN<br />
<br />
AT+CFUN?<br />
+CFUN: 1<br />
<br />
OK<br />
AT+CFUN=?<br />
+CFUN: (0,1,4),(0)<br />
<br />
OK<br />
<br />
8.4 Battery charge +CBC<br />
<br />
AT+CBC<br />
+CBC: 0,0<br />
<br />
OK<br />
AT+CBC=?<br />
+CBC: (0-3),(0-100)<br />
<br />
OK<br />
<br />
== Miscellaneous ==<br />
<br />
AT+CPAS<br />
+CPAS: 5<br />
<br />
OK<br />
<br />
AT+CPAS?<br />
ERROR<br />
AT+CPAS=?<br />
+CPAS: (0-5)<br />
<br />
OK<br />
<br />
AT%BAND?<br />
%BAND: 0<br />
<br />
OK<br />
AT%BAND=?<br />
%BAND: (0-1),(1-31)<br />
<br />
OK<br />
<br />
AT+CSSN?<br />
+CSSN: 0,0<br />
<br />
OK<br />
AT+CSSN=?<br />
+CSSN: (0,1),(0,1)<br />
<br />
OK<br />
<br />
<br />
[[Category:Neo1973 Hardware]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/Openmoko_Local_Groups:_LondonOpenmoko Local Groups: London2007-12-05T16:43:13Z<p>TonyGarnockJones: </p>
<hr />
<div>Welcome to OpenMoko London!<br />
<br />
Beer and Neo anyone?<br />
<br />
{|border=1<br />
!Name<br />
!Skills<br />
!Interest<br />
!Location<br />
!Device owned<br />
|-<br />
|[[User:jptmoore|John Moore]]<br />
|C/Scheme<br />
|Application development<br />
|Pinner<br />
|[[Image: Moko.jpg|center]]<br />
|-<br />
|Alex<br />
|Java,Perl,Python<br />
|User & developer<br />
|Hampshire<br />
|<br />
|-<br />
|[[User:Phlash|Phil Ashby]]<br />
|C/C++/Java /Embedded/Hardware<br />
|Kernel & Application development<br />
|Felixstowe<br />
|[[Image: Moko.jpg|center]]<br />
|-<br />
|John Cass<br />
|Java,C<br />
|User & developer<br />
|London<br />
|[[Image: Moko.jpg|center]]<br />
|-<br />
|[[User:TonyGarnockJones|Tony Garnock-Jones]]<br />
|C, assembly, Erlang, Scheme, ML, Haskell, Smalltalk, ...<br />
|User & developer<br />
|London<br />
|[[Image: Moko.jpg|center]]<br />
|}<br />
<br />
<br />
See [[Talk:OpenMoko_Local_Groups:_London|discussion]]<br />
<br />
[[Category:Community]]</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2007-12-05T16:41:26Z<p>TonyGarnockJones: </p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
I'm running Erlang with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).<br />
<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-oe/" for bitbake scripts for building erlang, erlang-gtknode and erlang-serial ipkg packages<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-serial/" to track the serial-port erlang interface program<br />
* "darcs get http://www.eighty-twenty.org/~tonyg/Darcs/erlang-openmoko/" to track my userland (gsmd/dialer etc) code</div>TonyGarnockJoneshttp://wiki.openmoko.org/wiki/User:TonyGarnockJonesUser:TonyGarnockJones2007-12-05T16:37:53Z<p>TonyGarnockJones: </p>
<hr />
<div>Tony Garnock-Jones, tonyg@lshift.net.<br />
<br />
I own a phase-1 Neo1973.<br />
<br />
I'm running Erlang with GTK and serial-port extensions on my phone, using it as an openmoko userland replacement (for gsmd/dialer/addressbook etc.).</div>TonyGarnockJones