OpenPandora: Building your own ROOTFS image (Part 1).

Updated: 7th June to expand the setup scripts section and tell people to get them from GIT.

This is the 1st of 2 articles I will be publishing on getting started with building the Linux distribution installed on the OpenPandora, from source code, from scratch.

Note: This is not a guide to using OpenEmbedded or bitbake, or writing package recipes. It’s just a guide to getting an OpenPandora build setup running.

This 1st article will cover the basic setup of OpenEmbedded environment and the building of our Ångström distribution derived ROOTFS, the 2nd will detail how you can run the resulting images on your OpenPandora from SD cards, or if you really want to, the NAND.

I also plan to write a separate related article will show how you can setup toolchains and SDK’s to help you develop applications for (and natively on) the OpenPandora using some of the strengths of OpenEmbedded to make this easier.

As I write these posts in my own time I can’t promise to do anything quickly. Nor can I make any promises about how accurate they may be . As always, feedback is welcome.

Most application developers/porters will only be interested in the related article on setting up SDK’s and toolchains, these 2 are really for the hardened Linux hackers who want to mess about with the ROOTFS/distribution development.

Health (and sanity) warning: Building the entire ROOTFS from scratch is pretty technical in nature, if you have no desire to rebuild the ROOTFS or hack with the inner workings of you’re OpenPandora this is probably not for you.

You can’t really damage anything on your OpenPandora but if your not familiar with compiling your own apps, kernels etc. and fixing things when they don’t work this will present a VERY steep learning curve. You also have the potential to make a mess of your build host if you are not careful with the setup.

I’ll focus showing how you can build a ‘one <> one’ version of the 1st official release (GIT tag: “Release-2010-05/1”). 

Once you have that going feel free to build the tips of the metadata GIT’s if you want to work with the latest and greatest or get stuck in modifying the metadata to suit whatever purpose you may have in mind.

Contents:

Closed source prerequisites
Host OS for building the ROOTFS
Important GIT repositories
Setting up your environment for OpenEmbedded
Building the OpenPandora ROOTFS images using OpenEmbedded

Closed source prerequisites:

Before we start you will need to collect up the few closed source components used in the ROOTFS, thankfully Texas Instruments and Imagination Technologies at least make getting the closed source binaries and SDK for the PowerVR SGX quite easy these days.

PowerVR SGX Binaries and SDK:

You will need to download version 3.01.00.02 of the Ti Graphics SDK (OMAP35x_Graphics_SDK_setuplinux_3_01_00_02.bin) from http://software-dl.ti.com/dsps/forms/export.html?prod_no=/OMAP35x_Graphics_SDK_setuplinux_3_01_00_02.bin

You will have to create a Ti account to download the software and agree to a license/export agreement but once you have done this Ti normally instantly grant access to the download. After you download this store it in a safe place, you will need to drop it into a folder in the build system later on.

The other closed source components are the firmware that is run on the WL1251 wireless chip and Bluetooth chip (the drivers themselves are open source and in mainline Linux). However our build system will automatically downloads these closed source firmware binary firmwares and places them into the appropriate place in the ROOTFS.

Host OS for building the ROOTFS:

Note: all my OpenEmbedded build boxes are 32bit Ubuntu Linux 10.04 servers with PAE enabled kernels, building on most other Linux distributions should be (and is) simple enough however some small adjustments may need to be made to suit your distribution. The OpenEmbedded and Ångström documentation can help with this.

You will need to install a number of packages onto your host PC before you start building OpenEmbedded images.

Try the command below, this should get most of the major prerequisite packages installed that you will need to start building using OpenEmbedded on a Ubuntu/Debian derived distribution.

sudo apt-get install ccache sed wget cvs subversion git-core coreutils unzip texi2html texinfo libsdl1.2-dev docbook-utils gawk python-pysqlite2 diffstat help2man libxml2-utils xmlto python-psyco

Note: The OpenEmbedded Required Software page also details this very well and is a must read.

One last thing to consider if your using a Ubuntu derivative is that they use dash as the default shell not bash.

This can cause a few issues with some of the packages we want to try and build, it’s not a problem with the build system per-say but issues with the individual packages assuming bash hacks in whatever /bin/sh is on the system.

