At a distance of some 18 months from last time I looked at this hardware, an element of self-congratulation is not entirely inappropriate inasmuch as the preceding entries in this blog have enabled me to get it working again without lost of life or significant personal injury.  The process would have been faster, though, if I had additionally noted these points

• minicom -D /dev/ttyUSB0
• stty -crtscts < /dev/ttyUSB0
• configuring it to boot with "init=/bin/sh" is fine as far as it goes but does not go far enough that it loads the audio modules or /proc or udev.  Remove that and have it do the whole init thing
• (not entirely related but) sometime since I installed this laptop Debian have changed from portmap to rpcbind, and getting a running nfs server is unnecessarily hard work when both are running at once.
• the current version of minipod is hardcoded to look for music in /mnt, which directory is empty until something is mounted there.

 

That's right, we have volume controls.

They're a bit slow and unfriendly right now, because we only call event handlers on button release so there's no possibility of a "drag" action. That's a trick for another day

It's not actually pretty in any conventionally recognised sense of the term, but it has a squirly waveform display (which, by the way, takes more CPU to draw than the wma does to decode...) that I quite like

After a little time playing with vlc I decided it was just Too Damn Big to learn my way around quickly, so I spent a couple of evenings ripping the Rockbox WMA codec out of its setting and making it build on a Linux host.  And now it plays music :-)  (Well, if you count Sneaker Pimps as music, anyway.  But I do).

WMA decoding uses 30% of CPU if built with gcc -g and the default optimization settings, slightly under 20% with -O3.  It'll do.

There is going to be a lot of refactoring in the near future, I can tell already.

 

I eventually settled on libmad to decode mp3s, which it does with less than 20% of the CPU, and libao to send them to the sound output.  WMA files are going to be trickier because an ARM 920T  doesn't quite have the CPU power to play them in realtime - so I need to find a WMA decoder that doesn't use floating point.  There's one in rockbox (and now also in vlc), so it just depends which variant of the code will prove easier to standaloneise.

SDL doesn't want to listen to the touchscreen (well, it does, but the pointer flickers all over the place).  I installed the tslib programs to calibrate the screen and find out why, and in the process noticed thanks to ts_test that writing directly to /dev/fb0 is really not that much work.  So, ditched SDL too.

A quick cut & shut job on madplay.c and ts_test.c has now given me a program that displays a file list on screen and lets me point to one of them to have it play.  Before I start breaking it again in the interest of making it less ugly, this would be a good time to introduce version control.

No photo with this post, it's visually not at all impressive.  Have a github link, though: http://github.com/telent/minipod .  Did I say it was ugly?

Still to do (or to find volunteers for)

• wire up external switches for the rider's remote control
• on-screen UI for seek/pause/volume etc
• prettify code, prettify UI
• mounting it onto the bike
• power supply
• make it automount usb sticks on insertion (and cope gracefully when they're removed unexpectedly)
• other formats than mp3 (WMA is pretty much a requirement, FLAC would be nice)
• make it boot from sd card and start minipod on boot

 

 

I approximately followed the instructions at
http://code.google.com/p/mini2440/wiki/MiniBringup
and
http://code.google.com/p/mini2440/downloads/detail?name=mini2440-bootstrap-v2.sh

1) Download u-boot from the friendlyarm.net downloads page, install to nand flash as per http://code.google.com/p/mini2440/wiki/MiniBringup

- note that the supervivi on this board doesn't have xmodem, so use usbpush (from friendlyarm.net site: compilation procedure was fairly obvious) to get u-boot into the system

2) Get a cross-compiler toolchain running. I used emdebian and suggest you do too as apt-cross is awesome

http://code.google.com/p/mini2440/wiki/EmdebianCross

$ apt-get install emdebian-tools
$ apt-cross -a armel -i libc6-dev
$ apt-cross -a armel -i gcc
$ apt-cross -a armel -i g++-4.4
$ sudo apt-get install gcc-4.4-arm-linux-gnueabi

3) Now you can rebuild u-boot, or at least enough of it to get the mkimage command you'll need for a kernel image

# get sources from git repositories linked from http://code.google.com/p/mini2440/
$ CC="arm-linux-gnueabi-gcc -march=armv4t -mtune=arm920t"
$ export CC
$ cd mini2440/
$ make distclean
$ make mini2440_config
$ make tools
$ cp tools/mkimage /usr/local/bin/mkimage

4) build the kernel according to mini2440-bootstrap-v2.sh

$ cd kernel/mini2440
$
$ make ARCH=arm mrproper
$ make ARCH=arm mini2440_defconfig
$ make ARCH=arm
$ make ARCH=arm modules
$ make ARCH=arm uImage

The output from this is arch/arm/boot/uImage - put it in your tftproot

5) now build the root fs thus: http://code.google.com/p/mini2440/wiki/Emdebian

I can't make it find root on mmc yet, so I'm booting nfsroot instead.

MINI2440 # setenv bootfile uImage
MINI2440 # setenv bootargs console=ttySAC0,115200 noinitrd root=/dev/nfs nfsroot=192.168.1.2:/big/nfsroot/2440 rootwait=4 rw ip=dhcp init=/bin/sh
MINI2440 # saveenv
MINI2440 # tftp ; bootm

6) there you are. Don't forget the second stage install as part of step 5.

7) How to make the screen do anything. After unpleasant experiences with directfb

• the example programs are in an html page and can't be cleanly cut & pasted
• the emdebian version is 1.0 which is too old to easily cross-compile when the normal debian version is 1.2

I wrote a program using SDL to show something on the screen. Output pictured.

Or at least, the bootloader now loads the kernel (tftp). Kernel can't find its root fs yet though ...

Pictured next to a light switch to give you an idea of scale.

Thry've sent the windows version not the linux one, so figuring out how to reinstall will be the first job