Features Download
From: Craig Hughes <craig <at> gumstix.com>
Subject: Re: flashing over ethernet
Newsgroups: gmane.linux.distributions.gumstix.general
Date: Wednesday 8th February 2006 06:04:20 UTC (over 12 years ago)
On Feb 7, 2006, at 4:47 PM, Lyndon Whaite wrote:

> Hi,
> i am having the same seg fault problem a lot of people it seems are  
> having, i am confident it will be solved if i bring the flash image  
> on the gumstix up to speed, only i dont have a serial connection, i  
> have been ssh'ing in. My question is, is it possible to flash with  
> only an ethernet connection (ie are you able to interrupt u-boot  
> somehow). If not what is there another way i could solve my problem  
> (library mismatch) without flashing.

Lyndon, there is a way to flash a new root_fs (and a new u-boot which  
you'll need because of the bootargs change) from within linux afer  
copying the files over via ethernet or usbnet.  However, if something  
goes wrong, then without a serial port you'll be hard pressed to  
figure out what went wrong.  That said, it's fairly easy (ie hard to  
get wrong).  If you're fairly confident, you can try the following:

copy the new root_fs_arm_nofpu and u-boot.bin from the buildroot to / 
tmp on the gumstix, via scp

then, on the gumstix, you'll need to identify where / is mounted  
from.  For you, this will most likely be MTD partition 2 -- for  
people who are already running a 2.6.15 root_fs, this will be MTD  
partition 1:

# mount | grep mtd
/dev/mtdblock2 on / type jffs2 (rw,noatime)

That's MTD partition 2.  This means u-boot is in MTD partition 1.  If  
this had said /dev/mtdblock1 then root_fs is in 1 and u-boot is in 0.

Now, follow the recipe:

# modprobe sa1100_wdt margin=1
# mount -o remount,ro /
# flash_unlock /dev/mtd1                                              
[note this would be /dev/mtd0 if you had root_fs in 1 above]
# flashcp -v /tmp/u-boot.bin /dev/mtd1                     [note this  
would be /dev/mtd0 if you had root_fs in 1 above]

If, and only if that above line succeeded, then proceed.  If the  
above line failed, you're probably in trouble and may have just  
prepared your gumstix for its life as a doorstop.  Well, actually, it  
can be reflashed using JTAG, but it'll still be a PITA.  If you need  
help trying to recover from a failure from the above 2 lines, then  
please DO NOT POWER DOWN YOUR GUMSTIX before asking for help from  
this forum.  If the above steps fail, and you power down before  
fixing it, then you will need JTAG to recover.

Ok, that's the hardcore warnings out of the way.  Onward:

# echo && flashcp -v /tmp/root_fs_arm_nofpu /dev/mtd2 && echo > /dev/ 
                                                    [note this would  
be /dev/mtd1 if you have root_fs in 1 above]

Ok, that's it -- the final "echo" there to the watchdog device will  
trigger a reboot 1 second after the new flash image is written to  
flash and correctly verified.  Do not do the above flashing of the  
root_fs if you do not have a 2.6.15 u-boot flashed onto the gumstix,  
or else you will need a serial console to fix the u-boot bootargs  
variable, without which fix linux will fail to come up all the way.

That's it.


PS I put fairly dire warnings in above to scare off the timid and  
those who are likely to hose it up.  The procedure is actually pretty  
simple and unlikely to fail with the current state of the buildroot.   
Note that if you only have ethernet and no serial console or USBnet  
connection possibility, you'll want to make sure that you have an  
"auto eth0" or something in the new root_fs_arm_nofpu image from the  
buildroot, so that ethernet is actually there again once you reboot  
to the new image.  This is now the default in the buildroot, so if  
you're bulding from the HEAD of the trunk, it should work OK for you  
as long as you didn't modify that.
CD: 4ms