Raspberry Pi: Bits and pieces, Hardware and OpenEmbedded support.

If you want to skip the stuff below just read this as ‘I am impressed with it and took some pictures of my ‘retail’ unit’.

The Raspberry Pi is yet another community focused development/education ARM board in the mould of many a Gumstix, BeagleBoard and others before it.

That in itself is not overly remarkable but the Raspberry Pi foundation managed to keep one little trick up their sleeve. It’s well priced coming in at around the £25 for the basic ‘Model A’ and £35 for the ‘Model B’ (The ‘Model B’ giving you a highly useful Ethernet port, driven off USB, and extra USB host port). Neither model features a connector for a serial console but it is put out on the GPIO header at 3.3v so easy enough to convert if you need it (like I do Winking smile). There is also an abundance of other I/O to play with on the headers.

Considering you get 256MB of RAM mounted over a Broadcom BCM2835 ARMv6 SoC (more commonly used in things like STB’s and media streamers from people like Roku) and access to a beefy, admittedly closed source, GPU/video decoder it is pretty damm impressive and rather hard to complain. Ok, some might say an v7 ARM core would not have hurt and more of this and that but if your going down that road you are completely missing the point of this little budget device. Just pay a little more and get something like a BeagleBone or it’s big brother the BeagleBoard-XM to hack on and enjoy it (I already enjoy hacking on them).

This neatly brings me on to my interest in the Raspberry Pi. It’s low end by todays ARM standards, but it’s still got a hell of a lot of power to play with, cheap, quirky (another way of saying full of interesting features that may blow up in your face Winking smile) and with a little luck it will bring out that wonderful streak of madness in people.

Hopefully it will become ubiquitous in the lower end of this market and bring in more and more hobbyist developers, hardware hackers and students. Take a few of these devices and mix with a liberal helping of Arduino’s and you have some awesome options for cheap experimentation.

All that makes this a pretty appealing platform to hack on and fits well with the other stuff I like to mess about with.

Hardware pictures (click for larger jpeg’s):

Here are a few random pictures of the ‘early release’ retail model B unit the Raspberry Pi foundation have kindly provided me for some hacking (the logoed shipping label on the package was cute by the way). Rather than overly comment on the workings (the specs are well known) I’ll just provide some soft-core hardware p0rn pictures and comment on the physical build.

Not a huge amount say on this but I’ll note that it is nicely built, soldering seems precise and of good quality and no diff joints I can see. There is no solder in the test points (handy), most connectors are well attached and there is a only a little flex in the board.

The HDMI port does seem a lot more fragile than I would like and it’s a tight fit but I guess the cost of battening connectors would push the board outside its price envelope and consume board space, just don’t yank cables out or it will end in tears.

All in all, it seems a lot like the earlier boards in respect of the build and layout and that’s quite a good thing just remember the price constraints when considering that.

A big concern I have is how well these will last uncased but I understand the educational units are cased (Raspberry Pi, please make sure that case provides some battening for connectors) and that is surely going be be where the boards see most abuse. In fairness the uncased concern could be levelled at any of the development boards I have.

I know the foundation is going for a model that will see several manufacturers turning out boards under license but as long as they all hit this quality level or get above it I can’t envisage that many build problems as long as people are gentle with them and understand what they are buying.

After all that fluff lets move on to what I actually plan to use this device for…

OpenEmbedded/Angstrom:

As the hardware is at the lower end proper optimisation is highly important to get the most out of the device and this is where OpenEmbedded comes into the mix. I have put together an OpenEmbedded-Core based BSP layer for the Raspberry Pi A and B hardware that ensures every package built for the machine is tuned for both the ARMv6 architecture and the ARM 1176jzf-s core. This was actually fairly easy to get going bar the time consuming mess that is the usual platform specific quirks, hacks and munges. However as the OpenPandora has used OpenEmbedded/Angstrom since its inception (and has it’s own set of quirks) I should be pretty familiar with it by now Smile.

Currently the layer it has a number of rough edges but the basics. kernel, bootloader and supporting bits and bobs are building and if you so desire it can be used to (almost, needs a small fix) create you a pre-configured SD card image file (currently setup for a 4GB > SD card) with the kernel and bootloaders on a vFAT partition and the RootFS on EXT4 all ready to write onto an SD and boot the unit.

Some more work is needed to clean up the recipes, fix a few bits and currently there is no support for the GPU libraries (coming as soon as I clean up some of the more obvious hacks and get confirmation of licence and redistribution terms). But you can already use this layer to boot an Angstrom (my OE based distribution of choice) console image or some of the more interesting image flavours (Xfce/E17 etc.) up on actual hardware.

