Serial console access:

← Older revision Revision as of 22:20, 19 December 2016 (6 intermediate revisions not shown)Line 6: Line 6: * 10393 camera system * 10393 camera system {| {| -|[[File:NC393-CS marked ports.jpeg|thumb|200px]]+|[[File:NC393-CS marked ports.jpeg|thumb|200px|Fig.1 10393 interfaces]] |} |} * Power supply wall adapter (default: 18-75V, [[10393_power|more information]]) * Power supply wall adapter (default: 18-75V, [[10393_power|more information]]) Line 18: Line 18: ====Notes==== ====Notes==== -* Boot time: ~40s+* Boot time: ~30s * The default boot is from the on-board NAND flash. [[Boot_options_393|More information]] on available boot options and recovery boot. * 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>==  -* Connect [[FPC_cables|sensors to system board]] - FPC cables are not symmetrical  -* Ports:  -{|  -|[[File:NC393-CS marked ports.jpeg|thumb|200px]]  -|}  -* [[10393_power|Power supply]]  ==<font color="blue">Defaults</font>== ==<font color="blue">Defaults</font>== Line 43: Line 35: |} |} -* The IP address is set in the ''/etc/elphel393/init_elphel393.py'' in the currenly mounted rootfs ("/").+* The default IP address is set in the ''/etc/elphel393/init_elphel393.py''. - + -==<font color="blue">init_elphel393.py</font>==+ -* /etc/elphel393/init_elphel393.py+ - + - + ==<font color="blue">Command line access</font>== ==<font color="blue">Command line access</font>== -ssh root@192.168.0.9+* ssh from PC terminal:  + $ ssh root@192.168.0.9 ==<font color="blue">Serial console access</font>== ==<font color="blue">Serial console access</font>== -* Use a ''microUSB-USB cable'' to connect to PC - the cable's end should be thin enough otherwise interferes with the micro SD card.+* Use a ''microUSB-USB cable'' to connect '''console &mu;USB port''' (see Fig.1) to PC - the cable's end should be thin enough otherwise interferes with an inserted mmc ('''m'''ulti '''m'''edia '''c'''ard = &mu;SD card). * Linux: '''minicom -c on''' * Linux: '''minicom -c on''' Oleg

← Older revision Revision as of 21:29, 19 December 2016 Line 85: Line 85: ** Inter-camera module synchronization with a 4-conductor flex cables. ** Inter-camera module synchronization with a 4-conductor flex cables. ** Two of the 10-conductor flex cable ports that carry 3.3VDC, 5.0VDC, USB, i2c and GPIO, compatible with existing [[103695|103695 IMU adapter]] and [[103696|103696 GPS adapter]] boards. ** Two of the 10-conductor flex cable ports that carry 3.3VDC, 5.0VDC, USB, i2c and GPIO, compatible with existing [[103695|103695 IMU adapter]] and [[103696|103696 GPS adapter]] boards.  +  +==Modifications==  +* [http://community.elphel.com/pictures/10393/FIX_boot_from_flash/ Fix boot from flash/mmc] [[Category:393]] [[Category:393]] Oleg

Important Notes:

← Older revision Revision as of 18:39, 19 December 2016 (8 intermediate revisions not shown)Line 1: Line 1: ==<font color="blue">Important Notes</font>== ==<font color="blue">Important Notes</font>== -* As of 2016/12/15, the software supports only 5MPix sensors, for 14MPix, please see:+* As of 2016/12/15, the software ported from 10353 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] **[http://wiki.elphel.com/index.php?title=Tmp_manual&oldid=14676 older version of this manual with links to older software images] Line 59: Line 59: ** likely device: <b>/dev/ttyUSB0</b> ** likely device: <b>/dev/ttyUSB0</b> ** settings: <b>115200 8N1, no</b> for hardware/software flow control ** settings: <b>115200 8N1, no</b> for hardware/software flow control  +  +==<font color="blue">web interface (camvc)</font>==  +http://192.168.0.9/closeme.html (will get changed soon) ==<font color="blue">Get images</font>== ==<font color="blue">Get images</font>== Line 91: Line 94: Example 1: (provide a correct media mount point) Example 1: (provide a correct media mount point) <font size='2'> <font size='2'> -* http://192.168.0.9/camogm.html+* http://192.168.0.9/camogmgui.php -</font>+ - + -Example 2:+ -<font size='2'>+ -* channel '''0''', '''/dev/sda1''', w/o a file name prefix+ -** setup:+ - http://192.168.0.9/camogm.php?chn=0&cmd=prefix=/mnt/sda1/;+ -** start:+ - http://192.168.0.9/camogm.php?chn=0&cmd=start;+ -** stop:+ - http://192.168.0.9/camogm.php?chn=0&cmd=stop;+ </font> </font> Line 110: Line 102: * channel '''2''', '''/home/root''', file prefix='''test_''', '''1GB''' or '''10min''' files whichever occurs first * channel '''2''', '''/home/root''', file prefix='''test_''', '''1GB''' or '''10min''' files whichever occurs first ** setup and start (in one line): ** setup and start (in one line): -  echo "format=mov;status=/var/tmp/camogm2.status;prefix=/home/root/test_;duration=600;length=1073741824;start" > /var/volatile/camogm_cmd2+  echo "format=mov;status=/var/tmp/camogm.status;prefix=/home/root/test_;duration=600;length=1073741824;start" > /var/volatile/camogm_cmd ** stop recording: ** stop recording: -  echo "stop" > /var/volatile/camogm_cmd2+  echo "stop" > /var/volatile/camogm_cmd   sync   sync </font> </font> ==<font color="blue">Change parameters</font>== ==<font color="blue">Change parameters</font>== -* http://192.168.0.9/controls.html - previews and basic parameters:+* http://192.168.0.9/autocampars.php - read & write parameters (through parsedit.php), save configuration (if booted from NAND flash - "shutdown -r now" will sync changes or copy /etc/elphel393/*.xml to /tmp/rootfs.ro/etc/elphel393/ (lower layer of overlayfs), if booted from mmc - no need to reboot, just '''sync''') -** Exposure - the values are in the sensor lines. Currently conversion to seconds is not correct.+* parsedit.php -** WB - r,g,b gains+The response is in XML form: -** Quality - compression quality - individual for compressor but common for the buffer driver - it's better to have the same value for all channels.+ -* For 5MPix the startup settings are defined int the ''/usr/local/verilog/startup5'' on the micro SD card, FAT32 partition:+Read: -  ...+ http://192.168.0.9/parsedit.php?immediate&sensor_port=0&PAR1&PAR2 - -c write_sensor_i2c  all 1 0 0x9009001e (exposure)+Change: - -c write_sensor_i2c  all 1 0 0x9035000a (set all gains to 0xa)+  http://192.168.0.9/parsedit.php?immediate&sensor_port=0&PAR1=VAL1&PAR2=VAL2 - -c write_sensor_i2c  all 1 0 0x902c000e (blue gain to 0xe)+  - -c write_sensor_i2c  all 1 0 0x9009001d (red gain to 0xd)+Note 1: It's just if the parameter value is specified it will be applied. The call can have mixed specified and unspecified parameters. - ...+  -{|+Note 2: The new value is read on the next call. -|[[File:10393_controls.jpeg|thumb|200px]]+  -|}+===Notes===  +* parsedit.php and autocampars.php were ported from 353 camera series. There are a few changes from the originals related to 4x sensor ports:  +** parameters are individual for each sensor port - writing parameters to multiple port at once is controlled with a (bit-)'''mask''' input box  +** if opened w/o sensor_port specified the page will show links to available ports  +** '''sensor_port=x''', where x=0..3 - in the address string - for a single sensor camera it is normally 0 ==<font color="blue">Temperature monitor</font>== ==<font color="blue">Temperature monitor</font>== Oleg

Mikhail Karpenko committed changes to the Elphel git project :
Fix incorrect updates of write pointer in disk driver

Mikhail Karpenko committed changes to the Elphel git project :
Fix incorrect updates of write pointer in disk driver

AndreyFilippov committed changes to the Elphel git project :
implementng mdct/imdct

AndreyFilippov committed changes to the Elphel git project :
implementng mdct/imdct

AndreyFilippov committed changes to the Elphel git project :
debugging DCT library

AndreyFilippov committed changes to the Elphel git project :
debugging DCT library

Change parameters:

← Older revision Revision as of 01:10, 18 December 2016 (7 intermediate revisions not shown)Line 59: Line 59: ** likely device: <b>/dev/ttyUSB0</b> ** likely device: <b>/dev/ttyUSB0</b> ** settings: <b>115200 8N1, no</b> for hardware/software flow control ** settings: <b>115200 8N1, no</b> for hardware/software flow control  +  +==<font color="blue">web interface (camvc)</font>==  +http://192.168.0.9/closeme.html (will get changed soon) ==<font color="blue">Get images</font>== ==<font color="blue">Get images</font>== Line 91: Line 94: Example 1: (provide a correct media mount point) Example 1: (provide a correct media mount point) <font size='2'> <font size='2'> -* http://192.168.0.9/camogm.html+* http://192.168.0.9/camogmgui.php -</font>+ - + -Example 2:+ -<font size='2'>+ -* channel '''0''', '''/dev/sda1''', w/o a file name prefix+ -** setup:+ - http://192.168.0.9/camogm.php?chn=0&cmd=prefix=/mnt/sda1/;+ -** start:+ - http://192.168.0.9/camogm.php?chn=0&cmd=start;+ -** stop:+ - http://192.168.0.9/camogm.php?chn=0&cmd=stop;+ </font> </font> Line 110: Line 102: * channel '''2''', '''/home/root''', file prefix='''test_''', '''1GB''' or '''10min''' files whichever occurs first * channel '''2''', '''/home/root''', file prefix='''test_''', '''1GB''' or '''10min''' files whichever occurs first ** setup and start (in one line): ** setup and start (in one line): -  echo "format=mov;status=/var/tmp/camogm2.status;prefix=/home/root/test_;duration=600;length=1073741824;start" > /var/volatile/camogm_cmd2+  echo "format=mov;status=/var/tmp/camogm.status;prefix=/home/root/test_;duration=600;length=1073741824;start" > /var/volatile/camogm_cmd ** stop recording: ** stop recording: -  echo "stop" > /var/volatile/camogm_cmd2+  echo "stop" > /var/volatile/camogm_cmd   sync   sync </font> </font> ==<font color="blue">Change parameters</font>== ==<font color="blue">Change parameters</font>== -* http://192.168.0.9/controls.html - previews and basic parameters:+* http://192.168.0.9/autocampars.php - read & write parameters (through parsedit.php), save configuration (if booted from NAND flash - "shutdown -r now" will sync changes or copy /etc/elphel393/*.xml to /tmp/rootfs.ro/etc/elphel393/ (lower layer of overlayfs), if booted from mmc - no need to reboot, just '''sync''') -** Exposure - the values are in the sensor lines. Currently conversion to seconds is not correct.+* parsedit.php -** WB - r,g,b gains+The response is in XML form: -** Quality - compression quality - individual for compressor but common for the buffer driver - it's better to have the same value for all channels.+   +Read:  + http://192.168.0.9/parsedit.php?immediate&sensor_port=0&PAR1&PAR2  +Change:  + http://192.168.0.9/parsedit.php?immediate&sensor_port=0&PAR1=VAL1&PAR2=VAL2  +   +Note 1: It's just if the parameter value is specified it will be applied. The call can have mixed specified and unspecified parameters.  +   +Note 2: The new value is read on the next call. -* For 5MPix the startup settings are defined int the ''/usr/local/verilog/startup5'' on the micro SD card, FAT32 partition:+===Notes=== - ...+* parsedit.php and autocampars.php were ported from 353 camera series. There are a few changes from the originals related to 4x sensor ports: - -c write_sensor_i2c  all 1 0 0x9009001e (exposure)+** parameters are individual for each sensor port - writing parameters to multiple port at once is controlled with a (bit-)'''mask''' input box - -c write_sensor_i2c  all 1 0 0x9035000a (set all gains to 0xa)+** if opened w/o sensor_port specified the page will show links to available ports - -c write_sensor_i2c  all 1 0 0x902c000e (blue gain to 0xe)+** '''sensor_port=x''', where x=0..3 - in the address string - for a single sensor camera it is normally 0 - -c write_sensor_i2c  all 1 0 0x9009001d (red gain to 0xd)+ - ...+ -{|+ -|[[File:10393_controls.jpeg|thumb|200px]]+ -|}+ ==<font color="blue">Temperature monitor</font>== ==<font color="blue">Temperature monitor</font>== Oleg

Record:

← Older revision Revision as of 00:44, 18 December 2016 (6 intermediate revisions not shown)Line 59: Line 59: ** likely device: <b>/dev/ttyUSB0</b> ** likely device: <b>/dev/ttyUSB0</b> ** settings: <b>115200 8N1, no</b> for hardware/software flow control ** settings: <b>115200 8N1, no</b> for hardware/software flow control  +  +==<font color="blue">web interface (camvc)</font>==  +http://192.168.0.9/closeme.html (will get changed soon) ==<font color="blue">Get images</font>== ==<font color="blue">Get images</font>== Line 91: Line 94: Example 1: (provide a correct media mount point) Example 1: (provide a correct media mount point) <font size='2'> <font size='2'> -* http://192.168.0.9/camogm.html+* http://192.168.0.9/camogmgui.php -</font>+ - + -Example 2:+ -<font size='2'>+ -* channel '''0''', '''/dev/sda1''', w/o a file name prefix+ -** setup:+ - http://192.168.0.9/camogm.php?chn=0&cmd=prefix=/mnt/sda1/;+ -** start:+ - http://192.168.0.9/camogm.php?chn=0&cmd=start;+ -** stop:+ - http://192.168.0.9/camogm.php?chn=0&cmd=stop;+ </font> </font> Line 110: Line 102: * channel '''2''', '''/home/root''', file prefix='''test_''', '''1GB''' or '''10min''' files whichever occurs first * channel '''2''', '''/home/root''', file prefix='''test_''', '''1GB''' or '''10min''' files whichever occurs first ** setup and start (in one line): ** setup and start (in one line): -  echo "format=mov;status=/var/tmp/camogm2.status;prefix=/home/root/test_;duration=600;length=1073741824;start" > /var/volatile/camogm_cmd2+  echo "format=mov;status=/var/tmp/camogm.status;prefix=/home/root/test_;duration=600;length=1073741824;start" > /var/volatile/camogm_cmd ** stop recording: ** stop recording: -  echo "stop" > /var/volatile/camogm_cmd2+  echo "stop" > /var/volatile/camogm_cmd   sync   sync </font> </font> ==<font color="blue">Change parameters</font>== ==<font color="blue">Change parameters</font>== -* http://192.168.0.9/controls.html - previews and basic parameters:+* http://192.168.0.9/autocampars.php - read & write parameters (through parsedit.php), save configuration (if boot from NAND flash - "shutdown -r now" will sync changes or copy /etc/elphel393/*.xml to /tmp/rootfs.ro/etc/elphel393/) -** Exposure - the values are in the sensor lines. Currently conversion to seconds is not correct.+* parsedit.php -** WB - r,g,b gains+The response is in XML form: -** Quality - compression quality - individual for compressor but common for the buffer driver - it's better to have the same value for all channels.+   +Read:  + http://192.168.0.9/parsedit.php?immediate&sensor_port=0&PAR1&PAR2  +Change:  + http://192.168.0.9/parsedit.php?immediate&sensor_port=0&PAR1=VAL1&PAR2=VAL2  +   +Note 1: It's just if the parameter value is specified it will be applied. The call can have mixed specified and unspecified parameters.  +   +Note 2: The new value is read on the next call. -* For 5MPix the startup settings are defined int the ''/usr/local/verilog/startup5'' on the micro SD card, FAT32 partition:+===Notes=== - ...+* parsedit.php and autocampars.php were ported from 353 camera series. There are a few changes from the originals related to 4x sensor ports: - -c write_sensor_i2c  all 1 0 0x9009001e (exposure)+** parameters are individual for each sensor port - writing parameters to multiple port at once is controlled with a (bit-)'''mask''' input box - -c write_sensor_i2c  all 1 0 0x9035000a (set all gains to 0xa)+** if opened w/o sensor_port specified the page will show links to available ports - -c write_sensor_i2c  all 1 0 0x902c000e (blue gain to 0xe)+** '''sensor_port=x''', where x=0..3 - in the address string - for a single sensor camera it is normally 0 - -c write_sensor_i2c  all 1 0 0x9009001d (red gain to 0xd)+ - ...+ -{|+ -|[[File:10393_controls.jpeg|thumb|200px]]+ -|}+ ==<font color="blue">Temperature monitor</font>== ==<font color="blue">Temperature monitor</font>== Oleg

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

AndreyFilippov committed changes to the Elphel git project :
merged with nc393 branch

AndreyFilippov committed changes to the Elphel git project :
merged with nc393 branch

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

Show changes Oleg

← 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

← 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

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

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