Subject: Re: flashing over ethernet
Date: Wednesday 8th February 2006 06:04:20 UTC (over 11 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/ watchdog [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. C 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.