Still, the fix is pretty easy, just set your default shell to bash using the command below.

sudo dpkg-reconfigure dash

Important GIT repositories (GITWeb links):

All the metadata (and custom source code etc.) is held on a publically accessible GIT server (git.openpandora.org).

For the purposes of building a working ROOTFS the following GIT repositories are of interest.

• http://git.openpandora.org/cgi-bin/gitweb.cgi?p=pandora-kernel.git;a=summary 

Important remote branches are pandora-27-omap1 (Our ‘default’ kernel as of now) and linux-omap (synced with top of the mainline Linux-OMAP tree).

• http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openpandora.oe.git;a=summary

The important remote branch is master. This is our OpenEmbedded overlay (i.e. custom OpenPandora specific stuff we lay on top of OpenEmbedded/Angstrom to build our images).

• http://git.openpandora.org/cgi-bin/gitweb.cgi?p=openembedded.git;a=summary

The important remote branch is op.openembedded.dev, this is a snap shot from mainline OpenEmbedded with our queued patches stuffed on top. This serves as our feed tree for getting stuff into mainline OpenEmbedded/Angstrom (with a few clearly marked exceptions, look for checkins with HACK: in the commit message, these won’t be going to mainline ).

Should you with to manually clone any of the OpenPandora GIT repositories for whatever reason you can by issuing.

git clone git://git.openpandora.org/repository.name.git destination.folder

But if you just plan to build an image you have no need to do this as the setup script will take care of it for you.

Setting up your build environment for OpenEmbedded:

Using OpenEmbedded to build images is actually a pretty simple affair if done right however often steps are missed or done in the wrong order leading to all manner of spurious issues and resulting pain.

Security Warning: Never build your images as the ‘root’ user, there is no need to use a root account and doing so is a really bad idea, just make sure your normal user has control of the folder containing your OpenEmbedded environment.

To make the process as simple as possible I have knocked up a few simple support scripts that can just be installed to an appropriate place and run, hopefully setting up the environment correctly as they go.

These scripts are pretty crude and lack robust error checking and such so should be run with a note of caution. The idea is to improve them as we go.

Note: You will need LOTS of space to undertake a complete build of the ROOTFS, my typical build folders are often in excess of 100Gbyte . Make sure you have the space before you start .

1st off you need to pick somewhere on your system to construct the OpenEmbedded environment, this should be a path with no symlinks above it, a rebound mount point is fine however.

The user you want to use for builds will need control of this folder.

Open a terminal and change into the above folder that you wish to become the top level for your OpenEmbedded environment.

Get a copy of the setup scripts by running…

git clone git://git.openpandora.org/pandora-oe-environment.git .

Once you have the files checked out run the environment script (you must run it with . ./op-env-oe.sh so it goes into the calling shells environment).

. ./op-env-oe.sh

Now you have all the environment variables setup you can run the script that initialises the environment (creates folders, checks out the GIT’s etc.).

./initial-setup.sh

This will take a while to run as it creates directories, clones the necessary GIT trees and populates the environment. Now is a good time for the 1st coffee .

The next step is to switch from the tip of our GIT trees to the “Release-2010-05/1” tag.

This will ensure you are working with exactly the same metadata as the 1st release.

You can skip this step if you want to work with the latest and greatest code.

./use-release-2010-05-1.sh

Note: If you want to you can later switch back to the tip of the GIT trees (development metadata) using ./use-tip.sh.

Be careful if you have uncommitted changes in your local GIT tree as the scripts will try and ‘git stash’ them but I suspect that may not be what you want.

Now your environment is all setup (assuming the scripts worked ok ) your build folder should look like the breakdown below, more folders will be created as soon as you run a build (folders for sources, package staging and temp data for example).

top of build area \

  bitbake \ < Bitbake lives here.

  build \

     conf \

        local.conf < This is the file that tells OpenEmbedded about our setup.

  metadata \

     openpandora.oe.git \    < Checkout of master from openpandora.oe.git

     openembedded.git \     < Checkout of op.openembedded.dev from

                                               openembedded.git

     user.collection \     < Area for any user created package recipes.

  tmp \ < The temp area that all the building is done under.

