← Older revision Revision as of 23:53, 8 November 2013 (9 intermediate revisions not shown)Line 1: Line 1:  +==About==  +* All of the described things happen in Kubuntu 13.04  +* Building Linux images for Zynq platform - ARMv7  + ==GIT== ==GIT== <font size='2'> <font size='2'>   git clone -b dylan git://git.yoctoproject.org/poky.git   git clone -b dylan git://git.yoctoproject.org/poky.git -  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git poky/meta-xilinx+  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git meta-xilinx -  git clone git://git.code.sf.net/p/elphel/meta-elphel393 poky/meta-elphel393+  git clone git://git.code.sf.net/p/elphel/meta-elphel393 meta-elphel393 </font> </font> Line 14: Line 18: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: <font size='2'> <font size='2'> -  <absolute-path>/poky/meta-xilinx \+  <absolute-path>/meta-xilinx \ -  <absolute-path>/poky/meta-xilinx/meta-zedboard \+  <absolute-path>/meta-xilinx/meta-zedboard \ -  <absolute-path>/poky/meta-elphel393 \+  <absolute-path>/meta-elphel393 \ </font> </font> * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: Line 22: Line 26:    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU) -   MACHINE ?= "zedboard" '''(?)'''+   MACHINE ?= "zedboard"  +</font>  +===Notes===  +<font color="red">  +*MACHINE="zedboard" is used to build the kernel. Doesn't matter for ramdisk.image.gz because the recipes don't have any bbappends for core-images. </font> </font> Line 28: Line 36: <font size='2'> <font size='2'>   bitbake linux-xlnx   bitbake linux-xlnx  +</font>  +  +===Notes===  +<font color="red">  +* The '''dtc''' script for converting device tree between *.dts and *.dtb formats is built along with the kernel. </font> </font> Line 33: Line 46: <font size='2'> <font size='2'>   bitbake elphel393   bitbake elphel393  +</font>  +===Notes===  +<font size='2'>  +<font color="red">  +* Current packages:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot python-core ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  +* Also works:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  + IMAGE_INSTALL_append = "python-core"  +* Why ''python-core'' and not just ''python''?  +** ''poky/meta/recipes-devtools/python/python-2.7-manifest.inc'' has a list in PACKAGES items from which should go into IMAGE_INSTALL  +** Among all there's no ''python'' in the PACKAGES list.  +** Does '''hob''' install all the PACKAGES if ''python'' is checked? Haven't tried, also the used '''hob''' version doesn't support saving recipes.  +* '''(Is there a better solution?)''' Adding packages : '''apache2''', '''php''', '''i2c-tools''', '''mtd-utils''', steps:  +**Clone '''meta-oe''' from OpenEmbedded:  + git clone -b dylan https://github.com/openembedded/meta-oe.git  +**Lines to ''bblayers.conf'':  +    <absolute-path>/meta-oe/meta-oe \  +    <absolute-path>/poky/meta-oe/meta-perl \  +    <absolute-path>/poky/meta-oe/meta-webserver \  +** ''elphel393.bb'' '''(some discussions mention the leading space is mandatory but somehow it works even without it)''':  + IMAGE_INSTALL_append = "'''<mandatory space?>'''python-core \  +                        i2c-tools \  +                        mtd-utils \  +                        modphp \  +                        apache2 \  +                        php-cli"  +** Why ''php-cli'' and not just ''php''?  + meta-oe/meta-oe/recipes-devtools/php/php.inc:  + PACKAGES = "${PN}-dbg ${PN}-cli ${PN}-cgi ${PN}-fpm ${PN}-fpm-apache2 ${PN}-pear ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN}"  +*** PACKAGES includes ''php''. What is installed? (No ''php-cli'': missing /usr/bin/php) Didn't investigate.  +*** What does hob build if ''php'' is checked? Didn't test.  +*** Using ''php-cli'' installs php in the /usr/bin/. Tested.  +*** Using ''php-cli'' increases the unpacked image size from ~16MB to ~50MB.  +**To fix the '''ERROR'''="'''Could not inherit file classes/vala.bbclass'''" in bitbake copy vala.bbclass from oe-core? or delete the conflicting recipes (2?)?  +**To fix the '''ERROR'''="'''Failed to parse krb5_1.11.3.bb'''" in bitbake delete the directory ''meta-oe/meta-oe/recipes-connectivity/krb5''  +===U-boot and device tree related notes===  +* '''The default UNPACKED ramdisk max size for zynq is 16MB - once it gets bigger you get KERNEL PANIC - the solution is [http://forums.xilinx.com/t5/Embedded-Linux/Need-bigger-ramdisk-32MB-on-ZC702/m-p/303457#M5775 modifying the device tree] - then recompile into DTB:'''  + *.dts, add to '''bootargs''' parameter ''ramdisk_size=32768'' (takes KB), example:  + bootargs = "console=ttyPS0,115200 root=/dev/ram rw ip=192.168.1.10 earlyprintk '''ramdisk_size=32768'''";  +* '''The default COMPRESSED ramdisk max size for zynq is 10MB set in u-boot''' - change according to your needs, example:  + ''zynq_zed.h'':  + "sdboot=echo Copying Linux from SD to RAM... && " \  +                "mmcinfo && " \  +                "fatload mmc 0 0x3000000 ${kernel_image} && " \  +                "fatload mmc 0 0x2A00000 ${devicetree_image} && " \  +                "fatload mmc 0 0x2000000 ${ramdisk_image} && " \  +                "bootm 0x3000000 0x2000000 0x2A00000\0" \  +  + So, the max sizes:  + compressed ramdisk    = 0x2A00000 - 0x2000000 = 0xA00000 = 10MB  + devicetree = 0x3000000 - 0x2A00000 = 0x600000 = 6MB  +  +</font> </font> </font> Oleg

U-boot and device tree related notes:

