Difference between revisions of "Firmware upgrade"

Revision as of 09:08, 19 June 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)

What I do not like in this approach (in addition to the need to modify it with each release of the ETRAX SDK) is that there is duplication of the MTD code and potential mismatch between the ported to bootloader MTD and the one that runs with the kernel.