This software is not supported or endorsed by OpenPeak or O2. Use at your own risk.
Towards the end of April 2012, something rather unprecedented happened over on the Joggler Forums. It appeared that we were being linked to by O2 themselves as the point of contact after they discontinued their support for the device. After some negotiation, the forum was provided with a ‘sunset’ build of the OpenPeak OS for the OpenFrame 1, on which the Joggler is based.
It’s rare that a company bows out from a device so graciously, effectively opening up the platform to enthusiasts to continue developing and supporting. They could have locked the device down, but they chose not to, and they deserve recognition for that.
The final release, version 30291, did come with a few minor hiccups; but most of those were ironed out pretty quickly. However, under the hood a couple of things had changed. Firstly, the standby partition was no longer used. Designed to recover the Joggler in the event of system problem (although it rarely worked in reality), this left a quarter of the flash memory wasted and empty in a separate partition. Secondly, automated updates and installations from USB sticks were disabled. And, for the paranoid, the OpenPeak update system was still live and potentially able to lock the devices down should somebody change their mind.
Because of this, I decided to do a little ‘tidy’ of the OpenPeak firmware image. What I’ve done is to take the final release of the OpenPeak firmware and make a few tweaks, re-versioning it as 30300.
This is what has changed:
Removed the empty backup partition (mmcblk0p3).
Allocated the recovered space to the /media partition (mmcblk0p4).
Disabled firmware updates from OpenPeak.
Enabled SSH and SCP by default.
Added ‘setpasswd’ command for easily changing the default password.
Enabled the ‘update from USB stick’ feature that was removed.
A mere six years later, I’ve revisited the image and made another tweak, producing version 30301.
Following the shutdown of OpenPeak’s servers, OpenFrames have been calling out into the wild for updates and config files, receiving no response. With the ownership of openpeak.net now uncertain, open for purchase by anybody, it seemed sensible to redirect these calls in the hope that we might one day be able to push EFI updates to locked-down devices. This represents the only way that OpenFrame 2 devices with locked EFI firmware can be unlocked, without flashing and replacing the soldered EFI chip.
There’s no timescale for this happening, but it at least opens the possibility. Definitely keep an eye on the Joggler Wiki Forum for updates and if you can help provide a server response that the OpenFrame will understand.
Because I’d not be able to afford the asking price for openpeak.net, and because binaries can’t be modified in size without breaking them, I’ve opted instead for openbeak.net. There’s a pun in there, if you look hard enough.
Other than these alterations, everything else is the same as the 30291 version.
So, please give it a try if it seems interesting and let me know how it performs for you!
To install Version 30300 on your Joggler, download the .img.gz and accompanying MD5 checksum file from the links above. Then follow the instructions on the Reflashing Tool pages to make your reflash device.
In Part 2: Add the Script or Firmware Image, follow the instructions for Flashing an Alternative OS.
Once the image has been checked, it will be flashed to your Jogglers’ internal memory. You cannot run the OpenPeak OS from a USB stick. It’s just not written to support that.
It should go without saying that doing this will reset everything on your Joggler to defaults, including the NVRAM and the contents of your /media area.
Make sure you’ve backed up your files!
You don’t need to read this unless you’re planning on messing with the system yourself!
Layout of the MMC
Reorganisation of the MMC device was achieved by removing /dev/mmcblk0p3 and resizing /dev/mmcblk0p4 to use the freed space. This has the side effect of retaining the original partition numbering, which will hopefully alleviate any troubles with software trying to talk directly to /dev/mmcblk0p4 (which would otherwise have disappeared). Code relating to the ‘standbyfs’ partition has been commented out.
Disk /dev/mmcblk0: 1028 MB, 1028128768 bytes
4 heads, 16 sectors/track, 31376 cylinders, total 2008064 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00065065
Device Boot Start End Blocks Id System
/dev/mmcblk0p1 * 16 125055 62520 ef EFI (FAT-12/16/32)
/dev/mmcblk0p2 125056 625151 250048 83 Linux
/dev/mmcblk0p4 626688 2007039 690176 83 Linux
The ‘local update’ feature, which allows payloads on USB sticks to be handled on boot, has been re-enabled by the inclusion of an empty /etc/.usb-key file. This file would normally be used as a simple signing system to determine that an update is official; by using a zero-byte file, a matching MD5 for the opupdt.tgz payload is sufficient to commence installation.
However, there were some changes to the mechanism between 26635 and 30291. The 30291 version is more secure, running the opupdt.run script that is extracted from the checksummed payload, rather than one that is simply sat on the USB stick root. If you are targeting both 26635 and 30xxx versions, you need to supply a working script within the payload and a ‘dummy’ script for 26635 in the USB root that executes it.
You will also need to provide two checksum files on the USB stick; one for each OS version. I’m sure you’ll be happy to hear that I’ve made this part a little easier, though. This gensum.sh script and keyfile will do the work for you.