Tux the penguin with the iRex logo.

I recently got the new iRex DR1000S ebook reader. One nice thing about the device is that iRex has graciously provided the source code for the device so you can play around making software of your own design for the DR1000. In this tutorial I'll show you how to setup a development environment for the DR1000 so you can start developing software for this device as quickly as possible. This tutorial is by no means complete, but it lays a groundwork for you by getting you from a fresh Linux install to a working "hello world" program that you can load into the DR1000 emulator on your computer. The next step is uploading it to the DR1000 to test it. If you want to skip all my talking and go straight to the downloads or the other useful websites you can go to the Links section at the end of this tutorial and just start downloading some software or looking at forums...etc.

Use the lastest Ubuntu distribution for development.  Hardy Heron was used for this document.

The first step in getting the development setup running in Ubuntu is specifying the apt source for the Opened Hand file source. In Ubuntu you need to have APT sources set up in order to get your application files from the correct resources. I am referring to the "apt-get" command that allows you to install and remove software on your Ubuntu machine. By supplying the location of the source files we can ensure that we are getting the proper files for our Ubuntu installation. In order to get some more information about apt-get you can go here: http://www.linux.com/feature/40745

Opened Hand is the company that is responsible for supplying the poky plugin that allows us to use the poky toolchain from within the Anjuta IDE. From the OpenedHand website:

http://labs.o-hand.com/anjuta-poky-sdk-plugin/

In order for us to get the proper files for our desired platform we need to add http://debian.o-hand.com to our APT sources:
To do this, add the relevent line for your distribution to the file /etc/apt/sources.list

deb http://debian.o-hand.com etch/
deb http://debian.o-hand.com unstable/

deb http://debian.o-hand.com edgy/
deb http://debian.o-hand.com feisty/
deb http://debian.o-hand.com gutsy/
deb http://debian.o-hand.com hardy/

The file is read-only so modify as superuser:

vim sources.list

The distribution of Ubuntu that I am using for this example is “Hardy Heron” so I chose the line ending in “hardy”. Add this line to the bottom of your sources.list file.

Once this line is integrated into the sources.list file you can try running an update on the system. This will look at this new sources.list entry and try to start retreiving the files related to it. Run the following command which gets all the updates to the lines added to the sources.list file:

Apt-get update

This resulted in a couple errors, but I moved on. See Troubleshooting section for more info on that.

aptitude install update

Next I ran the poky install to get the correct dependencies for the Poky environment.

apt-get install qemu poky-depends poky-scripts

If you run into errors here, you can use the following line to install the dependencies manually. Go to the Troubleshooting section for more info.

apt-get install build-essential python diffstat texinfo texi2html cvs subversion wget gawk help2man bochsbios gettext

Next get the poky snapshot downloaded from here:

http://developer.irexnet.com/pub/iOn/SDK

Move the poky snapshot into the ROOT directory. It will probably have a .tar.bz2 extension so unzip and untar it with the following commands:

mv poky-eabi-glibc-i686-arm-toolchain-sdk-3.2+snapshot-20081017.tar.bz2 /

cd /

bzip2 -d poky-eabi-glibc-i686-arm-toolchain-sdk-3.2+snapshot-20081017.tar.bz2

tar -xvf poky-eabi-glibc-i686-arm-toolchain-sdk-3.2+snapshot-20081017.tar

(note: your file names may be different depending on if you have a more recent version) Since the tar file is in your root directory untarring the snapshot file creates a “poky” directory in the “/usr/local” directory.
Next I copied the anjuta-plugin, zImage, and iRex poky files into the /usr/local directory and extracted the tarballs

cp poky-image-ion-devel-qemuarm-20081016230544.rootfs.ext2.bz2 /usr/local

cp zImage-2.6.23-qemuarm-20081016230544.bin /usr/local

cp anjuta-plugin-sdk-0.5.tar.tar /urs/local

cd /usr/local

tar -xvf anjuta-plugin-sdk-0.5.tar

bzip2 -d poky-image-ion-devel-qemuarm-20081016230544.rootfs.ext2.bz2

