Latest revision as of 08:27, 19 July 2008

Some project ideas

Add support for wifi and bluetooth

Add support for most used USB wifi and bluetooth USB keys.

Bluetooth remote control

Add a remote control via bluetooth and wifi.

Make more human-readable flash.log

The flash.log in the nfs share more human-readable. Maybe add some more info inside.

PHP interface for reflashing camera(s)

PHP web interface to reflash one or multiple cameras with ktest (show camera status), control options, browse log files. It would be useful to add memory, FPGA and other hardware and show results -- i.e. get JPEG image and check if the image is "normal". The interface should allow to configure all ktest parameters (and probably much more) individually per camera.

For production flashing include PoE switch control to reboot the camera.

The streamer

Audio

Implement audio from alsa source synced with video.

Subtitles

Implement subtitles what might be optionally read by the client. Subtitles should be able to handle info from EXIF and any user defined data.

Write to disk

Implement an option to stream to the network and/or to the hard drive / CF.

Exif

Add fields for geo-location (GPS), orientation of the camera and some user defined data. The camera model should also include sensor type and model.

Make a block diagram of the boot process

It is needed for new devs and to be able to have an overview of the process and be able to enhance it.

Better usage of busybox

Enable cool and useful staff from busybox such as passwd, cfdisk, minicom, ... (Please post a list to this section for discussion before doing what)

Hardware Test Software

Hmm... will be described later.

Do some magic to be able to pass params to the kernel over reboot

Implement (or just improve - something is already done) passing parameters to the next booted kernel. This can be done in different ways:

passing kernel params truth RAM
using KEXEC kernel function
simulate the green button pressure at boot time (to boot in flashing mode)
destroy signature magic after usage - even powered down SDRAM can hold data for many seconds

Green button

Get rid of the green button.

10353 Rev "E" PCB will still has a provision to install that button, but the board is able to operate without it. Instead the power should be applied/removed several (>~5) times to switch camera to the network boot mode. This can be done manually or with a manageable PoE switch.

Current (as of January 2008) PCB has rev "D", rev "E" will be available in the second quarter of 2008.

Init levels

Implement init levels, init 3 should have only GNU/Linux with telnetd, everything camera specific should run from init 5. The default level will be 5, but ktest should be able to pass init=3 to the kernel.

NetBoot

Better output

Some more output should be added to netboot to make it more verbose and user-friendly.

New function

Add new function and param to read & copy partitions from the flash to NFS for debuging.

Ethernet LEDs

Hack in to the ethernet driver to make a better usage of leds. For example during flash with pressed button boot with orange led ON, blink orange while booting the kernel, blink with the green led while copying from NFS to flash and green ON when completely flashed and ready to be rebooted. While normal operation leds can be used in a more nice way when now.

Genres

Enhance Genres plugin to get rid of multiple languages and dependences and rewrite all using only one programming language. Make it more stable.

camvc

Repair broken/buggy AJAX code, port CGIs to PHP and move to lighthttpd instead of boa. (keep them both at least at the beginning to compare te speed and stability)

Security

Lighthttpd

Add https to lighthttpd and add .htaccess protected directories.

Add SSH

This has apparently been done. The model 353 I received (July 2008) has the Dropbear implementation of ssh.

Separate user privileges

Add passwd command, implement users and groups with separated privileges. Make groups for FPGA and other hardware (as HD) access and make Lighthttpd/PHP run as user.

Netfilter firewall

Port the latest netfilter to be able to setup a firewall on the camera.

Ideas

Flashing via USB

It seems really simple to implement flashing via USB Flash/HD. If the camera find /autoupgrade.sh script on the USB-flash during the boot it upgrade the firmware.

