I was actually thinking that it might make more sense to enable module support in the kernel. IIRC, doing that doesn't increase overhead (until you insert modules, obviously). That way, people could add FAT support or anything else, just by having a new module made, rather than having to distribute a whole new kernel.

Am attaching the date binary. Don't remember where I dug it up, but there's been posted pointers to various tar-balls of utilities.

If nowhere else there's the debian arm distribution http://www.debian.org - just got to figure out which .deb file the wanted binary lives in...

I'm more than willing to compile a new kernel and modules for anybody that wants it but you'll have to test anything yourselves because I probably won't have the necessary hardware.

Might be an idea to ask Mark to turn on module support in his prebuilt kernels. If not I'll do them.

- Trevor

Looks like it adds about 32k to the compressed kernel, so it's not insubstantial. More reason for modules I believe although that will add some overhead.

What was the kernel size limit again? The empeg only has 1MB of flash all up remember

At first glance, module support would appear to make sense, but I have been thinking about it some more, and I suspect that it isn't worth it:

1) We'd have to define where the modules were kept on the filesystem. IIRC, they are usually in /lib/modules/version. This would have to live on a disk partition as it's size would be indeterminate, so a custom mount would be required. This isn't a big issue, but it'd be a pain to set up.

2) We'd also need the necessary modutils. insmod, which is symlinked by lsmod,rmmod and modprobe is 94k. This could probably live ok on the disc partition too, as long as it wasn't needed before pre-init. We'd also need /etc/modules.conf and /lib/modules/version/modules.dep (about 56k on my system, but it is build specific I believe)

3) What else do we really need in the kernel? I can't see any need for any other filesystem support - ext2 and FAT should cover it. Even if people are using the IDE bus in unexpected ways (eg this compactflash idea - way cool), chances are that anything they plug into it is going to be either ext2 or FAT. Maybe it'd be nice to have ext3 with it's journalling capabilites, but AFAIK this is only available in the 2.4.x linux trees, and hasn't been back-ported.
As for hardware, there isn't anywhere to plug any traditional hardware into. No PCI, no parallel, no USB master, no VESA, no AGP etc. All the current hardware (serial, LAN, USB slave, display board etc) is already controlled by the kernel anyway, so there's nothing to add here.
What does that leave that we might want?

just got to figure out which .deb file the wanted binary lives in...

Here's what I do:

1. Go to http://www.debian.org/distrib/packages
2. At the bottom of the page is the search window.
3. Type your binary name (e.g. 'date') into the "Search the contents" window.
4. Hit "Search". The results come back.
5. Top of the list, in this case, is bin/date, in base/shellutils

Now, if you click on the "base/shellutils" link, it'll take you to a page summarising dependencies, etc. Take a look at it. However, from here, it'll probably take you to x86 binaries. We want ARM binaries, so...

6. Go to http://http.us.debian.org/debian/dists/stable/main/binary-arm/
7. Click on (in this example) "base"
8. Grab the "shellutils_version.deb" file.

This is the .deb file containing the binary files we wanted (and probably more besides).

Now, to unpack the file, you'll either need a copy of 'ar' on your player, or a Linux/Cygwin installation handy:

1. ar p file.deb data.tar.gz > file.tar.gz
2. Send this file to the empeg (either using Hijack or ZModem). I generally put the .tar.gz files into /drive0, so that they're not overwritten by an upgrade.
3. Unpack it into the root.

Presto, a copy of date for your empeg.

Module support chews up a fair amount of RAM to hold the kernel exported symbol table. Dunno how much bigger that makes it.. maybe 64KBytes or so. I'd rather use that space as a music buffer.

By comparism, almost all of Hijack currently fits into about 64KB.

Cheers

Fair enough. Misinformation on my part.

This thing you're working on is pretty exciting. Is it possible to get one of those Flash Card interfaced IBM Microdrives and use it as a "Music Keg for the Empeg" ? :-)

Calvin

It would be interesting for those who want a small area to record things to with the microphone input, or for capturing live radio clips (albeit pretty short ones). Leaving a piece of flash RW would't seem to be as problematic as leaving a HD read-write. At least from the layman's point of view (i.e. mine).

Just a thought.

-Zeke

Well, just keep in mind that, contrary to common opinion, the Empeg's drives are "read write" the entire time they are running.. and the Empeg player software does write to them on the fly for shuffle lists, equalizer settings, and the INFO-SEEK tool data.