Note: for some reason it came up with an error when I tried to run this bzip2 command. I thought that the file was corrupt, but when I tried in windows I was able to unzip the file with WinRAR just fine. I then copied the resulting file over to my Ubuntu machine. Maybe someone can enlighten me on the reason for the problem.

At this point you have all the necessary files to make the Anjuta system work with all the iRex supplied images and files.

Source the environment setup script from within the new poky directory:

source environment-setup

For now I will move on to the Anjuta installation. This creates a development environment with poky using Anjuta so we don't have to worry about the command line approach to use poky.

On to Anjuta. 

Just to be clear, it's important to understand the following two key facts:

1. Poky is a plug-in for Anjuta
2. Anjuta needs the anjuta-plugin-sdk in order to allow poky to work with it.

Use Synaptic package manager to install Anjuta which has a bunch of dependencies. The dependencies will install automatically. Then move on to the anjuta-plugin-sdk again. From the install file for the anjuta-plugin:

The simplest way to compile this package is:

  1. `cd' to the directory containing the package's source code and type ./configure' to configure the package for your system.   Running `configure' might take a while.  While running, it prints some messages telling which features it is checking for.

  2. Type `make' to compile the package.

  3. Optionally, type `make check' to run any self-tests that come with the package.

  4. Type `make install' to install the programs and any data files and documentation.

  5. You can remove the program binaries and object files from the source code directory by typing `make clean'.   To also remove the files that `configure' created (so you can compile the package for a different kind of computer), type `make distclean'.  There is also a `make maintainer-clean' target, but that is intended mainly for the package's developers.  If you use it, you may have to get all sorts of other programs in order to regenerate files that came with the distribution.

  6. Often, you can also type `make uninstall' to remove the installed files again.

Therefore, the following commands should configure, build, and install this package:

./configure
make
make install

Once the plugin is installed, Anjuta is ready to go. Open Anjuta at a command prompt:

$anjuta

Add Poky in the preferences section. In Anjuta click on Edit -> preferences. Select the "General" tab then go down to Poky SDK and check the box next to it in order to include it in Anjuta. Here it would be a good idea to just close out of Anjuta and open it back up again to ensure that the Poky SDK stuck in the preferences.

Go back to Edit -> preferences to see the options for the Anjuta plugin.

You’ll notice that there’s two choices at the top of the preferences on the screenshot I have supplied. 

• The first one is “Use an external toolchain”.  This is the one you need to use in order to create code for the DR1000.  The external toolchain is that which was supplied by iRex on their developer site here:

            http://developer.irexnet.com/pub/iOn/

• The other option is “Use a full Poky tree” –  I think this option would be more useful for a custom project in which you use code directly from the Poky distribution.  You would point to the poky source files and start developing a useful toolchain.  In fact I would bet that iRex started developing the supplied toolchain using this option.  I’m only guessing though.  If you wanted to install the full version of Poky (currently the “pinky” distribution) you can do the following:
  
  Get the latest distribution of the Poky environment:
  wget http://pokylinux.org/releases/pinky-3.1.tar.gz
  tar zxvf pinky-3.1.tar.gz
  cd pinky-3.1/
  Run Synaptic Package Manager:
  System → Administration → synaptic Package Manager
  Search for “poky”
  Find the poky-scripts package.  Synaptic also recommends qemu which you would also select for installation.

SDK root:  this is just telling Anjuta where to find the files relating to your cross-compiler.  Set it to the “arm” folder of the poky directory structure which was created when you untarred the poky toolchain snapshot.  Setting it to the “arm” directory supplied by iRex will give Anjuta the necessary information to use the Poky plugin to create an appropriate set of output files tailored for the ARM processor inside the iRex DR1000. 
Toolchain Triplet: I don’t really know what a triplet refers to but it looks like the triplet is a combination of the hardware, toolchain, and operating system of the target.  I’ll have to look further into this for more details.

The other options provided relate to the Target Options. 

• For our purposes we will use the top option here, “Use QEMU Device Emulator.”  This option supplies the location of the two most important components of a Linux system, the kernel and the root filesystem.   Like the toolchain, these are also provided by iRex on the developer site:
  http://developer.irexnet.com/pub/iOn/
  The method used for  creating software for the DR1000 is to create/debug entirely against the QEMU emulator of the DR1000.  Once it works satisfactorily you upload your finished program to the SD card on your device and it’s done.  (hopefully).  Realistically it would be much better in my opinion if you could connect up directly to the device and run breakpoints in your code while it is running in the actual hardware. 
  With an emulator you are at the whims of the designer who programmed the emulator.  If there exists some quirks in the true system hardware and the developer left this out of the emulator then you won’t see it until you load your program into the DR1000.  And believe me – there are many “quirks” on the DR1000.  Actually, to program all these problems into an emulator would create quite a laughable outcome.  I guess the emulator is what their end product would look like in an ideal world (no time/money constraints and pesky deadlines).
• The other choice is “Use an external device.”  Since this has a section for an ip address it would likely be for remote installation and debugging of an embedded product.  Since we only have the option to load the newly created software onto the SD card provided with the DR1000 we don’t need to worry about this choice.  However, this would be valuable if you were building your own system. 

Kernel: Point this to your zImage file: “zImage-2.6.23-qemuarm-20081016230544.bin” in my case.  This is the Linux version 2.6.23 image that is made for use with the DR1000.  It’s likely a stripped-down version of this linux distrubution with minimal drivers and used specifically for this one hardware platform.  Tailoring for the DR1000 would shave off a lot of unnecessary memory hogs – a necessary step in pretty much any embedded project.
Root Filesystem:  This is a directory structure for linux to reside in.  It tells Linux where all its necessary files are and where to put other files. For mine I used the following:

poky-image-ion-devel-qemuarm-20081016230544.rootfs.ext2

 

Here's what my preferences looked like when I was done:

This is the anjuta preferences for poky.

From the Poky readme file you can see that they describe everything in a more compact form:

Configuration
~~~~~~~~~~~~
The configuration options presented in the preferences are:

* "SDK root" this is the root directory of the SDK for an ARM EABI SDK this
will be "/usr/local/poky/eabi-glibc/arm". This directory will contain
directories named like "bin", "include", "var", etc. With the file chooser
it is important to enter into the "arm" subdirectory for this example.

* "Toolchain triplet" this is the cross compile triplet, e.g.
"arm-poky-linux-gnueabi". The triplet can be identified from a directory
within the "SDK root"

* "Kernel" use the file chooser to select the kernel to use with QEMU

* "Root filesystem" use the file chooser to select the root filesystem image,
this should be an image (not a tarball)

Install the following packages through the synapsis package manager.

• autogen
• automake
• libgtk2.0-dev

New -> project should work fine now.

Questions:
1. Why would I need to download pinky?  Looks like poky directory is all I need, right?
2. What is OpenEmbedded cross-compile environment needed for?

Answers:
1. Pinky is the actual poky source code that's available for your use. Pinky is the latest version name. However, you don't need it for running the DR1000 development environment because the provided plugins already take care of all the necessary files and they are tailored directly for the DR1000.
2. OpenEmbedded cross-compile environment is not needed either since we are using Anjuta as our environment. OpenEmbedded was just used in the process of creating the plugins that we are using.

In order to make things run smoothly, you need to run the following line:

sudo sysctl -w vm.mmap_min_addr=0

Otherwise you'll run into the following error:

Error, please set /proc/sys/vm/mmap_min_addr to 0 since

To make this a permanent change you need to modify the /etc/sysctl.cfg file.  Make sure the variable vm.mmap_min_addr is set to zero.  Just keep in mind that this file won’t affect the system until you reboot.  You can run the "sudo..." line mentioned above instead of rebooting for now.

Run Tools -> Start QEMU in order to test that the QEMU emulator is working properly. It will slowly pop up with a black window with a logo.

Next task is to get the source code from iRex for a desired program that you want to try out. The first one you should just try out is the hellow_world program. I downloaded hello_world program from
http://developer.irexnet.com/pub/iOn/Sources/1.0/iRex/
then extracted the tar to the /usr/local directory

open hello_world.anjuta within Anjuta to get the project opened

I tried Build -> Run Autogenerate...

If you see some errors here, try re-activating the poky plugin within the preferences menu. See Troubleshooting for more info.

After running Autogenerate I was able to follow the anjuta-plugin-sdk README for further instructions on how to get the project built:

As an example, cross-compiling a project, deploying it into QEMU and running a debugger against it.

* Choose "Build->Run Configure" or "Build->Run Autogenerate" to configure (or  to run "autogen" on the project.) This passes command line arguments to instruct it to cross-compile.

* Next do "Build->Build Project" to build and compile the project. If you have previously built the project in the same tree without using the cross-compiler you may find that your project fails to link. Simply do "Build->Clean Project" to remove the old binaries. You may then try building again.

* Next start QEMU by using "Tools->Start QEMU", this will start QEMU and will show some any error messages in an message view. Once Poky has fully booted within QEMU you may now deploy into it

* Once built and QEMU is running, choose "Tools->Deploy", this will install the package into a temporary directory and then copy using rsync over SSH into the target. Progress and messages will be shown in the message view.

* To debug a program installed into onto the target choose "Tools->Debug remote". This prompts for the local binary to debug and also the command line to run on the target. The command line to run should include the full path to the to binary installed in the target. This will start a gdbserver over SSH on the target and also an instance of a cross-gdb in a local terminal. This will be preloaded to connect to the server and use the "SDK root" to find symbols.  This gdb will connect to the target and load in various libraries and the target program. You should setup any breakpoints or watchpoints now since you might not be able to interrupt the execution later. You may find it necessary to stop the debugger on the target using

* It is also possible to execute a command in the target over SSH, the appropriate environment will be be set for the execution. Choose "Tools->Run remote" to do this. This will open a terminal with the SSH command inside.

For our purposes the project we want to run is “hello_world”. Enter your root password if prompted.

* To do a system wide profile against the system running in QEMU choose "Tools->Profile remote". This will start up OProfileUI with the appropriate parameters to connect to the server running inside QEMU and will also supply the path to the debug information necessary to get a useful profile.

That gets you as far as running the project on the iRex DR1000 emulator using the QEMU option in Anjuta.

Download the 1.03 iOn code from the iRex website:

http://developer.irexnet.com/pub/iOn/SDK/1.03/

	hello-world-1.03.tar.gz	19K	Hello World example application
	poky-eabi-glibc-i686-arm-toolchain-sdk-..>	114M	SDK with GCC 4.3-based toolchain
	poky-image-ion-devel-qemuarm-2008122311..>	29M	Root filesystem for emulator
	zImage-2.6.23-qemuarm-20081223111858.bin	1.5M	Kernel for emulator

Put the snapshot in the root directory and untar it
Put the unzipped zImage and poky-image into the same directories as the old ones. In my case I have located them in the /usr/local directory.

Also download the 1.03 version of hello-world and put it into your projects directory.

Within the newly created hello-world directory you need to run the build script:

./build_all_from_scratch.sh

This ran into a problem at LIBERXX:

checking for LIBERXX... configure: error: Package requirements (liberipc >= 0.1 libergtk >= 0.1) were not met:

No package 'liberipc' found
No package 'libergtk' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.

Didn’t find LIBERXX in synaptic package manager so I went back to the iRex instructions.
Tried changing the environment variables according to the iRex instructions:

cd
echo "" >> .bashrc
echo "# set poky/qemu environment:" >> .bashrc
echo "source /usr/local/poky/eabi-glibc/arm/environment-setup"
>> .bashrc
tail .bashrc

The first line has a <space> after the “cd” command. The tail command is just showing you the tail-end of the text file specified (.bashrc).
This is pretty much straight from the poky documentation.  It sets up the system so when you try to build the project it knows where to find all the tools (like LIBERXX) by adding information to your PATH.

Tried the ./build_all_from_scratch.sh again.  worked this time just fine.

Change settings in anjuta’s poky plugin to point to the new files

Tried autogenerate but it failed with permissions problems:

Autom4te.cache/requests: Permission denied

Found out that the autom4te.cache is actually in the project directory.  Change ownership of the entire projects directory. This is wherever your projects are located so for me it’s the following:

chmod 777 –R /usr/local/projects

Project autogenerate worked fine now

Also tried running config.  Keep in mind that Anjuta asks if you want any variables passed into the configure command.  Leave this blank.  The variables are unnecessary because we already took care of that within the Poky preferences menu.  As you can see from the output below, the –host variable is already passed into the configuration. Here are the results from the messages window of anjuta:

./configure --host=arm-poky-linux-gnueabi
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
configure: loading site script /usr/local/poky/eabi-glibc/arm/site-config
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-poky-linux-gnueabi-strip... arm-poky-linux-gnueabi-strip
checking whether NLS is requested... yes
checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/msgfmt
checking for xgettext... /usr/bin/xgettext
checking for msgmerge... /usr/bin/msgmerge
checking for style of include used by make... GNU
checking for arm-poky-linux-gnueabi-gcc... arm-poky-linux-gnueabi-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-poky-linux-gnueabi-gcc accepts -g... yes
checking for arm-poky-linux-gnueabi-gcc option to accept ISO C89... none needed
checking dependency style of arm-poky-linux-gnueabi-gcc... gcc3
checking build system type... i686-pc-linux-gnu
checking host system type... arm-poky-linux-gnueabi
checking for ld used by GCC... /usr/local/poky/eabi-glibc/arm/arm-poky-linux-gnueabi/bin/ld
checking if the linker (/usr/local/poky/eabi-glibc/arm/arm-poky-linux-gnueabi/bin/ld) is GNU ld... yes
checking for shared library run path origin... done
checking whether NLS is requested... yes
checking for GNU gettext in libc... yes
checking whether to use NLS... yes
checking where the gettext function comes from... libc
checking for arm-poky-linux-gnueabi-gcc... (cached) arm-poky-linux-gnueabi-gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether arm-poky-linux-gnueabi-gcc accepts -g... (cached) yes
checking for arm-poky-linux-gnueabi-gcc option to accept ISO C89... (cached) none needed
checking dependency style of arm-poky-linux-gnueabi-gcc... (cached) gcc3
checking how to run the C preprocessor... arm-poky-linux-gnueabi-gcc -E
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for ANSI C header files... yes
checking for a BSD-compatible install... /usr/bin/install -c
checking for arm-poky-linux-gnueabi-pkg-config... no
checking for pkg-config... /usr/local/poky/eabi-glibc/arm/bin/pkg-config
configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet.  If you think this
configuration is useful to you, please write to autoconf@gnu.org.
checking pkg-config is at least version 0.9.0... yes
checking for DEPS... yes
checking for LIBERXX... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/Makefile
config.status: creating src/Makefile
config.status: creating po/Makefile.in
config.status: WARNING:  po/Makefile.in.in seems to ignore the --datarootdir setting
config.status: creating data/Makefile
config.status: creating doc/Makefile
config.status: creating doc/Doxyfile
config.status: creating config.h
config.status: config.h is unchanged
config.status: executing default-1 commands
config.status: creating po/POTFILES
config.status: creating po/Makefile
config.status: executing depfiles commands

App hello-world 1.0
=====================

prefix:                             /usr/local
source code location:               .

Building with Debug:               
Building with epaper support:       yes

Building with API Documentation:    no

 

Completed successful
Total time taken: 5 secs

Tools -> Start QEMU
Upon startup the new 1.03 emulator asks you to select your language. To satisfy this we need to just press the virtual button on the keyboard so we can proceed with English. You can press the virtual buttons by sending specified values to the emulator. In this case we need the GDK_Enter value sent:

Tools -> Run remote
Enter the command for the middle button on the left or right:
GDK_Enter
enter your root password if necessary. 

Wait for the screen to change – it may take a few seconds so be patient.  After that is taken care of just confirm that you’re running the 1.03 software by checking the Settings -> About within the emulator.

Tools -> Deploy
This will get the project sent to the emulator

Go to a directory with a file that you want to copy to the emulator (in this case I’m using “testfile.pdf”).  Then type in the following:

scp testfile.pdf 192.168.7.2:testfile.pdf

It will ask for the root’s password.  Just press enter because the root password for the DR1000 is blank.  scp is a secure copy program for copying files between hosts on a network.  Since the emulator is technically a host with its own IP address this is how you will copy files over to it. 

look at your DR1000 emulator’s file structure with the following command:

ssh 192.168.7.2

Press enter when it asks for a password again
check your /home/root directory for the file you uploaded to the emulator. 

Now, how do we view the pdf file you just put into the emulator?   Currently, using ssh, you're looking at the kernel directories in your filesystem. You can’t "view" system files on the emulator and right now your pdf is essentially a system file. If you had the physical device you'd just put your pdf onto the SD card supplied with your device and this is exactly what you need to do with the emulator as well.

In order to show a pdf file, for example, you need to upload it to your (virtual) SD memory card and then you can open it within the emulator environment.  So, create a virtual SD card, mount it in the emulator, then upload your files to it:

Create the SD card image in Ubuntu Linux:

dd if=/dev/zero of=/tmp/SDcard_image count=20480

Move to the tmp directory where the image resides, then make the filesystem:

cd /tmp/
mkfs SDcard_image

choose yes when it asks to proceed.  You’ll get output something like the following:

root@Ubuntu:/tmp# mkfs SDcard_image
mke2fs 1.40.8 (13-Mar-2008)
SDcard_image is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
2560 inodes, 10240 blocks
512 blocks (5.00%) reserved for the super user
First data block=1
Maximum filesystem blocks=10485760
2 block groups
8192 blocks per group, 8192 fragments per group
1280 inodes per group
Superblock backups stored on blocks:
8193

Writing inode tables: done                           
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Use scp again to copy the file over to the emulator:

scp SDcard_image root@192.168.7.2:/tmp/

Once the SDcard image is done uploading to the emulator, we need to change it so we can see it as a filesystem. First we connect to the device again with ssh:

ssh 192.168.7.2
mkdir /media/mmcblk0p1
mount -o loop=/dev/loop0 /tmp/SDcard_image /media/mmcblk0p1/
mkdir /media/mmcblk0p1/eBooks

At this point you have a mounted filesystem which is to be our SD card and a subfolder called eBooks. However, you won't be able to immediately see this folder in the emulator. You need to restart the Xserver in order to get it working. At the ssh prompt for the emulator, you first find the PID of Xfbdev then you start Xserver:

ps
kill 1952
/etc/X11/Xserver

This displays the running applications then kills the application with PID 1952. Use whatever your PID is for Xfbdev when you find it in the list. The last line starts up Xserver again. Once QEMU starts up there should be a "Documents" folder and this will have your eBooks folder under it.

Upload new ebooks or other pdfs to the folder with the following command:

scp testFile.pdf 192.168.7.2:/media/mmcblk0p1/eBooks

Now you should be able to see the file in that eBooks folder. Open up the file. I found that it took longer in the emulator to open a file than it does on the physical device. Here is the output of the front cover of an eBook that I uploaded to the emulator:

QEMU ebook screenshot

(click the image for a bigger view)

And yes, it really does look that good. The device has very high resolution. I have not included the full view of the cover because the computer I'm using has a screen that's a little too small to show the whole view of the emulator. Once I get on a machine with a larger screen I'll put a full cover screenshot up. Also I'll add a screenshot of a document showing some small text content so you can see what a full page of text looks like.

The next step after that is to get the project onto the physical device. Detailed instructions on this part of the process is pretty important since you could potentially mess up your device if you do it wrong. Then again the worst that can happen, I think, is that you'll have to re-install the software onto your SD card. You can find instructions on this below in the links section.

Apt-get update problem

When I ran this at first I ran into this error:

Hit http://ca.archive.ubuntu.com hardy-updates/multiverse Sources             

Fetched 2B in 14s (0B/s)                                                      

W: Failed to fetch http://security.ubuntu.com/ubuntu/dists/hardy-security/universe/source/Sources.bz2  Hash Sum mismatch

I ran the aptitude update instead

aptitude install update

This did not result in any errors though I'm not quite sure if it worked correctly. After poking around on the net for some answers about the "hash sum mismatch" problem I decided to run the poky install to get the correct dependencies for the Poky environment. This is a necessary step for later anyways and if you run into a roadblock sometimes it's good to move on to something else.

Poky dependencies error

apt-get install qemu poky-depends poky-scripts

I then ran into the following error:

root@Ubuntu:/etc/apt# apt-get install poky-scripts
Reading package lists... Done
Building dependency tree      
Reading state information... Done
E: Couldn't find package poky-scripts

At first I thought this was likely due to the error mentioned above which was seen during the update step. Then I found out that the reason poky-scripts wasn't found is because the poky-scripts don't exist for the Hardy Heron version of Ubuntu yet! (even though it is listed as existing in the readme file for the plugin.)  That solves that problem. I contacted the developer and he said he would add the necessary code in order to allow for this to work correctly for Hardy Heron. By the time you read this it should be working correctly, but for now we can just install it by hand. To get all the dependencies and install them individuallly run the following lines:

apt-get install build-essential python diffstat texinfo texi2html cvs subversion wget gawk help2man bochsbios

 

Running poky from command line:

According to the readme file you can get something running from the command prompt. I decided to test this out by trying the following:

MACHINE=<machine> poky-qemu <zimage> <filesystem>

where <machine> is qemuarm in this instance
<zimage> is the location of the zImage file
<filesystem> is the location of the rootfs file

Tried running the following command according to this convention:

root@Ubuntu:/usr/local/poky/eabi-glibc/arm# poky-qemu /usr/local/zImage-2.6.23-qemuarm-20081016230544.bin /usr/local/poky-image-ion-devel-qemuarm-20081016230544.rootfs.ext2

Error, please set /proc/sys/vm/mmap_min_addr to 0 since otherwise it can cause problems with QEMU

For some reason I couldn't set this to zero – tried with vim but it said I couldn't write to it.  Current setting is 65536. You can see how to fix this in a later step on this page.

After I figured out how to set this value to zero I never came back to trying this command line approach, but if I try it out I'll document the outcome here. Looking at it now I should have added "qemuarm" to the beginning of that last command.

mmap_min_addr to 0 error:

Error, please set /proc/sys/vm/mmap_min_addr to 0 since

This is the same problem that I ran into in an earlier stage. I looked through the net for an answer on this and found a command that will fix this:

sudo sysctl -w vm.mmap_min_addr=0

Subversion question

QUESTION:

Is there a way to use subversion (svn) to get the source code from iRex? Tried the command:

svn co http://developer.irexnet.com/pub/iOn/Sources/1.0/Boot/

but this did not work.  Got an error:

svn: PROPFIND request failed on '/pub/iOn/Sources/1.0/Boot'

svn: PROPFIND of '/pub/iOn/Sources/1.0/Boot': 301 Moved Permanently (http://developer.irexnet.com)

Then I looked on the repository link at the developer.irexnet.com site and found a README file.  It stated to use the repo address instead to download the repository, like this:

svn co http://developer.irexnet.com/repo

That downloaded things fine.  However, I'm not sure if it's the same stuff.  Isn't there a way to download the stuff From the iOn/Sources/1.0 directory without individually downloading each file? i Looked in synaptic package manager and found a svn program called Bazaar.  Downloading it.

I wanted to get a project to succeed in building so I moved on to that instead of worrying about the subversion attempts.

Autogenerate problems

I tried Build -> Run Autogenerate...
this did not work.  It said:

...can not execute command: autoreconf
execvp failed:  No such file or directory
Completed unsuccessful

Tried looking on synaptic for a autoreconf package.  Autoconf came up so I tried that. I got a different error:

autoconf failed to run aclocal: no such file or directory

Found out that aclocal is part of automake.  Looked for package in synaptic.  Found and installed it. Autogenerate worked, but there was no “Build project” option afterwards and there were a couple of red X's at the end of the generate sequence.  New option “Run Configure” came up though in the build menu.  Tried this and it came up with an error:

No package 'gtk+-2.0' found
No package 'glib+-2.0' found

I couldn't find gtk in synaptic.  Found out from ubuntuforums.org that gtk+-2.0 is an old name for libgtk2.0-dev.  Found and installed this in synaptic.  This included the glib package. This didn't solve the problem though and it still didn't work.  Tried also installing libgtk1.2-dev but this didn't remove the error either.  Next tried a few other gtk tools:

gtk-doc-tools
the GTK+ documentation tools

These tools extract documentation embedded in GNOME source code, and produce a good looking easy to read output via DocBook SGML.

Found out my problems were only related to the fact that the Anjuta preferences for Poky had disappeared.  SO – I just had to re-activate the poky plugin within the preferences menu and everything worked fine again. 

If you have some information to contribute to this tutorial please contact me or just leave a comment below. I would like to add as much information as possible to help people get over the initial steep learning curve of using the available tools for software development on the iRex Dr1000 ereader device. It was hard enough getting this far along and I just don't think it should be necessary to fight with a lot of development environment tools. The tools should work for us, not the other way around. Our main focus should be on developing code and deploying it to the DR1000. Agreed?

1. Poky linux software development environment for iRex DR1000s:
   http://pokylinux.org/
   http://pokylinux.org/releases/pinky-3.1/
   Poky development tool handbook:
   http://www.pokylinux.org/doc/poky-handbook.html#platdev-appdev-external-sdk
   Poky hardware reference guide:
   http://pokylinux.org/releases/pinky-3.1/readme.hardware
2. Anjuta plug-in for Poky:
   Anjuta is a graphical integrated development environment targetting GTK/GNOME development.
   http://labs.o-hand.com/anjuta-poky-sdk-plugin/
   Anjuta homepage:
   http://www.anjuta.org/
   
   
3. Developer downloads and GPL Source code for iRex DR1000s
   http://developer.irexnet.com/pub/iOn/
   
   
4. Here's the resource link for QEMU
   http://bellard.org/qemu/
   http://bellard.org/qemu/user-doc.html
   
   
5. linux development environment for embedded systems:
   http://wiki.openembedded.net/index.php/Main_Page
   http://wiki.openembedded.net/index.php/Getting_Started
6. blog for iRex DR1000 development:
   http://i-to-i.irexnet.com/2008/10/23/ion-source-codes-and-sdk-released/
   http://i-to-i.irexnet.com/category/irex-dr1000/
   
   
7. developers forum from mobileRead for iRex DR1000s
   http://www.mobileread.com/forums/forumdisplay.php?s=6e6e7880ba7ca1d6ad1ddd2f4feedcde&f=174
   
8. FBreader for reading different formats of eBooks (includes open source):
   http://fbreader.org/about.php
   http://fbreader.org/downloads.php
   http://fbreader.org/documentation.php
   Project on freshmeat webpage:
   http://freshmeat.net/projects/fbreader
9. Shops:
   iRex shop for buying extras (stylus, cases...etc):
   https://www.irexshop.com/product_info.php?cPath=37&products_id=71&osCsid=335d9a4d9cbb101afbff4df2161d8b11
   
10. eReader Outfitters:
    Downloads:  http://www.ereaderoutfitters.com/info/Free+downloads.html
11. iRex support
    DR1000 knowledge base:
    http://support.irexnet.com/index.php?_m=knowledgebase&_a=view&parentcategoryid=19&pcid=0&nav=0
    
12. Download directory for DR1000 software (includes companion software):
    http://updates.irexnet.com/companion/dr1000/
13. Card Restore download:
    http://support.irexnet.com/index.php?_m=downloads&_a=viewdownload&downloaditemid=27&nav=0,17
    
14. PressReader instructions:
    http://support.irexnet.com/index.php?_m=downloads&_a=viewdownload&downloaditemid=32
    
    
15. How to update your DR1000s
    http://support.irexnet.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=79&nav=0
    
16. Static affecting buttons
    http://forum.irexnet.com/viewtopic.php?t=3054
17. Missing companion software
    http://www.mobileread.com/forums/archive/index.php/t-30320.html
18. Startup problems on lowbattery/incomplete upgrade
    http://support.irexnet.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=83
    
    
19. Is there an SDK available?
    http://support.irexnet.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=80