|
|
| (12 intermediate revisions by the same user not shown) |
| Line 5: |
Line 5: |
| | I'll use this page to share my experiencs on successes and obstacles I find. Feedback always appreciated. | | I'll use this page to share my experiencs on successes and obstacles I find. Feedback always appreciated. |
| | | | |
| − | ==My Build system==
| + | Building the image and kernel is not yet successful!! |
| − | I am running a VM-ware player image with Gentoo Linux placed on a USB hostpowered disc. This does not give highest possible performance, but it allows for a lot of mobility and portability. Peripherals like a (micro)SD-card reader adapter for USB works fine, but the built-in one in my laptop is not available within the VM-ware player.
| + | [[buildingImage|Building the Image]] |
| | | | |
| − | On my Gentoo linux I set-up the build environment according to the instructions for the [http://www.gumstix.net/Software/view/Software-Overo/Setting-up-a-build-environment/111.html overo build system].
| + | [[booting|Booting from the SD card]] |
| | | | |
| − | The reason for choosing the open-embedded as for Overo is that the Verdex buildsystem has not been updated for approx. a year now and I wanted the latest recipes to get e.g. Open JDK.
| + | [[javaAwt|Getting Java and AWT to work]] |
| − | | + | |
| − | == Building an Rootfs image and a kernel==
| + | |
| − | | + | |
| − | First I checked out a copy of ([http://www.gumstix.net/Software/view/Getting-started/Setting-up-a-build-environment/111.html instructions]) the Verdex build system. So the home directory now has:
| + | |
| − | ~/gumstix/gusmtix-oe/
| + | |
| − | ~/overo-oe/
| + | |
| − | | + | |
| − | Then, I copied the Verdex image recipes to the user.collection.
| + | |
| − | mkdir -p ~/overo-oe/user.collection/images/
| + | |
| − | cp ~/gumstix/gumstix-oe/com.gumstix.collection/packages/images/* ~/overo-oe/user.collection/images/
| + | |
| − | | + | |
| − | Once copied, I ran:
| + | |
| − | bitbake gumstix-basic-image
| + | |
| − | | + | |
| − | Resulting in a failure and Bitbake reporting that nothing provides some package and exited without building anything. I then copied the recipes for those packages and ran bitbake again. At the end I had copied:
| + | |
| − | task-base-gumstix
| + | |
| − | motd
| + | |
| − | uisp
| + | |
| − | version
| + | |
| − | www-content
| + | |
| − | | + | |
| − | ==Problems with No GNU_HASH fount in elf ==
| + | |
| − | | + | |
| − | Baking the gumstix-basic-image the process stopped with the I2C package and the log information boiled down to the error message: No GNU_HASH fount in elf for the i2c.
| + | |
| − | | + | |
| − | Asking for hints in the gumstix.users mailing list helped alot. Thanks Koen and Philip (archive [http://www.nabble.com/No-GNU_HASH-found-in-elf-binary-td23072960.html here]) and I could find the problem in the i2c.bb file:
| + | |
| − | The task do_compile ignored the LDFLAGS set by the oe/autoconf tools.
| + | |
| − | do_compile () {
| + | |
| − | ${CC} -o i2c *.c
| + | |
| − | }
| + | |
| − | | + | |
| − | Adding ${LDFLAGS} to the line for compiling solved this problem:
| + | |
| − | do_compile () {
| + | |
| − | ${CC} -o i2c *.c ${LDFLAGS}
| + | |
| − | }
| + | |
| − | | + | |
| − | Then the same problem emerged in the pxaregs recipes and the same solution applied. This resulted in a completed bake.
| + | |
| − | | + | |
| − | ==Booting the gumstix from a micro SD card==
| + | |
| − | | + | |
| − | Currently, I boot the gumstix from a 2GB micro SD card. NOTE that 4GB SDHC does work to boot from. If booting from flash, the card is found and read/write works fine even with 4GB. Probably the U-boot version does not support SDHC cards.
| + | |
| − | These [http://www.gumstix.net/User/view/User-how-to-s/Booting-from-microSD/SD/MMC/110.html instructions] for setting up the MicroSD card works fine for me. Don't forget to enable the MMC_ROOT by uncommenting the line in the ~/gumstix/gumstix-oe/com.gumstix.collection/conf/machine/gumstix-custom-verdex.conf
| + | |
| − | | + | |
| − | MACHINE_FEATURES += "mmcroot"
| + | |
| − | | + | |
| − | | + | |
| − | ===If boot hangs at ??===
| + | |
| − | The first boot from the SD starts fine, but hangs after a while at
| + | |
| − | This seems to be a problem with ... and can be worked around by interrupting the boot by pressing 'Ctrl-c' on the serial console, which lets the boot continue. Then you can log in. At this point removing two files like so, should make the boot process complete at the next boot:
| + | |
| − | | + | |
| − | rm
| + | |
| − | | + | |
| − | ==Errors encountered when building==
| + | |
| − | | + | |
| − | ===Gumstix-kernel and sumversion.h ===
| + | |
| − | The Gumstix-kernel recipe fails with the error message
| + | |
| − | warning: unused variable 'filelist'
| + | |
| − | The problem is solved by adding '#include <limits.h>' after strings.h in scripts/mod/sumversion.c fixes the issue. The file is found at:
| + | |
| − | ~/overo-oe/tmp/work/gumstix-verdex-angstrom-linux-gnueabi/gumstix-kernel-2.6.21-r0/linux-2.6.21/scripts/mod/sumversion.c
| + | |
| − | | + | |
| − | #include <netinet/in.h>
| + | |
| − | #ifdef __sun__
| + | |
| − | #include <inttypes.h>
| + | |
| − | #else
| + | |
| − | #include <stdint.h>
| + | |
| − | #endif
| + | |
| − | #include <ctype.h>
| + | |
| − | #include <errno.h>
| + | |
| − | #include <string.h>
| + | |
| − | #include <limits.h> <--- add this line
| + | |
| − | #include "modpost.h"
| + | |
| − |
| + | |
| − | /*
| + | |
| − | * Stolen form Cryptographic API.
| + | |
| − | *
| + | |
| − | * MD4 Message Digest Algorithm (RFC1320).
| + | |
| − | | + | |
| − | | + | |
| − | ===I2C package No GNU_HASH found in elf binary===
| + | |
| − | The I2C package fails in the QA phase with the error message:
| + | |
| − | ERROR: QA Issue: No GNU_HASH in the elf binary: '/home/<user>/overo-oe/tmp/work/armv5te-angstrom-linux-gnueabi/i2c-1.0-r2/install/i2c/usr/bin/i2c'
| + | |
| − | The problem is because the recipe ignores the linker flags set in the oe environment and therefore builds the wrong type of binary ([http://www.nabble.com/No-GNU_HASH-found-in-elf-binary-td23072960.html see posts on gumstix-users]). The problem is easily fixed by editing the I2C recipe like this:
| + | |
| − | # nano ~/overo-oe/org.openembedded.dev/recipes/i2c/i2c.bb
| + | |
| − | | + | |
| − | do_compile () {
| + | |
| − | ${CC} -o i2c *.c ${LDFLAGS}
| + | |
| − | }
| + | |
| | | | |
| | ==Coming challenges== | | ==Coming challenges== |
| | Setting up a bluetooth PAN from verdex to my gentoo to easily deploy new builds of my java application | | Setting up a bluetooth PAN from verdex to my gentoo to easily deploy new builds of my java application |
| | | | |
| − | setting up working java that have GUI and uses the touch screen. | + | setting up a continuous integration environment |
| | | | |
| − | finding and building a lib for java serial
| + | ==Bugs that I have encountered == |
| | | | |
| − | setting up a continuous integration environment
| + | Bitbake failed due to DBus problem. [http://www.nabble.com/Re%3A-Build-error-dbus-native-1.0.1-p23905434.html| This solution might do the trick.] |
I am working on settin up my Verdex Pro 400-Bt with LCD to run java with the touch screen and a simple graphical gui.
I'll use this page to share my experiencs on successes and obstacles I find. Feedback always appreciated.
Setting up a bluetooth PAN from verdex to my gentoo to easily deploy new builds of my java application
