You are not logged in. Please login or register.
chumbysphere forum → Software → Debian Lenny on a Chumby Classic
Hi all,
I've posted initial instructions on getting Debian Lenny working on a Chumby Classic at http://www.openminddev.net/projects/wik … n_a_Chumby. This includes X-Windows working with touchscreen support.
All comments and feedback including typos and omissions here please.
Cheers,
Rasjid.
This is EXACTLY what I have been looking for.
I am doing this procedure as I type this still downloading kernel sources.. thanx so much for this recipe as it gives me back an environment the same as I had on my netslug(NSLU2) except with lcd and touchscreen support(if sucessful) wooooowooooo!
thanx again for posting this simple recipe rasjidw, you rock!
gwen
ps at creating debootstrap so far so good..
btw after debian is installed on the chumby, are there any issues you see about upgrading to current kernel level for arm?
SCREAM... the 2gb sandisk usb sticks which I had been using with debian CANT be read by the current chumby kernel it seems not because of fat 16/32 format issues.. its because of the thrice damned U3 software area defined on the key that I cant seem to find or delete with gparted but which displays under windows is there enough space on the classic to copy the new kernel via ssh and copy into place manually? any guidance?
a VERY frustated gwen
ps once a debian kernel into place then these keys no issue and the rest of the install no problem..(i hope)
ok I have managed to locate the update.sh script 
and it looks like mtd device 4 is where the kernel image is installed to..
so I will rewrite a version of this script to ssh my kernel image from my virtual ubuntu and flash it..
and not worry about a temporary usb incompatibility which will disappear when I get the new kernel in place...
time consuming
gwen
it would seem that the following two commands would effect the upgrade after I sshed k1.bin.zip to the chumby's /tmp
flash_eraseall /dev/mtd4
unzip -p /tmp/k1.bin.zip |chumbyflash -m /dev/mtd4 -s 0x0 #no bad blocks at all in my chumby so no offset?
anyway here goes
time to brick a chumby classic
my flash exhibits no bad blocks so zero offset would be appropriate?
chumby:/usr/chumby# flash_eraseall /dev/mtd4
Erasing 16 Kibyte @ 2f8000 -- 98 % complete.
chumby:/usr/chumby# unzip -p /tmp/k1.bin.zip |chumbyflash -m /dev/mtd4 -s 0x0
Scanning for bad blocks..
Bad block scan complete.
Flash complete: wrote 1508864 bytes.
hmm so far so good..
now to follow the rest of the debian instructions... more later
hmm wiped out /usr/chumby/scripts somehow.. had to restore to factory defaults but the uname -a shows my kernel still there
uname -a
Linux (none) 2.6.16-csb #3 Tue Sep 14 01:33:50 PDT 2010 armv5tejl unknown
chumby:/usr/chumby/scripts#
and /usr/chumby/scripts back to normal
cat /proc/filesystems shows
nodev sysfs
nodev rootfs
nodev bdev
nodev proc
nodev sockfs
nodev usbfs
nodev pipefs
nodev futexfs
nodev tmpfs
nodev inotifyfs
nodev eventpollfs
nodev devpts
ext3
ext2
cramfs
nodev ramfs
msdos
vfat
hfsplus
nodev nfs
nodev nfs4
nodev jffs2
romfs
so ext2 and ext3 there and supported..
Cool I used the U2 removal tool and now my drive is seen by the chumby.. after I managed to find another valid path for updating the kernel image
So now the chroot stage for debootstrap is running and I am waiting..
So far this debian install procedure has been completely accurate .. all errors have been caused by the U3 windows garbage.
Then I have 3 more chumbys to do it to
gwen
it would seem that the following to commands would effect the upgrade after I sshed k1.bin.zip to the chumby's /tmp
flash_eraseall /dev/mtd4
unzip -p /tmp/k1.bin.zip |chumbyflash -m /dev/mtd4 -s 0x0 #no bad blocks at all in my chumby so no offset?
anyway here goes
time to brick a chumby classic
Hi Gwen,
I'm a bit puzzled why you are doing the update this way rather than using the standard Chumby update process? Using the standard update process at least means that there is little chance of bricking your Chumby.
Cheers,
Rasjid.
Hi rasjid..
5 reasons..
1.I did not find the U3 removal tool till after I did this..
2. I went through the update script so I knew what it was doing,
3 I am an old kernel hack from unix SVR4 days and I like doing everything by command line initially so I understand it completely and can go around the normal process if necessary.
4. I have some max-232 chips around so if necessary I can build a ttl-rs-232 converter cable and unbrick the unit if necessary.
5. I have 4 of these to play with and repurpose
kind regards
gwen
ps thanx again.. for the recipe.. its working perfectly so far.. all detours were because of U3,
currently the second stage is at unpacking coreutils
btw after debian is installed on the chumby, are there any issues you see about upgrading to current kernel level for arm?
Oh, I wish it were that simple. Perhaps it is, but as far as I can tell, a number of the drivers for the Chumby classic would need to be ported from the 2.6.16 kernel to the debian kernel in question.
I have not yet even got to the point where I can view the boot messages during startup. (I asked about this at http://forum.chumby.com/viewtopic.php?id=5430 but have not yet got a response from anyone who knows the answer. A post I came across here somewhere suggested that I just need to change the framebuffer being displayed, but unfortunately I didn't bookmark it and can't find it again.)
I've been busy with other things, but will get back to this sometime soon I hope. If you can find some way of getting the boot message displaying on the current 2.6.16 kernel, that would be a great start. Even better if for a standard Debian kernel or the current vanilla kernel.
Cheers,
Rasjid.
hmm..
oh well.. if it can run X and use the touchscreen.. I will be happy..I mainly will be using it to ssh into and either run miniterm.rb OR run the standard minicom to talk to a sanguino. Installing debian was FAR easier than porting minicom to chumby 
IMHO
gwen
hmm..
oh well.. if it can run X and use the touchscreen.. I will be happy..I mainly will be using it to ssh into and either run miniterm.rb OR run the standard minicom to talk to a sanguino. Installing debian was FAR easier than porting minicom to chumbygwen
Mostly I wanted PyQt on the chumby, which was being a pain to port too. Thanks to Debian, the following small python program gives me a fullscreen web-browser on my chumby.
-----
#!/usr/bin/env python
import sys
from PyQt4.QtCore import *
from PyQt4.QtGui import *
from PyQt4.QtWebKit import *
app = QApplication(sys.argv)
web = QWebView()
web.load(QUrl("http://www.google.com.au"))
web.showFullScreen()
sys.exit(app.exec_())
------
Cheers, Rasjid.
ok I am to the point where the debian system is executing my first 2 installs
tmux from backports and minicom
also ran top and noticed the process chumbyflashplay is a real pig.. killed it with a -9 and it spawns anew.. have to enable the rootfs for writing on the chumby and disable ALL of the original chumby housekeeping pertaining to flash to make this stuff run fast enough.. ie I dont share well with others
above wasnt necessary just put an invocation of "stop_control_panel" someplace where it will get executed right after boot.
and just noticed it gets invoked late in the installation.. probabaly should put it before we start running aptitude so things run nice and quick for all the installs
gwen
I dont even really need X although I am putting it on anyway
hmm it would be nice to trim down step 7 if possible so it only installs the precise X server used on the chumby not everything xorg supports..
gwen
or am I incorrect about this?
and I wonder if we can get this procedure working on the silvermoon hardware...ie bestbuy
gwen
It should be easier on Silvermoon.
The file system is ext3 and can be mounted as r/w, the kernel is newer, plus the software is *completely* replaceable since it's on a removable MicroSD card (though you would have to open the case to get at it).
OK this is beyond cool.. now can use the chumby as a limited output device under X and a very limited input device under X ie no virtual keyboard yet I will have to search for X source to same to compile up.. but just having a chroot debian environment via ssh available totally rocks for moi...(and memory is very tight) so all of this(the kernel and X server) needs a severe slimming down to exactly what is needed instead of the usual debian bloatware.
gwen
thanx so much for this
gwen
hmm it would be nice to trim down step 7 if possible so it only installs the precise X server used on the chumby not everything xorg supports..
gwen
or am I incorrect about this?
The guide is just meant as a starting point - my goal so far was just to get it working and to see if the Chumby is capable of doing what I want it to do. All suggested improvements are welcome. :-)
ARGGGHHHH I just tried using minicom in a chroot environment WTF no /dev/ttyUSB0 in /dev
hmm chumby /dev has it as c 188 0 tried creating that in the chrooted environment and minicom seems to be read-only(its a bug in a startup macro for bitlash)
but I am getting the interpreter header from bitlash... wooo wooo!!
I created my usb partition layout to include /update2/k1.bin.zip /psp/*debian* to /scripts and /debugchumby all in the vfat partition and of course debian in the ext2 partition resulting in a chumby classic conversion usbkey 2gb image that I am dding from key to key to convert all 4 chumbys to debian, I still have to add a chroot debian sshd invocation on a different port /
clues for the clueless
gwen
ps it prolly will fit in 750mb or smaller..
ARGGGHHHH I just tried using minicom in a chroot environment WTF no /dev/ttyUSB0 in /dev
hmm chumby /dev has it as c 188 0 tried creating that in the chrooted environment but get a no such device catting from it and minicom gives no joy at all
clues for the clueless
gwen
ps was also thinking about putting aoetools on the chumby
When I first did this, I originally mounted the chumby's /dev under the debian chroot (like all the other -o bind mounts). ie, I had:
mount -o bind /sys $DEB_ROOT/sys
mount -o bind /dev/ $DEB_ROOT/dev
mount -o bind /dev/pts $DEB_ROOT/dev/pts
I changed the process as I was having issues with X-Windows starting up and looking for non-existent devices. But maybe what I had originally was the better approach, and it would be better to add in the devices that X needs to the existing /dev/. Anyway, you can try that and see if it helps.
If that doesn't help, my guess is that you'll need to reconfigure the kernel and compile some kernel module that has not been selected.
Cheers, Rasjid.
and it looks like I am good to go..
minicom is happy with the mknod now...
gwen
ouch seems to be working with the mknod approah only intermittently.. will try your approach...
gwen
ouch seems to be working with the mknod approah only intermittently.. will try your approach...
gwen
Let me know if there is a difference, but to be honest I can't see why there would be. The binding of /dev was just be to push the udev support from the real chumby rootfs into the debian chroot fs, and save you having to use mknod.
Cheers, Rasjid.
It may be that init is grabbing the USB device. /etc/inittab tries to start up a terminal on /dev/ttyUSB0, if I remember right.
Also, the MTD filesystem names should be in /proc/mtd, I think.
It seems reliable this morning..(mknod) dont know what was going on yesterday.,. been building kernels with slip so can slattach my ardiuno/sanguino running uip/slip.
I have created a 2gb debian conversion key/chroot rruntime image.. prolly could be easily done in 256mb, includes the update2 and the debian scripts from psp and the chroot image.. and all works to convert a classic in 2 minutes or less to debian chroot.
gwen
turns out a getty is started in the cramfs image... on ttyUSB0.. have been unsucessful in creating a new image that boots so far using the procedure found in the forums but with the getty disabled.. thats why the unreliability...
gwen
ps who is recreating all his work of the past few days this morning due to user error
chumbysphere forum → Software → Debian Lenny on a Chumby Classic
Powered by PunBB, supported by Informer Technologies, Inc.