@@ Line 1: / Line 1: @@
-== TODO list ==
+Some project ideas
+= Add support for wifi and bluetooth =
+Add support for most used USB wifi and bluetooth USB keys.
+= Bluetooth remote control =
-Some project ideas
+Add a remote control via bluetooth and wifi.
+= Make more human-readable flash.log =
+The flash.log in the nfs share more human-readable. Maybe add some more info inside.
+= PHP interface for reflashing camera(s) =
+PHP web interface to reflash one or multiple cameras with ktest (show camera status), control options, browse log files. It would be useful to add memory, FPGA and other hardware and show results -- i.e. get JPEG image and check if the image is "normal". The interface should allow to configure all ktest parameters (and probably much more) individually per camera.
+For production flashing include PoE switch control to reboot the camera.
+= The streamer =
+== Audio ==
+Implement audio from alsa source synced with video.
+== Subtitles ==
+Implement subtitles what might be optionally read by the client. Subtitles should be able to handle info from EXIF and any user defined data.
+== Write to disk ==
+Implement an option to stream to the network and/or to the hard drive / CF.
+= Exif =
+Add fields for geo-location (GPS), orientation of the camera and some user defined data. The camera model should also include sensor type and model.
+= Make a block diagram of the boot process =
+It is needed for new devs and to be able to have an overview of the process and be able to enhance it.
+= Better usage of busybox =
+Enable cool and useful staff from busybox such as passwd, cfdisk, minicom, ...
+(Please post a list to this section for discussion before doing what)
+= Hardware Test Software =
+Hmm... will be described later.
+= Do some magic to be able to pass params to the kernel over reboot =
+Implement (or just improve - something is already done) passing parameters to the next booted kernel. This can be done in different ways:
+* passing kernel params truth RAM
+* using KEXEC kernel function
+* simulate the green button pressure at boot time (to boot in flashing mode)
+* destroy signature magic after usage - even powered down SDRAM can hold data for many seconds
+= Green button =
+Get rid of the green button.
+Rev "E" PCB will still has a provision to install that button, but the board is able to operate without it. Instead the power should be applied/removed several (>~5) times to switch camera to the network boot mode. This can be done manually or with a manageable PoE switch.
+Current (as of January 2008) PCB has rev "D", rev "E" will be available in the second quarter of 2008.
+= Init levels =
+Implement init levels, init 3 should have only GNU/Linux with telnetd, everything camera specific should run from init 5. The default level will be 5, but ktest should be able to pass init=3 to the kernel.
+= NetBoot =
+== Better output ==
+Some more output should be added to netboot to make it more verbose and user-friendly.
+== New function ==
+Add new function and param to read & copy partitions from the flash to NFS for debuging.
+= Ethernet LEDs =
+Hack in to the ethernet driver to make a better usage of leds. For example during flash with pressed button boot with orange led ON, blink orange while booting the kernel, blink with the green led while copying from NFS to flash and green ON when completely flashed and ready to be rebooted. While normal operation leds can be used in a more nice way when now.
+= Genres =
+Enhance Genres plugin to get rid of multiple languages and dependences and rewrite all using only one programming language. Make it more stable.
-=== Camera reflashing over TCP/IP ===
+= camvc =
-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.
+Repair broken/buggy AJAX code, port CGIs to PHP and move to lighthttpd instead of boa. (keep them both at least at the beginning to compare te speed and stability)
+= Security =
-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.
+== Lighthttpd ==
-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.
+Add https to lighthttpd and add .htaccess protected directories.
-Model 333 has 3 memories:
+== Add SSH ==
-# System SDRAM - 32MB
+This has apparently been done.  The model 353 I received (July 2008) has the [http://matt.ucc.asn.au/dropbear/dropbear.html Dropbear]  implementation of ssh.
-# System Flash - 16MB, it holds root file system (see [[333_File_System#cramfs]])
-# "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.
+== Separate user privileges ==
-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.
+Add passwd command, implement users and groups with separated privileges. Make groups for FPGA and other hardware (as HD) access and make Lighthttpd/PHP run as user.
-=== Hardware Test Software ===
+== Netfilter firewall ==
-We definitely need some production test software including memory test for the frame memory, FPGA.
+Port the latest netfilter to be able to setup a firewall on the camera.
-One particular program can be
+= Ideas =
-==== Flash Memory Read ====
+== Flashing via USB ==
-In network boot mode. On rare occasions the flash image gets corrupted and camera does not boot until the boot sector is overwritten. And we do not know what causes the boot sector to be overwritten - bug in a driver? Or something else? What might help is to be able to actually read that corrupted sector and it is definitely possible to do without booting the camera with modified version of the network boot loader. Such program might help with other post mortem analysis of the non-bootable flash images.
+It seems really simple to implement flashing via USB Flash/HD. If the camera find /autoupgrade.sh script on the USB-flash during the boot it upgrade the firmware.

Difference between revisions of "TODO"