Difference between revisions of "Firmware upgrade"

From ElphelWiki
Jump to: navigation, search
(corrected mac address: it had Oes (the vowel) instead of 0 (zeroes))
Line 1: Line 1:
 +
{{Manual legacy_pages}}
 +
 +
 +
 
== Firmware Installation and Upgrade ==
 
== Firmware Installation and Upgrade ==
 
=== Background ===
 
=== Background ===

Revision as of 10:13, 16 April 2009

This is a legacy page. The information bellow is not compatible with Elphel 393 or 353/363 series cameras.


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.

mkdir -p /nfs/elphel353-2.10/
chmod 777 -R /nfs/elphel353-2.10/
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

Install NFS server on your computer

To install NFS server on your Debian/Ubuntu GNU/Linux execute:

sudo apt-get install nfs-kernel-server nfs-common portmap

When configuring portmap do ***not*** bind loopback.

Now configure exported file systems:

sudo vi /etc/exports

and put this text inside:

/nfs/elphel353-2.10  192.168.0.15/24(rw,no_root_squash)

last stage:

sudo /etc/init.d/nfs-kernel-server restart
sudo exportfs -a

Your NFS server should be up and running.

How to reflash (update firmware) in the camera.

I. Reflash from camera:

This work only if you upgrade from 7.1.*, if you are upgrading from 7.0.* you need to use method II.

 1. login with telnet to camera with login "root" and password "pass"
 2. edit file /etc/reflash.conf, if needed, and change NFS server address and directory, where placed firmware
 3. type "reflash"
 4. check flash log file on NFS server in directory with firmware, log file name is flash.log.MAC-ADDRESS_of_camera

II. Reflash from computer with ktest:

Your current working directory should be the CVS tree. (normally it should be ~/elphel353-2.10

Do not forget to change the mac address, the camera's IP and the IP of your NFS server (your computer)

If you are performing an upgrade from 7.0.* you should use "cmd=all" in other case use "cmd=update"

Unlike the previous method for this one you need to press the green button on the back of the camera while booting.

 cd elphel353/
 sudo su
. ./init_env
./ktest -d eth1 mac=000E64000000 ip=192.168.0.9 nfs=192.168.0.15:/nfs/elphel353-2.10 cmd=update

ktest parameters & options:

  • [-d ethX] - network interface to camera, by default, eth0
  • mac=OOOE64000000 - MAC address for camera; if SERNO in camera boot block not present, this MAC address will be written in bootblock
  • ip=xxx.xxx.xxx.xxx - 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)


When the camera started from ktest, it boot, mount NFS share and write the firmware to the flash.

If the firmware was flashed successfully you should see a log file in /nfs/elphel353-2.10 finishing with "done".

Only after this you can unplug the Ethernet cable for 10 seconds and reconnect the camera. (those 10 seconds are due to a bug that will be corrected in near future)

Troubleshouting

If you see only "Starting boot..." and nothing after it mean what you forgot the ktest's "-d" parameter or did not press the green button on the camera when power up.

If you see something after "Starting boot...", but do not see any log files in your NFS share after one minute it probably mean what the camera was not able to mount the NFS share. The camera will remain booted from the network and accessible trouth telnet. You may telnet to the camera and manually try to execute one by one commands from /bin/reflash script. (just to see what's wrong)