← Older revision Revision as of 21:59, 8 November 2013 (8 intermediate revisions not shown)Line 1: Line 1:  +==About==  +* All of the described things happen in Kubuntu 13.04  +* Building Linux images for Zynq platform - ARMv7  + ==GIT== ==GIT== <font size='2'> <font size='2'>   git clone -b dylan git://git.yoctoproject.org/poky.git   git clone -b dylan git://git.yoctoproject.org/poky.git -  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git poky/meta-xilinx+  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git meta-xilinx -  git clone git://git.code.sf.net/p/elphel/meta-elphel393 poky/meta-elphel393+  git clone git://git.code.sf.net/p/elphel/meta-elphel393 meta-elphel393 </font> </font> Line 14: Line 18: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: <font size='2'> <font size='2'> -  <absolute-path>/poky/meta-xilinx \+  <absolute-path>/meta-xilinx \ -  <absolute-path>/poky/meta-xilinx/meta-zedboard \+  <absolute-path>/meta-xilinx/meta-zedboard \ -  <absolute-path>/poky/meta-elphel393 \+  <absolute-path>/meta-elphel393 \ </font> </font> * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: Line 22: Line 26:    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU) -   MACHINE ?= "zedboard" '''(?)'''+   MACHINE ?= "zedboard"  +</font>  +===Notes===  +<font color="red">  +*MACHINE="zedboard" is used to build the kernel. Doesn't matter for ramdisk.image.gz because the recipes don't have any bbappends for core-images. </font> </font> Line 28: Line 36: <font size='2'> <font size='2'>   bitbake linux-xlnx   bitbake linux-xlnx  +</font>  +  +===Notes===  +<font color="red">  +* The '''dtc''' script for converting device tree between *.dts and *.dtb formats is built along with the kernel. </font> </font> Line 33: Line 46: <font size='2'> <font size='2'>   bitbake elphel393   bitbake elphel393  +</font>  +===Notes===  +<font size='2'>  +<font color="red">  +* Current packages:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot python-core ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  +* Also works:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  + IMAGE_INSTALL_append = "python-core"  +* Why ''python-core'' and not just ''python''?  +** ''poky/meta/recipes-devtools/python/python-2.7-manifest.inc'' has a list in PACKAGES items from which should go into IMAGE_INSTALL  +** Among all there's no ''python'' in the PACKAGES list.  +** Does '''hob''' install all the PACKAGES if ''python'' is checked? Haven't tried, also the used '''hob''' version doesn't support saving recipes.  +* '''(Is there a better solution?)''' Adding packages : '''apache2''', '''php''' and '''i2c-tools''', steps:  +**Clone '''meta-oe''' from OpenEmbedded:  + git clone -b dylan https://github.com/openembedded/meta-oe.git  +**Lines to ''bblayers.conf'':  +    <absolute-path>/meta-oe/meta-oe \  +    <absolute-path>/poky/meta-oe/meta-perl \  +    <absolute-path>/poky/meta-oe/meta-webserver \  +** ''elphel393.bb'' '''(some discussions mention the leading space is mandatory but somehow it works even without it)''':  + IMAGE_INSTALL_append = "'''<mandatory space?>'''python-core \  +                        i2c-tools \  +                        modphp \  +                        apache2 \  +                        php-cli"  +** Why ''php-cli'' and not just ''php''?  + meta-oe/meta-oe/recipes-devtools/php/php.inc:  + PACKAGES = "${PN}-dbg ${PN}-cli ${PN}-cgi ${PN}-fpm ${PN}-fpm-apache2 ${PN}-pear ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN}"  +*** PACKAGES includes ''php''. What is installed? (No ''php-cli'': missing /usr/bin/php) Didn't investigate.  +*** What does hob build if ''php'' is checked? Didn't test.  +*** Using ''php-cli'' installs php in the /usr/bin/. Tested.  +*** Using ''php-cli'' increases the unpacked image size from ~16MB to ~50MB.  +**To fix the '''ERROR'''="'''Could not inherit file classes/vala.bbclass'''" in bitbake copy vala.bbclass from oe-core? or delete the conflicting recipes (2?)?  +**To fix the '''ERROR'''="'''Failed to parse krb5_1.11.3.bb'''" in bitbake delete the directory ''meta-oe/meta-oe/recipes-connectivity/krb5''  +===U-boot and device tree related notes===  +* '''The default UNPACKED ramdisk max size for zynq is 16MB - once it gets bigger you get KERNEL PANIC - the solution is [http://forums.xilinx.com/t5/Embedded-Linux/Need-bigger-ramdisk-32MB-on-ZC702/m-p/303457#M5775 modifying the device tree] - then recompile into DTB:'''  + *.dts, add to '''bootargs''' parameter ''ramdisk_size=32768'' (takes KB), example:  + bootargs = "console=ttyPS0,115200 root=/dev/ram rw ip=192.168.1.10 earlyprintk '''ramdisk_size=32768'''";  +* '''The default COMPRESSED ramdisk max size for zynq is 10MB set in u-boot''' - change according to your needs, example:  + ''zynq_zed.h'':  + "sdboot=echo Copying Linux from SD to RAM... && " \  +                "mmcinfo && " \  +                "fatload mmc 0 0x3000000 ${kernel_image} && " \  +                "fatload mmc 0 0x2A00000 ${devicetree_image} && " \  +                "fatload mmc 0 0x2000000 ${ramdisk_image} && " \  +                "bootm 0x3000000 0x2000000 0x2A00000\0" \  +  + So, the max sizes:  + compressed ramdisk    = 0x2A00000 - 0x2000000 = 0xA00000 = 10MB  + devicetree = 0x3000000 - 0x2A00000 = 0x600000 = 6MB  +  +</font> </font> </font> Oleg