Just don’t expect everything to work yet, ok, being honest don’t expect a lot to work yet!

Building OpenEmbedded/Angstrom packages for the RaspberryPi

If your interested in trying this (and assuming your familiar with OpenEmbedded-Core and have a build setup) you can just add the meta-raspberrypi layer (git@github.com:djwillis/meta-raspberrypi.git) to your build setup and use MACHINE = "raspberrypi" in your local.conf.

If you have never tried building an operating system from scratch using OpenEmbedded/Angstrom you can find a really good guide on the Angstrom site. With a few little tweaks you can get a build going in no time (just be prepaired to use a LOT of disk space and waiting many hours for it all to build, not to mention having to deal with the odd snags that come along).

Following the above guide if you change:

git clone git://github.com/Angstrom-distribution/setup-scripts.git

to

git clone git://github.com/djwillis/setup-scripts.git

This will ensure you grab a fork of the setup scripts with the RaspberryPi layer already added.

Then if you proceed to use ‘raspberrypi’ as the machine you should be off the starting blocks and on the journey to getting something built.

What happens next?

Once things have settled down a little and the GPU libraries are all working my aim is to get the meta-raspberrypi layer into a state that can be included by default in the upstream Angstrom distribution. That would bring lots of nice benefits like ARMv6 and RaspberryPi optimised software feeds and use of the Angstrom online image builder to put RaspberryPi images together.

I’ll also find a way, if I can, to distribute images all setup with binaries for the GPU and ready to go. People can then grab it and write to an SD just like other distributions.

It would be great to get some input into this as it is just something I have been hacking on in my (limited) free time for a while, if anyone wants to help with this work this please fork and send over pull requests.

Regards,

John

ScummVM: ‘GIT 6b8fb196-pre1.4.0’ builds for GPH devices (GP2XWiz and Caanoo)

Edit: These builds are now outdated and people should try the official 1.4.1 releases on www.scummvm.org.

Most interested people will have realised that my ScummVM backends (GP2X, Wiz, Caanoo and OpenPandora) missed the entire 1.3.* release cycle leaving the official releases stuck back in the old 1.2.* cycle.

There are a number of reasons for this (all my fault) but rather than dwell, lets just say I am trying to get them all back into shape for future releases. With that in mind I am going to start doing test ‘point in time’ builds of the code for various devices when things reach a point that I would like some community testing done.

The first of these test releases is for the GP2XWiz and Caanoo. The GP2X build will follow once I nail the last annoying little input bug that is causing the cursor to go off for a wonder on it’s own Winking smile(simple bug I am sure but you know how it is when you stare at something). Then I will turn to fixing up the OpenPandora backend.

They have been built from the main ScummVM GIT (Revision:  6b8fb196cbd58e20ef57bf367d5ecbf0ee2ebdad).

These builds exist purely to get some feedback and testing from the community so I can try and get a good solid release done when we get into the next official ScummVM release cycle.

If your not interested in testing and providing feedback (and dealing with the odd issue) please stick with the old 1.2.* releases. These are not robust, fully tested release builds but I am also pretty sure they will not eat or damage your GPH device.

Note: Please don’t mirror or hotlink these preview/test/alpha etc. releases or put them on download services but rather, direct people to this page.

This helps me ensure that users always have the most recent versions and cuts down on me being requested to support ancient releases.

Also note that these test releases are not officially (or unofficially) supported Winking smile.

They are built from the new unified ScummVM backend for all the GPH devices (to make supporting them somewhat easier for me and to cut out the rot that had set into the old dedicated stand alone GP2X backend).

All the engines enabled in configure are included in this build but I make no promises about the usability of any WIP game engine.

Continue reading

Installing Windows 8 Preview on the HTC Shift

The HTC Shift is a wonderful anachronism left over from the results of earlier HTC and Microsoft love-ins, flirting with touchscreens, neat hybrid form factors and ULV CPU’s. It’s origins lie in hardware that was created to run the ill-fated Origami platform on top of Vista. That combined with a Windows Mobile 5/6 device (on the ARM side) managing a 3G connection and low power access to mails, contacts and the like made for one very interesting bit of hardware.

I have been happily using the Shift for a few years now (since a good friend kindly passed it on to me) with various Windows and Linux setups (on both the ARM and x86 side).

But in fairness I have been using it less and less of late. As it feels that the Origami work is spiritually being dusted off and rolled into Windows 8 with the healthy dose of the Metro design language and friends it seemed only right to dust off the venerable old Shift and see how it coped with the latest software incarnation.

No part of this process is very complicated, it mostly came down to installing the right drivers in the right order Winking smile, just read the post and follow each point and you should not go far wrong.

