TODO

From ElphelWiki
Revision as of 18:01, 5 October 2005 by Andrey.filippov (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

TODO list

Some project ideas

Camera reflashing over TCP/IP

Elphel cameras use very nice feature of Axis ETRAX100LX processor - network boot. It is a tiny hard-wired boot loader that uses CPU cache for temporary storage, does not need any special hardware but the Ethernet PHY (anyway present in a networked system). No special connectors, just a single pushbutton switches the system into network boot allowing cold boot of a system without any component pre-programming. It is also a very safe way fro the firmware upgrades - if anything went wrong (i.e. power interruption) it is always possible to start over again - all the software on the camera end resides in the CPU ROM.


But there are some shortcomings of this process. The bootloader is really tiny and needs some special low-level packets from the host. No http/ftp, no TCP/IP at all - that imposes special software requirements on the server (host PC) side.

So - it will be nice to complement this bullet-proof flashing process (that works for cold booting) with a more convenient one for upgrades, including remote upgrades when there is no easy access to the camera. The original method (all the server side software comes on Live CD with the camera) will be used just for the factory firmware installation and as a backup method for customers if the camera does not boot anymore for some reasons.

Model 333 has 3 memories:

  1. System SDRAM - 32MB
  2. System Flash - 16MB, it holds root file system (see 333_File_System#cramfs)
  3. "Frame buffer" memory - actually universal 32MB DDR SDRAM connected directly to the FPGA

It is possible to use the system SDRAM for the temporary buffering of the new flash image but we do not know how this memory will be used in the future software releases, so it can be a good solution that uses frame buffer memory for that purpose. Usage of this memory requires that FPGA is programmed and active, there is driver that allows R/W access to this memory as a block device. FPGA access to the memory is rather flexible, clock rate is variable so it will be good to test this memory and verify data integrity before overwriting the flash memory.

Other challenge (maybe it is not that difficult) is to unmount flash-based file systems (including root) during the flash process that will end with system reboot to the new image.