← Older revision Revision as of 21:18, 8 November 2013 (6 intermediate revisions not shown)Line 1: Line 1:  +==About==  +* in Kubuntu 13.04  +* Building Linux images for Zynq platform - ARMv7  + ==GIT== ==GIT== <font size='2'> <font size='2'>   git clone -b dylan git://git.yoctoproject.org/poky.git   git clone -b dylan git://git.yoctoproject.org/poky.git -  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git poky/meta-xilinx+  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git meta-xilinx -  git clone git://git.code.sf.net/p/elphel/meta-elphel393 poky/meta-elphel393+  git clone git://git.code.sf.net/p/elphel/meta-elphel393 meta-elphel393 </font> </font> Line 14: Line 18: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: <font size='2'> <font size='2'> -  <absolute-path>/poky/meta-xilinx \+  <absolute-path>/meta-xilinx \ -  <absolute-path>/poky/meta-xilinx/meta-zedboard \+  <absolute-path>/meta-xilinx/meta-zedboard \ -  <absolute-path>/poky/meta-elphel393 \+  <absolute-path>/meta-elphel393 \ </font> </font> * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: Line 22: Line 26:    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU) -   MACHINE ?= "zedboard" '''(?)'''+   MACHINE ?= "zedboard"  +</font>  +===Notes===  +<font color="red">  +*MACHINE="zedboard" is used to build the kernel. Doesn't matter for ramdisk.image.gz because the recipes don't have any bbappends for core-images. </font> </font> Line 28: Line 36: <font size='2'> <font size='2'>   bitbake linux-xlnx   bitbake linux-xlnx  +</font>  +  +===Notes===  +<font color="red">  +* The '''dtc''' script for converting device tree between *.dts and *.dtb formats is built along with the kernel. </font> </font> Line 33: Line 46: <font size='2'> <font size='2'>   bitbake elphel393   bitbake elphel393  +</font>  +===Notes===  +<font size='2'>  +<font color="red">  +* Current packages:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot python-core ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  +* Also works:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  + IMAGE_INSTALL_append = "python-core"  +* Why ''python-core'' and not just ''python''?  +** ''poky/meta/recipes-devtools/python/python-2.7-manifest.inc'' has a list in PACKAGES items from which should go into IMAGE_INSTALL  +** Among all there's no ''python'' in the PACKAGES list.  +** Does '''hob''' install all the PACKAGES if ''python'' is checked? Haven't tried, also the used '''hob''' version doesn't support saving recipes.  +* '''(Is there a better solution?)''' Adding packages : '''apache2''', '''php''' and '''i2c-tools''', steps:  +**Clone '''meta-oe''' from OpenEmbedded:  + git clone -b dylan https://github.com/openembedded/meta-oe.git  +**Lines to ''bblayers.conf'':  +    <absolute-path>/meta-oe/meta-oe \  +    <absolute-path>/poky/meta-oe/meta-perl \  +    <absolute-path>/poky/meta-oe/meta-webserver \  +** ''elphel393.bb'' '''(some discussions mention the leading space is mandatory but somehow it works even without it)''':  + IMAGE_INSTALL_append = "'''<mandatory space?>'''python-core \  +                        i2c-tools \  +                        modphp \  +                        apache2 \  +                        php-cli"  +** Why ''php-cli'' and not just ''php''?  + meta-oe/meta-oe/recipes-devtools/php/php.inc:  + PACKAGES = "${PN}-dbg ${PN}-cli ${PN}-cgi ${PN}-fpm ${PN}-fpm-apache2 ${PN}-pear ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN}"  +*** PACKAGES includes ''php''. What is installed? (No ''php-cli'': missing /usr/bin/php) Didn't investigate.  +*** What does hob build if ''php'' is checked? Didn't test.  +*** Using ''php-cli'' installs php in the /usr/bin/. Tested.  +*** Using ''php-cli'' increases the unpacked image size from ~16MB to ~50MB.  +**To fix the '''ERROR'''="'''Could not inherit file classes/vala.bbclass'''" in bitbake copy vala.bbclass from oe-core? or delete the conflicting recipes (2?)?  +**To fix the '''ERROR'''="'''Failed to parse krb5_1.11.3.bb'''" in bitbake delete the directory ''meta-oe/meta-oe/recipes-connectivity/krb5''  +===U-boot and device tree related notes===  +* '''The default UNPACKED ramdisk max size for zynq is 16MB - once it gets bigger you get KERNEL PANIC - the solution is [http://forums.xilinx.com/t5/Embedded-Linux/Need-bigger-ramdisk-32MB-on-ZC702/m-p/303457#M5775 modifying the device tree] - then recompile into DTB:'''  + *.dts, add to '''bootargs''' parameter ''ramdisk_size=32768'' (in KB), example:  + bootargs = "console=ttyPS0,115200 root=/dev/ram rw ip=192.168.1.10 earlyprintk '''ramdisk_size=32768'''";  +* '''The default COMPRESSED ramdisk max size for zynq is 10MB set in u-boot''' - change according to your needs, example:  + ''zynq_zed.h'':  + "sdboot=echo Copying Linux from SD to RAM... && " \  +                "mmcinfo && " \  +                "fatload mmc 0 0x3000000 ${kernel_image} && " \  +                "fatload mmc 0 0x2A00000 ${devicetree_image} && " \  +                "fatload mmc 0 0x2000000 ${ramdisk_image} && " \  +                "bootm 0x3000000 0x2000000 0x2A00000\0" \  +  + So, the max sizes:  + compressed ramdisk    = 0x2A00000 - 0x2000000 = 0xA00000 = 10MB  + devicetree = 0x3000000 - 0x2A00000 = 0x600000 = 6MB  +  +</font> </font> </font> Oleg

← Older revision Revision as of 20:51, 8 November 2013 (5 intermediate revisions not shown)Line 1: Line 1:  +==About==  +* in Kubuntu 13.04  +* Building Linux images for Zynq platform - ARMv7  + ==GIT== ==GIT== <font size='2'> <font size='2'>   git clone -b dylan git://git.yoctoproject.org/poky.git   git clone -b dylan git://git.yoctoproject.org/poky.git -  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git poky/meta-xilinx+  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git meta-xilinx -  git clone git://git.code.sf.net/p/elphel/meta-elphel393 poky/meta-elphel393+  git clone git://git.code.sf.net/p/elphel/meta-elphel393 meta-elphel393 </font> </font> Line 14: Line 18: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: <font size='2'> <font size='2'> -  <absolute-path>/poky/meta-xilinx \+  <absolute-path>/meta-xilinx \ -  <absolute-path>/poky/meta-xilinx/meta-zedboard \+  <absolute-path>/meta-xilinx/meta-zedboard \ -  <absolute-path>/poky/meta-elphel393 \+  <absolute-path>/meta-elphel393 \ </font> </font> * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: Line 22: Line 26:    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU) -   MACHINE ?= "zedboard" '''(?)'''+   MACHINE ?= "zedboard"  +</font>  +===Notes===  +<font color="red">  +*MACHINE="zedboard" is used to build the kernel. Doesn't matter for ramdisk.image.gz because the recipes don't have any bbappends for core-images. </font> </font> Line 33: Line 41: <font size='2'> <font size='2'>   bitbake elphel393   bitbake elphel393  +</font>  +===Notes===  +<font size='2'>  +<font color="red">  +* Current packages:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot python-core ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  +* Also works:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  + IMAGE_INSTALL_append = "python-core"  +* Why ''python-core'' and not just ''python''?  +** ''poky/meta/recipes-devtools/python/python-2.7-manifest.inc'' has a list in PACKAGES items from which should go into IMAGE_INSTALL  +** Among all there's no ''python'' in the PACKAGES list.  +** Does '''hob''' install all the PACKAGES if ''python'' is checked? Haven't tried, also the used '''hob''' version doesn't support saving recipes.  +* '''(Is there a better solution?)''' Adding packages : '''apache2''', '''php''' and '''i2c-tools''', steps:  +**Clone '''meta-oe''' from OpenEmbedded:  + git clone -b dylan https://github.com/openembedded/meta-oe.git  +**Lines to ''bblayers.conf'':  +    <absolute-path>/meta-oe/meta-oe \  +    <absolute-path>/poky/meta-oe/meta-perl \  +    <absolute-path>/poky/meta-oe/meta-webserver \  +** ''elphel393.bb'' '''(some discussions mention the leading space is mandatory but somehow it works even without it)''':  + IMAGE_INSTALL_append = "'''<mandatory space?>'''python-core \  +                        i2c-tools \  +                        modphp \  +                        apache2 \  +                        php-cli"  +** Why ''php-cli'' and not just ''php''?  + meta-oe/meta-oe/recipes-devtools/php/php.inc:  + PACKAGES = "${PN}-dbg ${PN}-cli ${PN}-cgi ${PN}-fpm ${PN}-fpm-apache2 ${PN}-pear ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN}"  +*** PACKAGES includes ''php''. What is installed? (No ''php-cli'': missing /usr/bin/php) Didn't investigate.  +*** What does hob build if ''php'' is checked? Didn't test.  +*** Using ''php-cli'' installs php in the /usr/bin/. Tested.  +*** Using ''php-cli'' increases the unpacked image size from ~16MB to ~50MB.  +**To fix the '''ERROR'''="'''Could not inherit file classes/vala.bbclass'''" in bitbake copy vala.bbclass from oe-core? or delete the conflicting recipes (2?)?  +**To fix the '''ERROR'''="'''Failed to parse krb5_1.11.3.bb'''" in bitbake delete the directory ''meta-oe/meta-oe/recipes-connectivity/krb5''  +===U-boot and device tree related notes===  +* '''The default UNPACKED ramdisk max size for zynq is 16MB - once it gets bigger you get KERNEL PANIC - the solution is [http://forums.xilinx.com/t5/Embedded-Linux/Need-bigger-ramdisk-32MB-on-ZC702/m-p/303457#M5775 modifying the device tree] - then recompile into DTB:'''  + *.dts, add to '''bootargs''' parameter ''ramdisk_size=32768'' (in KB), example:  + bootargs = "console=ttyPS0,115200 root=/dev/ram rw ip=192.168.1.10 earlyprintk '''ramdisk_size=32768'''";  +* '''The default COMPRESSED ramdisk max size for zynq is 10MB set in u-boot''' - change according to your needs, example:  + ''zynq_zed.h'':  + "sdboot=echo Copying Linux from SD to RAM... && " \  +                "mmcinfo && " \  +                "fatload mmc 0 0x3000000 ${kernel_image} && " \  +                "fatload mmc 0 0x2A00000 ${devicetree_image} && " \  +                "fatload mmc 0 0x2000000 ${ramdisk_image} && " \  +                "bootm 0x3000000 0x2000000 0x2A00000\0" \  +  + So, the max sizes:  + compressed ramdisk    = 0x2A00000 - 0x2000000 = 0xA00000 = 10MB  + devicetree = 0x3000000 - 0x2A00000 = 0x600000 = 6MB  +  +</font> </font> </font> Oleg

