[Elphel-support] Kernel versions in NC353 and NC393 cameras

[support-list]

Hello Emil,

We did not try to update NC353 camera to a newer kernel - our distro is based on Axis software, but they abandoned their processor and stopped supporting new kernel development for it. That processor had unique architecture (arch/cris) and there is nobody upstream now on this branch. And we do not have adequate resources to perform all this porting/maintenance development on our own.

With NC393 we are definitely behind schedule, we planned to release the updated PCBs by the end of 2014 and I'm still not done with the full testing (this involves significant part of the FPGA code+drivers development). Significant part of the 2014 (and the end of 2013) was spent on the work that we did not anticipate. This development was needed to make it possible to use Xilinx Zynq SOC with Free Software and Free Software tools.

First it was a catch with a bootloader - building U-Boot for custom hardware required incorporating code generated by Xilinx tools, and that proprietary code had proprietary license, so it would be illegal for us to distribute our products - we would violate either Xilinx license or GPLv2 of U-Boot. Recently Xilinx released an option to generate the hardware-specific FSBL code under GPLv2, but it happened a full year after we developed a replacement code generator taht we consider more convenient - it is Free Software, written in Python, uses plain text configuration files and has multiple debugging options, providing full control over booting new, yet untested hardware.

Next part of the development was replacing Xilinx Vivado GUI with a more flexible and customizable environment while keeping the power of the modern IDE based on Eclipse. That work was started (and most part of the code was written then) many years ago, when developing code for NC353, but it was not finalized and we continued to use old versions of Xilinx ISE (it was usually very difficult to upgrade to a new version - the old code did not compile with the new tools). Now, starting new code for the new camera it seemed to be a good time to  finish that project and start using it. That work is done by now, the new Eclipse plugin allows Verilog code development (this part is based on existing VEditor with added functionality), launching external tools with flexible output parsing. Plugin uses XML-based TSL (tool specification language) making it possible to integrate different tools without the need to modify the plugin code itself. Currently we have configurations for Xilinx Vivado and Xilinx ISE, it should be rather easy to add tools from the other manufacturers, such as Altera. This PDF file has some screenshots  of the VDT plugin: for https://github.com/Elphel/vdt-docs/raw/master/VDT-UserManualAddendum.pdf 

Third portion of the development we did not plan was the replacement of the Xilinx MIG (Memory interface Generator) - it uses encrypted Verilog modules even for Xilinx hard primitives, making it incompatible with Elphel code released under GNU GPLv3. It also can not be simulated using Icarus Verilog we use. This project is documented in our blog - http://blog.elphel.com/2014/06/ddr3-memory-interface-on-xilinx-zynq-soc-free-software-compatible/ .

It seems that by now we have resolved all these unexpected issues and the road is clear for the NC393 code development itself. I also finished some other projects that required immediate attention and starting next week plan to get deep into the new camera code development. We are also working now on getting more developers into our team, so hopefully the things will start moving faster.

Andrey




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://support.elphel.com/pipermail/support-list_support.elphel.com/attachments/20141229/6cb888b1/attachment-0002.html>