‎Notes

← Older revision Revision as of 21:56, 23 December 2019 (31 intermediate revisions by the same user not shown)Line 175: Line 175:    # Test 3: Run a local script (and include a local dir) in contatiner:   # Test 3: Run a local script (and include a local dir) in contatiner:    https://www.tensorflow.org/install/docker   https://www.tensorflow.org/install/docker  +  +  +==Walkthrough for CUDA 10.2 (Dec 2019)==  +  +===Install CUDA===  +* In this [https://www.tensorflow.org/install/gpu guide] there's a [https://developer.nvidia.com/cuda-toolkit-archive link to CUDA toolkit].  +** The toolkit (CUDA Toolkit 10.2) also updated the system driver to 440.33.01  +** Will have to reboot  +  +===Docker===  +====Instructions====  +'''https://www.tensorflow.org/install/docker'''  +  +Quote:  + Docker is the easiest way to enable TensorFlow GPU support on Linux since only the NVIDIA® GPU driver is required on the host machine (the NVIDIA® CUDA® Toolkit does not need to be installed).  +  +====Docker images====  +Where to browse: https://hub.docker.com/r/tensorflow/tensorflow/:  +{| class='wikitable'  +!TF version  +!Python major version  +!GPU support  +!TAG for Docker command  +|-  +|align='center'|1.15  +|align='center'|3  +|align='center'|yes  +|<font color='darkgreen'>'''tensorflow/tensorflow:1.15.0-gpu-py3'''  +|-  +|align='center'|2.0.0+  +|align='center'|3  +|align='center'|yes  +|<font color='darkgreen'>'''tensorflow/tensorflow:latest-gpu-py3'''  +|-  +|align='center'|2.0.0+  +|align='center'|2  +|align='center'|yes  +|<font color='darkgreen'>'''tensorflow/tensorflow:latest-gpu'''  +|}  +  +====nvidia-docker====  +Somehow it was already installed.  +  +* Check NVIDIA docker version  + ~$ nvidia-docker version  +  +* In the docs it's clear that Docker version 19.03+ should use nvidia-docker2. For Docker of older versions - nvidia-docker v1 should be used.  +* It's not immediately clear about the '''nvidia-container-runtime'''. nvidia-docker v1 & v2 already register it.  +  +====Notes====  +* Can mount a local directory in a 'binding' mode - i.e., update files locally so they are updated in the docker container as well:  + <font size='2'># this will bind-mount directory '''target''' located in '''$(pwd)''', which is a dir the command is run from  + # to '''/app''' in the docker container  +  + ~$ '''docker run \'''  +    '''-it \'''  +    '''--rm \'''  +    '''--name devtest \'''  +    '''-p 0.0.0.0:6006:6006 \'''  +    '''--mount type=bind,source="$(pwd)"/target,target=/app \'''  +    '''--gpus all \'''  +    <font color='darkgreen'>'''tensorflow/tensorflow:latest-gpu-py3</font> \'''  +    '''bash'''</font>  +  +* How to run tensorboard from the container:  + <font size='2'># from [https://briancaffey.github.io/2017/11/20/using-tensorflow-and-tensor-board-with-docker.html here]  + # From the running container's command line (since it was run with 'bash' in the step above):  + root@e9efee9e3fd3:/# '''tensorboard --bind_all --logdir=/app/log.txt'''  + # Then open a browser:  + '''http://localhost:6006'''</font> Oleg

‎Notes

← Older revision Revision as of 21:20, 23 December 2019 (27 intermediate revisions by the same user not shown)Line 175: Line 175:    # Test 3: Run a local script (and include a local dir) in contatiner:   # Test 3: Run a local script (and include a local dir) in contatiner:    https://www.tensorflow.org/install/docker   https://www.tensorflow.org/install/docker  +  +  +==Walkthrough for CUDA 10.2 (Dec 2019)==  +  +===Install CUDA===  +* In this [https://www.tensorflow.org/install/gpu guide] there's a [https://developer.nvidia.com/cuda-toolkit-archive link to CUDA toolkit].  +** The toolkit (CUDA Toolkit 10.2) also updated the system driver to 440.33.01  +** Will have to reboot  +  +===Docker===  +====Instructions====  +'''https://www.tensorflow.org/install/docker'''  +  +Quote:  + Docker is the easiest way to enable TensorFlow GPU support on Linux since only the NVIDIA® GPU driver is required on the host machine (the NVIDIA® CUDA® Toolkit does not need to be installed).  +  +====Docker images====  +Where to browse: https://hub.docker.com/r/tensorflow/tensorflow/  +* tag for python2 + gpu: '''tensorflow/tensorflow:latest-gpu'''  +* tag for python3 + gpu: '''tensorflow/tensorflow:latest-gpu-py3'''  +  +====nvidia-docker====  +Somehow it was already installed.  +  +* Check NVIDIA docker version  + ~$ nvidia-docker version  +  +* In the docs it's clear that Docker version 19.03+ should use nvidia-docker2. For Docker of older versions - nvidia-docker v1 should be used.  +* It's not immediately clear about the '''nvidia-container-runtime'''. nvidia-docker v1 & v2 already register it.  +  +====Notes====  +* Can mount a local directory in a 'binding' mode - i.e., update files locally so they are updated in the docker container as well:  + <font size='2'># this will bind-mount directory '''target''' located in '''$(pwd)''', which is a dir the command is run from  + # to '''/app''' in the docker container  +  + ~$ '''docker run \'''  +    '''-it \'''  +    '''--rm \'''  +    '''--name devtest \'''  +    '''-p 0.0.0.0:6006:6006 \'''  +    '''--mount type=bind,source="$(pwd)"/target,target=/app \'''  +    '''--gpus all \'''  +    '''tensorflow/tensorflow:latest-gpu-py3 \'''  +    '''bash'''</font>  +  +* How to run tensorboard from the container:  + <font size='2'># from [https://briancaffey.github.io/2017/11/20/using-tensorflow-and-tensor-board-with-docker.html here]  + # From the running container's command line (since it was run with 'bash' in the step above):  + root@e9efee9e3fd3:/# '''tensorboard --bind_all --logdir=/app/log.txt'''  + # Then open a browser:  + '''http://localhost:6006'''</font> Oleg

