Hi,
 
Progress! It's 2:38am and I have it working now.
I managed to get into uboot and log into linux via the serial console. The eth0 thing has been reconfigured and so the ethernet (netCF-vx) was down. 
 
The version I checked out (1564) had eth0 doing something else for a mmc card I think. I changed the /etc/modprobe.conf and /etc/modules (changed the eth0 bit from smc911x to smc91x and this seemed to do the job. No idea why, but it worked!
 
Thanks,
JR
 

-----Original Message-----
From: "Jonathan Rodgers" <J.Rodgers@kelman.co.uk>
To: "General mailing list for gumstix users." <gumstix-users@lists.sourceforge.net>
Date: Thu, 29 Nov 2007 01:37:50 +0000
Subject: Re: [Gumstix-users] Confusion over mtd2 when flashing Verdex XLP6

Hi,
 
Well, I managed to search with nabble. I gave it a go:
 
# modprobe sa1100_wdt margin=1
# mount -0 remount,ro /
mount: invalid option -- 0
BusyBox v1.1.2 (2007.03.01-01:59+0000) multi-call binary
Usage: mount [flags] DEVICE NODE [-o options,more-options]
Mount a filesystem.  Filesystem autodetection requires /proc be mounted.
Flags:
 -a:  Mount all filesystems in fstab
 -o option: One of many filesystem options, listed below
 -r:  Mount the filesystem read-only
 -t fs-type:    Specify the filesystem type
 -w:  Mount for reading and writing (default)
Options for use with the "-o" flag:
 async/sync:    Writes are asynchronous / synchronous
 atime/noatime: Enable / disable updates to inode access times
 dev/nodev: Allow use of special device files / disallow them
 exec/noexec:   Allow use of executable files / disallow them
 loop:   Ignored (loop devices are autodetected)
 suid/nosuid:   Allow set-user-id-root programs / disallow them
 remount:  Re-mount a mounted filesystem, changing its flags
 ro/rw:  Mount for read-only / read-write
 bind:  Bind a directory to an additional location
 move:  Relocate an existing mount point.
There are EVEN MORE flags that are specific to each filesystem
You'll have to see the written documentation for those filesystems
# mount -o remount,ro /
# flash_unlock /dev/mtd0
# flashcp -v /tmp/u-boot.bin /dev/mtd0
Erasing blocks: 2/2 (100%)
Writing data: 157k/157k (100%)
Verifying data: 157k/157k (100%)
# echo && flashcp -v /tmp/rootfsuimage /dev/mtd1 && echo > /dev/watchdog
Erasing blocks: 254/254 (100%)
Writing data: 32457k/32457k (100%)
Verifying data: 32457k/32457k (100%)
#
 
Seemed to work ok but it hasn't come back up on the network! I suppose I'll have to try it with the serial console to see what is going on.
Was i wrong to copy the images to mtd0 and mtd1 as oppposed to mtdblock0 and mtdblock1?
 
Regards,
JR

 

-----Original Message-----
From: "Jonathan Rodgers" <J.Rodgers@kelman.co.uk>
To: "gumstix-users@lists.sourceforge.net" <gumstix-users@lists.sourceforge.net>
Date: Thu, 29 Nov 2007 00:32:49 +0000
Subject: [Gumstix-users] Confusion over mtd2 when flashing Verdex XLP6

Hi All,
 
I'm a little confused about the instructions for flashing a Verdex. I have been studying the instructions for doing it over SSH, and I digg the instructions for uBoot and the rootfs. My problem lies with the uImage and mtd2:
 
# echo && flashcp -v /tmp/rootfs.arm_nofpu.jffs2 /dev/mtd1 && flashcp /tmp/uImage /dev/mtd2 && echo > /dev/watchdog
I don't have a /dev/mtd2 to 

copy the uImage to!
I  have the following:
# cd /dev/
# ls

console    log       
mtd1      
null       random    
ttyS1
full      
mem        mtd1ro    
port      
shm        ttyS2

kmem      
mtd0       mtdblock0 
ptmx      
tty        urandom

kmsg       mtd0ro    
mtdblock1  pts       
ttyS0      zero
Also, my root is on  
mtdblock1:
# df

Filesystem               
Size      Used Available Use% Mounted on

/dev/mtdblock1          
31.8M      8.1M     23.7M 
25% /
I have noted that when I dd mtdblock1 I 
get an output  
file of size 0x01fc0000 which is 0x00100000 (supposed size of mtd2) bigger
than it should be! Help with this would be greatly appreciated as I have a
new image from buildroot that I want to get up and going!
I also  
assume that I will use a command like:
# echo && flashcp -v
/tmp/rootfs.arm_nofpu.jffs2 /dev/mtdblock1 && flashcp /tmp/uImage
/dev/mtdblock2 && echo > /dev/watchdog
and substitue
/dev/mtdblock0 for /dev/mtd0 when flashing the uBoot (first of course).
Details of my setup:
Verdex XL6P, 2.6.18gum, Release
1321, uBoot - Unsure (will flash it first anyway)
 
Regards,
Jonathan Rodgers
 
P.S. has
anyone else noticed a problem with the maillist search on sourceforge. It
has been returning errors when I try and search for things!

 
 




>> CONFIDENTIALITY NOTICE <<

The information contained in this e-mail is intended only for the individual to whom it is addressed. It may contain legally privileged or confidential information or otherwise be exempt from disclosure. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. You must not use, disclose, copy or alter this message for any unauthorised purpose. Neither Kelman Ltd. nor any of its subsidiaries will be liable for any direct, special, indirect or consequential damages as a result of any virus being passed on, or arising from the alteration of the contents of this message by a third party.




>> CONFIDENTIALITY NOTICE <<

The information contained in this e-mail is intended only for the individual to whom it is addressed. It may contain legally privileged or confidential information or otherwise be exempt from disclosure. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. You must not use, disclose, copy or alter this message for any unauthorised purpose. Neither Kelman Ltd. nor any of its subsidiaries will be liable for any direct, special, indirect or consequential damages as a result of any virus being passed on, or arising from the alteration of the contents of this message by a third party.




>> CONFIDENTIALITY NOTICE <<

The information contained in this e-mail is intended only for the individual to whom it is addressed. It may contain legally privileged or confidential information or otherwise be exempt from disclosure. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. You must not use, disclose, copy or alter this message for any unauthorised purpose. Neither Kelman Ltd. nor any of its subsidiaries will be liable for any direct, special, indirect or consequential damages as a result of any virus being passed on, or arising from the alteration of the contents of this message by a third party.




>> CONFIDENTIALITY NOTICE <<

The information contained in this e-mail is intended only for the individual to whom it is addressed. It may contain legally privileged or confidential information or otherwise be exempt from disclosure. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. You must not use, disclose, copy or alter this message for any unauthorised purpose. Neither Kelman Ltd. nor any of its subsidiaries will be liable for any direct, special, indirect or consequential damages as a result of any virus being passed on, or arising from the alteration of the contents of this message by a third party.




>> CONFIDENTIALITY NOTICE <<

The information contained in this e-mail is intended only for the individual to whom it is addressed. It may contain legally privileged or confidential information or otherwise be exempt from disclosure. If you have received this message in error or there are any problems, please notify the sender immediately and delete the message from your computer. You must not use, disclose, copy or alter this message for any unauthorised purpose. Neither Kelman Ltd. nor any of its subsidiaries will be liable for any direct, special, indirect or consequential damages as a result of any virus being passed on, or arising from the alteration of the contents of this message by a third party.