I had to physically remove the wifistix board from the assembled stack.  I never did figure out why it happened and now, sadly, my entire gumstix work is gone.  We had a hurricane here in Galveston, Texas and my office was under eight (8) feet of water.  Kind of a pain.  Sorry – you are on your own.




From: Francois H. Theron []
Sent: Friday, December 12, 2008 8:45 AM
To: General mailing list for gumstix users.
Subject: Re: [Gumstix-users] UBoot/Kermit Hang


OK. Problem was with kermit.
My environment:
Kubuntu 8.04
apt-get install ckermit  (kermit version 8.0.211)
apt-get install minicom
apt-get install lrzsz (not sure if this is needed)

kermit worked for a while but then simply stopped being able to send.

I then used minicom. You need to set everything you want to set in ~/.kermrc
and then send a file using kermit from minicom (as you would with xmodem etc).

This works perfectly.

I am still not sure what broke kermit, but hope this helps anyone who might get file transfer issues.


FHT wrote:

I know it is a long time ago, but the problem you had then is the same as one
I am having now.
However, I would like to know what you meant by "remove the Wifistix from
the stack". 
Is this the hardware board being removed from the gumstix hardware board
'stack', or the wifistix
drivers from the kernel build (which would change the rootfs*.jffs2 file I
suppose) or something
on your normal PC? This will help me in finding something that causes this
issue for me. I do
not have wifistix, just the basix 400xm-bt module, uboot 1.1.4.
I follow these instructions using kermit: except
for an extra  "robust" just before "send" and it normally works fine. But
once I forgot the robust command and being habitual with things I don't
fully understand yet I Ctrl-Ced the current send, did a robust and sent the
jffs2 file again. The resulting kernel didn't really boot at all with a
seeming infinite loop of bad magic numbers output for the erase blocks. So
naturally I rebuilt my kernel and tried to send it again. This is where the
send stopped responding. Everything else in uboot seems to be working
normally. Worst thing about this problem is of course that you cannot
replace uboot now...
Michael A. Nixon wrote:
So, I've been flailing away and finally decided to remove the Wifistix
the stack and, voila, the uboot image sends with no hang or missed packets
at all.  And I get:
U-Boot 1.1.4 (Jan 28 2008 - 07:54:51) - 200 MHz - 1364
as expected.  Moral of the story.  Go back to the least common denominator
to minimize any adverse interactions.  For the life of me, I couldn't
determine how the Wifistix was corrupting the Kermit transfer so badly
only a process termination could solve it.  Another problem for another
[] On Behalf Of Michael
Sent: Friday, February 01, 2008 10:22 AM
To: 'General mailing list for gumstix users.'
Subject: [Gumstix-users] UBoot/Kermit Hang
I recently "upgraded" my U-boot on my connex 200 from 1.1.4 to 1.2.0 in
anticipation of using the OE build.  However, since I only have the 4MB
version of flash, my attempts to reduce the file system to a size that
properly have failed.
So - my decision is to move back to U-boot 1.1.4.  I downloaded the
buildroot svn again for version 1364 and rebuilt the entire toolchain and
filesystem.  There is, of course, in my buildroot a new U-boot.bin file. 
"strings" command on this file shows it is a version 1.1.4 of U-boot.
So far so good.
Now, I hook up the Gumstix to my serial port, fire up Kermit, plug in the
Gumstix and start the boot process.  I halt it and get the GUM> prompt. 
to upload the file.
GUM> loadb a2000000 is executed and the Gumstix says it is ready to
the file.  Escape back to Kermit and enter:
Ckermit> send u-boot.bin
Kermit starts the file send but the first packet fails.  I have
the Kermit protocols as specified in the wiki (and done a hundred times
before).  I can Ctrl-C out of the send back to the Kermit prompt but a
"connect" to the Gumstix just hangs.  I thought that it was the Gumstix
hanging on file receive but when I removed power from the Gumstix, I still
cannot recover the Kermit session.  I have to kill the process to get back
control of the terminal session.
The only thing that I can think of that changed is that I updated by
system (emerge -va -update world) since my last successful download.
Anyone have any suggestions?  I am trying to isolate the problem to a
particular area and since I have been mucking about by changing U-boot, I
wondering if v1.2.0 on a connex can create this behaviour due to memory
This email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
gumstix-users mailing list