← Older revision Revision as of 19:35, 8 November 2013 (3 intermediate revisions not shown)Line 1: Line 1:  +==About==  +* in Kubuntu 13.04  +* Building Linux images for Zynq platform - ARMv7  + ==GIT== ==GIT== <font size='2'> <font size='2'>   git clone -b dylan git://git.yoctoproject.org/poky.git   git clone -b dylan git://git.yoctoproject.org/poky.git -  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git poky/meta-xilinx+  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git meta-xilinx -  git clone git://git.code.sf.net/p/elphel/meta-elphel393 poky/meta-elphel393+  git clone git://git.code.sf.net/p/elphel/meta-elphel393 meta-elphel393 </font> </font> Line 14: Line 18: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: <font size='2'> <font size='2'> -  <absolute-path>/poky/meta-xilinx \+  <absolute-path>/meta-xilinx \ -  <absolute-path>/poky/meta-xilinx/meta-zedboard \+  <absolute-path>/meta-xilinx/meta-zedboard \ -  <absolute-path>/poky/meta-elphel393 \+  <absolute-path>/meta-elphel393 \ </font> </font> * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: Line 22: Line 26:    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    BB_NUMBER_THREADS = "8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU)    PARALLEL_MAKE = "-j 8" (depends on the PC's CPU) -   MACHINE ?= "zedboard" '''(?)'''+   MACHINE ?= "zedboard"  +</font>  +===Notes===  +<font color="red">  +*MACHINE="zedboard" is used to build the kernel. Doesn't matter for ramdisk.image.gz because the recipes don't have any bbappends for core-images. </font> </font> Line 33: Line 41: <font size='2'> <font size='2'>   bitbake elphel393   bitbake elphel393  +</font>  +===Notes===  +<font size='2'>  +<font color="red">  +* Current packages:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot python-core ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  +* Also works:  + ''elphel393.bb'':  + IMAGE_INSTALL = "packagegroup-core-boot ${ROOTFS_PKGMANAGE_BOOTSTRAP} ${CORE_IMAGE_EXTRA_INSTALL}"  + IMAGE_INSTALL_append = "python-core"  +* Why ''python-core'' and not just ''python''?  +** ''poky/meta/recipes-devtools/python/python-2.7-manifest.inc'' has a list in PACKAGES items from which should go into IMAGE_INSTALL  +** Among all there's no ''python'' in the PACKAGES list.  +** Does '''hob''' install all the PACKAGES if ''python'' is checked? Haven't tried, also the used '''hob''' version doesn't support saving recipes.  +* '''(Is there a better solution?)''' Adding packages : '''apache2''', '''php''' and '''i2c-tools''', steps:  +**Clone '''meta-oe''' from OpenEmbedded:  + git clone -b dylan https://github.com/openembedded/meta-oe.git  +**Lines to ''bblayers.conf'':  +    <absolute-path>/meta-oe/meta-oe \  +    <absolute-path>/poky/meta-oe/meta-perl \  +    <absolute-path>/poky/meta-oe/meta-webserver \  +** ''elphel393.bb'' '''(some discussions mention the leading space is mandatory but somehow it works even without it)''':  + IMAGE_INSTALL_append = "'''<mandatory space?>'''python-core \  +                        i2c-tools \  +                        modphp \  +                        apache2 \  +                        php-cli"  +** Why ''php-cli'' and not just ''php''?  + meta-oe/meta-oe/recipes-devtools/php/php.inc:  + PACKAGES = "${PN}-dbg ${PN}-cli ${PN}-cgi ${PN}-fpm ${PN}-fpm-apache2 ${PN}-pear ${PN}-dev ${PN}-staticdev ${PN}-doc ${PN}"  +*** PACKAGES includes ''php''. What is installed? (No ''php-cli'': missing /usr/bin/php) Didn't investigate.  +*** What does hob build if ''php'' is checked? Didn't test.  +*** Using ''php-cli'' installs php in the /usr/bin/. Tested.  +*** Using ''php-cli'' increases the unpacked image size from ~16MB to ~50MB.  +**To fix the '''ERROR'''="'''Could not inherit file classes/vala.bbclass'''" in bitbake copy vala.bbclass from oe-core? or delete the conflicting recipes (2?)?  +**To fix the '''ERROR'''="'''Failed to parse krb5_1.11.3.bb'''" in bitbake delete the directory ''meta-oe/meta-oe/recipes-connectivity/krb5''  +* '''The default ramdisk size for zynq is 16MB - once it gets bigger you get KERNEL PANIC - the solution is [http://forums.xilinx.com/t5/Embedded-Linux/Need-bigger-ramdisk-32MB-on-ZC702/m-p/303457#M5775 modifying the device tree] - then recompile into DTB:'''  + *.dts, add to '''bootargs''' parameter ''ramdisk_size=32768'' (in KB), example:  + bootargs = "console=ttyPS0,115200 root=/dev/ram rw ip=192.168.1.10 earlyprintk '''ramdisk_size=32768'''";  +</font> </font> </font> Oleg

← Older revision Revision as of 17:55, 7 November 2013 Line 2: Line 2: <font size='2'> <font size='2'>   git clone -b dylan git://git.yoctoproject.org/poky.git   git clone -b dylan git://git.yoctoproject.org/poky.git -  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git poky/meta-xilinx+  git clone -b dylan https://github.com/Xilinx/meta-xilinx.git meta-xilinx -  git clone git://git.code.sf.net/p/elphel/meta-elphel393 poky/meta-elphel393+  git clone git://git.code.sf.net/p/elphel/meta-elphel393 meta-elphel393 </font> </font> Line 14: Line 14: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: * Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS: <font size='2'> <font size='2'> -  <absolute-path>/poky/meta-xilinx \+  <absolute-path>/meta-xilinx \ -  <absolute-path>/poky/meta-xilinx/meta-zedboard \+  <absolute-path>/meta-xilinx/meta-zedboard \ -  <absolute-path>/poky/meta-elphel393 \+  <absolute-path>/meta-elphel393 \ </font> </font> * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: * Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things: Oleg