‎Walkthrough for CUDA 10.2 (Dec 2019)

← Older revision Revision as of 20:17, 23 December 2019 (10 intermediate revisions by the same user not shown)Line 175: Line 175:    # Test 3: Run a local script (and include a local dir) in contatiner:   # Test 3: Run a local script (and include a local dir) in contatiner:    https://www.tensorflow.org/install/docker   https://www.tensorflow.org/install/docker  +  +  +==Walkthrough for CUDA 10.2 (Dec 2019)==  +  +===Install CUDA===  +* In this [https://www.tensorflow.org/install/gpu guide] there's a [https://developer.nvidia.com/cuda-toolkit-archive link to CUDA toolkit].  +** The toolkit (CUDA Toolkit 10.2) also updated the system driver to 440.33.01  +** Reboot  +  +===Docker===  +  +====Instructions====  +https://www.tensorflow.org/install/docker  +  +====nvidia-docker====  +* Check NVIDIA docker version  + ~$ nvidia-docker version  +  +In the docs it's clear that Docker version 19.03+ should use nvidia-docker2. For Docker of older versions - nvidia-docker v1 should be used.  +  +It's not immediately clear about the '''nvidia-container-runtime'''. What? Why? Is it automatically installed with nvidia-docker thing?  +  +====Notes====  +* Can mount a local directory in a 'binding' mode - i.e., update files locally so they are updated in the docker container as well:  + <font size='3'># this will bind-mount directory '''target''' located in '''$(pwd)''', which is a dir the command is run from  + # to '''/app''' in the docker container  + docker run \  +    --gpus all \  +    --name sometest \  +    --mount type=bind,source="$(pwd)"/target,target=/app \  +    -it \  +    tensorflow/tensorflow:latest-gpu \  +    bash</font> Oleg

‎Walkthrough for CUDA 10.2 (Dec 2019)

← Older revision Revision as of 19:15, 23 December 2019 (3 intermediate revisions by the same user not shown)Line 175: Line 175:    # Test 3: Run a local script (and include a local dir) in contatiner:   # Test 3: Run a local script (and include a local dir) in contatiner:    https://www.tensorflow.org/install/docker   https://www.tensorflow.org/install/docker  +  +  +==Walkthrough for CUDA 10.2 (Dec 2019)==  +  +===Install CUDA===  +* In this [https://www.tensorflow.org/install/gpu guide] there's a [https://developer.nvidia.com/cuda-toolkit-archive link to CUDA toolkit].  +** The toolkit (CUDA Toolkit 10.2) also updated the system driver to 440.33.01  +** Reboot Oleg

