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

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

← Older revision Revision as of 21:55, 8 August 2019 (8 intermediate revisions by the same user not shown)Line 69: Line 69:     ==<font color='green'>'''[SOLVED]'''</font> Note 1: Bring back fpga char device== ==<font color='green'>'''[SOLVED]'''</font> Note 1: Bring back fpga char device== −* /dev/xdevfg got obsolete - there's fpga manager instead which cannot load *.bit (only *.bin or *.bit.bin)+* /dev/xdevfg got retired by Xilinx - instead there's the FPGA 'Manager' which is unable to load a simple *.bit (only *.bin or *.bit.bin).  * '''Solution:''' * '''Solution:'''    Brought back the old driver (drivers/char/xilinx_devcfg.c and edited Kconfig and Makefile)- it works as it used to   Brought back the old driver (drivers/char/xilinx_devcfg.c and edited Kconfig and Makefile)- it works as it used to 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  + - 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 (13 intermediate revisions by the same user not shown)Line 30: Line 30:    │   │   ├── <font color='green'>jpeghead.c</font>   │   │   ├── <font color='green'>jpeghead.c</font>    │   │   ├── klogger_393.c   │   │   ├── klogger_393.c −  │   │   ├── lepton.c+  │   │   ├── <font color='green'>lepton.c</font> −  │   │   ├── mt9f002.c+  │   │   ├── <font color='green'>mt9f002.c</font>    │   │   ├── <font color='green'>mt9x001.c</font> # sensor is programmed correctly   │   │   ├── <font color='green'>mt9x001.c</font> # sensor is programmed correctly    │   │   ├── multi10359.c   │   │   ├── multi10359.c Line 69: Line 69:     ==<font color='green'>'''[SOLVED]'''</font> Note 1: Bring back fpga char device== ==<font color='green'>'''[SOLVED]'''</font> Note 1: Bring back fpga char device== −* /dev/xdevfg got obsolete - there's fpga manager instead which cannot load *.bit (only *.bin or *.bit.bin)+* /dev/xdevfg got retired by Xilinx - instead there's the FPGA 'Manager' which is unable to load a simple *.bit (only *.bin or *.bit.bin).  * '''Solution:''' * '''Solution:'''    Brought back the old driver (drivers/char/xilinx_devcfg.c and edited Kconfig and Makefile)- it works as it used to   Brought back the old driver (drivers/char/xilinx_devcfg.c and edited Kconfig and Makefile)- it works as it used to 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  + - 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 Line 197: Line 217:    - write/read works   - write/read works    −==<font color='green'>'''-'''</font> Note 12: test raw recording==+==<font color='green'>'''[SOLVED]'''</font> Note 12: test raw recording==  * test recording on a raw partition * test recording on a raw partition  +* comments:  + There was a typo in camogm_align.c - it was not aligning when it should have.  + CHUNK_LEADER changed to CHUNK_HEADER in line 339:  + ...  + if (chunks[CHUNK_HEADER].iov_len != 0){ // only if it is not TIFF  + ...  +  +==<font color='green'>'''[SOLVED]'''</font> Note 13: FLIR Lepton 3.5 sensor: NULL pointer dereference==  +* Solution:  + Forgot to pull the latest device tree with lepton description  + Old device tree didn't have i2c configuration for lepton hence something returned NULL  +  +* Original log:  + framepars_operations elphel393-framepars@0: Configuring compressor DMA channels  + circbuf elphel393-circbuf@0: Setting i2c drive mode for port 0  + circbuf elphel393-circbuf@0: register_i2c_sensor()  + detect_sensors elphel393-detect_sensors@0: detect_sensors_par2addr_init(): sensorPortConfig[0].sensor[0] = 0x44  + Unable to handle kernel NULL pointer dereference at virtual address 00000000  + pgd = ecdb4000  + [00000000] *pgd=00000000  + Internal error: Oops - BUG: 5 [#1] PREEMPT SMP ARM  + Modules linked in:  + CPU: 1 PID: 1755 Comm: php Not tainted 4.14.0-xilinx-v2018.3 #1  + Hardware name: Xilinx Zynq Platform  + task: ee80cd80 task.stack: ecda0000  + PC is at register_i2c_sensor+0x244/0x2ac  + LR is at 0x0  + pc : [<c05a19e8>]    lr : [<00000000>]    psr: 60030013  + sp : ecda1480  ip : ecda14a8  fp : 00000000  + r10: c0ee625c  r9 : 000000fc  r8 : 00000000  + r7 : 00000028  r6 : ecda14a8  r5 : c0c3ca58  r4 : 00000000  + r3 : 00000000  r2 : c09b093a  r1 : ee973c91  r0 : 00000000  + Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none  + Control: 18c5387d  Table: 2cdb404a  DAC: 00000051  + Process php (pid: 1755, stack limit = 0xecda0210)  + Stack: (0xecda1480 to 0xecda2000)  + ...  + ---[ end Kernel panic - not syncing: Fatal exception in interrupt Oleg

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

Show changes Oleg

Show changes Oleg

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

Show changes Oleg

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

Show changes Oleg

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

Show changes Oleg

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

Show changes Oleg

‎[SOLVED] Note 12: test raw recording

Show changes Oleg

‎[SOLVED] Note 12: test raw recording

Show changes Oleg