User:Cdollar

Flashing a rootfs via a network with Boa and CGI
In addition to being able to reflash your gumstix root filesystem thru u-boot and a serial console connection, it can also be done from within linux using the flashcp command. And since the gumstix boa webserver supports CGI scripts it then is possible to create a web based interface to upload and re-flash your gumstix rootfs. Note that doing something like this 'opens a security hole' to your gumstix that you have to manage and be comfortable with. Hey, convenience comes at a price ;) I should also note that the procedure below (really the CGI script referenced below) just does what Craig describes in this post for reflashing a rootfs with flashcp.

The Haserl CGI Wrapper and control_panel script
The main form processing is done using a CGI wrapper called Haserl that supports embedding shell scripts into html pages as well as file uploads. Its really small in size (~16K) and is really quite powerful.

The control_panel page is the actual CGI script that in turn calls haserl. The script really only does 2 things: 1) show you some simple statuses about your gumstix system and 2) allows you to upload a rootfs image and flash it to your gumstix. When called upon to reflash a rootfs image the script will determine the mtd device that your rootfs will use and does some basic checks to make sure the current filesystem on your gumstix has the necessary programs (like flashcp) and that the filesystem image to be flashed is fully padded. It also does a crude check to make sure that your u-boot bootargs has root=1f01, which is necessary for a 2.6.13+ rootfs. The uploaded filesystem image is stored in memory in the /tmp directory on the gumstix.

To build haserl create a haserl directory in your buildroot

cd  mkdir packages/haserl

and then you can use this .mk file and the control_panel script. Just move the haserl.mk and control_panel files into the packages/haserl directory, and then build haserl.

If you see an error like "/bin/sh: Syntax error: Bad substitution", when running the control_panel script, find the following line:

let RM=${LR:13:11}

and change it to:

RM=`df | grep mtd | sed -e "s/^[^0-9]*\([0-9]\).*/\1/g"`

mv /haserl.mk /control_panel /package/haserl cd  make haserl

To use haserl and the control_panel script without re-flashing a rootfs now just copy the haserl binary from /build_arm_nofpu/root/bin to the /bin directory on your gumstix, and then copy the control_panel script from /package/haserl to /var/www/cgi-bin on your gumstix. Make sure the control_panel script has execute permissions in the cgi-bin directory.

cd /var/www/cgi-bin chmod +x control_panel

Creating a Padded rootfs Image
One thing about using flashcp from within linux is that the jffs2 image that is to be flashed HAS to fill the entire flash area. This means that for an XM gumstix the rootfs image must be 16MB - 128K for u-boot, or 16128K, and similarly for a 4MB gumstix. The good news is that the buildroot makes it really easy to create a padded rootfs image. To do this go into the buildroot menuconfig and make these changes:

cd  make menuconfig

Target Options --> [*] Pad Output (0xfc0000) Pad output size *** change this to 0x3c0000 for a non-xm gumstix [ ] Use sumtool to write summaries to the filesystem

Notice that you have to un-select the 'Use sumtool...' option or your build will fail. Now you can run 'make' from within your buildroot directory and the rootfs.arm_nofpu.jffs2 created should be padded correctly.

Editing boa.conf
Since the parts of the control_panel script used to reflash a gumstix write to the /tmp directory and use flashcp which is owned by root the boa webserver also has to be run as root. And since we are uloading files we also have to tell boa to allow uploads and set the limit on the size of those uploads. Its really easy make these changes, but it should also be noted that this opens up a security risk to your gumstix. The control_panel script can and does erase the filesystem of your gumstix - imagine the possibilities if this got into the wrong hands. Only do this if you know what you are doing, or better yet, only make this change long enough to reflash your gumstix, and then let boa run as the boa user from then on.

On your gumstix you'll need to edit the /etc/boa/boa.conf file. Towards the top of the file change the user/group section to read


 * 1)  User: The name or UID the server should run as.
 * 2) Group: The group name or GID the server should run as.

User root Group root

and towards the bottom of the file you'll see a comment about SinglePostLimit. Add this line there:

SinglePostLimit 20000000
 * 1) SinglePostLimit: The maximum allowable number of bytes in
 * 2) a single POST.  Default is normally 1MB.

This should give you an upload limit large enough to reflash an XM gumstix.

Now you'll need to restart boa. You can do this by telling the boa service to restart, but I've found that many times when doing this that boa in fact does not restart, so you have to issue the command again. The failproof way though is just to reboot your gumstix.

Flashing a new root filesystem
Now that we've got haserl and boa ready, we can flash a new filesystem image. Its probably a good idea to stop any programs that you have running and close out of any ssh sessions you have open, although I've done this a number of times with an open ssh session with no bad side effects.

On your build host machine pull up a web browser and point it to http://your-gumstix-ip/cgi-bin/control_panel This should take you to the main status page that will show some basics about your gumstix. On the left is a link to reflash a new rootfs image - click that link.

On the next page you can upload your padded rootfs image. Browse to where you created your padded image and click the upload button. Once the image is uploaded to your gumstix the control_panel script will check to make sure the uploaded image is padded correctly and that your bootargs are set correctly. The next step is to remount the / filesystem read-only and to load the watchdog timer, which will be what we use to reset the gumstix after we're done flashing the filesystem.

When you're ready to move on click the button to complete the remaining steps (you still have one chance to abort before the reflashing begins). Once the / filesystem is remounted and watchdog timer loaded, we're ready to go. Click the 'Reflash now' button to start reflashing the filesystem. Once you click the button flashcp will start to do its thing. Don't click stop in your browser or power off your gumstix at this point. What will happen if you do? dunno, but I'm sure it won't be good.

Once flashcp starts it will first erase the flash, copy the new image to it, and then verify what it has written. I use firefox as my web browser, and while the reflash is taking place I will occasionally get the output from flashcp written to the screen. Sometimes it updates the screen really frequently - sometimes it waits almost 30sec before it updates the screen. In other browsers it may not show you the progress at all. At this point the key is to just be patient. The process doesn't take a lot of time (I've never actually timed it), but it should complete in < 5min.

Once flashcp is done it will write to the watchdog timer and your gumstix will reboot. Thats it!

At this point if something went wrong, you're probably still ok, but you'll most likely have to get console access to u-boot to reflash a rootfs from there. That being said, I've been using this script in various forms for 4+ months and have never had a problem.