With all three of the new boards for the NC393 series cameras assembled (but only partially tested) it is now possible to connect them with the existent components and show some possible configurations. Main applications of Elphel cameras are scientific research, system prototyping, proofs of concepts designs – areas that routinely require unique configurations, and this new cmaer series will continue tradition of high modularity.

The camera boards look nothing like Lego blocks, but nevertheless they can zip together in different ways allowing to make new systems with minimal additional hardware. Elphel new design values our prior work (hardware development is still expensive) and provides compatibility with the existent modules, simultaneously enabling new features that were not previously possible, The most obvious example – sensor interface. The 10393 board is designed to accommodate our existent sensor front ends, custom flex cables of different lengths and shapes. That will help us to reduce the transition period to the new camera so we can focus on the high performance system board and port portions of the software and FPGA code, code that is already proven to work.

The same camera sensor ports will allow us to use multi-lane serial sensor connections needed for the modern high speed and high resolution devices, but we will work on this only after the first part will be done and we will be able to replace our current systems with the new ones. Implementation of the serial sensor connection has some challenges for us because the used protocols are not open and we have to rely only on the pieces of the available information and some reverse-engineering and research. It is not the most fun work to do, but being an Open Hardware/ Free Software company we will not provide our users with semi-open documentation. Our users will always be able to rebuild all the binaries from the source code – same binaries from the same code we have access ourselves. The only NDA Elphel ever signed was with Kodak – that sensor NDA had clear expiration time, so at the moment we planned to start distributing our products (and so the source documentation) we were not be bound by it anymore.

Sample configuration illustrated below combines the new and existent modules, the later have links to the design documentation on Elphel wiki. It is not so for the new boards (10393, 10385, 10389) – no circuit diagrams, parts lists or PCB layouts are publicly available when this post is being written. Hardware errors are usually much more expensive to fix, and we do not want somebody to duplicate our hardware “bugs” until we consider our products (“binaries”) to be good enough to go to our users. So while we set up public Git repository when we start software development, we publish our hardware documentation simultaneously with the start of the product distribution – together with “binaries”, not ahead of them.

Sample configuration of the electronic modules of Elphel NC393 camera family

• 1 – 10393 Multisensor camera system board based on Xilinx Zynq 7030 SoC.
• 2 – 10385 Power supply board
• 3 – 10389 Interface board
• 4 – Inter-board power distribution: 6-pin (3 circuits) header on the 10385, receptacles on both 10393 and 10389
• 5 – Inter-board signal connector: 40 pins (USB, SATA, GPIO)
• 6 – mSATA SSD card
• 7 – Processor heat sink (temporary). Production cameras will have custom heat spreader to transfer CPU/FPGA generated heat to the camera aluminum body or other heat sinks in multicamera systems
• 8 – Ethernet (GigE) jack, РоЕ-compatible
• 9 – DC power input (9-36V or 18-72V depending on application)
• 10 – Memory card (can be used to boot the system for cold firmware update)
• 11 – Micro USB B connector for system serial console with GPIO signals to select boot mode and generate system reset. Mounted on the 10393 system board
• 12 – Micro USB A host connector for communication with external memory and I/O devices. Mounted on the 10389 interface board.
• 13 – USB A/eSATA combo connector. eSATA port will be used for interfacing external storage devices (HDD, SSD) and downloading data from the camera internal SSD to the host computer. USB portion of the connector can provide power to the external device through the same cable as SATA data.
• 14 – 2.5mm audio type connector for external synchronization input and output (opto-isolated and directly coupled)
• 15,16,17 – directly connected sensor front ends. Compatible with the current 5MPix 10338 (shown) and other parallel data output sensors, programmable interface voltage. With the controlled impedance cables same ports will allow using up to 9 differential lanes plus I2C and 2 extra control signals.
• 18,19,20 – sensor front ends connected through 21 – 10359 multiplexer that allows simultaneous acquisition of images from up to 3 sensors into on-board SDRAM and then transferring them to the system board. In the future we will develop a faster multiplexer supporting serial links to the sensors and/or the system.
• 22 – 103695 – IMU adapter board, or other "granddaughter" extension board connected to the 10389 interface (daughter) board. Two 10-pin connectors provide 3.3V and 5.0V power, USB and 4 GPIO connected to the FPGA pads through high speed voltage level shifters
• 23 – 103696 – Serial GPS adapter board with 1pps input, uses another "granddaughter" port.
• 24,25,26 – Inter-camera synchronization (daisy chain connection) for the systems with multiple camera boards located in the same enclosure, similar to the current Elphel Eyesis4pi cameras

The setup shown above is a sort of mockup – while all the components are real, we do not yet have software to run it, even to test it. So there is no sense in powering up such a system – nothing will happen. And there is a lot to be done before we will be able even to completely test the new hardware and prepare and release revision “A” of each of the prototyped boards. We plan to be ready by the middle of 2014.

Fix:

← Older revision Revision as of 06:15, 7 November 2013 Line 1: Line 1: ==<font color=red>Fix</font>== ==<font color=red>Fix</font>== -There was an error recently discovered in the 10359 & 10359A boards - due to a wrong source the sensors (J2,J3,J4) were powered from the 10359's 2.5V instead of the correct 3V coming from 10353 - the result was almost not noticeable - vertical stripes with a 4-pixel period (only with 10338d boards) - [[10359_fix|FixGuide]].+There was an error discovered in 2011 in the 10359 & 10359A boards - due to a wrong source the sensors (J2,J3,J4) were powered from the 10359's 2.5V instead of the correct 3V coming from 10353 - the result was almost not noticeable - vertical stripes with a 4-pixel period (only with 10338d boards) - [[10359_fix|FixGuide]]. 10359B - [[Media:10359b_sch.pdf|10359 Circuit Diagram]],  [[Media:10359b_gerber.tar.gz|10359 Gerber files]] 10359B - [[Media:10359b_sch.pdf|10359 Circuit Diagram]],  [[Media:10359b_gerber.tar.gz|10359 Gerber files]] Andrey.filippov

← Older revision Revision as of 23:15, 6 November 2013 Line 35: Line 35: <font size='2'> <font size='2'>   cd u-boot-xlnx   cd u-boot-xlnx -  ./makeuboot {target}+  ./makeuboot <target> -Supported {targets}:+Supported <targets>:   ./makeuboot zynq_microzed_config   ./makeuboot zynq_microzed_config   ./makeuboot zynq_zc706_config   ./makeuboot zynq_zc706_config Oleg

New page

==GIT==
<font size='2'>
git clone -b dylan git://git.yoctoproject.org/poky.git
git clone -b dylan https://github.com/Xilinx/meta-xilinx.git poky/meta-xilinx
git clone git://git.code.sf.net/p/elphel/meta-elphel393 poky/meta-elphel393
</font>