Pretty safe on the whole. I think sudden powerfail to a compactflash device is way more dangerous.

-ml

I sit corrected! I guess needing to set the drives RO at the end of terminal sessions led me to that belief. I'm a bit of a luddite on these matters...

-Zeke

Hi everyone

Again - thanks for all your help with my project.
Product support like this can't be beaten
Here's an update on the project:

I have now written the first (very raw) version of my script, which checks the existence of the CF card after boot (run via a preinit script), and then just copies its entire content to a directory under /drive0/images with the name YYYYMMDD-HHMMSS.

This way I get a complete backup of the CF card everytime i boot the Empeg.

The script then writes the current status of the "imagebank" and updates the log - all in a file called "statuslog".
I can the read this logfile using John Heathco's Viewer application - run from the Hijack menu.
The logfile looks something like this:

-------- status --------
Empeg currently holds:
images: 34
movies: 0
size: 16M
--------- log ----------
25 Apr 14:53
copied 13 img & 0 mov
24 Apr 17:21
copied 21 img & 0 mov

I made a directory called /cfcopy for the logfiles, this then has a subdirectory /cfcopy/images which is a link to /drive0/images.

Heres the script (first version - not necessarily well written ):

#!/bin/sh



#Checking for existence of CF card

if mount -t msdos -r -o noauto,nocheck /dev/hdc1 /mnt/cf

then 



  # Mounting hdd in RW mode

  /bin/rw

  /bin/rwm



  #Copying images to hdd

  imgdir=`/bin/date +%Y%m%d-%H%M%S`

  mkdir /cfcopy/images/$imgdir

  cp --preserve --recursive /mnt/cf/* /cfcopy/images/$imgdir



  #Updating status

  imgnumall=`ls -R /cfcopy/images | grep -c jpg`

  movnumall=`ls -R /cfcopy/images | grep -c avi`

  size=`du -Shc /cfcopy/images/* | grep total`

  echo "--------  status  --------" > /cfcopy/.tmp/status

  echo "Empeg currently holds:" >> /cfcopy/.tmp/status

  echo " images: $imgnumall" >> /cfcopy/.tmp/status

  echo " movies: $movnumall" >> /cfcopy/.tmp/status

  echo " size: $size" >> /cfcopy/.tmp/status

  echo "---------   log  ----------" >> /cfcopy/.tmp/status

  

  #Updating log

  imgnum=`ls -R /cfcopy/images/$imgdir | grep -c jpg`

  movnum=`ls -R /cfcopy/images/$imgdir | grep -c avi`

  echo `/bin/date "+%d %b %H:%M"` > /cfcopy/.tmp/log.new

  echo " copied $imgnum img & $movnum mov" >> /cfcopy/.tmp/log.new

  cat /cfcopy/.tmp/log.new /cfcopy/.tmp/log.old > /cfcopy/.tmp/log

  cp --force /cfcopy/.tmp/log /cfcopy/.tmp/log.old

  

  #Writing new status file

  cat /cfcopy/.tmp/status /cfcopy/.tmp/log > /cfcopy/statuslog

    

  # Cleaning up

  umount /dev/hdc1

  /bin/rom

  /bin/ro

  

else 



  echo "Copying failed..." 



fi

My next plan is to borrow some of the source code from the excellent viewer application, and make use of its capability of hacking into the Hijack menu.
This way I could do a lot of extra things in the code, for instance do a verification of the copying, launch the copy process itself from within the menu instead of running it at boot time and many other things...

And by the way - I got my new Kingston 256 Mb CF card yesterday - and it is working perfect!
At boot time it reports itself as a "TOSHIBA THNCF256MBA, ATA DISK drive".

Regards
Nicolai

What Mark was saying is that even though the music partitions are mounted read-only, other parts of the drive get written to during normal operation. You do need to set the music partitions (and the root partition) read-only when you've finished them, unless you want to corrupt your filesystems.

Sorry about that, my lab machine that had the crosscompiler died in an RAID bios glitch. I had forgotten to update things here.

Wow, this is really cool. You're basically making the empeg into a Digital Wallet. So, if you ever go on a road trip, you have all the storage you need! I guess it would work for those of you who take your empeg with you on planes too...

Please keep us posted as to how this comes along...