Read this: Please make sure….

  • You are 100% happy to totally wipe the Shift’s HDD. Don’t bother with an upgrade from Windows 7. Not worth the hassle!
  • You don’t mind manually reinstalling Windows Vista or Windows 7 when you decide 8 is not for you.
  • You are signed up on XDA Developers Winking smile
  • You are well aware you are installing an unsupported pre-beta bit of software on your device, and the device is under MS’s recommended minimum specs. The chances are it will not work well! But it’s fun to try.
  • You understand not all the hardware is 100% supported and there may be driver issues.
  • You have removed any external storage from the device other than the USB stick (no SD card inserted, no random USB HDD connected etc.).
  • You have enabled WiFi using the Shift Control Panel before you start the install inside the old OS. If you don’t you may need to have a USB Ethernet adaptor before you can enable WiFi to get on the internet.

Continue reading

ScummVM: “1.2.1 – Børk Børk Børk release”.

It’s been a hectic few weeks but I finally had time to get the 1.2.1 builds uploaded for my all backends following the main Dec. 19th release. Sorry about the delay Winking smile.

The 1.2.1 release is mainly a bugfix and cleanup release for 1.2.0 and also introduces some additional translations of the GUI.

There are few changes to my backend code but all the core changes are rolled in.

Oh, I also just noticed the date so “Happy New Year” everybody.
Maybe I should try and find more hacking time in 2011 Open-mouthed smile.

Providing feedback:

If you would like me to consider a feature or fix a bug in my backends help me to help you by ensuring the reports end up recorded in official places.

Downloads:

All the 1.2.1 releases including my GP2X/GP2XWiz/Caanoo and OpenPandora backends can me found on the main ScummVM download site.

    • ScummVM’s Main Download Page: download

ScummVM: “1.2.0 – FaSCInating release”.

This post is a few days late but as all my releases are now uploaded and available I thought it was work announcing the release.

The entire ScummVM team is rather proud of this release and you can read the official announcement here. One of the major ‘headline features’ is that this is the first release to feature the fruits of the integration/refactoring of the FreeSCI codebase and it’s substantual enhancement and extension by our own SCI engine team.

There are also enhancements for several engines and the addition of support for “Fascination” (An amusing risqué point and click adventure from Coktel) in the Gob engine.

From my point of view the 1.2.0 release marks the 1st official release of 2 new device backends/ports I have put together (GPH Caanoo and OpenPandora) and also features quite a few enhancements and speedups to my existing GP2X and GP2XWiz backends.

It also marks the official release of new backends for Android and Dingux and the unfortunate retirement of the venerable old PalmOS backend.

The upshot is that this should be our best release yet and I would certainly recommend this release over any older versions of ScummVM for the devices I support.

Continue reading

OpenPandora: Using custom cursors in fullscreen X11 SDL windows without touchscreen drifting/grabbing issues.

Note: This is is quick guide aimed at developers/porters looking to fix issues with custom SDL cursors (Cursors made up using an SDL_Surface) and the OpenPandora touchscreen, if your not using SDL then the chances are your not seeing the issue.

Normally I would not put together quick posts with small code snippets (I tend to direct people to code and tell them to work it out Winking smile) but as several people pointed out to me recently ScummVM for the OpenPandora works around a ‘feature’ in the SDL build on the device that causes relative screen coordinates to be returned to the event stack when you hit the screen edges with the touchscreen. In essence this is a code fix for the ‘cursor drift’ bug people report.

Nubs, mice, in fact any relative input device are fine, it is absolute input devices like the touchscreen that ‘drift’ and end up offset making some types of application unusable with the touchscreen (ScummVM was one of them).

As the same issue seems to cause problems several other applications on the OpenPandora I thought I would do a quick howto with a work around and give a little background on the issue.

Continue reading

ScummVM: “1.2.0 preview 1” for the OpenPandora.

EDIT: This release has been superseded, please get the latest release.

This post is to announce the release of a testing preview of the upcoming 1.2.0 ScummVM release for the OpenPandora handheld.

It is a little later (and a bit close to the final 1.2.0 release date) than I would have liked but that’s real life for you, always getting in the way of perfectly good hacking time Sad smile.

This release supersedes any recent ‘SVN’ builds you may be using and should provide a very good indication of what to expect in the final 1.2.0 release for the OpenPandora.

Note: Please don’t mirror or hotlink these preview/test/alpha etc. releases or put them on download services but rather, direct people to this site.

This helps me ensure that users always have the most recent versions.

Also note that these test releases are not officially (or unofficially) supported Winking smilebut I will help if I can.

