Imaging solutions with Free Software & Open Hardware

Who's online

There are currently 0 users online.

DCT type IV implementation

Elphel Development Blog - Sat, 12/17/2016 - 00:15

As we finished with the basic camera functionality and tested the first Eyesis4π built with the new 10393 system boards (it is smaller, requires less power and, is faster) we are moving forward with the in-camera image processing. We plan to combine our current camera calibration methods that require off-line post processing and the real-time image correction using the camera own FPGA resources. This project development will require switching between the actual FPGA coding and the software implementation of the same algorithms before going to the next step – software is still easier to design. The first part was in FPGA realm – it was to implement the fundamental image processing block that we already know we’ll be using and see how much of the resources it needs.

DCT type IV as a building block for in-camera image processing

We consider a small (8×8 pixel) DCT-IV to be a universal block for conditioning of the raw acquired images. Such operations as lens optical aberrations correction, color conversion (de-mosaic) in the presence of the lateral chromatic aberration, image rectification (de-warping) are easier to perform in the frequency domain using convolution-multiplication property and other algorithms.

In post-processing we use DFT (Discrete Fourier Transform) over rather large (64×64 to 512×512) tiles, but that would be too much for the in-camera processing. First is the tile size – for good lenses we do not need that large convolution kernels. Additionally we plan to combine several processing steps into one (based on our off-line post-processing experience) and so we do not need to sub-sample images – in our current software we double resolution of the raw images at the beginning and scale back the final result to reduce image degradation caused by re-sampling.

The second area where we plan to reduce computations is the replacement of the DFT with the DCT that is designed to be fed with the pure real data and so requires less arithmetic operations than DFT that processes complex input values.

Why “type IV” of the DCT?

Fig.1. Signal flow graph for DCT-IV

We already have DCT type II implemented for the JPEG/JP4 compression, and we still needed another one. Type IV is used in audio compression because it can be converted to a modified discrete cosine transform (MDCT) – a procedure when multiple overlapped windows are processed one at a time and the results are seamlessly combined without any block artifacts that are familiar for the JPEG with low settings of the compression quality. We too need lapped transform to process large images with relatively small (much smaller than the image itself) convolution kernels, and DCT-IV is a perfect fit. 8-point DCT-IV allows to implement transformation of 16-point segments with 8-point overlap in a reversible manner – the inverse transformation of 8-point data may be converted to 16-point overlapping segments, and being added together these segments result in the original data.

There is a price though to pay for switching from DFT to DCT – the convolution-multiplication property being so straightforward in FFT gets complicated for DCT[1]. While convolving with symmetrical kernels is still simple (just the kernel has to be transformed differently, but it is anyway done off-line in our case), the arbitrary kernel convolution (or just a shift in image space needed to compensate the lateral chromatic aberration) requires both DCT-IV and DST-IV transformed data. DST-IV can be calculated with the same DCT-IV modules (just by reversing the direction of input data and alternating the sign of the output samples), but it still requires additional hardware resources and/or more processing time. Luckily it is only needed for the direct (image domain to frequency domain) transform, the inverse transform IDCT-IV (frequency to image) does not require DST. And IDCT-IV is actually the same as the direct DCT-IV, so we can again instantiate the same module.

Most of the two-dimensional transforms combine 1-d transform modules (because DCT is a separable transform), so we too started with just an 8-point DCT. There are multiple known factorizations for such algorithm[2] and we used one of them (based on BinDCT-IV) shown in Fig.1.

Fig.2. Simplified diagram of Xilinx DSP48E1 primitive (only used functionality is shown)

DSP primitive in Xilinx Zynq

This algorithm is implemented with a pair of DSP48E1[3] primitives shown in Fig.2. This primitive is flexible and allows to configure different functionality, the diagram contains only the blocks and connections used in the current project. The central part is the multiplier (signed 18 bits by signed 25 bits) with inputs from a pair of multiplexed B registers (B1 and B2, 18 bits wide) and the pre-adder AD register (25 bits). The AD register stores sum/difference of the 25-bit D-register and a multiplexed pair of 25-bit A1 and A2 registers. Any of the inputs can be replaced by zero, so AD can receive D, A1, A2, -A1, -A2, D+A1, D-A1, D+A2 and D-A2 values. Result of the multiplier (43 bits) is stored in the M register and the data from M is combined with the 48-bit output accumulator register P. Final adder can add or subtract M to/from one of the P, 48-bit C-register or just 0, so the output P register can receive +/-M, P+/-M and C+/-M. The wrapper module dsp_ma_preadd_c.v reduces the number of DSP48E1 signals and parameters to those required for the project and in addition to the primitive instance have a simple model of the DSP slice to allow simulation without the DSP48E1 source code for convenience.

Fig.3. One-dimensional 8-point DCT-IV implementation

8-point DCT-IV transform

The DCT-IV implementation module (Fig.3.) operates in 16 clocks cycles (2 clock periods per data item) and the input/output permutations are not included – they can be absorbed in the data source and destination memories. Current implementation does not implement correct rounding and saturation to save resources – such processing can be added to the outputs after analysis for particular application data widths. This module is not in the coder/decoder signal chain so bit-accuracy is not required.

