Hardware - verdex XL6P, console-st, netmicroSD-vx
Buildroot 1573 

I just received my factory re-flashed verdex,  Based on my recent experience I was proceeding with extreme caution as management did not enjoy this two week delay by bricking the verdex.

I carefully followed the instruction on the Buildroot wiki. I downloaded the current version of the Buildroot. And then:
cd gumstix-buildroot 
rm .config 
make defconfig 
make menuconfig (added python to buildroot)

The Buildroot completed and I had my 3 shiny new files. Again, taking extreme care, I did the following via serial connection and kermit using instructions for the Verdex and post-1325 versions of Basix and Connex: (I did use loady instead of loadb on the 18MB rootfs)

GUM>loady a2000000 
ymodem>send rootfs.arm_nofpu.jffs2 
GUM>pro on 1:0-1 && jera all && cp.b a2000000 40000 ${filesize} 


GUM>loadb a2000000 
kermit>send uImage 
GUM>katinstall 100000 
GUM>katload 100000 

Upon reboot, Kernel Panic - not syncing: No init found. Try passing init= option to kernel. So I assumed that the rootfs was corrupted, but just to be thorough I decided to update u-Boot. 

u-Fool! I performed the following as indicated from the u-Boot wiki:

GUM>loadb a2000000 
kermit>send u-boot.bin 
GUM>protect off all 
GUM>era 1:0-1 
GUM>cp.b a2000000 0 ${filesize} 

Upon reboot, I was still seeing the same problem. So I generated another Buildroot. I then went back to my laptop equipped with serial cable and entered the following:
GUM>loady a2000000 
ymodem>send rootfs.arm_nofpu.jffs2 
GUM>pro on 1:0-1 && jera all && cp.b a2000000 40000 ${filesize} 

The file transfer window pops up, and it appears that it will begin the transfer, but the following error message appears: File transfer limit exceeded. Please see online documentation. 

Repeated attempts with same results regardless of which of the 3 files I attempt to send. I haven't power down the verdex. I was still able to drop into u-Boot last night...  I was reading over the mailing lists looking for clues and saw that a very similar event had occurred for another user and the gumstix user who answered his post mentioned he might want to try tftp to replace the files. 

I configured the variables as follows: 

setenv serverip (used tftp server IP address)
setenv ipaddr  (used IP address of gumstix)
tftp a2000000 [your rootfs image name, e.g rootfs.arm_nofpu.jffs2] 

Upon hitting enter, the display indicated tftp had begun. After fifteen minutes, I checked the tftp server, and it indicated no client activity. 

But now, the verdex appeared to be locked up.I left it on overnight hoping for a timeout, but today it still indicated the tftp was in progress. I restarted my communications software in the hopes of being able to interrupt the verdex. No such luck. I have tried a multitude of key strokes and various incantations  and I cannot establish communication with the verdex. 

I still have not powered down the verdex. This was pretty much the same symptom on my first go round with the verdex and when I powered it down, it never came back up. Is there a glaring error here in procedure or thought process. Your input and insights would be greatly appreciated.

Can this verdex be saved? 



Jack Putnam