The next step is to copy in the copy the PowerVR SDK you downloaded earlier into the right place in the build folder.

You need to copy OMAP35x_Graphics_SDK_setuplinux_3_01_00_02.bin into metadata/openembedded.git/recipes/powervr-drivers (so it ends up in the same folder as libgles-omap3_3.01.00.02.bb).

The command below should do it if you run it from the folder you downloaded the SDK into.

cp ./OMAP35x_Graphics_SDK_setuplinux_3_01_00_02.bin ${OEBRANCH}/recipes/powervr-drivers

Now you want to do a simple test to check everything is working as expected.

From the top of your build directory run…

bitbake nano

After a fair period of time (it will download and build a version of GCC to target the OpenPandora GCC so it can then use that GCC to build NANO ) you should have a successful build of the NANO text editing package.

Note: You can check this by looking in tmp/angstrom.5/deploy/glibc/ipk/armv7a to see the NANO ipk package (nano_2.0.9-r0.5_armv7a.ipk).

The ‘angstrom.5’ part of the path comes from the concatenation of angstrom and it’s internal distribution revision (currently 5).

Your now ready to move on to building something a little more complex…

Building the OpenPandora ROOTFS images using OpenEmbedded.

Now you have a suitable environment setup you can move on to building your 1st image.

Every time you open a new shell/terminal you will need to call the environment setup script to create the necessary environment variables, the rest of the setup is already done.

. ./op-env-oe.sh

You have the full Angstrom and OpenEmbedded metadata at your disposal but for the purposes in hand there are a 2 main types of OpenPandora image stored in our OpenEmbedded overlay and 2 additional ones showcasing other Desktop environments.

You can see if a package is in a given image by looking at the corresponding recipe task file (found in metadata/openpandora.oe.git/recipes/tasks).

They are as follows (image name – task used).

• pandora-core-image – task-pandora-core

This image contains all of the core packages for the OpenPandora but lacks any GUI/X Server etc. – It is lightweight (reasonably) and obviously CLI. Ideal if your working on hardware drivers etc. and don’t need a GUI layered on top. It also features things like libPND baked in.

• pandora-xfce-image – task-pandora-xfce

This is the default OpenPandora image that ships on the NAND. It contains everything in the core image above and adds XOrg, Xfce and MiniMenu as the GUI elements. It also contains a myriad of GUI applications, scripts and the like as you would expect.

• pandora-desktop-image – task-pandora-desktop

This is an Enlightenment (E17) based variant of the Xfce image above, it’s not had much love for a little while but should broadly be comparable to the Xfce image if you swapped out Xfce for E17 . I am hoping this image will get a little love ‘post release’ to bring it in line with the Xfce image.

• pandora-gui-image – task-pandora-gui

This is a Matchbox based variant of the Xfce image above, it’s not had much love for a little while but should broadly be comparable to the Xfce image if you swapped out Xfce for Matchbox . This image feels very ‘PDA’ like and less ‘pocket Linux system’.

pandora-desktop-image and pandora-gui-image are not really images intended for end users but rather then remove them from the tree they have been left so interested parities can mess about with them.

Remember that building any of these images from scratch is going to take several hours even on the fastest of boxes.

Building the OpenPandora release image is now is as simple as running

bitbake pandora-xfce-image

from the top level folder of your newly created build tree. Make sure you have run the environment setup script first or it wont find your metadata.

If all goes well just go away and have a coffee (or 20) and check every now and then to see how things are going.

It’s going to take a good few hours to build everything and there may be the odd snags along the way, if you run into troubles drop me a line and I’ll see if I can help.

Note: Once the build finishes you can check the output in tmp/angstrom.5/deploy/glibc/images/omap3-pandora, with a little luck you should have a version of the pandora-xfce-image image ready to go. A tar.bz2 (ideal for extracting to an EXT 2/3 SD card) and a .ubifs.img (ready to flash to the NAND).

I’ll cover what you should do to get your newly generated ROOTFS running on the OpenPandora in the next article.

Known Issues

OpenEmbedded is a complex beast at the best of times and can often throw up issues when you least expect things. As long as your building on recent, fairly standard, Debian based (so Ubuntu et. all) type distributions you should not run into much trouble.

