Wiki Recent Changes

Track the most recent changes to the wiki in this feed. MediaWiki 1.28.0

URL: https://wiki.elphel.com/wiki/Special:RecentChanges

Updated: 24 min 40 sec ago

Poky migration from rocko to warrior

Mon, 09/09/2019 - 13:49

← 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?!! −=='''SOLVED''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'==+=='''[SOLVED]''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== * Kernel Oops: * Kernel Oops: [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 35.872118] BUG: unsupported FP instruction in kernel mode Oleg

Poky manual

Mon, 09/09/2019 - 13:44

← Older revision Revision as of 19:44, 9 September 2019 (8 intermediate revisions by the same user not shown)Line 1: Line 1: +==Description== +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]. + ==Use cases== ==Use cases== −* 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. ==Description== ==Description== * 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: ==Requirements== ==Requirements== −* 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] ==Output files== ==Output files== Line 38: Line 42: |- |- ! File(s) ! File(s) +! Build Command ! Description ! Description |- |- | '''boot.bin''' | '''boot.bin''' +| ''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''' |- |- | '''u-boot-dtb.img''' | '''u-boot-dtb.img''' +| ''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'| '''devicetree.dtb''' |valign='top'| '''devicetree.dtb''' +| 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: |- |- | '''uImage''' | '''uImage''' +| ''bitbake linux-xlnx'' | kernel, drivers | kernel, drivers |- |- | '''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz''' | '''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz''' +| ''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: −* Poky 2.6 Thud (Kubuntu 18.04)+* Poky 2.7.1 Warrior (Kubuntu 16.04 or 18.04) − 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 − −'''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)]] |} |} − −==Build== − −===All targets=== − − bitbake u-boot device-tree linux-xlnx core-image-elphel393 − −===Bootloader=== − − bitbake u-boot − −====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 − −===Device tree=== − − bitbake device-tree − −====Output==== −* '''devicetree.dtb''' − −===Kernel=== − − bitbake linux-xlnx − −====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 − −===Rootfs=== − − bitbake core-image-elphel393 − −====Output==== −* '''rootfs.tar.gz''' −* '''rootfs.ubi''', '''rootfs.ubifs''' ==Details for development== ==Details for development== [[Development_for_10393|'''Development for 10393''']] [[Development_for_10393|'''Development for 10393''']] Oleg

Poky manual

Mon, 09/09/2019 - 13:09

‎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: ==Requirements== ==Requirements== −* 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] ==Output files== ==Output files== Line 38: Line 37: |- |- ! File(s) ! File(s) +! Build Command ! Description ! Description |- |- | '''boot.bin''' | '''boot.bin''' +| ''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''' |- |- | '''u-boot-dtb.img''' | '''u-boot-dtb.img''' +| ''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'| '''devicetree.dtb''' |valign='top'| '''devicetree.dtb''' +| 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: |- |- | '''uImage''' | '''uImage''' +| ''bitbake linux-xlnx'' | kernel, drivers | kernel, drivers |- |- | '''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz''' | '''rootfs.ubifs''', '''rootfs.ubi''', '''rootfs.tar.gz''' +| ''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: −* Poky 2.6 Thud (Kubuntu 18.04)+* Poky 2.7.1 Warrior (Kubuntu 16.04 or 18.04) − 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: |} |} −==Build== − −===All targets=== − − bitbake u-boot device-tree linux-xlnx core-image-elphel393 − −===Bootloader=== − − bitbake u-boot − −====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 − −===Device tree=== − − bitbake device-tree − −====Output==== −* '''devicetree.dtb''' − −===Kernel=== − − bitbake linux-xlnx − −====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 − −===Rootfs=== − − bitbake core-image-elphel393 − −====Output==== −* '''rootfs.tar.gz''' −* '''rootfs.ubi''', '''rootfs.ubifs''' ==Details for development== ==Details for development== [[Development_for_10393|'''Development for 10393''']] [[Development_for_10393|'''Development for 10393''']] Oleg

Poky migration from rocko to warrior

Mon, 09/09/2019 - 12:39

‎- 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?!! −=='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'==+=='''SOLVED''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== * Kernel Oops: * Kernel Oops: [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 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 =='''[SOLVED]''' Note 5: Bring up NAND OTP support== =='''[SOLVED]''' Note 5: Bring up NAND OTP support== Oleg

Poky migration from rocko to warrior

Tue, 08/20/2019 - 11:30

‎- 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

Poky migration from rocko to warrior

Thu, 08/08/2019 - 15:55

‎- 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?!! =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== =='''-''' 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

Poky migration from rocko to warrior

Thu, 08/08/2019 - 15:55

‎- 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?!! =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== − +* Kernel Oops: −* '''autocampars.php''' runs at boot and sometimes causes Kernel Oops: − [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 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 [ 35.999422] note: php[1756] exited with preempt_count 2 −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

Poky migration from rocko to warrior

Thu, 08/08/2019 - 15:55

‎- 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: =='''[SOLVED]''' Note 1: Bring back fpga char device== =='''[SOLVED]''' 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?!! =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== − +* Kernel Oops: −* '''autocampars.php''' runs at boot and sometimes causes Kernel Oops: − [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 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 [ 35.999422] note: php[1756] exited with preempt_count 2 −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

Poky migration from rocko to warrior

Thu, 08/08/2019 - 15:55

‎- 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: │ │ ├── jpeghead.c │ │ ├── jpeghead.c │ │ ├── klogger_393.c │ │ ├── klogger_393.c − │ │ ├── lepton.c+ │ │ ├── lepton.c − │ │ ├── mt9f002.c+ │ │ ├── mt9f002.c │ │ ├── mt9x001.c # sensor is programmed correctly │ │ ├── mt9x001.c # sensor is programmed correctly │ │ ├── multi10359.c │ │ ├── multi10359.c Line 69: Line 69: =='''[SOLVED]''' Note 1: Bring back fpga char device== =='''[SOLVED]''' 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?!! =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== =='''-''' Note 4: PHP causing 'unsupported FP instruction in kernel mode'== − +* Kernel Oops: −* '''autocampars.php''' runs at boot and sometimes causes Kernel Oops: − [ 35.872118] BUG: unsupported FP instruction in kernel mode [ 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 [ 35.999422] note: php[1756] exited with preempt_count 2 −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 −=='''-''' Note 12: test raw recording==+=='''[SOLVED]''' 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 + ... + +=='''[SOLVED]''' 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