Data is output each other cycle (so two such modules can easily be used to increase bandwidth), while input data is scrambled more, some of the items have to appear twice in a 16-cycle period. This implementation uses two of the DSP48E1 primitives connected in series. First one implements the left half of the Fig.1. graph – 3 rotators (marked R8, and two of R4), four adders, and four subtracters, The second one corresponds to the right half with R1, R5, R9, R13, four adders, and four subtracters. Two of the small memories (register files) – 2 locations before the first DSP and 4 locations before the second effectively increase the number of the DSP internal D registers. The B inputs of the DSPs receive cosine coefficients, the same ROM provides values for both DSP stages.

The diagram shows just the data paths, all the DSP control signals as well as the memories write and read addresses are generated at the defined times decoded from the 16-cycle period. The decoder is based on the spreadsheet draft of the design.

Fig.4. Two-dimensional 8×8 DCT-IV

Two-dimensional 8×8 points DCT-IV

Next diagram Fig.4. show a two-dimensional DCT type IV implementation using four of the 1-d 8-point DCT-IV modules described above. Input data arrives continuously in line-scan order, next 64-item block may follow either immediately or after a delay of at least 16 cycles so the pipelines phases are correctly restarted. Two of the input 8×25 memories (width can be reduced to match input data, 25 is the width of the DSP48E1 inputs) are used to re-order the input data.As each of the 1-d DCT modules require input data at more than a half cycles (see bottom of Fig.3) interleaving with the common memory for both channels is not possible, so each channel has to have a dedicated one. First of the two DCT modules convert even lines of 8 points, the other one – odd lines. The latency of the data output from the RAM in the second channel is made 1 cycle longer, so the output data from the channels also arrive at odd/even time slots and can be multiplexed to a common transpose buffer memory. Minimal size of the buffer is 2 of the 64 item pages (width can be reduced to match application requirements), but having just a two-page buffer increases the minimal pause time between blocks (if they are not immediate), with a four page buffer (and BRAM primitives are larger even if just halves are used) the minimal non-immediate delay of the 16 cycles of a 1-d module is still valid.

The second (vertical) pass is similar to the first (horizontal) one, it also has individual small memories for input data reordering and 2 output de-scrambler memories. It is possible to use a single stage, but the memory should hold at least 17 items (>16) and the primitives are 16-deep, and I believe that splitting in series makes it easier for the placer/router tools to implement the design.

Next steps

Now when the 8×8 point DCT-IV is designed and simulated the next step is to switch to the Java coding (add to our ImageJ plugin for camera calibration and image post-processing), convert calibration data to the form suitable for the future migration to FPGA and try the processing based on the chosen 8×8 DCT-IV. When satisfied with the results – continue with the FPGA coding.

References

[1] Martucci, Stephen A. “Symmetric convolution and the discrete sine and cosine transforms.” IEEE Transactions on Signal Processing 42.5 (1994): 1038-1051. pdf

[2] Rao, K. Ramamohan, and Ping Yip. Discrete cosine transform: algorithms, advantages, applications. Academic press, 2014.

[3] 7 Series DSP48E1 Slice, UG479 (v1.9), Xilinx, Sep. 2016. pdf

12/16/16 [imagej-elphel][master] by AndreyFilippov: merged with nc393 branch

Elphel GIT logs - Fri, 12/16/2016 - 23:07
AndreyFilippov committed changes to the Elphel git project :
merged with nc393 branch

12/16/16 [imagej-elphel][master] by AndreyFilippov: merged with nc393 branch

Elphel GIT logs - Fri, 12/16/2016 - 23:07
AndreyFilippov committed changes to the Elphel git project :
merged with nc393 branch

Boot options 393

Wiki Recent Changes - Fri, 12/16/2016 - 17:27

Internal NAND flash (default):

← Older revision Revision as of 00:27, 17 December 2016 Line 17: Line 17: ==<font color="blue">Boot instructions</font>== ==<font color="blue">Boot instructions</font>== ===Internal NAND flash (default)=== ===Internal NAND flash (default)=== -* Make sure the recovery card is not inserted+* Make sure the recovery card is not inserted (recovery card can stay in) * Power on * Power on Oleg

NAND flash boot rootfs

Wiki Recent Changes - Fri, 12/16/2016 - 16:44