I can’t speak for distributions like SuSE, Arch, Fedora etc. as I don’t use them.

One known issue that seems to crop up (especially with the release-2010-05-1 metadata, I have a fix lined up for the trunk) is that the build will fail complaining about an issue with the ‘encodings’ package.

Should you see that issue the fix is very simple.

bitbake -cclean encodings

Then you just need to rerun whatever command you had run before (don’t worry, it won’t run all the steps again) and everything should be just fine.

The encodings issue is caused by mixed up dependences and cleaning it out and letting OpenEmbedded rebuild it sorts out those issues.

If you notice other issues do please let me know (or better still send patches).

Regards,

John

‘Mobile Broadband’ on the Pandora?

One of the little things I have been asked several times is can people use Mobile Broadband (GPRS/UMTS/HSDPA etc.) USB adaptors on the Pandora (in Europe we are lucky enough to have easy and fairly cheap access to cellular broadband tariffs).

While the real answer to this is ‘most probably’ with some caveats about Linux support for your chosen adaptor, USB 2 device support etc. etc. I decided to try and get my own adaptor working on my Pandora development board and this is a post about that exercise.

It is worth remembering that I am messing with the my own development images and this should not be considered anything ‘official’, it is just me having a hack about for the hell of it.

What adaptor am I using?

For this exercise I am using my Huawei E220. It has been upgraded with the 7.2Mbps firmware (version 11.117.09.04.00).

Under Windows this will appear as a USB CDROM (well CDFS on a USB Mass Storage device for the pedantic) and then prompt you to install the included software to drive the modem side of the adaptor. It is all actually quite tidy to be honest and makes use of the device pretty painless on Windows.

How is it connected?

Unfortunately my USB stick is a USB 1.1 full speed (USB OHCI) device so connecting it straight to the Pandora gets us nowhere. Remember the USB host socket on the Pandora is an EHCI (i.e. USB2 high speed) host so it needs a hub inline to step down to USB 1.1 speeds.

So out comes a USB hub and into a hub port goes the USB stick.

What happened?

Well, the first time I plugged it in (as you might imagine) not a lot happened other then the USB stack spitting out some info about the device and installing the mass storage side of things.

usb 1-2.4: new full speed USB device using ehci-omap and address 7

usb 1-2.4: configuration #1 chosen from 1 choice

scsi4 : SCSI emulation for USB Mass Storage devices

usb 1-2.4: New USB device found, idVendor=12d1, idProduct=1003

usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0

usb 1-2.4: Product: HUAWEI Mobile

usb 1-2.4: Manufacturer: HUAWEI Technologies

usb-storage: device found at 7

usb-storage: waiting for device to settle before scanning

usb 1-2.4: USB disconnect, address 7

usb 1-2.4: new full speed USB device using ehci-omap and address 8

usb 1-2.4: configuration #1 chosen from 1 choice

usb-storage: probe of 1-2.4:1.0 failed with error -5

usb-storage: probe of 1-2.4:1.1 failed with error -5

scsi7 : SCSI emulation for USB Mass Storage devices

usb 1-2.4: New USB device found, idVendor=12d1, idProduct=1003

usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0

usb 1-2.4: Product: HUAWEI Mobile

usb 1-2.4: Manufacturer: HUAWEI Technologies

usb-storage: device found at 8

usb-storage: waiting for device to settle before scanning

scsi 7:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2

sr0: scsi-1 drive

sr 7:0:0:0: Attached scsi CD-ROM sr0

sr 7:0:0:0: Attached scsi generic sg0 type 5

usb-storage: device scan complete

Ok, a quick check of the shipped kernel modules shows that I forgot to build that into the image so off I trek back to my OpenEmbedded build system and after a quick edit to the defconfig for our kernel recipe and a bump of the kernel package revision I now have a nice usbserial.ko included in the image.

After deploying the new image I plugged it in and things got a whole lot more interesting. A couple of /dev/ttyUSB devices had been created, just what every modem connection needs.

usb 1-2.4: new full speed USB device using ehci-omap and address 4

usb 1-2.4: configuration #1 chosen from 1 choice

scsi1 : SCSI emulation for USB Mass Storage devices

usb 1-2.4: New USB device found, idVendor=12d1, idProduct=1003

usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0

usb 1-2.4: Product: HUAWEI Mobile

usb 1-2.4: Manufacturer: HUAWEI Technologies

usb-storage: device found at 4

usb-storage: waiting for device to settle before scanning

usb 1-2.4: USB disconnect, address 4

usb 1-2.4: new full speed USB device using ehci-omap and address 5

usb 1-2.4: configuration #1 chosen from 1 choice

usb-storage: probe of 1-2.4:1.0 failed with error -5

usb-storage: probe of 1-2.4:1.1 failed with error -5

scsi4 : SCSI emulation for USB Mass Storage devices

usb 1-2.4: New USB device found, idVendor=12d1, idProduct=1003

usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0

usb 1-2.4: Product: HUAWEI Mobile

usb 1-2.4: Manufacturer: HUAWEI Technologies

usb-storage: device found at 5

usb-storage: waiting for device to settle before scanning

usbcore: registered new interface driver usbserial

usbserial: USB Serial support registered for generic

usbcore: registered new interface driver usbserial_generic

usbserial: USB Serial Driver core

usbserial: USB Serial support registered for GSM modem (1-port)

option 1-2.4:1.0: GSM modem (1-port) converter detected

usb 1-2.4: GSM modem (1-port) converter now attached to ttyUSB0

option 1-2.4:1.1: GSM modem (1-port) converter detected

usb 1-2.4: GSM modem (1-port) converter now attached to ttyUSB1

usbcore: registered new interface driver option

option: USB Driver for GSM modems: v0.7.2

scsi 4:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2

scsi 4:0:0:0: Attached scsi generic sg1 type 5

usb-storage: device scan complete

Driver 'sr' needs updating - please use bus_type methods

sr0: scsi-1 drive

Uniform CD-ROM driver Revision: 3.20

sr 4:0:0:0: Attached scsi CD-ROM sr0

ISO 9660 Extensions: Microsoft Joliet Level 1

ISOFS: changing to secondary root

ls /dev/ttyUSB*

/dev/ttyUSB0  /dev/ttyUSB1

The first thing that jumps out at me is why the kernel has helpfully installed the Option driver when this it not an option card ‘option: USB Driver for GSM modems: v0.7.2’. That does not look right but lets give it a try anyway.

After a quick read it seems that if you don’t have any other USB serial devices connected the modem will be assigned to /dev/ttyUSB0 and the user interface device to /dev/ttyUSB1. So far so good.

Now to wrap all this up and see if we can connect to the Internet.

It is worth noting at this point that our images currently have NetworkManager 0.7.0 in them as I have been evaluating that for managing the WiFi connection (along with Connman) so my plan is to see just how good the NetworkManager integration with the underlying adaptor is using the command line tools (I do not have the nm-applet GUI working with 0.7.0 yet).

So I booted up the resulting image on the Pandora, plugged the USB stick in to the hub and waited a few seconds for that to settle and get connected then started to setup the connection.

netm-cli -l

GSM Devices:

ttyUSB0:

        Udi: /org/freedesktop/Hal/devices/usb_device_12d1_1003_noserial_if0_serial_usb_0

        Driver: option

        Capabilities:

                - Supported

        State: Disconnected

        Managed: True

        IP config:

                No IP settings found

Excellent, ok, NetworkManager sees that we have a ttyUSB0 GSM device. Now lets try connecting to the internet with it using my Vodafone SIM.

netm-cli --connect --gsm=ttyUSB0 --user=web --passwd=web --apn=internet --number=*99#

Device ttyUSB0: activating the connection

Device ttyUSB0: created connection '/org/freedesktop/NetworkManager/ActiveConnection/1'

/org/freedesktop/NetworkManager - State: Connecting

Device ttyUSB0: state - Prepare

Device ttyUSB0: state - Config

Device ttyUSB0: state - Need Auth

Device ttyUSB0: state - IP Config

/org/freedesktop/NetworkManager - State: Connected

Device ttyUSB0: state - Activated

/org/freedesktop/NetworkManager/ActiveConnection/1 - State: Activated

Wonderful, NetworkManager has talked to the modem and negotiated a connection to the internet.