==Configure==
* Step 1: Init environment
<font size='2'>
cd poky
. ./oe-init-build-env
</font>
* Step 2: Edit ''build/conf/bblayers.conf'' - add paths to BBLAYERS:
<font size='2'>
<absolute-path>/poky/meta-xilinx \
<absolute-path>/poky/meta-xilinx/meta-zedboard \
<absolute-path>/poky/meta-elphel393 \
</font>
* Step 3: Edit ''build/conf/local.conf'' - set MACHINE and other things:
<font size='2'>
BB_NUMBER_THREADS = "8" (depends on the PC's CPU)
PARALLEL_MAKE = "-j 8" (depends on the PC's CPU)
MACHINE ?= "zedboard" '''(?)'''
</font>

==Build kernel==
<font size='2'>
bitbake linux-xlnx
</font>

==Build ramdisk.image.gz==
<font size='2'>
bitbake elphel393
</font>

==Build toolchain==
* Step 1: build
<font size='2'>
bitbake meta-toolchain
</font>

* Step 2: install - launch installer from <some-path>/poky/build/tmp/deploy/ Oleg

← Older revision Revision as of 17:39, 5 November 2013 Line 4: Line 4: ==Supported boards== ==Supported boards== * [http://microzed.org Avnet MicroZed] - Zynq 7Z010 * [http://microzed.org Avnet MicroZed] - Zynq 7Z010  +* [http://www.xilinx.com/products/boards-and-kits/EK-Z7-ZC706-G.htm Xilinx ZC706] - Zynq 7Z045  +* [http://www.zedboard.org/ Digilent/Avnet ZedBoard] - Zynq 7Z020 (not tested)  +* [http://blog.elphel.com/2013/11/nc393-development-progress-testing-the-hardware/ Elphel 10393] - Zynq 7Z030 ==Output== ==Output== Line 32: Line 35: <font size='2'> <font size='2'>   cd u-boot-xlnx   cd u-boot-xlnx -  ./makeuboot+  ./makeuboot {target} -</font>+   +Supported {targets}:  + ./makeuboot zynq_microzed_config  + ./makeuboot zynq_zc706_config  + ./makeuboot elphel393_config  + ./makeuboot zynq_zed_config * The generated files are: * The generated files are: Line 61: Line 69: </font> </font> * Bitstream loading is not tested, current code does not enable level shifters - it may be more appropriate to do just before loading of the bitstream. * Bitstream loading is not tested, current code does not enable level shifters - it may be more appropriate to do just before loading of the bitstream.  +* Write level training for DDR memory doesn't work in MicroZed and ZC706 Oleg

10393 board, memory side

We received the first prototype of the 10393 rev.’0″ – the new camera system board with all the BGA chips mounted. It took a little longer as our PCB assembly manufacturer had to order solder paste stencils as some chips (DC-DC converter module in LGA package and QFN chips with central thermal pads) required more than just applying tacky flux and running them through the reflow oven. The photo shows the 10393 system board together with the 10385 power supply board that I assembled earlier while waiting for the main one. This time the power supply is a separate module so we’ll not need different system board versions for different power supply options as we do with Elphel current NC353.

The shown prototype version has the full functionality, including РоЕ – feature that we will not offer in the production cameras to stay out of trouble with the patent trolls. As soon as the relevant patents will be ruled invalid we will be able to build such boards, but currently the cameras will be powered through the regular barrel-type DC jack or the 4-pin Molex connector in the multi-camera systems like Eyesis. 10385 also has a low-leakage (few microamps idle consumption) switch to use the battery-powered camera in remote locations, controlled by the system clock powered by a super-capacitor (not yet installed – there is an empty space with “+” sign on visible on the photo).

10393 with 10385 board, SoC side

I finalized the 10393 board assembly installing other components including couple hundred (bragging again) 0201 resistors and capacitors. Before starting I tested the resistance (lack of shorts) between the ground and power rails to make sure that I did not screw up pinouts during schematic/PCB design and so the board revision “0″ has a chance to be successfully tested. I repeated those tests while installing components as a power-to-ground shorts are rather difficult to locate as there are so many tiny capacitors between them.

With assembly done the board was ready for the first “smoke” test – power it up while controlling the power consumption (I used a regular test bench power supply instead of the 10385 to provide the primary 3.3V power). I was turning power on for just a few seconds controlling the secondary voltages (1.0V, 1.8V and 1.5V) with the oscilloscope. After fixing a bad soldering on the intermediate “power good” pullup resistor (secondary voltages are supposed to come up in a prescribed sequence) all 3 of these voltages were up, measured OK and the board consumed 320 mA with the system reset released but no firmware to run. There are several additional DC-DC converters on board (5V for USB and 2 independently software-regulated voltages for the external boards (sensor front ends in most applications), but these converters are turned on by the software and I did not have any at the moment.

10393 board, SoC side

Photos show the heat sink and a fan attached to aluminum angle, not directly to the Zynq chip. In production camera there will be a custom heat sink (no fan) between the 10393 and the optional 10389 interface/storage board, it will transfer processor heat to the camera aluminum body and the on-chip thermometer will be used to monitor the temperature and prevent overheating. Rather large temporary heat sink will be used during development (not to depend on the temperature monitoring software), thin angle part will allow to test the 10389 board that will nearly touch the other surface of the aluminum plate.

The next thing to test was to make the CPU (Xilinx Zynq XC7Z030-1FBG484C) run and test the DDR3 memory. If this core of the system is operational, we can test the peripherals one by one, and failures in some of them would not prevent testing of the others. If the core would fail – we’ll have to try to find out (or just guess) the problem and redesign the board, order new ones, have new stencils, assemble and try again. Of course we’ll need to re-spin the board before the production units manufacturing, but I hoped that just the next revision will be good enough to go to the users, that changes will be small. I wrote “guessed”, because if the problems would be related to the DDR3 memory operation the means to troubleshoot them would be limited – the data and address/command lines are completely buried between the chips – memory is placed directly opposite to the Zynq SoC. There are no resistor terminations on the address/command lines, the DQ lines are swapped in each byte group and the byte groups are also swapped. I relied on Xilinx documentation that they OR-ed the data lines during write leveling, so the DQ swapping will not harm this functionality.

Skipping the requirement for the address line termination allowed the overall design to be compact and the connections themselves to be really short (actually shorter than the lines inside the SoC chip itself). I used Micron documentation when considering such solution, but it still needed to be tested on the real board. Such component placement allowed me to make average length of the address/command traces 15.5mm, individual traces had to be shortened/extended to keep combined PCB delays and internal SoC pin delays the same for each address/command and for each member in the byte group for data. Internal DDR3 chip delays do not need to be considered as they are balanced inside the package. Data connections lengths (they are just peer-to-peer, no split for the two memory chips as for address/command lines) are even shorter – they average from 8.5mm to 14.5 mm for different byte groups.

Additional challenge for the initial breathing life in this new board was that we did not have the proven code to run on it, something we had for the Avnet MicroZed board while developing the free software bootloader to replace the Xilinx proprietary one. So that was a real test for our code and I decided to never even try the proprietary one on the new system.

The 10393 board has no LED (not to count 2 Ethernet jack ones, but they are controlled by the Ethernet PHY), so I temporary borrowed one GPIO signal from the MDIO bus (Ethernet PHY control) to be able to step through the boot process not relying on the serial console to be operational. I just put the LED there without any transistor, so the 1.8V-powered diode was really dim, but that was OK. And the serial output turned out to be alive immediately so there was no real need for that debug tool and I was able to remove those extra wires. The board got to U-Boot prompt immediately, but unfortunately – not every time. So I had to spend several days (one of them because of just the faulty micro-SD card that silently replaced one sector with garbage even when read back by the computer) figuring out the instability. I still do not understand exactly what is wrong (it happens when the relocated code switches the memory mapping and copies itself back to the low addresses), but just adding delay by copying that range twice resolved the issue, it turned out to be software-related one as it was present when running other (proven) boards also, not just with the 10393.

The core of the system is now verified, automatic write leveling and the two other hardware-implemented memory training functions produce reasonable results and the delay settings seem to be rather forgiving. That confirms the PCB design and makes it possible to move forward with testing of the other peripherals and starting the FPGA part of the design.

There are other urgent projects at Elphel I have to be involved now, so not yet working on the NC393 full time, but this makes really good news for us to pass the important test. Booting the new board with just the free software, no proprietary tools at all – it is also very encouraging. Xilinx just released the new version of the tools, the human-readable (html) part of the FSBL output looks even fancier than that of Ezynq, but I believe ours is still more convenient to work with – we made it for ourselves, and so for other developers (who are like us) too.

This page gives brief overview of multirotor UAV platform called “Tau”, which is built specially for participating in flying robots contest which is established by Croc company. Our team name was “Autonomous aerospace”.

Doing contest machine we were not looking for easiest way of implementation. Some of the purposes are:further developing of our autopilot and getting experience of integrating machine vision functionality in real-time into control loop.

During contest preparation we dealed for a first time with multyrotor platform . There was only airplanes autopiloting experience before. Adopting autopilot for quadrotor was not so obvious as we expected, but we succeded. Now proudly can say, that we built first quadrotor which calculates all the navigation and control math under QNX real-time operating system . At least no one did any crazy stuff like this before

Mission

Mission is to take off from start marker, follow simple maze toward finish marker, touch down within its contour and than fly back. Then landing on start marker and cutoff engines. On path to target random barrier is set. It can be moved by organizators across the wall and gate might be aligned at left, at right or anywhere between walls.

Drone is allowed to touch walls, but not allowed to touch the ground.

On-board UAV control system

Computers

Central control unit is autopilot AP-05 (AP). It has embedded inertial navigational system (INS), air data system (ADS), global navigational satellite systems GLONASS/GPS (GNSS). Computer in AP-05 – is ARM9 family processor with 400MHz clock frequency and 64 megabytes of RAM. Operation of computer is conducted under  QNX Neutrino real time operating system (RTOS) control. QNX is used under academic licence. Major point is implementation of navigational and control loop under QNX by separate processes: fnav for navigation, fcont for control. Loop frequency is 200 Hz.

Decicions for flight in contest maze is made in autopilot by setting input values for roll, pitch and yaw PID regulators.
Machine vision computer (MVC) is i.MX6Q SABRE lite board with 4 processors of Cortex-A9 archetecture. For the research of QNX technologies machine vision is also computed under QNX.
Connection between AP and MVC is made by Ethernet via native qnet protocol.
For the programmer is gives transparency and flexibility, all interprocess communication is unix-like locally or remotely by qnx messages. Local is conducted by kernel, remote by kernel+qnet.

 

Sensors

As a proximity sensors ultrasonic rangefinders SRF08 are used. They are mounded at bumper each for front, rear, left, right sides accordingly. Same sensor is used for altimetry. Sensors are connected to i.MX6Q SABRE lite (MVC) via I2C interface  to the same bus with different adresses. Doing altitude and wall navigation control loop over such a long way looks weird. All because AP doesn’t have external I2C due to its noise vulnerability. Process which polls range finders reflects data to the system by /dev/fsrf resource manager. Autopilot reads this data over qnet stack like /net/mvc/dev/fsrf file. After reading by navigational process range data is filtered and after reflected as feedback for altitude control and wall avoidance algorithm.

When we were looking for camera main problem was making an software interface for OpenCV in QNX. Making port of webcam USB interface to QNX in a short time seemed impossible, because of lack of knowledge in that field.
Thats why search for camera was narrowed only on IP cameras. Finally Elphel NC353L was found. It has several software interfaces for image: MJPEG over RSTP; HTTP. Camera has opened sources, so it seemed guaranteed way to make own low level protocol and image pre-processing.

Also camera has multiply configurational parameters for optimizing real time picture. Additionally matrix has higher resolution, than other cameras in same price segment.
With understanding that camera is open sourced we estimated our chances to miss appropriate solution as very low and this estimation was correct =).
Calculation of machine vision algorithm is conducted by process called fmv, and its discrete results is represented at /dev/fmv resource manager.

 

Machine vision

Start finish markers search

Searching for start/finish points is done by comparison of current image colour histograms with histograms of reference images. Histograms for B,R,G channels was compated accordingly, and then integral weighted estimation of similarity was calculated. Similarity is calculated separately for start and finish markers.

Stereo vision

For the barrier gate entrance we initially decided to implement stereo vision algorithms to determine its position. At the beginning of contest preparations width between walls on final approach to finish marker supposed to be 20 meters. It seemed challenging to find gate with 3m width. Thats why we decided to integrate Elphel NC353L solution. This version has multiplexor board, which simultaniously gather both sensor data to single image. Stereo camera was generously provided us by Elphel company to participate in contest.

We had previously tested semi-global block matching algorithm (SGBM). Method gives disparity map from two images. Using SGBM method, requiers distortion remap and aligning preprocessing of input images. Using matrices of internal parameters of cameras we performed images rectification, so left image row coincides with rows of right image. Experimentally we tuned scene parameters and looked for optimal diversity map. Diversity map has same dimentions as input images, but consist of 16 bit depth values. Seeing on single row in the middle of image, selected by INS to fit horizon we recoverd distance to near objects and supposed to determine gate.

 

Multicopter UAV Tau frame design

Starting from the design…

For compact setting of all required devices we decided to make central frame with 3 levels. Each level is milled carbon fiber plate.     Level plates are fitted together by aluminium spacers. Between first and second levels there are carbon beams that are tighten between aluminium clamps. At the end of each beam motor is mounted using aluminium brackets. Motors are working with 12″ x 4.5 propellers. For the protection of propellers and equipment special bumper was made. 4 parts form closed perimeter. Bumper part has U-like cut and made of carbon 3 layer composite sandwich. Mounding of bumper is made by Г-like bracket, which is fixed at bottom of motor mount. After design process production and assembly started. Fristly carbon fiber plates and beams were baked. Parallely all aluminium parts were milled. On preparated plates we milled them on CNC. Then molds for bumper and brackets were milled.

After all assembly started!
In a five days we fit everything together and made wiring of all devices.
Design of airframe in STEP format is freely avaiable: with all equipment and as plain frame.

     

 

Flight testing 

When everything were done on assembly 10 days before contest begin left. Actually we had flight test platform before, so we started not from scratch in a flight software.

Previous results were got on fiber glass strong frame before. Some explanations are made on russian in following videos:

After contest drone assembly we spend 5 days to make it flight properly: maintain attitude and regulate distance from the walls.

Next five days we spent to test all mission algorithm in a combination with machine vision and real markers. We’ve got some sucessful complete tests, but all system was very unstable. Most of the problems was about flying. A lot of time was eaten by i2c rangers problems: high current of motors and vibration were making contact and ground potential unstable, and it lead to bus stuck. When bus stuck, altimeter is also stucks, what was leading to engines turn off. Many thanks for our designers and all mechanical shop. In dozens of fallings we’ve once broke bumper braket, and one leg.

Algorithm for maze flying is classical, keep right, keep distance from the walls and pray . We do not making turns, UAV maintains yaw, which is set on initial alignment. And it is aligned by rear side toward right direction at start. So it begins to fly backwards, than left, then front. And on a flight back – in reverse.

Fly front means to hold distance from front wall. When wall is far, front ranger is saturated in its maximum value, so regulator moves drone forward, by tilting its pitch front.

 

Contest video

In a real contest (sizes were officially corrected) distance between final approach walls became 5 meters, so finding gate was not a such big problem anymore. So barier detection was made in autopilot by finite state machine. If front stereo camera (by one of its eye) have seen ellipse in front of it, that means we have passed the gate and must see marker soon by looking down camers. If no, we probably holding right now distance from the barrier wall and must move left.

First attempt 

It was failed because of improper finite state machine criterion for barrier avoidance. Drone thought that it has reached barier and next cycle it thought it has reached front wall at marker, didn’t find any markers and turned back.

 

Second attempt

Here we have our machine vision algorithm failed. Camera didn’t recognized landing marker, so drone tryed to find on the way back and it was dead end of algorithm.
As always there were just a question of two days of debugging to make everything right

 

Conclusion

We have not completely succeeded, but we have not failed.
Our team dramatically improved existed software and developed new direction – machine vision.
That was great teamwork experience, that charged our team to handle further challenges.

← Older revision Revision as of 23:51, 16 October 2013 (6 intermediate revisions not shown)Line 51: Line 51:   <font size='2'>./makeuboot</font>   <font size='2'>./makeuboot</font> -<font color="red">'''IMPORTANT:''' Only '''192KB''' of zynq's series on-chip memory are available at boot. It is the maximal size of '''u-boot.bin''' (not the final '''boot.bin''')</font>+<font color='red'>'''IMPORTANT:''' Only '''192KB''' of zynq's series on-chip memory are available at boot. It is the maximal size of '''u-boot.bin''' (not the final '''boot.bin''') - the python script will throw just a warning.</font> ==Known issues== ==Known issues== -* USB does not work yet.+* <font color='green'>[FIXED]</font> (in Linux) USB does not work yet. -* Ethernet is not tested (on the board we have it does not work with provided images, so we suspect a hardware problem.+* <font color='green'>[FIXED]</font> (in Linux) Ethernet is not tested (on the board we have it does not work with provided images, so we suspect a hardware problem. If no network:  +<font size='2'>  + ifconfig eth0 down  + ifconfig eth0 up  +</font> * Bitstream loading is not tested, current code does not enable level shifters - it may be more appropriate to do just before loading of the bitstream. * Bitstream loading is not tested, current code does not enable level shifters - it may be more appropriate to do just before loading of the bitstream. Oleg

Develop (add boards support):

← Older revision Revision as of 01:00, 15 October 2013 (3 intermediate revisions not shown)Line 51: Line 51:   <font size='2'>./makeuboot</font>   <font size='2'>./makeuboot</font> -<font color="red">'''IMPORTANT:''' Only '''192KB''' of zynq's series on-chip memory are available at boot. It is the maximal size of '''u-boot.bin''' (not the final '''boot.bin''')</font>+<font color='red'>'''IMPORTANT:''' Only '''192KB''' of zynq's series on-chip memory are available at boot. It is the maximal size of '''u-boot.bin''' (not the final '''boot.bin''') - the python script will throw just a warning.</font> ==Known issues== ==Known issues== -* USB does not work yet.+* <font color='orange'>[works with u-boot-xlnx 'master'-branch]</font> USB does not work yet. -* Ethernet is not tested (on the board we have it does not work with provided images, so we suspect a hardware problem.+* <font color='green'>[FIXED]</font> Ethernet is not tested (on the board we have it does not work with provided images, so we suspect a hardware problem. * Bitstream loading is not tested, current code does not enable level shifters - it may be more appropriate to do just before loading of the bitstream. * Bitstream loading is not tested, current code does not enable level shifters - it may be more appropriate to do just before loading of the bitstream. Oleg

← Older revision Revision as of 19:00, 11 October 2013 (One intermediate revision not shown)Line 51: Line 51:   <font size='2'>./makeuboot</font>   <font size='2'>./makeuboot</font> -<font color="red">'''IMPORTANT:''' Only '''192KB''' of zynq's series on-chip memory are available at boot. It is the maximal size of '''u-boot.bin''' (not the final '''boot.bin''')</font>+<font color='red'>'''IMPORTANT:''' Only '''192KB''' of zynq's series on-chip memory are available at boot. It is the maximal size of '''u-boot.bin''' (not the final '''boot.bin''') - the python script will throw a warning.</font> ==Known issues== ==Known issues== * USB does not work yet. * USB does not work yet. -* Ethernet is not tested (on the board we have it does not work with provided images, so we suspect a hardware problem.  * Bitstream loading is not tested, current code does not enable level shifters - it may be more appropriate to do just before loading of the bitstream. * Bitstream loading is not tested, current code does not enable level shifters - it may be more appropriate to do just before loading of the bitstream. Oleg

← Older revision Revision as of 17:50, 10 October 2013 Line 51: Line 51:   <font size='2'>./makeuboot</font>   <font size='2'>./makeuboot</font> -<font color="red">'''IMPORTANT:''' Only '''192KB''' of zynq's series on-chip memory are available at boot. It is the maximal size of '''u-boot.bin''' (not the final '''boot.bin''')</font>+<font>'''IMPORTANT:''' Only '''192KB''' of zynq's series on-chip memory are available at boot. It is the maximal size of '''u-boot.bin''' (not the final '''boot.bin''') - the python script will throw an error.</font> ==Known issues== ==Known issues== Oleg

New user account

Richardski

0353-23-10 - SFE insert holder:

← Older revision Revision as of 01:39, 5 October 2013 Line 21: Line 21: ---- ---- -=== 0353-23-10 - SFE insert holder  ===+=== 0353-23-10 - SFE insert holder, Revision "0" === {{Cad4|0353-23-10}} {{Cad4|0353-23-10}} ---- ----  +=== 0353-23-10A - SFE insert holder, Revision "A"  ===  +{{Cad4|0353-23-10A}}  +  +---- === 0353-23-11 - SFE insert assembly plate  === === 0353-23-11 - SFE insert assembly plate  === Andrey.filippov

0353-19-651 - Sensor ring:

← Older revision Revision as of 01:37, 5 October 2013 (One intermediate revision not shown)Line 320: Line 320: ---- ---- -=== 0353-19-651 - Sensor ring ===+=== 0353-19-65E - SFE Plate, revision "E" ===  +{{Cad4|0353-19-65E}}  +   +----  +   +=== 0353-19-651 - Sensor ring, Revision "0" === {{Cad4|0353-19-651}} {{Cad4|0353-19-651}}  +  +----  +  +=== 0353-19-651A - Sensor ring, Revision "A" ===  +{{Cad4|0353-19-651A}} ---- ---- Andrey.filippov