Difference between revisions of "Firmware upgrade"

Revision as of 18:39, 7 August 2007

Firmware Installation and Upgrade

Background

We are now reworking the process of the initial installation and upgrade of the software in Elphel cameras (starting with 353/363). So far it was a modified version of Axis communications e100boot and fsboot, that after receiving the compressed flash image from the host over the network was erasing and writing the flash chip.

It was OK with the NOR flash, but even with it I had to rewrite the flashing software as Axis supported only AMD type of NOR flash, but not Intel/Micron we used in the camera. With the NAND flash and ETRAX FS things got more complicated - handling NAND flash and bad block needs more code. In 2006 I had to port MTD drivers to the bootloader myself because Axis SDK that supports NAND flash was not ready then. In spring 2007 that new SDK (2.10) was released and so we need to merge it with our hardware-specific modifications once again. And this merging among other things includes the bootloader too.

Problems with the old bootloader

• Need to overhaul the bootloader with each SDK change
• duplicate port of MTD drivers and mtd-utils in the bootloader - possible mismatch with those running with the booted system
• problems with handling of the flash larger than RAM - normally bootloader downloads the image to RAM first, then writes it to flash

New software installation process

All the time I was using Axis ETRAX and software it had "ktest" - ability to boot system from the network bypassing flash. And most of the time that code was broken - sometimes it did not work in SDK, sometimes - we broke it ourselves. Now we fixed it and the system boots without doing anything with flash.

How does it help?

We have running a "normal" system running, with the current mtd drivers and mtd-utils - same ones that will be used in the camera during normal operation. The actual installation of the flash images is implemented using MTD drivers and mdt-utils that know how to skip the bad blocks in the NAND flash. The data to write to flash is received by the camera from the NFS server using regular network protocols that handle lost packets much better than spartan network implementation in the bootloader, so multiple cameras can be programmed at the same time without interfering with each other.

After booting from the network (no flash used) cameras will receive IP addresses from the DHCP server using either earlier assigned MAC address (written in bootblock of the flash) or, if it is a brand new camera, temporary use random MAC address. Next step - running installation script from the NFS server that, among others will assign permanent serial number/MAC address to each new camera. Different scripts can be prepared for different tasks - upgrading a single camera, production programming of the multiple cameras, programming of the specialized multi-camera systems.

Such installation process can use either complete images for each JFFS2 partition or it can just install uncompressed files.

Similar procedure can be used to read flash from the camera for postmortem analysis of the data if camera does not boot for some reason.

TODO

1. It would be nice to make it possible for the camera to boot same kernel + root file system from flash, not only from the network. That will simplify remote firmware upgrade (that does not require pressing the button on the camera)

2. Pass parameter string to the kernel through the network bootloader (i.e. serial number fro the new camera) and during reboot (too instruct flash bootloader not to mount flash but use RAM instead)

--Andrey.filippov 12:07, 19 June 2007 (CDT)

Most of the TODO is already done, below is the README.flash included with the current software:

How to install from CVS.

cvs -d:pserver:anonymous@elphel.cvs.sourceforge.net:/cvsroot/elphel login 
cvs -z3 -d:pserver:anonymous@elphel.cvs.sourceforge.net:/cvsroot/elphel co -P elphel353-2.10
./install_elphel_from_cvs 
cp -R ../353/* .
./install_elphel
mkdir -p /nfs/elphel353-2.10/
cp -R elphel353/image353-2.10-7.1.0.9/* /nfs/elphel353-2.10/

How to reflash (update firmware) in the camera.

I. removed - was old style reflashing

II. Reflash from camera:

1. setup NFS server with firmware in directory (by default, server with IP 192.168.0.15 and firmware placed in /nfs/elphel353-2.10 directory); you must use for NFS folder options rw,no_root_squash.
2. login with telnet to camera with login "root" and password "pass"
3. edit file /etc/reflash.conf, if needed, and change NFS server address and directory, where placed firmware
4. type "reflash"
5. check flash log file on NFS server in directory with firmware, log file name is flash.log.MAC-ADDRESS_of_camera

III. Reflash from computer with ktest:

cd elphel353/
. ./init_env
./ktest -d eth1 mac=OOOE64000000 ip=192.168.0.9 nfs=192.168.0.15:/nfs/elphel353-2.10 cmd=all

1. set up NFS server as in II.1 step
2. run ktest with parameters './ktest [-d ethX] options'
[-d ethX] - network interface to camera, by default, eth0
options - parameters for camera:
mac=OOOE64000000 - MAC address for camera; if SERNO in camera boot block not present, this MAC address be writted in bootblock
ip=xx.xx.xx.xx - ip for camera (by default, 192.168.0.9)
nfs=192.168.0.15:/nfs/elphel353-2.10 - NFS server, where placed firmware.
cmd=boot|update|all

- boot - just boot camera, don't touch flash memory, by default - update - update firmware (results as in II) - all - rewrite all partitions on camera (be careful with this option)

Example:
./ktest -d eth0 mac=000E64000000\ ip=192.168.0.9\ nfs=192.168.0.15:/nfs/elphel353-2.10\ cmd=update
3. when camera started from ktest, it's boot and try write firmware from NFS server - check log on NFS server