Sparking up a Firefox session on the Pandora proves this and shows that it is working just fine. FTP and all the usual IP services are all working as expected. The connection has been up for a good few hours now and seems very stable.

So, what does this all prove. Well Mobile Broadband sticks (at least the Huawei E220) will work on the Pandora, NetworkManager is happy to configure the connection and as soon as I can get the NetworkManager 0.7.0 GUI going this whole process should be ‘plug and play’ just like it is on other major distributions like Ubuntu.

I am not 100% sure at this stage about choosing NetworkManager or Connman for the final images (it is rather dependent on some tweaks that need doing to our TI1251 Wireless driver to properly support Linux Wireless Extensions and further stability/signal tests) but either way NetworkManager will be available in the Pandora repositories and, as proven here, provides a perfectly viable and quick way to connect to Mobile Broadband if you have supported hardware.

John

Unpacking the GP2X Wiz

I was recently fortunate enough to be sent a ‘near release’ prototype of the new GamePark Holdings (GPH) portable games console, the GP2X Wiz. Considering that, it only seems fitting to put together a quick post with some random observations and pictures.

Remember that these observations are not based on a long period of testing so come with the caveat that my opinions may change!

Now, obviously this is the successor to the GP2X (and spiritually the GP32).

What is interesting from my point of view is the direction GPH have taken the Wiz.

First thing you note is that it’s a tiny little console (only a little bigger then a GameBoy Micro). It’s small. Not really small but somehow much smaller then I was expecting.

Secondly, GPH seem to be betting a lot of making the device accessible to Flash developers (this really does feel like it is the focus for the device as the front end ‘launcher’ is flash based). This is quite a marked departure from the GP2X and feels more like a step into the casual game market that is often dominated by mobile phones. I guess this change makes sense for their Korean markets.

Time will tell what effect this has on the wider markets and the adoption of Flash on the device. I suspect very little to start with as a lot of GP2X devs will no doubt get a Wiz and treat it as a logical extension of what they have done there and start hacking the hardware and giving flash little more then a glance . Given time however Flash could lower the entry level for apps and open the door to creative non-coders and that can only be a good thing for homebrew.

Anyway, onto some hardware information.

The GP2X Wiz is based on the MagicEyes Pollux SoC clocked at 533MHz and powered along by its ARMv5 ARM926EJ core. Paired with that you have the usual large page NAND, 64MB of RAM, touch screen and an SDHC slot for storage. Oh, and finally a decent fitted lithium-ion battery (that proudly tells you not to let Children and Pets chew or lick it as it may be a health risk).

I was initially a little surprised that GPH did not opt for the MagicEyes MMSP2+ SoC in the Wiz (the GP2X used the older MMSP2 SoC) as moving to the VRender range means you loose some very handy features (The ARM94* 2nd core, the basic 2D engine, RGB scalar etc.) but on the flip side you do get an OpenGL ES 1.1 3D core. Unfortunately, as it stands, no one has got the said 3D core doing much yet (but I know Pickle was doing a little investigation work). As there are only a few dozen of these devices out and about in hackers hands that is no surprise. It is something I want to dabble with time permitting .

One interesting thing I want to test sometime is to discover if the Pollux used in the Wiz suffers the same issues with strangled RAM bandwidth that the MMSP2+ suffers with. When I get time I will try the apps I built to test RAM bandwidth on the MMSP2+. If the Pollux is as bad as the MMSP2+ when it comes to RAM bandwidth that could be a bit of a snag.

The form factor.

It’s really shiny. To say the plastic used smudges easily is a massive understatement . That said it feels well made and fairly solid to hold with no flex (a pleasant continuation of the GP2X F200 level of build quality rather than a slide back to the dire quality of the 1st GP2X’s). It even has a slot for the stylus now, something the F200 GP2X did not manage.

The control layout is not quite to my tastes (big hands so it can tend to feel a little cramped). Buttons seem responsive and have a fairly positive feeling. The dPad is not as bad as all that but I have not really tried it in games yet. Not sure I am a convert to the ‘split dPad’ button layout for the right hand side mind you. This also raises the point that the L and R triggers are inset from the edges of the unit. That feels a little odd but you get used to it I guess. All in all, the controls are not great but not bad. They do the job.