I am hoping to get at least another preview release out for the OpenPandora before the final 1.2.0 release as I carry on fixing bugs. This is why it is important to provide feedback, patches, fixes etc.

Please give these releases a go and provide feedback.

Noteworthy features:

Continue reading

ScummVM: “1.2.0 preview 1” for GPH devices (GP2X, Caanoo & GP2X Wiz).

EDIT: This release has been superseded, please get the latest release.

This post is to announce the release of a testing preview of the upcoming 1.2.0 ScummVM release for the GPH (GamePark Holdings) devices I support.

This release supersedes recent ‘SVN’ builds as should provide a very good indication of what to expect in the final 1.2.0 release.

Note: Please don’t mirror or hotlink these preview/test/alpha etc. releases or put them on download services but rather, direct people to this site.

This helps me ensure that users always have the most recent versions.

Also note that these test releases are not officially (or unofficially) supported Winking smilebut I will help if I can.

I am hoping to get at least another preview release out for the GPH devices before the final 1.2.0 release as I carry on fixing bugs. This is why it is important to provide feedback, patches, fixes etc.

Please give these releases a go and provide feedback.

Noteworthy features:

Below are the main features and fixes added with this new release.

ALL:

Changes to the way the music drivers are loaded (should fix game loading issues).

Performance improvements.

Add support for TouchScreen ‘Tap Modes’, Left Click, Right Click and Hover.

GP2X:

Performance tweaks/code clean-up (quite noticeable in some areas, not giving up on the old GP2X any time soon).

Revised the button layout (please read http://wiki.scummvm.org/index.php?title=GP2X for more info), feedback on the button layouts is appreciated.

GP2X Wiz:

Fixes to 16 bit graphics support (still not sure this is 100% working well).

Revised the button layout (please read http://wiki.scummvm.org/index.php?title=GP2XWiz for more info), feedback on the button layouts is appreciated.

Caanoo:

Revised the button layout (please read http://wiki.scummvm.org/index.php?title=Caanoo for more info), feedback on the button layouts is appreciated.

TODO List:

ALL:

Add support for a ‘Left Handed Mode’ (swapping the Left and Right trigger behaviour).

Make the ‘Trigger Tap’ configurable by the user.

Anything on the TODO may not happen in time for the 1.2.0 release, it is all rather dependent on my free time and that is at a premium at the moment.

Continue reading

ScummVM: “SVN r52631” builds for the Caanoo and GP2X Wiz.

EDIT: This release has been superseded, please get the latest release.

This is just a quick post is to announce a new set of SVN builds of ScummVM mainline code for the GP2X Wiz and new Caanoo.

Note: Please don’t mirror or hotlink these preview/test/alpha etc. releases or put them on download services but rather, direct people to this site.

This helps me ensure that users always have the most recent versions.

Also note that these test releases are not officially (or unofficially) supported Winking smilebut I will help if I can.

This release is mainly to give users a chance to preview updates to some of my ScummVM backends and try a bug fixed version of the Caanoo port with working controls. They are not by any means bug free.

All of my backends will get further preview/test releases before the 1.2.0 release as I carry on fixing bugs.

These releases are built straight from the mainline trunk ScummVM code for the given SVN revision number.

OpenPandora and original GP2X ScummVM SVN releases should be ready late next week (very busy with work at the moment). The GP2X code is being merged in with the Wiz and Caanoo to create a GPH backend so expect the GP2X to get all the new features from it’s siblings. The OpenPandora code has now been merged into ScummVM but is still in need of a lot of bug fixing.

Please give these releases a go and provide feedback.

Continue reading

ScummVM: “SVN r52440” builds for the Caanoo and GP2X Wiz.

“Edit 07/09/2010: These builds have been superseded. Please get the latest ones.”

This is just a quick post is to announce a set of SVN builds of ScummVM mainline code for the GP2X Wiz and new Caanoo,.

“Edit 05/09/2010: Thanks for the feedback on the control issues on the Caanoo release, a fix is in the works.”

This release is mainly to support SCI testing and give users a chance to preview updates to some of my ScummVM backends.

These releases are build straight from the mainline trunk ScummVM code for the given SVN revision number.

An OpenPandora and original GP2X ScummVM SVN release should follow next week(ish). Been a little busy to track down some bugs in them.

Note: Please don’t mirror or hotlink these preview/test/alpha etc. releases or put them on download services but rather, direct people to this page.

This helps me ensure that users always have the most recent versions.

Also note that these test releases are not officially (or unofficially) supported Winking smile.

Please give these releases a go and provide feedback.

Continue reading

The web log of a meandering nobody…