After several months of actively developing with Sprinkles I think it’s time to make a tag and call it a version. I’ve still got far to go in terms of documentation but with Cloudbees free Jenkins instance I have a build running with JUnit and Javadocs available. I’ve also created a recipe for OpenEmbedded so embedded devices can also taste the functional fruits in Java. Oh, and Sprinkles exports its package just like a good OSGi bundle should!
I have quite a few ARM-based devices in my office. Some are for work, others are for fun. One good thing about these little machines is that there is always room for one more. A few days back I received the Dreamplug I ordered back in February. It runs Ubuntu 9.10 out-of-the-box and sets itself up as a Wifi access point for easy connections. This is a big improvement over the original beagleboard and other boards that expect the user to choose and burn a distro on an SD card before using the device. I was able to connect the Dreamplug to the wall and ssh into the machine in a matter of minutes. And being that it’s Ubuntu, which is a distro I am familiar with, I felt right at home. Overall my impressions of the device are good. The plastics are solid and the design is clean. What attracted me to the Dreamplug however was some unique I/O it offers. One problem with common ARM-based boards like the Beagleboard is that the USB/SD interface for storage is pretty slow. This limits it’s utility when considering applications that require speedy file access. I am currently using it to play music over the network, but I’d like to have some fast local storage to speed things up, and be able to play music without ethernet attachements. Since the Dreamplug has built-in eSata, optical audio out, and wifi, it seems almost perfect for my application.
I have yet to test the eSata and optical out. The wifi seems to work as advertised. The base Ubuntu install is customized with a Globaltechnologies-developed wireless access point application that seems to handle the incoming connections. I wanted to do away with this and just work wired initially, so I deleted the start script in /root that is run on boot. I also opened up the device to get at the internal SD card. To be honest, I bricked it early on when trying to change the subnet that the wireless network uses, as it conflicts with my internal network. I was ultimately unsuccessful in changing this and decided just to stick with wired networking for now.
I also have a Dreamplug ancestor , the SheevaPlug. This device is superior to the SheevaPlug in every way. The design is better and the machine itself is bigger and faster. And, except for video, pretty much all I/O options are covered for a device of this nature.
I may post more info about this device as I become more familiar with it. Here are some photos of the Dreamplug.
The box
USB, optical audio, JTAG, serial, reset, ethernet ports. iPhone 3GS stacked on top.
Audio in/out, eSata, SD, and USB
Top of Dreamplug with iPhone 3GS for size comparison.
Power adapter. Note how the device does not sit flat on desk when power adapter is used.
Another shot with iPhone to show thickness.
Innovative! The power supply is detachable. Unfortunately the cable is too short to be of much use.
Internals. Note the microSD card on the separate board. Just the standard FAT/Ext3 kernel/rootfs partition scheme.
Closeup of the top of the board.
Bottom of the board.
Power supply options.
While the BUG 2.0 hardware platform is the shiney new toy everyone wants/NEEEDS, what can we say about our trusty BUG 1.x devices sitting around? I think they are in need of some love, and as a community effort, have released some alpha-level builds of BUG 2.0 software for BUG 1.x hardware. The project is called leafcutter, and the idea is that your BUG 1.3 device should be able to run all the BUGapps that your 2.0 device does, assuming you have the necessary modules. The main work involved in this is migrating from the legacy Poky 3.0 build system to the OpenEmbedded 2011-stable build system. The result of this migration means:
I’m planning on having Dragonfly SDK support available, so development is seemless between hardware versions. Have a look at the project page to see the current state of things. Since this is not an official Bug Labs project, the sources are being hosted at Gitorious instead of the Bug Labs GitHub repo. While the project is in an early stage, the basic Linux environment and OpenJDK JVM are currently working. Depending on your needs, this may already be enough for some users to migrate.
And as a community-hosted project, everyone is welcome to contribute! Areas that need attention:
The start page has all the details regarding building and getting access to ready-to-install binaries.
I seem to have ascended to that (low) level of Git aptitude that makes me want to stick any old thing into a git repository. Namely, the “dotfiles” or things that live in my home directory that tend to follow me around from machine to machine. There are various established ways of doing this, including symlinks and scripts. Due to Git not permitting the cloning of a repo into a non-empty directory, the process becomes more complex that it should be. After an hour of bungling, my approach has become:
1) My central repo is not public (aka github). So, I don’t need to worry about stray personal info being accentially dangled in front of the world.
2) No scripts or symlinks, the home dir is the repo.
My process:
1) On the new machine/account, get my ssh keys on there stat.
2) git clone <secret git repo>/homedir && cp -r homedir/* . && cp -r homedir/.* .
3) rm -Rf homedir
4) log out/back in for freshness
Poof, that’s all. Then, when inspiration strikes and I update one of my little treasures, the ol’ git push ‘n pull gets all my accounts synced up.
I have grumbled from time to time about Google’s Android platform and porting docs being out of date many times in the past. It can be frustrating to be toiling away on some subsystem/makefile/API only to later find out that it no longer works that way. However, Google pulling the whole thing from the web replacing it with a vague message saying something better will come someday is not a step in the right direction. Hopefully that someday is soon. In the meantime I’ve scraped the cache for reference:
Building native applications for BUG requires a toolchain configured for the specific hardware architecture, as well as all the development libraries your application may require. Poky, the build system used for the BUG 1.x line of devices, provides these tools and libraries as part of the meta-toolchain package. For convienence, this toolchain is provided as a download for x86-64 machines so that one doesn’t have to build all of it from scratch. Here are quick instructions on how to use the toolchain. I’m assuming you have a simple C program to test with. Mine prints helloworld and exits.
# cd /
# wget http://bugcommunity.com/downloads/files/poky-sdk/poky-eabi-glibc-x86_64-arm-toolchain-1.4.3.tar.bz2
# wget http://bugcommunity.com/downloads/files/poky-sdk/poky-eabi-glibc-x86_64-arm-toolchain-1.4.3-extras.tar.bz2
# tar xfj poky-eabi-glibc-x86_64-arm-toolchain-1.4.3.tar.bz2
# tar xfj poky-eabi-glibc-x86_64-arm-toolchain-1.4.3-extras.tar.bz2
# cd /usr/local/poky
# source eabi-glibc/arm/environment-setup
arm-poky-linux-gnueabi-gcc test.c -o test
# file test
test: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.10, not stripped
# scp test [BUGIP]:
# ssh root@bug
root@BUG:~# ./test
Hello world!
As described in the Poky handbook, the toolchain-sdk package provides development libraries for packages that are by default shipped on the BUG 1.x device. For those wishing to build the tools themselves, I had to make two minor changes to Poky to build meta-toolchain on Ubuntu 10.10 x86-64. The patch for those changes is here.
When we first started working on getting Android on BUG with Tarent last year, my right brain was happy and excited. I love learning new things. And after all, Android is a fun, creative new platform for application development.
But my left brain had some doubts. How will BMI and other unique hardware BUG features work? What about our existing APIs and applications? How can we maintain two seperate software platforms?
But recently my left brain has changed it’s tune. Things are really starting to come together. Tarent did a great job of providing a solid base Froyo build that we are now busily polishing and tuning for BUG 2.0 hardware. Android was designed for mobile devices, so the user experience has a lot of potential. And while we certainly don’t have all the answers, it is clear that with BUG we can take Android application develepment to whole new domains.
So if your left (or right) brain is looking like mine, have a look at the Android for BUG 2.0 start page on GitHub. Heck maybe even download a build and take it for a spin. If you’re interested to see what we’re actively working on, take a look at the issues. And by all means, if you see something you can fix yourself, have at it!
I recently purchased an Android tablet for comparison for Android development on BUG. The tablet ships with a very spartan install of stock Android 2.2, without any applications or marketplace. I’ve been able to install APKs from the web from sites of dubious repute. Here is some information gleaned from ADB:
<5>[ 0.000000] Linux version 2.6.32.9 (xmhzj@tablet-server) (gcc version 4.4.0 (GCC) ) #2 SMP PREEMPT Sat Dec 4 11:06:51 CST 2010<4>[ 0.000000] CPU: ARMv7 Processor [411fc090] revision 0 (ARMv7), cr=10c53c7f<4>[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache<4>[ 0.000000] Machine: NVIDIA Harmony Development System
<5>[ 0.000000] Kernel command line: mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=ttyS0,115200n8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=78dbcd131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),204800K@96000K(system),222464K@301312K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)
Build: harmony-eng 2.2 FRF91 eng.xmhzj.20101204.100011 test-keysBootloader: unknownRadio: unknownNetwork: (unknown)Kernel: Linux version 2.6.32.9 (xmhzj@tablet-server) (gcc version 4.4.0 (GCC) ) #2 SMP PREEMPT Sat Dec 4 11:06:51 CST 2010Command line: mem=448M@0M nvmem=64M@448M vmalloc=192M video=tegrafb console=ttyS0,115200n8 usbcore.old_scheme_first=1 cpuid=200102 devicetype=1002 btmac=78dbcd131a00 tegraboot=nand mtdparts=tegra_nand:16384K@12032K(misc),16384K@62208K(recovery),16384K@79104K(boot),204800K@96000K(system),222464K@301312K(cache),4096K@7424K(bootbmp),32768K@28928K(logodata)
Other info:
Support page: http://pc-support.jp.onkyo.com/pds/manual_list.aspx?pc=0300980000001
Shell to Linux Bridge has a new feature and a tweak. The tweak is no log output for socket errors. I often run multiple instances of eclipse and don’t want to sort through these messages when I’m looking for something else. The feature is a “project mode” in which, an Eclipse project is generated for a given directory. This can be handy for evaluating a new package, or simply browsing some source files that are not apart of a formal, language-oriented project in your workspace. With my netcat-based client, I type from the terminal:
$ steb -p /tmp/myproject
And steb picks this up, creates a new general project named “myproject”, and recursively adds all child files and folders. Be careful when removing these projects from Eclipse, if you elect to have Eclipse delete the files…that’s exactly what it will do!
As always the updatesite is: http://angelshare.org/org.steb.updatesite
The steb client shell script is available at: http://angelshare.org/org.steb.updatesite/steb
I recently got a request for a diagram of the BUGapp lifecycle. “What a great opportunity to hone my n00bean InkScape skills!”, I thought. So, here is my take on the creation and descruction from the perspective of a BUGapp:
Ken's Digital Den 