The screen (when it is not suffering something like a vsync tear) is very nice. Its OLED technology and is nice and bright. Assuming the screen setup issues are software its a classy screen despite the low (comparatively) resolution of 320*240.

Something else that jumped out at me was the interesting choice GPH has made by deciding to move everything other than the headphones to the EXT port on the bottom. This includes things like the USB (device and host), TV out and charging. You won’t be connecting your Wiz to a PC directly without some additional fly leads due to the lack of a USB device port on the unit.

I suspect GPH plans to ship (as an extra or included, not sure) a dock or clip-on unit that provides at least USB and TV out and maybe WiFi if the picture below is accurate.

The software platform.

The 1st thing that greats you is the Flash menu GPH have developed for the unit.

Not a lot to say about it really. It feels like a sloppier version of the menu used on the GP2X. I hope this is down to the unit being pre-release but the menu crashes regularly and does a generally poor job of being a menu. Another aspect of the pre-release software is the lack of a lot else on the unit (that reliably works) so there is not a lot of software to talk about.

It is Linux 2.6 based but I have yet to get hold of the source to have a look at how clean the MagicEyes/GPH changes are. Looking at the file system and kernel it seems safe to assume that AESOP Embedded did the kernel porting work like they have done for other MagicEyes chips.

It seems to ship with a decent set of libraries and SDL. It is not clear if the stock SDL features some basic hardware acceleration.

I’ll update this and add more pictures when there is final software available as it is more then a little unfair to draw real conclusions from early code such as this

So what do I plan to do with it?

Not a lot right now (for at least the next few days) as I have some other projects to clear off my plate but once they are out of the way the 1st thing I want to do is clean up my basic ScummVM port then look at what is needed to add the Wiz as a supported machine to OpenEmbedded and look at what funky stuff can be done towards supporting stuff like kexecboot and a full Ångström distribution .

What about the Pandora?

Well it’s no secret that I look after the Ångström based operating system for the Pandora (among other things) and I guess that could represent a conflict of interests (yeah, right) but I would draw your attention to one little fact. I am a geek who likes to mess around with electronics . The more the merrier. I could not give a stuff about ‘community politics’. I just simply look at something and ask myself ‘does that look interesting’ and ‘will I mess about with it’.

Having now had a little time to mess about with the Wiz it is obvious to me that I will be doing some hacking about with it and I can’t really see how it and the Pandora are in any way directly ‘competing’. Different design goals, different software goals, different platforms and different price points . Both look like decent hacking platforms in there own way. When they are out, and if you can afford it, get both or just ask yourself what you want to do with it and ignore anyone who sounds rather too devout about one platform or the other.

The Wiz with some other consoles to get an idea of size.

OpenPandora, OpenEmbedded and Ångström

One of the things I have been asked a few times is what the relationship is between OpenEmbedded, Ångström and the Pandora.

It really is quite simple . To quote Wikipedia “The OpenEmbedded Project (OE for short) is a software framework to create Linux distributions aimed for embedded devices”.

Ångström is a distribution that builds upon OpenEmebdded to collect everything needed for a feature rich Linux kernel based operating system.

We use Ångström as a base to then build the operating system images for the Pandora. There are a number of reasons behind this but some of the top ones include OpenEmbedded’s extreme flexibility, Ångström’s sensible approach to configuration and the ability for us to get fine grain optimisation into the images (packages on the Pandora are ARMv7 where possible and many include patches for Cortex A8 features like the NEON or OMAP specific optimisations).

OpenEmbedded’s overlay approach to the way it handles metadata also allows us a great deal of freedom to tailor the Pandora distribution without compromising the main Ångström/OpenEmebdded metadata removing any need for silly things like forks or additional OpenEmebdded distributions.

When I talk about Ångström on the Pandora I really am talking about the mainline Ångström and not some nasty Pandora specific fork. If we add new features to Ångström our aim is to push them upstream in a sensible way quickly and only provide our overlay with the minimal amount of transitional stuff or things that would never be acceptable in mainline.

Anyway, on the back of all this I recently made a long overdue hello to the Ångström developers mailing list to try and garner some interest and support. If your interested in reading that you can find the mails in the Ångström developers mail archive here.