Yocto tests
Yocto tests
Add a patch to a recipe:
Show changes OlegYocto tests
Yocto tests
Yocto tests
Add a patch to a recipe:
Show changes OlegYocto tests
Ezynq
Yocto tests
Yocto tests
Yocto tests
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> OlegYocto tests
Yocto tests
Yocto tests
Yocto tests
Elphel next camera – sample configuration
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.
10359
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.filippovEzynq
Yocto tests
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
Ezynq
NC393 development progress – testing the hardware
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.
Pages