← Older revision Revision as of 22:01, 5 December 2019 Line 9: Line 9:  |[https://arxiv.org/pdf/1911.06975.pdf Filippov, Andrey and Dzhimiev, Oleg "Long Range 3D with Quadocular Thermal (LWIR) Camera" arXiv preprint arXiv:1911.06975 (2019).] |[https://arxiv.org/pdf/1911.06975.pdf Filippov, Andrey and Dzhimiev, Oleg "Long Range 3D with Quadocular Thermal (LWIR) Camera" arXiv preprint arXiv:1911.06975 (2019).]  |Elphel publication |Elphel publication  +|-  +|2019  +|[https://www.researchgate.net/profile/Cui_Xiangbin/publication/335406867_The_conditions_of_the_formation_and_existence_of_Blue_Ice_Areas_in_the_ice_flow_transition_region_from_the_Antarctic_Ice_Sheet_to_the_Amery_Ice_Shelf_in_the_Larsemann_Hills_area/links/5d675ab5299bf11adf29bb92/The-conditions-of-the-formation-and-existence-of-Blue-Ice-Areas-in-the-ice-flow-transition-region-from-the-Antarctic-Ice-Sheet-to-the-Amery-Ice-Shelf-in-the-Larsemann-Hills-area.pdf Markov, Aleksey and Polyakov, Sergey and Sun, Bо and Lukin, Valeriy and Popov, Sergey and Yang, Huigen and Zhang, Tijun and Cui, Xiangbin and Guo, Jingxue and Cui, Penghui and others "Polar Science"]  +|Used Ephel camera in experimental setup  +  |- |-  |2019 |2019  |[https://documat.unirioja.es/descarga/articulo/6802185.pdf Campbell, Andrew, Alan Both, and Qian Chayn Sun. "Detecting and mapping traffic signs from Google Street View images using deep learning and GIS."] |[https://documat.unirioja.es/descarga/articulo/6802185.pdf Campbell, Andrew, Alan Both, and Qian Chayn Sun. "Detecting and mapping traffic signs from Google Street View images using deep learning and GIS."]  |Elphel cameras for GSV referenced   |Elphel cameras for GSV referenced    +  |- |-  |2019 |2019 Andrey.filippov

← Older revision Revision as of 01:12, 27 November 2019 (One intermediate revision by the same user not shown)Line 9: Line 9:  |[https://arxiv.org/pdf/1911.06975.pdf Filippov, Andrey and Dzhimiev, Oleg "Long Range 3D with Quadocular Thermal (LWIR) Camera" arXiv preprint arXiv:1911.06975 (2019).] |[https://arxiv.org/pdf/1911.06975.pdf Filippov, Andrey and Dzhimiev, Oleg "Long Range 3D with Quadocular Thermal (LWIR) Camera" arXiv preprint arXiv:1911.06975 (2019).]  |Elphel publication |Elphel publication  +|-  +|2019  +|[https://documat.unirioja.es/descarga/articulo/6802185.pdf Campbell, Andrew, Alan Both, and Qian Chayn Sun. "Detecting and mapping traffic signs from Google Street View images using deep learning and GIS."]  +|Elphel cameras for GSV referenced  +|-  +|2019  +|[https://documat.unirioja.es/descarga/articulo/6802185.pdf Díaz, Hernán Porras, Duvan Yahir Sanabria Echeverry, and Johan Alexander Ortiz Ferreira. "Tendencia mundial en tecnologías de sistemas de mapeo móvil implementadas con láser."]  +|Elphel Eyesis referenced  |- |-  |2019 |2019 Andrey.filippov

← Older revision Revision as of 21:34, 19 November 2019 (2 intermediate revisions by the same user not shown)Line 5: Line 5:  ! Citation/link ! Citation/link  ! Comments ! Comments  +|-  +|2019  +|[https://arxiv.org/pdf/1911.06975.pdf Filippov, Andrey and Dzhimiev, Oleg "Long Range 3D with Quadocular Thermal (LWIR) Camera" arXiv preprint arXiv:1911.06975 (2019).]  +|Elphel publication  |- |-  |2019 |2019 Line 19: Line 23:  |- |-  |2018 |2018 −|[https://arxiv.org/pdf/1811.08032 Filippov, Andrey, and Oleg Dzhimiev. "See far with TPNET: a Tile Processor and a CNN Symbiosis." arXiv preprint arXiv:1811.08032 (2018).]+|[https://arxiv.org/pdf/1811.08032 Filippov, Andrey, and Dzhimiev, Oleg. "See far with TPNET: a Tile Processor and a CNN Symbiosis." arXiv preprint arXiv:1811.08032 (2018).]  |Elphel publication |Elphel publication  |- |- Andrey.filippov

‎[SOLVED] Note 14: fixdep: Permission denied

← Older revision Revision as of 23:49, 3 October 2019 (6 intermediate revisions by the same user not shown)Line 260: Line 260:    ...   ...    ---[ end Kernel panic - not syncing: Fatal exception in interrupt   ---[ end Kernel panic - not syncing: Fatal exception in interrupt  +  +==<font color='green'>'''[SOLVED]'''</font> Note 14: fixdep: Permission denied==  +* Description:  + - We've had this error for a while, probably since kernel 4.0  + - usually happened when running do_compile_kernelmodules  + - EXTRA_OEMAKE = "-s -w '''-B''' KCFLAGS='-v'"  + - That '''-B''' forces to rebuild all targets and we also have '''-j8''' (in PARALLEL_MAKE variable) for the parallel build  +  - so when running the parallel build fixdep gets rebuilt several times and at some point  +    one of the targets (e.g. sortextable or kallsyms) calls it while fixdep is being compiled and overwritten for another target (probably)  +  - the exec rights are correct after the fact  +  +* Solution:  +  Removed '''-B'''. It make fixdep build only once and the problem is gone.  +  +* Note:  +  ~$ make -h  +    ...  +    -B, --always-make          Unconditionally make all targets.  +    ... Oleg

‎Updating to 4.19

← Older revision Revision as of 20:10, 26 September 2019 (4 intermediate revisions by the same user not shown)Line 9: Line 9:  * ON-DIE ECC feature supported - they call it internal ECC in the datasheet: * ON-DIE ECC feature supported - they call it internal ECC in the datasheet:    Internal ECC enables 5-bit detection and 4-bit error correction in 512 bytes   Internal ECC enables 5-bit detection and 4-bit error correction in 512 bytes −* Subpage (or partial) writes are not supported.      ==Linux Kernel 4.14 and older== ==Linux Kernel 4.14 and older== Line 20: Line 19:  * A lot has changed since 4.14 * A lot has changed since 4.14  ** new ''->exec_op'' hook vs old ''->cmdfunc'' ** new ''->exec_op'' hook vs old ''->cmdfunc''  +** Xilinx tries to keep up with their driver - they might have tested this on [https://lwn.net/Articles/756725/ Micron MT29F2G08ABAEAWP (On-die capable) and AMD/Spansion S34ML01G1]  * OTP function are not supported yet, and need a minor change to make them more universal * OTP function are not supported yet, and need a minor change to make them more universal −* Old LOCK/UNLOCK function need to be updated to the new codebase+ That minor change is to set ops.mode to MTD_OPS_RAW instead of normal. Hooks for normal ops −* Set ''nand-ecc-mode = "on-die";'' in the device tree.+ can enable/disable ECC features which will reset OTP mode (which is also a feature set)  +   +* Old LOCK/UNLOCK functions from pre 4.14 kernel need to be updated to the new codebase  + Those op_parser patterns.  + Also UNLOCK command is 2 parts: 0x23 BOUND_LO 0x24 BOUND_HI - so, before 0x24 has to be some sort of a delay or the op should be split into 2.  + Datasheet does not provide any timing info  +   +* Set ''nand-ecc-mode = "on-die";'' in the device tree.  + In 4.14 it used to be detected as "on-die", but not anymore.  * Add NAND_NO_SUBPAGE_WRITE to chip->options for MT29F8G08ADBDAH4 * Add NAND_NO_SUBPAGE_WRITE to chip->options for MT29F8G08ADBDAH4 −===Results===+ Otherwise driver goes for subpage program support. '''Need to test this.'''  +   +===Driver code===  See the code here: See the code here:  * [https://git.elphel.com/Elphel/linux-elphel/blob/warrior/src/arch/arm/boot/dts/elphel393-zynq-base.dtsi#L299 device tree] * [https://git.elphel.com/Elphel/linux-elphel/blob/warrior/src/arch/arm/boot/dts/elphel393-zynq-base.dtsi#L299 device tree] −  Those ''arm,nand-cycle-t0-6'' can be removed+  Those ''arm,nand-cycle-t0-6'' are obsolete and can be removed from DT.  * [https://git.elphel.com/Elphel/linux-elphel/tree/d4f217cf68d8c3c9a84f680dd014b1a0de0571c8/src/drivers/mtd/nand/raw driver code] * [https://git.elphel.com/Elphel/linux-elphel/tree/d4f217cf68d8c3c9a84f680dd014b1a0de0571c8/src/drivers/mtd/nand/raw driver code] −  Didn't make a patch - the changes are for a specific MT29F8G08ADBDAH4. Although they might work for others as well we have only tested the chip we use.+  Didn't make a patch - the changes are for a specific MT29F8G08ADBDAH4. Although they might work for other chips as well we have only tested the one we use. Oleg

‎Updating to 4.19

← Older revision Revision as of 18:47, 26 September 2019 (One intermediate revision by the same user not shown)Line 20: Line 20:  * A lot has changed since 4.14 * A lot has changed since 4.14  ** new ''->exec_op'' hook vs old ''->cmdfunc'' ** new ''->exec_op'' hook vs old ''->cmdfunc''  +** Xilinx tries to keep up with their driver  * OTP function are not supported yet, and need a minor change to make them more universal * OTP function are not supported yet, and need a minor change to make them more universal −* Old LOCK/UNLOCK function need to be updated to the new codebase+ That minor change is to set ops.mode to MTD_OPS_RAW instead of normal. Hooks for normal ops −* Set ''nand-ecc-mode = "on-die";'' in the device tree.+ can enable/disable ECC features which will reset OTP mode (which is also a feature set)  +   +* Old LOCK/UNLOCK functions from pre 4.14 kernel need to be updated to the new codebase  + Those op_parser patterns.  + Also UNLOCK command is 2 parts: 0x23 BOUND_LO 0x24 BOUND_HI - so, before 0x24 has to be some sort of a delay or the op should be split into 2.  + Datasheet does not provide any timing info  +   +* Set ''nand-ecc-mode = "on-die";'' in the device tree.  + In 4.14 it used to be detected as "on-die", but not anymore.  * Add NAND_NO_SUBPAGE_WRITE to chip->options for MT29F8G08ADBDAH4 * Add NAND_NO_SUBPAGE_WRITE to chip->options for MT29F8G08ADBDAH4 −===Results===+ Otherwise driver goes for subpage program support  +   +===Driver code===  See the code here: See the code here:  * [https://git.elphel.com/Elphel/linux-elphel/blob/warrior/src/arch/arm/boot/dts/elphel393-zynq-base.dtsi#L299 device tree] * [https://git.elphel.com/Elphel/linux-elphel/blob/warrior/src/arch/arm/boot/dts/elphel393-zynq-base.dtsi#L299 device tree] −  Those ''arm,nand-cycle-t0-6'' can be removed+  Those ''arm,nand-cycle-t0-6'' are obsolete and can be removed from DT.  * [https://git.elphel.com/Elphel/linux-elphel/tree/d4f217cf68d8c3c9a84f680dd014b1a0de0571c8/src/drivers/mtd/nand/raw driver code] * [https://git.elphel.com/Elphel/linux-elphel/tree/d4f217cf68d8c3c9a84f680dd014b1a0de0571c8/src/drivers/mtd/nand/raw driver code] −  Didn't make a patch - the changes are for a specific MT29F8G08ADBDAH4. Although they might work for others as well we have only tested the chip we use.+  Didn't make a patch - the changes are for a specific MT29F8G08ADBDAH4. Although they might work for other chips as well we have only tested the one we use. Oleg

Created page with "==About== Below are the changes had to be made to update our nand flash driver code from kernel 4.14 to 4.19. The kernel versions mentioned are the rebases from the mainline k..."

New page

==About==
Below are the changes had to be made to update our nand flash driver code from kernel 4.14 to 4.19.
The kernel versions mentioned are the rebases from the mainline kernel in linux-xlnx repo with xilinx's code:
[https://github.com/Xilinx/linux-xlnx/tree/xlnx_rebase_v4.14 xlnx_rebase_v4.14]
[https://github.com/Xilinx/linux-xlnx/tree/xlnx_rebase_v4.19 xlnx_rebase_v4.19]

==NAND FLASH chip==
Micron MT29F8G08ADBDAH4:
* ON-DIE ECC feature supported - they call it internal ECC in the datasheet:
Internal ECC enables 5-bit detection and 4-bit error correction in 512 bytes
* Subpage (or partial) writes are not supported.

==Linux Kernel 4.14 and older==
Until 4.14 (including) our driver code additions worked unchanged. We basically needed a couple of things:
* LOCK/UNLOCK functions (which were removed in 4.14). The code existed in up to 4.13 release - so it was just taken from there.
* Function to work with the chip's (MT29F8G08ADBDAH4) OTP area. The original code was taken from [http://webcache.googleusercontent.com/search?q=cache:-k_EdkxxQCUJ:lists.infradead.org/pipermail/linux-mtd/2013-March/045994.html+&cd=2&hl=en&ct=clnk&gl=us&client=ubuntu here]

==Updating to 4.19==
===Notes===
* A lot has changed since 4.14
** new ''->exec_op'' hook vs old ''->cmdfunc''
* OTP function are not supported yet, and need a minor change to make them more universal
* Old LOCK/UNLOCK function need to be updated to the new codebase
* Set ''nand-ecc-mode = "on-die";'' in the device tree.
* Add NAND_NO_SUBPAGE_WRITE to chip->options for MT29F8G08ADBDAH4
===Results===
See the code here:
* [https://git.elphel.com/Elphel/linux-elphel/blob/warrior/src/arch/arm/boot/dts/elphel393-zynq-base.dtsi#L299 device tree]
Those ''arm,nand-cycle-t0-6'' can be removed
* [https://git.elphel.com/Elphel/linux-elphel/tree/d4f217cf68d8c3c9a84f680dd014b1a0de0571c8/src/drivers/mtd/nand/raw driver code]
Didn't make a patch - the changes are for a specific MT29F8G08ADBDAH4. Although they might work for others as well we have only tested the chip we use. Oleg

‎[SOLVED] Note 3: Entropy device hwrng

← Older revision Revision as of 19:06, 10 September 2019 (One intermediate revision by the same user not shown)Line 92: Line 92:  ** Haven't found if Xilinx uses any driver for /dev/hwrng ** Haven't found if Xilinx uses any driver for /dev/hwrng  ** TODO: Find out if the order of entropy sources can be changed ** TODO: Find out if the order of entropy sources can be changed −** That lag at boot is really annoying - 5-10 seconds?!!+** That lag at boot is really annoying - 5 secs?!!     ==<font color='green'>'''[SOLVED]'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'== ==<font color='green'>'''[SOLVED]'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'== Line 148: Line 148:    - <s>switched from '''-mfloat-abi=softfp''' to '''-mfloat-abi=hard''' - the problem seems to go away - but is it 100%?</s>   - <s>switched from '''-mfloat-abi=softfp''' to '''-mfloat-abi=hard''' - the problem seems to go away - but is it 100%?</s>    - used kmalloc instead of auto variable in mt9x001_pgm_initsensor() - no Oopses so far   - used kmalloc instead of auto variable in mt9x001_pgm_initsensor() - no Oopses so far  +  +* More notes on debugging  + - CONFIG_DEBUG_STACK_USAGE=y  +  and it reports how many bytes left in stack for various processes. For that particular process (php) the "bytes left" were '''4''' on successful boots and  +  ~'''1028''' after a huge variable (of 1024 bytes) got moved to heap.  + - Also there's a warning in Eclipse about "frame size" beaing larger than 1024     ==<font color='green'>'''[SOLVED]'''</font> Note 5: Bring up NAND OTP support== ==<font color='green'>'''[SOLVED]'''</font> Note 5: Bring up NAND OTP support== Oleg

‎[SOLVED] Note 3: Entropy device hwrng

← Older revision Revision as of 19:06, 10 September 2019 (2 intermediate revisions by the same user not shown)Line 92: Line 92:  ** Haven't found if Xilinx uses any driver for /dev/hwrng ** Haven't found if Xilinx uses any driver for /dev/hwrng  ** TODO: Find out if the order of entropy sources can be changed ** TODO: Find out if the order of entropy sources can be changed −** That lag at boot is really annoying - 5-10 seconds?!!+** That lag at boot is really annoying - 5 secs?!!    −==<font color='green'>'''SOLVED'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'==+==<font color='green'>'''[SOLVED]'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'==  * Kernel Oops: * Kernel Oops:    <font size='1'>[  35.872118] BUG: unsupported FP instruction in kernel mode   <font size='1'>[  35.872118] BUG: unsupported FP instruction in kernel mode Line 148: Line 148:    - <s>switched from '''-mfloat-abi=softfp''' to '''-mfloat-abi=hard''' - the problem seems to go away - but is it 100%?</s>   - <s>switched from '''-mfloat-abi=softfp''' to '''-mfloat-abi=hard''' - the problem seems to go away - but is it 100%?</s>    - used kmalloc instead of auto variable in mt9x001_pgm_initsensor() - no Oopses so far   - used kmalloc instead of auto variable in mt9x001_pgm_initsensor() - no Oopses so far  +  +* More notes on debugging  + - CONFIG_DEBUG_STACK_USAGE=y  +  and it reports how many bytes left in stack for various processes. For that particular process (php) the "bytes left" were '''4''' on successful boots and  +  ~'''1028''' after a huge variable (of 1024 bytes) got moved to heap.  + - Also there's a warning in Eclipse about "frame size" beaing larger than 1024     ==<font color='green'>'''[SOLVED]'''</font> Note 5: Bring up NAND OTP support== ==<font color='green'>'''[SOLVED]'''</font> Note 5: Bring up NAND OTP support== Oleg

← Older revision Revision as of 19:49, 9 September 2019 Line 94: Line 94:  ** That lag at boot is really annoying - 5-10 seconds?!! ** That lag at boot is really annoying - 5-10 seconds?!!    −==<font color='green'>'''SOLVED'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'==+==<font color='green'>'''[SOLVED]'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'==  * Kernel Oops: * Kernel Oops:    <font size='1'>[  35.872118] BUG: unsupported FP instruction in kernel mode   <font size='1'>[  35.872118] BUG: unsupported FP instruction in kernel mode Oleg

← Older revision Revision as of 19:44, 9 September 2019 (8 intermediate revisions by the same user not shown)Line 1: Line 1:  +==<font color="blue">Description</font>==  +How to build the firmware for Elphel 10393 series camera systems from scratch.  +  +Prebuilt releases can be found [https://community.elphel.com/files/393/ here].  +  ==<font color="blue">Use cases</font>== ==<font color="blue">Use cases</font>== −* Linux kernel update when adding/developing a driver+* Update Linux Kernel when developing a driver −* When an application needs to be included into the firmware image archive+* Include application to the default firmware package  * Update Elphel's PHP extension * Update Elphel's PHP extension  * C/C++ applications if developed on PC require a cross-compiler and require Yocto installation or some other alternative. * C/C++ applications if developed on PC require a cross-compiler and require Yocto installation or some other alternative.    −Other projects that use Python, PHP, Javascript, HTML, C/C++ on hardware (compiler is included in the firmware image) do not require this SDK use but it makes the process more convenient, e.g. by copying the built packages straight to the target hardware.+Other projects written in Python, PHP, Javascript, HTML, C/C++ (gcc is installed on the system board) can be developed on the camera. Installing the framework is not required but it can simplify the development process.     ==<font color="blue">Description</font>== ==<font color="blue">Description</font>==     * Building embedded Linux image for Zynq ARMv7 platform - Elphel 10393 board * Building embedded Linux image for Zynq ARMv7 platform - Elphel 10393 board −* Yocto Poky revision = 2.6 (Thud)+* Yocto Poky revision = 2.7.1 (Warrior)  * Yocto Poky revision = 2.4 (Rocko) * Yocto Poky revision = 2.4 (Rocko)  * <s>Yocto Poky revision = 2.0 (Jethro)</s> * <s>Yocto Poky revision = 2.0 (Jethro)</s> Line 29: Line 34:     ==<font color="blue">Requirements</font>== ==<font color="blue">Requirements</font>== −* Kubuntu 16.04 x64 (as of Dec 2018) for Poky 2.4 Rocko+* Kubuntu 16.04 x64 (as of Dec 2018) - Poky: 2.4 Rocko, 2.7.1 Warrior −* Kubuntu 18.04 x64 (as of Dec 2018)+* Kubuntu 18.04 x64 (as of Dec 2018) - Poky: 2.7.1 Warrior (not tested but might build w/o problems) −* For Poky 2.6 Thud see [http://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html Yocto Project Poky 2.6 mega-manual]      ==<font color="blue">Output files</font>== ==<font color="blue">Output files</font>== Line 38: Line 42:  |- |-  ! File(s) ! File(s)  +! Build Command  ! Description ! Description  |- |-  | <font color='darkblue'>'''boot.bin'''</font> | <font color='darkblue'>'''boot.bin'''</font>  +| ''bitbake u-boot''  | u-boot as the first stage bootloader = Secondary Program Loader (SPL) that boots '''u-boot-dtb.img''' | u-boot as the first stage bootloader = Secondary Program Loader (SPL) that boots '''u-boot-dtb.img'''  |- |-  | <font color='darkblue'>'''u-boot-dtb.img'''</font> | <font color='darkblue'>'''u-boot-dtb.img'''</font>  +| ''bitbake u-boot''  | full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > 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'')  |- |-  |valign='top'| <font color='darkblue'>'''devicetree.dtb'''</font> |valign='top'| <font color='darkblue'>'''devicetree.dtb'''</font>  +| bitbake device-tree  | device tree with listed interfaces, zynq registers, interrupts and drivers | device tree with listed interfaces, zynq registers, interrupts and drivers  * ''elphel393/bootable-images/mmc/devicetree.dtb'' - mount rootfs from mmc partition * ''elphel393/bootable-images/mmc/devicetree.dtb'' - mount rootfs from mmc partition Line 52: Line 60:  |- |-  | <font color='darkblue'>'''uImage'''</font> | <font color='darkblue'>'''uImage'''</font>  +| ''bitbake linux-xlnx''  | kernel, drivers | kernel, drivers  |- |-  | <font color='darkblue'>'''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz'''</font> | <font color='darkblue'>'''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz'''</font>  +| ''bitbake core-image-elphel393''  | rootfs in different formats - *.ubi* for NAND, *.tar.gz for mmc | rootfs in different formats - *.ubi* for NAND, *.tar.gz for mmc  |} |} Line 90: Line 100:  </font> </font>    −* Poky 2.6 Thud (Kubuntu 18.04)+* Poky 2.7.1 Warrior (Kubuntu 16.04 or 18.04)  <font size='2'> <font size='2'> −  git clone -b '''thud''' https://git.elphel.com/Elphel/elphel393.git+  git clone -b '''warrior''' https://git.elphel.com/Elphel/elphel393.git    cd elphel393   cd elphel393    ./setup.py   ./setup.py Line 105: Line 115:    ./check_versions.py root@192.168.0.9   ./check_versions.py root@192.168.0.9  </font> </font> −  −'''Notes:'''   −* '''deployed''' = running on the target system      {| {| −|[[File:Check versions.png|thumb|400px|check_versions.py output in terminal]]+|[[File:Check versions.png|thumb|400px|check_versions.py output in terminal (web-393 revision on PC is ahead of the one installed on the camera)]]  |} |} −  −==<font color="blue">Build</font>==  −  −===<font color="blue">All targets</font>===  −<font size='2'>  − bitbake u-boot device-tree linux-xlnx core-image-elphel393  −</font>  −===<font color="blue">Bootloader</font>===  −<font size='2'>  − bitbake u-boot  −</font>  −====Output====  −* '''boot.bin'''  −* '''u-boot-dtb.img'''  −  −====Notes====  −* Current the recipe installs only binaries. We will upgrade u-boot from '''2016.05''' to the current release later.   −2016.05 will not compile in Kubuntu 18.04  −  −===<font color="blue">Device tree</font>===  −<font size='2'>  − bitbake device-tree  −</font>  −====Output====  −* '''devicetree.dtb'''  −  −===<font color="blue">Kernel</font>===  −<font size='2'>  − bitbake linux-xlnx  −</font>  −====Output====  −* '''uImage'''  −  −====Notes====  −* linux-xlnx '''rocko''' branch was simply moved to '''thud''' branch  −* yocto thud:  Kernel version is 4.9.0, linux-xlnx  −* Device Tree Blob is compiled separately in linux-xlnx  −* Uncompiled device tree files are present in the linux sources provided by linux-xlnx  −  −===<font color="blue">Rootfs</font>===  −<font size='2'>  − bitbake core-image-elphel393  −</font>  −====Output====  −* '''rootfs.tar.gz'''  −* '''rootfs.ubi''', '''rootfs.ubifs'''      ==<font color="blue">Details for development</font>== ==<font color="blue">Details for development</font>==  [[Development_for_10393|'''Development for 10393''']] [[Development_for_10393|'''Development for 10393''']] Oleg

‎Requirements

← Older revision Revision as of 19:09, 9 September 2019 (4 intermediate revisions by the same user not shown)Line 10: Line 10:     * Building embedded Linux image for Zynq ARMv7 platform - Elphel 10393 board * Building embedded Linux image for Zynq ARMv7 platform - Elphel 10393 board −* Yocto Poky revision = 2.6 (Thud)+* Yocto Poky revision = 2.7.1 (Warrior)  * Yocto Poky revision = 2.4 (Rocko) * Yocto Poky revision = 2.4 (Rocko)  * <s>Yocto Poky revision = 2.0 (Jethro)</s> * <s>Yocto Poky revision = 2.0 (Jethro)</s> Line 29: Line 29:     ==<font color="blue">Requirements</font>== ==<font color="blue">Requirements</font>== −* Kubuntu 16.04 x64 (as of Dec 2018) for Poky 2.4 Rocko+* Kubuntu 16.04 x64 (as of Dec 2018) - Poky: 2.4 Rocko, 2.7.1 Warrior −* Kubuntu 18.04 x64 (as of Dec 2018)+* Kubuntu 18.04 x64 (as of Dec 2018) - Poky: 2.7.1 Warrior (not tested but might build w/o problems) −* For Poky 2.6 Thud see [http://www.yoctoproject.org/docs/2.6/mega-manual/mega-manual.html Yocto Project Poky 2.6 mega-manual]      ==<font color="blue">Output files</font>== ==<font color="blue">Output files</font>== Line 38: Line 37:  |- |-  ! File(s) ! File(s)  +! Build Command  ! Description ! Description  |- |-  | <font color='darkblue'>'''boot.bin'''</font> | <font color='darkblue'>'''boot.bin'''</font>  +| ''bitbake u-boot''  | u-boot as the first stage bootloader = Secondary Program Loader (SPL) that boots '''u-boot-dtb.img''' | u-boot as the first stage bootloader = Secondary Program Loader (SPL) that boots '''u-boot-dtb.img'''  |- |-  | <font color='darkblue'>'''u-boot-dtb.img'''</font> | <font color='darkblue'>'''u-boot-dtb.img'''</font>  +| ''bitbake u-boot''  | full size u-boot with a stripped device tree (''cat u-boot.img some_stripped_devicetree.dtb > 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'')  |- |-  |valign='top'| <font color='darkblue'>'''devicetree.dtb'''</font> |valign='top'| <font color='darkblue'>'''devicetree.dtb'''</font>  +| bitbake device-tree  | device tree with listed interfaces, zynq registers, interrupts and drivers | device tree with listed interfaces, zynq registers, interrupts and drivers  * ''elphel393/bootable-images/mmc/devicetree.dtb'' - mount rootfs from mmc partition * ''elphel393/bootable-images/mmc/devicetree.dtb'' - mount rootfs from mmc partition Line 52: Line 55:  |- |-  | <font color='darkblue'>'''uImage'''</font> | <font color='darkblue'>'''uImage'''</font>  +| ''bitbake linux-xlnx''  | kernel, drivers | kernel, drivers  |- |-  | <font color='darkblue'>'''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz'''</font> | <font color='darkblue'>'''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz'''</font>  +| ''bitbake core-image-elphel393''  | rootfs in different formats - *.ubi* for NAND, *.tar.gz for mmc | rootfs in different formats - *.ubi* for NAND, *.tar.gz for mmc  |} |} Line 90: Line 95:  </font> </font>    −* Poky 2.6 Thud (Kubuntu 18.04)+* Poky 2.7.1 Warrior (Kubuntu 16.04 or 18.04)  <font size='2'> <font size='2'> −  git clone -b '''thud''' https://git.elphel.com/Elphel/elphel393.git+  git clone -b '''warrior''' https://git.elphel.com/Elphel/elphel393.git    cd elphel393   cd elphel393    ./setup.py   ./setup.py Line 113: Line 118:  |} |}    −==<font color="blue">Build</font>==  −  −===<font color="blue">All targets</font>===  −<font size='2'>  − bitbake u-boot device-tree linux-xlnx core-image-elphel393  −</font>  −===<font color="blue">Bootloader</font>===  −<font size='2'>  − bitbake u-boot  −</font>  −====Output====  −* '''boot.bin'''  −* '''u-boot-dtb.img'''  −  −====Notes====  −* Current the recipe installs only binaries. We will upgrade u-boot from '''2016.05''' to the current release later.   −2016.05 will not compile in Kubuntu 18.04  −  −===<font color="blue">Device tree</font>===  −<font size='2'>  − bitbake device-tree  −</font>  −====Output====  −* '''devicetree.dtb'''  −  −===<font color="blue">Kernel</font>===  −<font size='2'>  − bitbake linux-xlnx  −</font>  −====Output====  −* '''uImage'''  −  −====Notes====  −* linux-xlnx '''rocko''' branch was simply moved to '''thud''' branch  −* yocto thud:  Kernel version is 4.9.0, linux-xlnx  −* Device Tree Blob is compiled separately in linux-xlnx  −* Uncompiled device tree files are present in the linux sources provided by linux-xlnx  −  −===<font color="blue">Rootfs</font>===  −<font size='2'>  − bitbake core-image-elphel393  −</font>  −====Output====  −* '''rootfs.tar.gz'''  −* '''rootfs.ubi''', '''rootfs.ubifs'''      ==<font color="blue">Details for development</font>== ==<font color="blue">Details for development</font>==  [[Development_for_10393|'''Development for 10393''']] [[Development_for_10393|'''Development for 10393''']] Oleg

‎- Note 4: PHP causing 'unsupported FP instruction in kernel mode'

← Older revision Revision as of 18:39, 9 September 2019 (One intermediate revision by the same user not shown)Line 94: Line 94:  ** That lag at boot is really annoying - 5-10 seconds?!! ** That lag at boot is really annoying - 5-10 seconds?!!    −==<font color='green'>'''-'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'==+==<font color='green'>'''SOLVED'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'==  * Kernel Oops: * Kernel Oops:    <font size='1'>[  35.872118] BUG: unsupported FP instruction in kernel mode   <font size='1'>[  35.872118] BUG: unsupported FP instruction in kernel mode Line 134: Line 134:     * Causes? * Causes? −  - hardware  −    - power board?  −    - system board? (probably not cause reproduced on 2 boards)  −    - temperature?      - kernel?    - kernel? −     - some racing conditions?+     - <s>some racing conditions?</s> −   - php?  +    - huge variables in the stack overflow it at mt9x001.c:mt9x001_pgm_initsensor()  +   <s>- php?         - too old? the version 5.6.40 is EOL      - too old? the version 5.6.40 is EOL −     - got built with some package that is too new for it? Like it won't build with newer mysql+     - got built with some package that is too new for it? Like it won't build with newer mysql</s>     * Solution?: * Solution?: −  - Took arch/vfp/vfpmodule.c from kernel 4.19. The current was 4.14. It didn't work. Roll back and check which php call caused it? Also might be a linux driver.+  - <s>Took arch/vfp/vfpmodule.c from kernel 4.19. The current was 4.14. It didn't work. Roll back and check which php call caused it? Also might be a linux driver.</s> −  - Try php 7.x.x - need to update the extension+  - <s>Try php 7.x.x - need to update the extension</s> −  - Try php 5.6.31 (the one that used to work) - Opps persists+  - <s>Try php 5.6.31 (the one that used to work) - Opps persists</s> −  - On the bright side, at least it's not a kernel panic+  - <s>On the bright side, at least it's not a kernel panic</s> −  - switched from '''-mfloat-abi=softfp''' to '''-mfloat-abi=hard''' - the problem seems to go away - but is it 100%?+  - <s>switched from '''-mfloat-abi=softfp''' to '''-mfloat-abi=hard''' - the problem seems to go away - but is it 100%?</s> − + - used kmalloc instead of auto variable in mt9x001_pgm_initsensor() - no Oopses so far −* TODO: keep an eye on this, because the real reason is not investigated      ==<font color='green'>'''[SOLVED]'''</font> Note 5: Bring up NAND OTP support== ==<font color='green'>'''[SOLVED]'''</font> Note 5: Bring up NAND OTP support== Oleg

‎- Note 4: PHP causing 'unsupported FP instruction in kernel mode'

← Older revision Revision as of 17:30, 20 August 2019 Line 149: Line 149:    - Try php 5.6.31 (the one that used to work) - Opps persists   - Try php 5.6.31 (the one that used to work) - Opps persists    - On the bright side, at least it's not a kernel panic   - On the bright side, at least it's not a kernel panic  + - switched from '''-mfloat-abi=softfp''' to '''-mfloat-abi=hard''' - the problem seems to go away - but is it 100%?     * TODO: keep an eye on this, because the real reason is not investigated * TODO: keep an eye on this, because the real reason is not investigated Oleg

‎- Note 4: PHP causing 'unsupported FP instruction in kernel mode'

← Older revision Revision as of 21:55, 8 August 2019 (2 intermediate revisions by the same user not shown)Line 92: Line 92:  ** Haven't found if Xilinx uses any driver for /dev/hwrng ** Haven't found if Xilinx uses any driver for /dev/hwrng  ** TODO: Find out if the order of entropy sources can be changed ** TODO: Find out if the order of entropy sources can be changed  +** That lag at boot is really annoying - 5-10 seconds?!!     ==<font color='green'>'''-'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'== ==<font color='green'>'''-'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'== Line 145: Line 146:  * Solution?: * Solution?:    - Took arch/vfp/vfpmodule.c from kernel 4.19. The current was 4.14. It didn't work. Roll back and check which php call caused it? Also might be a linux driver.   - Took arch/vfp/vfpmodule.c from kernel 4.19. The current was 4.14. It didn't work. Roll back and check which php call caused it? Also might be a linux driver. −  - Try php 7.x.x+  - Try php 7.x.x - need to update the extension −   +  - Try php 5.6.31 (the one that used to work) - Opps persists  + - On the bright side, at least it's not a kernel panic  +   * TODO: keep an eye on this, because the real reason is not investigated * TODO: keep an eye on this, because the real reason is not investigated    Oleg

‎- Note 4: PHP causing 'unsupported FP instruction in kernel mode'

← Older revision Revision as of 21:55, 8 August 2019 (5 intermediate revisions by the same user not shown)Line 92: Line 92:  ** Haven't found if Xilinx uses any driver for /dev/hwrng ** Haven't found if Xilinx uses any driver for /dev/hwrng  ** TODO: Find out if the order of entropy sources can be changed ** TODO: Find out if the order of entropy sources can be changed  +** That lag at boot is really annoying - 5-10 seconds?!!     ==<font color='green'>'''-'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'== ==<font color='green'>'''-'''</font> Note 4: PHP causing 'unsupported FP instruction in kernel mode'== − +* Kernel Oops: −* '''autocampars.php''' runs at boot and sometimes causes Kernel Oops:  −      <font size='1'>[  35.872118] BUG: unsupported FP instruction in kernel mode   <font size='1'>[  35.872118] BUG: unsupported FP instruction in kernel mode    [  35.877621] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM   [  35.877621] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM Line 121: Line 120:    [  35.999422] note: php[1756] exited with preempt_count 2</font>   [  35.999422] note: php[1756] exited with preempt_count 2</font>    −Unsupported floating point instruction in kernel?+* Unsupported floating point instruction in kernel?  +   +* Details:  + - single sensor (MT9P006) on port 0  + - at boot  + - after the Oops the camera seems to be operating normal  + - the appearance is random (but <50%) - easier reproduced with ''reboot -f'' than power cycle  + - '''autocampars.php''' runs at boot and sometimes causes this - it happens after 0 is written to initiate sensors' driver  + - fpga is already programmed  + - after mt9x001_pgm_initsensor() exit  + - autocampars.php log seems to be ok and full  + - tested with 2 boards    −* Is it hardware (some faulty board? temperature based?) or kernel or php?+* Causes?  +  - hardware  +    - power board?  +    - system board? (probably not cause reproduced on 2 boards)  +    - temperature?  +  - kernel?  +    - some racing conditions?  +  - php?    +    - too old? the version 5.6.40 is EOL  +    - got built with some package that is too new for it? Like it won't build with newer mysql    −* solution?:+* Solution?: −  Took arch/vfp/vfpmodule.c from kernel 4.19+  - Took arch/vfp/vfpmodule.c from kernel 4.19. The current was 4.14. It didn't work. Roll back and check which php call caused it? Also might be a linux driver. − The current was 4.14+ - Try php 7.x.x - need to update the extension − It didn't work. Roll back and check which php call caused it?+ - Try php 5.6.31 (the one that used to work) - Opps persists − Also might be a linux driver.+ - On the bright side, at least it's not a kernel panic     * TODO: keep an eye on this, because the real reason is not investigated * TODO: keep an eye on this, because the real reason is not investigated Oleg