← Older revision Revision as of 23:44, 16 December 2016 (One intermediate revision not shown)Line 1: Line 1: -==Boot from NAND flash (rootfs)==  -* The default boot option - power on.  -* A UBIFS image of rootfs is written to /dev/mtd4 ('''ubi0:elphel393-rootfs''' in bootargs in the device tree) - mounted as '''/'''  -  ==Reflash factory image== ==Reflash factory image== ===Notes=== ===Notes=== -* Update software/firmware or corrupt flash partition+* Will overwrite software/firmware or corrupt flash partition * To update u-boot images, device tree and kernel - booting from micro SD card is not required. * To update u-boot images, device tree and kernel - booting from micro SD card is not required. -* To update rootfs - boot from micro SD card otherwise a mounted flash partition will be rewritten, get corrupt and the camera won't boot - boot from micro SD card and reflash rootfs partition to recover.  +* To update rootfs - boot from micro SD card otherwise a mounted flash partition will be rewritten, get corrupt and the camera might not boot - to recover, boot from micro SD card and reflash rootfs partition.   * '''boot.bin''', '''u-boot-dtb.img''' - most likely won't need updating at all. Only if their partitions get corrupt * '''boot.bin''', '''u-boot-dtb.img''' - most likely won't need updating at all. Only if their partitions get corrupt -** As Zynq's BootROM performs 32KB jumps within the first 128MiB of flash in the search of a boot.bin header with a correct checksum it is possible to flash a few backup images to the 1st flash partition (mtd0) in the device tree. The partition size is 1MB, boot.bin size is normally around 100KB (<192KB - Zynq OCM requirement)+** As Zynq's BootROM performs 32KB jumps within the first 128MiB of flash in the search of a boot.bin header with a correct checksum it is possible to flash a few backup images to the 1st flash partition (mtd0) in the device tree. The partition size is 1MB, boot.bin size is normally around 100KB (<192KB - Zynq's OCM requirement) ===Instructions=== ===Instructions=== -* Use files from '''.../poky/build/tmp/deploy/images/elphel393/nand/'''+* Use files from '''elphel393/bootable-images/elphel393/nand/''' ** '''boot.bin''' ** '''boot.bin''' ** '''u-boot-dtb.img''' ** '''u-boot-dtb.img''' ** '''devicetree.dtb''' ** '''devicetree.dtb''' ** '''uImage''' ** '''uImage''' -** '''rootfs.ubifs''' (<font color='green'>recommended</font>), '''rootfs.ubi''' (<font color='red'>radical</font>)+** '''rootfs.ubi''' or '''rootfs.ubifs''' -* Copy all of the image files to a micro SD card (or boot first from the card then copy over network)+  -* Boot from micro SD card (<font color='red'>important for rootfs updates</font>)+====Option 1====  +* Boot the camera from the micro SD card (<font color='red'>important for rootfs update</font>)  +* Go to the http://192.168.0.9/update_software.html  +* Upload '''uImage''' and '''rootfs.ubi'''  +* Verify, download backup then Flash  +   +====Option 2: manual====  +* Boot the camera from the micro SD card (<font color='red'>important for rootfs update</font>)  +* Copy file to the camera, example from the PC terminal:  + $ scp boot.bin u-boot-dtb.img devicetree.dtb uImage rootfs.ubi root@192.168.0.9:/tmp/ * Reflash what is needed: * Reflash what is needed: ** Reflash SPL ('''boot.bin''', /dev/mtd0) ** Reflash SPL ('''boot.bin''', /dev/mtd0) Oleg

Boot options 393

Wiki Recent Changes - Fri, 12/16/2016 - 16:05

← Older revision Revision as of 23:05, 16 December 2016 Line 70: Line 70: * '''RAM''' - unpack an archive from a &mu;SD card FAT32 partition into RAM but it was tested a while ago: * '''RAM''' - unpack an archive from a &mu;SD card FAT32 partition into RAM but it was tested a while ago:   bootargs = "cma=336M console=ttyPS0,115200 root=/dev/ram rw ip=192.168.0.9 earlyprintk ramdisk_size=262144";   bootargs = "cma=336M console=ttyPS0,115200 root=/dev/ram rw ip=192.168.0.9 earlyprintk ramdisk_size=262144";  +** Changes will not be stored  +** Modify env commands in the u-boot (in elphel393.h or when in the u-boot command line)  +** Carefully check the actual and hardcoded images' sizes in the u-boot (elphel393.h) and the device tree (elphel393_xxx.dts) with the actual sizes.  +** Don't want to waste the RAM - make tiny rootfs ====Notes==== ====Notes==== * when loaded the full-size u-boot can be key-interrupted and override bootargs parameter of the device tree. * when loaded the full-size u-boot can be key-interrupted and override bootargs parameter of the device tree. * '''To build a custom device tree''', see [http://wiki.elphel.com/index.php?title=Poky_2.0_manual SDK manual]''' * '''To build a custom device tree''', see [http://wiki.elphel.com/index.php?title=Poky_2.0_manual SDK manual]''' -  ==<font color="blue">cp210x_gpio.py -h</font>== ==<font color="blue">cp210x_gpio.py -h</font>== Oleg

Poky 2.0 manual

Wiki Recent Changes - Fri, 12/16/2016 - 16:04

Write files to media and boot:

← Older revision Revision as of 23:04, 16 December 2016 (5 intermediate revisions not shown)Line 38: Line 38: </font> </font> ==<font color="blue">Output files</font>== ==<font color="blue">Output files</font>== -Found in the poky's deploy directory: +The names are listed as they appear in the u-boot configuration header file - actual output files have different names: -* files for rootfs in NAND Flash: '''poky/build/tmp/deploy/images/elphel393/nand/'''+ -* files for rootfs on MMC (micro SD card): '''poky/build/tmp/deploy/images/elphel393/mmc/'''+ - + -These names are listed as they appear in the u-boot configuration header file - actual output files have different names:+ * '''boot.bin''' - u-boot as the first stage bootloader = Secondary Program Loader that boots '''u-boot-dtb.img''' * '''boot.bin''' - u-boot as the first stage bootloader = Secondary Program Loader that boots '''u-boot-dtb.img''' * '''u-boot-dtb.img''' - full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > u-boot-dtb.img'') * '''u-boot-dtb.img''' - full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > u-boot-dtb.img'') -* '''devicetree.dtb''' - device tree with listed interfaces, zynq registers, interrupts and drivers+* '''devicetree.dtb''' - device tree with listed interfaces, zynq registers, interrupts and drivers.  +** ''elphel393/bootable-images/mmc/devicetree.dtb'' - mount rootfs from mmc partition  +** ''elphel393/bootable-images/nand/devicetree.dtb'' - mount rootfs from NAND flash * '''uImage''' - kernel, drivers * '''uImage''' - kernel, drivers -* '''rootfs.ubifs''' or '''rootfs.tar.gz''' - rootfs+* '''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz''' - rootfs in different formats  +   +They are found poky's deploy directory '''elphel393/poky/build/tmp/deploy/images/elphel393/''', linked to  +'''elphel393/bootable-images/''' for convenience.  +   +* complete set of files for rootfs in NAND Flash: ''elphel393/bootable-images/nand/''  +* complete set of files for rootfs on MMC (micro SD card): ''elphel393/bootable-images/mmc/'' -==<font color="blue">Boot options</font>==+==<font color="blue">Write files to media and boot</font>== -===Boot from micro SD card (rootfs)===+===Boot from micro SD card=== -* The micro SD card/adapter must be modified for this boot mode (to keep CD pin high) - only then the camera will boot+* Use recovery or regular &mu;SD card * EXT4 partition mounted as '''/''' * EXT4 partition mounted as '''/''' -* [[Sd_boot_rootfs|Detailed instructions]]+[[Sd_boot_rootfs|Detailed instructions]] -===Boot from NAND flash (rootfs)===+===Boot from NAND flash=== * The default boot option - power on. * The default boot option - power on. * A UBIFS image is written to /dev/mtd4 - is mounted as '''/''' * A UBIFS image is written to /dev/mtd4 - is mounted as '''/''' -* [[NAND_flash_boot_rootfs|Detailed instructions]]+[[NAND_flash_boot_rootfs|Detailed instructions]] ===Notes=== ===Notes=== -* It is possible to unpack rootfs to RAM not mounting any partitions ('''/''' in RAM, ramdisk):+* [[Boot_options_393|'''Read more''']] about boot options. -** Changes are not stored+ -** Boot faster?+ -** Work faster?+ -** Modify env commands in the u-boot (in elphel393.h or when in the u-boot command line)+ -** Carefully check the actual and hardcoded images' sizes in the u-boot (elphel393.h) and the device tree (elphel393_xxx.dts) with the actual sizes.+ ==<font color="blue">Setup</font>== ==<font color="blue">Setup</font>== Oleg

Poky 2.0 manual

Wiki Recent Changes - Fri, 12/16/2016 - 15:54

Boot options:

← Older revision Revision as of 22:54, 16 December 2016 (3 intermediate revisions not shown)Line 38: Line 38: </font> </font> ==<font color="blue">Output files</font>== ==<font color="blue">Output files</font>== -Found in the poky's deploy directory: +The names are listed as they appear in the u-boot configuration header file - actual output files have different names: -* files for rootfs in NAND Flash: '''poky/build/tmp/deploy/images/elphel393/nand/'''+ -* files for rootfs on MMC (micro SD card): '''poky/build/tmp/deploy/images/elphel393/mmc/'''+ - + -These names are listed as they appear in the u-boot configuration header file - actual output files have different names:+ * '''boot.bin''' - u-boot as the first stage bootloader = Secondary Program Loader that boots '''u-boot-dtb.img''' * '''boot.bin''' - u-boot as the first stage bootloader = Secondary Program Loader that boots '''u-boot-dtb.img''' * '''u-boot-dtb.img''' - full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > u-boot-dtb.img'') * '''u-boot-dtb.img''' - full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > u-boot-dtb.img'') -* '''devicetree.dtb''' - device tree with listed interfaces, zynq registers, interrupts and drivers+* '''devicetree.dtb''' - device tree with listed interfaces, zynq registers, interrupts and drivers.  +** ''elphel393/bootable-images/mmc/devicetree.dtb'' - mount rootfs from mmc partition  +** ''elphel393/bootable-images/nand/devicetree.dtb'' - mount rootfs from NAND flash * '''uImage''' - kernel, drivers * '''uImage''' - kernel, drivers -* '''rootfs.ubifs''' or '''rootfs.tar.gz''' - rootfs+* '''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz''' - rootfs in different formats  +   +They are found poky's deploy directory '''elphel393/poky/build/tmp/deploy/images/elphel393/''', linked to  +'''elphel393/bootable-images/''' for convenience.  +   +* complete set of files for rootfs in NAND Flash: ''elphel393/bootable-images/nand/''  +* complete set of files for rootfs on MMC (micro SD card): ''elphel393/bootable-images/mmc/'' -==<font color="blue">Boot options</font>==+==<font color="blue">Write files to media and boot</font>== ===Boot from micro SD card (rootfs)=== ===Boot from micro SD card (rootfs)=== -* The micro SD card/adapter must be modified for this boot mode (to keep CD pin high) - only then the camera will boot+* Use recovery or regular &mu;SD card * EXT4 partition mounted as '''/''' * EXT4 partition mounted as '''/''' -* [[Sd_boot_rootfs|Detailed instructions]]+[[Sd_boot_rootfs|Detailed instructions]] ===Boot from NAND flash (rootfs)=== ===Boot from NAND flash (rootfs)=== * The default boot option - power on. * The default boot option - power on. * A UBIFS image is written to /dev/mtd4 - is mounted as '''/''' * A UBIFS image is written to /dev/mtd4 - is mounted as '''/''' -* [[NAND_flash_boot_rootfs|Detailed instructions]]+[[NAND_flash_boot_rootfs|Detailed instructions]] ===Notes=== ===Notes=== * It is possible to unpack rootfs to RAM not mounting any partitions ('''/''' in RAM, ramdisk): * It is possible to unpack rootfs to RAM not mounting any partitions ('''/''' in RAM, ramdisk): -** Changes are not stored+** Changes will not be stored -** Boot faster?+ -** Work faster?+ ** Modify env commands in the u-boot (in elphel393.h or when in the u-boot command line) ** Modify env commands in the u-boot (in elphel393.h or when in the u-boot command line) ** Carefully check the actual and hardcoded images' sizes in the u-boot (elphel393.h) and the device tree (elphel393_xxx.dts) with the actual sizes. ** Carefully check the actual and hardcoded images' sizes in the u-boot (elphel393.h) and the device tree (elphel393_xxx.dts) with the actual sizes.  +** Don't want to waste RAM ==<font color="blue">Setup</font>== ==<font color="blue">Setup</font>== Oleg

Boot options 393

Wiki Recent Changes - Fri, 12/16/2016 - 11:43

← Older revision Revision as of 18:43, 16 December 2016 (3 intermediate revisions not shown)Line 51: Line 51:   ./cp210x_gpio.py 0xf;   ./cp210x_gpio.py 0xf; -===Other boot options===+===Other boot options (set in u-boot or device tree)=== -The instructions are defined by the 3 options above.+Follow the instructions of the 3 options above but with different bootloader or device tree. -They define where the camera will load the u-boot, device tree and kernel from: &mu;SD card or NAND flash. The location of rootfs ("/") is set in the device tree. Available locations for rootfs:+   +The 3 options above define where the cpu's boot ROM loads SPL version of u-boot from: NAND flash or &mu;SD card. The SPL u-boot loads the full-size u-boot.  +In its turn he full size u-boot can be instructed where to load the device tree and the kernel from, available options:  +* NAND flash (default if SPL was loaded from flash)  +* &mu;SD card (default if SPL was loaded from &mu;SD card)  +* internal SSD (not tested)  +* network (not tested)  +   +Next, the location of rootfs ("/") is set in the device tree. Available locations for rootfs:  +  * '''any &mu;SD card partition'''. The default device tree parameter is: * '''any &mu;SD card partition'''. The default device tree parameter is:   bootargs = "cma=336M console=ttyPS0,115200 root=/dev/mmcblk0p2 rw ip=192.168.0.9 earlyprintk rootwait rootfstype=ext4";   bootargs = "cma=336M console=ttyPS0,115200 root=/dev/mmcblk0p2 rw ip=192.168.0.9 earlyprintk rootwait rootfstype=ext4"; Line 62: Line 71:   bootargs = "cma=336M console=ttyPS0,115200 root=/dev/ram rw ip=192.168.0.9 earlyprintk ramdisk_size=262144";   bootargs = "cma=336M console=ttyPS0,115200 root=/dev/ram rw ip=192.168.0.9 earlyprintk ramdisk_size=262144";  +====Notes====  +* when loaded the full-size u-boot can be key-interrupted and override bootargs parameter of the device tree.  +* '''To build a custom device tree''', see [http://wiki.elphel.com/index.php?title=Poky_2.0_manual SDK manual]''' -'''To build a custom device tree''', see [http://wiki.elphel.com/index.php?title=Poky_2.0_manual SDK manual]'''  ==<font color="blue">cp210x_gpio.py -h</font>== ==<font color="blue">cp210x_gpio.py -h</font>== Oleg

Ezynq

Wiki Recent Changes - Fri, 12/16/2016 - 11:13

"Free" the code part:

← Older revision Revision as of 18:13, 16 December 2016 Line 14: Line 14: <b>as of 2016/03/18...</b> <b>as of 2016/03/18...</b> * u-boot-xlnx master-next branch is removed long ago - so the link above is broken * u-boot-xlnx master-next branch is removed long ago - so the link above is broken  +  +<b>as of 2016/06/25...</b>  +* ezynq depends on original u-boot instead of u-boot-xlnx ==Supported boards== ==Supported boards== Oleg

12/15/16 [elphel-apps-camogm][master] by Mikhail Karpenko: Add disk reading test to camogm_test

Elphel GIT logs - Thu, 12/15/2016 - 19:57
Mikhail Karpenko committed changes to the Elphel git project :
Add disk reading test to camogm_test

12/15/16 [elphel-apps-camogm][master] by Mikhail Karpenko: Add disk reading test to camogm_test

Elphel GIT logs - Thu, 12/15/2016 - 19:57
Mikhail Karpenko committed changes to the Elphel git project :
Add disk reading test to camogm_test

12/15/16 [elphel-apps-camogm][master] by Mikhail Karpenko: Merge branch 'master' of https://github.com/Elphel/elphel-apps-camogm

Elphel GIT logs - Thu, 12/15/2016 - 19:56
Mikhail Karpenko committed changes to the Elphel git project :
Merge branch 'master' of https://github.com/Elphel/elphel-apps-camogm

12/15/16 [elphel-apps-camogm][master] by Mikhail Karpenko: Merge branch 'master' of https://github.com/Elphel/elphel-apps-camogm

Elphel GIT logs - Thu, 12/15/2016 - 19:56
Mikhail Karpenko committed changes to the Elphel git project :
Merge branch 'master' of https://github.com/Elphel/elphel-apps-camogm

12/15/16 [linux-elphel][master] by Mikhail Karpenko: Process late IRQs, add time stamps to datascope

Elphel GIT logs - Thu, 12/15/2016 - 19:54
Mikhail Karpenko committed changes to the Elphel git project :
Process late IRQs, add time stamps to datascope

12/15/16 [linux-elphel][] by Mikhail Karpenko: Process late IRQs, add time stamps to datascope

Elphel GIT logs - Thu, 12/15/2016 - 19:54
Mikhail Karpenko committed changes to the Elphel git project :
Process late IRQs, add time stamps to datascope

Tmp manual

Wiki Recent Changes - Thu, 12/15/2016 - 19:25

← Older revision Revision as of 02:25, 16 December 2016 (6 intermediate revisions not shown)Line 1: Line 1:  +==<font color="blue">Important Notes</font>==  +* As of 2016/12/15, the software supports only 5MPix sensors, for 14MPix, please see:  +**[http://wiki.elphel.com/index.php?title=Tmp_manual&oldid=14676 older version of this manual with links to older software images]  + ==<font color="blue">In the package</font>== ==<font color="blue">In the package</font>== -* 10393 system+* 10393 camera system {| {| |[[File:NC393-CS marked ports.jpeg|thumb|200px]] |[[File:NC393-CS marked ports.jpeg|thumb|200px]] |} |} -* Power supply wall adapter (48V)+* Power supply wall adapter (default: 18-75V, [[10393_power|more information]]) * CAT6 network cable * CAT6 network cable * &mu;USB-to-USB cable * &mu;USB-to-USB cable Line 13: Line 17: * Connect to LAN using the network cable * Connect to LAN using the network cable -NOTE: the boot time is ~30s+====Notes====  +* Boot time: ~40s  +* The default boot is from the on-board NAND flash. [[Boot_options_393|More information]] on available boot options and recovery boot. ==<font color="blue">Connections</font>== ==<font color="blue">Connections</font>== Line 22: Line 28: |} |} * [[10393_power|Power supply]] * [[10393_power|Power supply]] -  -==<font color="blue">Important Notes</font>==  -* As of 2016/12/15, the software supports only 5MPix sensors, for 14MPix, please see:  -**[http://wiki.elphel.com/index.php?title=Tmp_manual&oldid=14676 older version of this manual with links to older software images]  ==<font color="blue">Defaults</font>== ==<font color="blue">Defaults</font>== Line 46: Line 48: * /etc/elphel393/init_elphel393.py * /etc/elphel393/init_elphel393.py -==<font color="blue">Boot</font>==  -Normally camera boots from the internal NAND flash memory, and it is always possible to boot it from the micro SD card, so even corruption of files on the internal flash will not "brick" the system. There are no buttons or switches on the camera and the camera should be instructed to change the boot source. Always booting from micro SD is not practical - in that case it would not be possible to leave a non-bootable card (intended just for image/video storage) in the camera slot.  -There are two ways to switch camera to the micro SD boot mode. One requires camera to be connected to the host computer with the USB cable (micro USB socket under the network jack - marked "console" on the picture). There is an internal USB-to-serial converter in the camera (CP2103) that offers 4 additional GPIO signals in addition to just the serial connection. One of these signals selects the boot source (GPIO0 - 0 - MMC, 1 - NAND), another (GPIO3 - 0 reset, 1 - normal operation). Unfortunately GPIO control of the CP2103 is not in a mainline cp210x Linux driver so this functionality requires a modified version (see instructions below).  -  -Another way to "tell" the camera to boot from the &mu;SD card instead of the internal NAND flash is to use a mechanically modified card or card adapter (such cards are provided with the camera). Standard specifies two alternative ways for detection of the card presence - one is a mechanical switch (closed when the card is inserted), another is a pull-up resistor on a data line. Camera uses both signals at boot time to determine the boot source:  -* Switch not closed, pull-up resistor not detected -> no card present, boot from the internal NAND flash  -* Switch closed -> data (non-bootable) card present, boot from the internal NAND flash  -* Switch not closed, pull-up resistor is detected -> bootable card present, boot from the MMC card  -  -* [default behavior] on power-on the camera boots from NAND flash: u-boot, device tree and kernel.  -devicetree has "chosen = ...root=/dev/mmcblk0p2..." - rootfs is on the micro SD card second partition. Thus, the &mu;SD card must be inserted.  -* boot from &mu;SD card only options:  -** A modified card that doesn't lock the mechanical CD pin in the slot - it's done by carefully filing off the corner (see Fig.2) - most cards have circuitry there and get damaged.  -** &mu;USB-to-USB cable: in Linux compile [https://sourceforge.net/p/elphel/cp210x_gpio/ci/master/tree/ this driver], connect camera to PC, reload the driver then type:  - ./cp210x_gpio.py 0x6;  - ./cp210x_gpio.py 0xe;  -{|  -|[[File:Recover mmc.jpeg|130px|thumb|Fig.2 Recovery &mu;SD card ('cut' corner) - enforces the system board to boot from it]]  -|}  ==<font color="blue">Command line access</font>== ==<font color="blue">Command line access</font>== Oleg

Boot options 393

Wiki Recent Changes - Thu, 12/15/2016 - 19:04

Other boot options:

New page

==<font color="blue">Description</font>==
Normally camera boots from the internal NAND flash memory, and it is always possible to boot it from the micro SD card, so even corruption of files on the internal flash will not "brick" the system. There are no buttons or switches on the camera - it should be instructed to change the boot source. Always booting from micro SD is not practical - in that case it would not be possible to leave a non-bootable card (intended just for image/video storage) in the camera slot.

There are two ways to switch camera to the micro SD boot mode.

One requires camera to be connected to the host computer with the USB cable (micro USB socket under the network jack - marked "console" on the picture). There is an internal USB-to-serial converter in the camera (CP2103) that offers 4 additional GPIO signals in addition to just the serial connection. One of these signals selects the boot source (GPIO0 - 0 - MMC, 1 - NAND), another (GPIO3 - 0 reset, 1 - normal operation). Unfortunately GPIO control of the CP2103 is not in a mainline cp210x Linux driver so this functionality requires a modified version (see instructions below).

Another way to "tell" the camera to boot from the &mu;SD card instead of the internal NAND flash is to use a mechanically modified card or card adapter (such cards are provided with the camera). Standard specifies two alternative ways for detection of the card presence - one is a mechanical switch (closed when the card is inserted), another is a pull-up resistor on a data line. Camera uses both signals at boot time to determine the boot source:
* Switch not closed, pull-up resistor not detected -> no card present, boot from the internal NAND flash
* Switch closed -> data (non-bootable) card present, boot from the internal NAND flash
* Switch not closed, pull-up resistor is detected -> bootable card present, boot from the MMC card

{|
|[[File:Recover mmc.jpeg|130px|thumb|Fig.1 Recovery &mu;SD card ('cut' corner) - forces the system board to boot from it]]
|}

==<font color="blue">Boot instructions</font>==
===Internal NAND flash (default)===
* Make sure the recovery card is not inserted
* Power on

===Recovery micro SD card===
Requirements:
* A modified card that doesn't lock the mechanical CD pin in the slot - it's done by carefully filing off the corner (see Fig.1) - most cards have circuitry there and get damaged. Use the one that came with the camera or order a new one.
Instructions:
* insert the card, power on

===Regular micro SD card===
Requirements:
* &mu;USB-to-USB cable
* Linux: compile [https://sourceforge.net/p/elphel/cp210x_gpio/ci/master/tree/ cp210x driver]
Instructions:
* Power on
* Connect the camera's console port (see Fig.2, right under the &mu;SD slot) to PC using &mu;USB-to-USB cable
{|
|[[File:NC393-CS marked ports.jpeg|thumb|200px|Fig.2 10393 camera ports]]
|}
* Reload the cp210x driver:
** unplug the &mu;USB-to-USB cable
** In the terminal from the directory where the driver was built, run:
sudo rmmod cp210x
sudo insmod cp210x.ko
** plug the cable back (the driver will stay loaded until the PC is rebooted).

* In the terminal from the directory where the driver was built, run:
./cp210x_gpio.py 0x6;
./cp210x_gpio.py 0xe;

* To reboot back to NAND flash w/o power cycling:
./cp210x_gpio.py 0x7;
./cp210x_gpio.py 0xf;

===Other boot options===
The instructions are defined by the 3 options above.
They define where the camera will load the u-boot, device tree and kernel from: &mu;SD card or NAND flash. The location of rootfs ("/") is set in the device tree. Available locations for rootfs:
* '''any &mu;SD card partition'''. The default device tree parameter is:
bootargs = "cma=336M console=ttyPS0,115200 root=/dev/mmcblk0p2 rw ip=192.168.0.9 earlyprintk rootwait rootfstype=ext4";
* '''any internal NAND flash partition'''. The default parameter is:
bootargs = "cma=336M console=ttyPS0,115200 root=ubi0:elphel393-rootfs rw ip=192.168.0.9 earlyprintk rootwait rootfstype=ubifs ubi.mtd=4,2048";
* '''any internal SSD''' (if installed) partition. There is no default device tree.
* '''RAM''' - unpack an archive from a &mu;SD card FAT32 partition into RAM but it was tested a while ago:
bootargs = "cma=336M console=ttyPS0,115200 root=/dev/ram rw ip=192.168.0.9 earlyprintk ramdisk_size=262144";


'''To build a custom device tree''', see [http://wiki.elphel.com/index.php?title=Poky_2.0_manual SDK manual]'''

==<font color="blue">cp210x_gpio.py -h</font>==
$./cp210x_gpio.py -h
usage: cp210x_gpio.py [-h] [-d DEVICE] [-m MASK] [gpio_value]

positional arguments:
gpio_value hex value for GPIO. Example (GPIO[3:0]): 0xf - all
1's, 0x0 - all 0's. If not specified - read GPIO only

optional arguments:
-h, --help show this help message and exit
-d DEVICE, --device DEVICE
USB device. Default: /dev/ttyUSB0
-m MASK, --mask MASK hex value for masking out GPIO bits: 1 - enable
rewrite, 0 - disable. Example (GPIO[3:0]): -m 0xf


[[Category:393]] Oleg

Boot options 393

Wiki Recent Changes - Thu, 12/15/2016 - 18:37

New page

==<font color="blue">Description</font>==
Normally camera boots from the internal NAND flash memory, and it is always possible to boot it from the micro SD card, so even corruption of files on the internal flash will not "brick" the system. There are no buttons or switches on the camera - it should be instructed to change the boot source. Always booting from micro SD is not practical - in that case it would not be possible to leave a non-bootable card (intended just for image/video storage) in the camera slot.

There are two ways to switch camera to the micro SD boot mode.

One requires camera to be connected to the host computer with the USB cable (micro USB socket under the network jack - marked "console" on the picture). There is an internal USB-to-serial converter in the camera (CP2103) that offers 4 additional GPIO signals in addition to just the serial connection. One of these signals selects the boot source (GPIO0 - 0 - MMC, 1 - NAND), another (GPIO3 - 0 reset, 1 - normal operation). Unfortunately GPIO control of the CP2103 is not in a mainline cp210x Linux driver so this functionality requires a modified version (see instructions below).

Another way to "tell" the camera to boot from the &mu;SD card instead of the internal NAND flash is to use a mechanically modified card or card adapter (such cards are provided with the camera). Standard specifies two alternative ways for detection of the card presence - one is a mechanical switch (closed when the card is inserted), another is a pull-up resistor on a data line. Camera uses both signals at boot time to determine the boot source:
* Switch not closed, pull-up resistor not detected -> no card present, boot from the internal NAND flash
* Switch closed -> data (non-bootable) card present, boot from the internal NAND flash
* Switch not closed, pull-up resistor is detected -> bootable card present, boot from the MMC card

{|
|[[File:Recover mmc.jpeg|130px|thumb|Fig.1 Recovery &mu;SD card ('cut' corner) - forces the system board to boot from it]]
|}

==<font color="blue">Boot instructions</font>==
===Internal NAND flash (default)===
* Make sure the recovery card is not inserted
* Power on

===Recovery micro SD card===
Requirements:
* A modified card that doesn't lock the mechanical CD pin in the slot - it's done by carefully filing off the corner (see Fig.1) - most cards have circuitry there and get damaged. Use the one that came with the camera or order a new one.
Instructions:
* insert the card, power on

===Regular micro SD card===
Requirements:
* &mu;USB-to-USB cable
* Linux: compile [https://sourceforge.net/p/elphel/cp210x_gpio/ci/master/tree/ cp210x driver]
Instructions:
* Power on
* Connect the camera's console port (see Fig.2, right under the &mu;SD slot) to PC using &mu;USB-to-USB cable
{|
|[[File:NC393-CS marked ports.jpeg|thumb|200px|Fig.2 10393 camera ports]]
|}
* Reload the cp210x driver:
** unplug the &mu;USB-to-USB cable
** In the terminal from the directory where the driver was built, run:
sudo rmmod cp210x
sudo insmod cp210x.ko
** plug the cable back (the driver will stay loaded until the PC is rebooted).

* In the terminal from the directory where the driver was built, run:
./cp210x_gpio.py 0x6;
./cp210x_gpio.py 0xe;


==<font color="blue">cp210x_gpio.py -h</font>==
$./cp210x_gpio.py -h
usage: cp210x_gpio.py [-h] [-d DEVICE] [-m MASK] [gpio_value]

positional arguments:
gpio_value hex value for GPIO. Example (GPIO[3:0]): 0xf - all
1's, 0x0 - all 0's. If not specified - read GPIO only

optional arguments:
-h, --help show this help message and exit
-d DEVICE, --device DEVICE
USB device. Default: /dev/ttyUSB0
-m MASK, --mask MASK hex value for masking out GPIO bits: 1 - enable
rewrite, 0 - disable. Example (GPIO[3:0]): -m 0xf


[[Category:393]] Oleg

Pages

Subscribe to www3.elphel.com aggregator