OpenEmbedded/Yocto support for the UDOO Boards In the following description I do use Yocto as reference but the same concepts should apply to the pure OpenEmbedded layers. The provided meta-udoo layer depends on the Freescale arm layer For an easy start I do provide a patched version of fsl-community-bsp-platform this repo manifests is for cloning all needed layers. The Yocto project organizes its releases in different branches. Each branch is related to a Release version. The ongoing development takes place in the master branch. It is recommended that every layer which stacks on top of this should follow this convention. Thus I decided to provide support for the latest release of Yocto "jethro" Recommendation for the build host The OpenEmbedded buildsystem builds everything from source. So it is recommended to have at least 50GB of free disk space. Better is 100GB. The recommended Distribution to build on is the latest Ubuntu LTS Release for jethro this is Ubuntu 14.04. When it comes to CPU power of the buildhost more is always better. I do my builds on a quadcore intel i5 with 3.2GHz. The less CPU cores the more time it will last. My experience is when it comes to RAM you should not go below 8GB. For faster builds a SSD is recommended but this may stresses your SSD. Build the BSP You`ll find the complete build instructions on the meta-udoo github wiki page Burning the image to the SD-Card Please double check the device of your SD-Card. This can corrupt your installation I do the following on my Linux box $ umount /dev/sdd? $ zcat tmp/deploy/images/udooneo/udoo-image-full-cmdline-udooneo.sdcard.gz | sudo dd of=/dev/sdd bs=16M Qt5 If you are interested in Qt5 support for your image it is recommended to read Qt for Embedded Linux first. I have tested Qt5 support on both the Neo and the Quad/Dual family without X11 and EGLFS support. This tutorial is based on the Qt5 on wandboard tutorial Clone the meta-qt5 layer into your source dir $ cd ${BSPDIR}/sources/ $ git clone -b jethro https://github.com/meta-qt5/meta-qt5.git Prepare your build environment $ source ./setup-environment build Add the Qt5 Layer to your con/bblayers.conf file [...] ${BSPDIR}/sources/meta-qt5 \ ${BSPDIR}/sources/meta-openembedded/meta-ruby \ [...] Modify the conf/local.conf for EGLFS accelerated Framebuffer only [...] DISTRO_FEATURES_remove = "x11 wayland" [...] Build the Qt5 image $ MACHINE=udooneo bitbake udoo-image-full-cmdline Cross compile a Qt5 SDK to use in QtCreator The recommended way to build a fully featured toolchain for your image is to use the populate_sdk target for building a toolchain installer $ MACHINE=udooneo bitbake udoo-image-qt5 -c populate_sdk Grab a good book and wait until the task is finished.... After the builds has finished you can install the toolchain like this: $ sudo tmp/deploy/sdk/poky-glibc-x86_64-udoo-image-qt5-cortexa9hf-vfp-neon-toolchain-2.0.sh [sudo] password for chris: Poky (Yocto Project Reference Distro) SDK installer version 2.0 =============================================================== Enter target directory for SDK (default: /opt/poky/2.0): You are about to install the SDK to "/opt/poky/2.0". Proceed[Y/n]? Extracting SDK....................................................................................................................................................done Setting it up...done SDK has been successfully set up and is ready to be used. Each time you wish to use the SDK in a new shell session, you need to source the environment setup script e.g. $ . /opt/poky/2.0/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi QtCreator set-up Run qtcreator from the terminal after running the setup environment script $ source /opt/poky/2.0/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi $ qtcreator In the QtCreator go to Tools > Options > Devices and add your UDOOBoard as a generic linux device. go to Tools > Options > Build & Run Add a new compiler. Select your poky compiler: /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ Add your new cross compiled Qt version by selecting the qmake located in /opt/poky/2.0/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/ Add a new kit selecting your new Qt5 version and compiler and setting the sysroot to /opt/poky/2.0/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi/ and leave the Qt mkspec empty. Finally select your UDOOBoaard for the device. !!! ATTENTION !!! To have a fully working UDOO board you have to use udoo-image-full-cmdline instead of core-image-full-commandline. Because core-image-full-commandline lacks packagegroup-base which uses MACHINE_EXTRA_RRECOMMENDS I know this is a bit disapointing because the name core-image-full-commandline implies it is fully bloated command line image. To get more details on this I suggest to read the Yocto Reference Manual
[UDOO Neo] Uploading Arduino Sketches Please read this Posting how to upload Arduino Sketches to the Cortex M4 on the UDOO Neo Board when running a Yocto Image. WiFi on UDOO Neo/Quad/Dual Ensure your image support Wifi and all drivers are loaded Code: root@udooqdl:~# ifconfig wlan0 up root@udooqdl:~# iw wlan0 scan [...] TSF: 2455654730245 usec (28d, 10:07:34) freq: 2452 beacon interval: 100 TUs capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431) signal: -41.00 dBm last seen: 160 ms ago Information elements from Probe Response frame: SSID: TOP-SECRET Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 9 Country: DE Environment: Indoor/Outdoor Channels [1 - 13] @ 20 dBm ERP: <no flags> RSN: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: CCMP * Authentication suites: PSK * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000) Extended supported rates: 24.0 36.0 48.0 54.0 HT capabilities: Capabilities: 0x18e HT20/HT40 SM Power Save disabled TX STBC RX STBC 1-stream Max AMSDU length: 3839 bytes No DSSS/CCK HT40 Maximum RX AMPDU length 65535 bytes (exponent: 0x003) Minimum RX AMPDU time spacing: 8 usec (0x06) HT RX MCS rate indexes supported: 0-15 HT TX MCS rate indexes are undefined HT operation: * primary channel: 9 * secondary channel offset: below * STA channel width: any * RIFS: 0 * HT protection: non-HT mixed * non-GF present: 0 * OBSS non-GF present: 1 * dual beacon: 0 * dual CTS protection: 0 * STBC beacon: 0 * L-SIG TXOP Prot: 0 * PCO active: 0 * PCO phase: 0 WPA: * Version: 1 * Group cipher: TKIP * Pairwise ciphers: TKIP * Authentication suites: PSK WMM: * Parameter version 1 * BE: CW 15-1023, AIFSN 3 * BK: CW 15-1023, AIFSN 7 * VI: CW 7-15, AIFSN 2, TXOP 3008 usec * VO: CW 3-7, AIFSN 2, TXOP 1504 usec [...] Okay lets assume we want to connect to the network TOP-SECRET we have to change two files Code: root@udooqdl:~# vi /etc/network/interfaces Change the WLAN block to this: Code: # Wireless interfaces iface wlan0 inet dhcp wireless_mode managed wireless_essid any wpa-driver nl80211 wpa-conf /etc/wpa_supplicant.conf The important part is the line Code: wpa-driver nl80211 After this we have to change the wpa_supplicant config Code: root@udooqdl:~# vi /etc/wpa_supplicant.conf To something like this Code: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 update_config=1 network={ ssid="TOP-SECRET" scan_ssid=1 proto=WPA key_mgmt=WPA-PSK pairwise=TKIP group=TKIP psk="<Insert your top secret key here>" } For more details about wpa_supplicant.conf please check for example the wpa_supplicant manpage Now we can test if everything works fine: Code: root@udooqdl:~# ifdown wlan0 [ 2156.644323] wlan0: deauthenticating from 9c:c7:a6:16:XX:XX by local choice (reason=3) [ 2156.709390] cfg80211: Calling CRDA for country: DE root@udooqdl:~# ifup wlan0 Successfully initialized wpa_supplicant rfkill: Cannot open RFKILL control device [ 2165.144654] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready udhcpc (v1.23.2) started Sending discover... [ 2166.697130] wlan0: authenticate with 9c:c7:a6:16:XX:XX [ 2166.792515] wlan0: send auth to 9c:c7:a6:16:XX:XX (try 1/3) [ 2166.800814] wlan0: authenticated [ 2166.804607] rt2800usb 1-1.3:1.0 wlan0: disabling HT/VHT due to WEP/TKIP use [ 2166.813078] wlan0: associate with 9c:c7:a6:16:XX:XX (try 1/3) [ 2166.826939] wlan0: RX AssocResp from 9c:c7:a6:16:XX:XX (capab=0x431 status=0 aid=1) [ 2166.848286] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 2166.854771] wlan0: associated Sending discover... Sending select for 192.168.23.159... Lease of 192.168.23.159 obtained, lease time 864000 RTNETLINK answers: File exists /etc/udhcpc.d/50default: Adding DNS 192.168.23.1
Great! If you provide us a working image we'll send you a Quad too, so you can work also on the Quad. If you like, obviously
Cool, so I can send a working image for Neo. The quad will follow when I have the board . BTW the quad is what I am used to. Because at ifm we use it for our O3D300 industrial 3D camera. Gesendet von meinem Nexus 4 mit Tapatalk
Here we go.... Yocto image for UDOO NEO - 20151109191206 The image is zipped and it is a full SD-CARD image. So it should be possible to use a approach like you describe in your getting started tutorial. On Ubuntu I put it on SD-Card this way: ATTENION please check the path of your SD-CARD Writer first!!! Otherwise you may damage your harddrive.... umount /dev/sde? && zcat core-image-full-cmdline-udooneo-20151109191206.rootfs.sdcard.gz | sudo dd of=/dev/sde bs=32M After inserting the SD-CARD into your NEO you can either connect a 3.3V USB <-> serial converter to your NEO board or use the USB-Serial port ( /dev/ttyACM0 ) spawned by the UDOO Neo. I've written a complete Howto on on my Blog some time ago. On the login prompt just type root for the username and no password. For the Bluetooth part you have to call the following command: Code: root@udooneo:~# hciconfig hci0 up root@udooneo:~# hciconfig hci0: Type: BR/EDR Bus: UART BD Address: 74:DA:EA:C7:19:B4 ACL MTU: 1021:6 SCO MTU: 180:4 UP RUNNING RX bytes:1176 acl:0 sco:0 events:62 errors:0 TX bytes:804 acl:0 sco:0 commands:62 errors:0 If you want to scan for Bluetooth Low Energy devices for example you can do this like this: Code: root@udooneo:~# hcitool lescan LE Scan ... 68:C9:0B:06:EF:CC (unknown) 68:C9:0B:06:EF:CC CC2650 SensorTag A4:77:33:A6:FF:D5(unknown) A4:77:33:A6:4D:D1 (unknown) 68:C9:0B:06:EF:CC (unknown) 68:C9:0B:06:EF:CC CC2650 SensorTag Code: root@udooneo:~# hcitool leinfo 68:C9:0B:06:EF:CC Requesting information ... Handle: 1025 (0x0401) LMP Version: 4.1 (0x7) LMP Subversion: 0x200 Manufacturer: Texas Instruments Inc. (13) Features: 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 For the WiFi part I tried a simple scan Code: root@udooneo:~# ifconfig wlan0 up root@udooneo:~# iw wlan0 scan BSS 5c:49:79:21:31:75(on wlan0) TSF: 2075562266 usec (0d, 00:34:35) freq: 2412 beacon interval: 100 TUs capability: ESS Privacy ShortPreamble ShortSlotTime (0x0431) signal: -67.00 dBm last seen: 410 ms ago SSID: XXXX Supported rates: 1.0* 2.0* 5.5* 11.0* 6.0 9.0 12.0 18.0 DS Parameter set: channel 1 Country: DE Environment: Indoor/Outdoor Channels [1 - 13] @ 20 dBm ERP: <no flags> Extended supported rates: 24.0 36.0 48.0 54.0
I am facing some trouble with the out of tree kernel builds Yocto is doing. So my announcement having something GUI based by the end of this week is not possible. At the moment it looks like the backported drivers cause the Kbuild system to an endless loop when running building out of tree. For my console based build I mad a hack and build the kernel in tree. But Yocto builds the Vivante Driver from a separate repo. And this is broken. Maybe I can skip the seperate build of Vivante Driver or I can fix the endless loop. If there is kconfig superhero around please give me some hints. Gesendet von meinem Nexus 4 mit Tapatalk
I did some investigations and have an idea about how to fix the endless loop. But meanwhile I found a hack to use the vivante driver included in the UDOO Neo kernel sources. This is okay for now but maybe an issue when Yocto uses a newer or older version of the vivante userland. Anyway here is a youtube video where you can see UDOO Neo booting into the graphical Sato image based on a yocto master from end of November. If you want to test the image yourself you can download it here
Hi graugans, which kernel are you using? If you use this you will get Neo and Quad/Dual support out of the box. If you want to use u-boot 2015 (that we will use in the next UDOObuntu releases): - 2015.10+fslc is u-boot for Quad/Dual and has SPL support - 2015.10+fslc_NEO has Neo support and SPL support This may help you on building SPL u-boot and flash it in the right places on the sdcard.
Thank you Francesco, yesterday in the evening I managed to run the 2015.10+fslc on the UDOO Quad/Dual. It is really cool to swap one SD-Card between both boards and it is booting smoothly. For the kernel I have to switch to master soon. At the moment I am using the two branches one for the Neo and the other one for the Quad/Dual. My suggestion for the naming of the Quad/dual board in Yocto is udooqdl Or are there any other suggestions? The name of the UDOO Neo is pretty simple udooneo After cleaning stuff up and getting SPL support for the Neo up and running I have to figure out how to support that splash screen stuff.
The name "udooqdl" is acceptable as it is an internal name. A user visible name should otherwise always be "UDOO Quad/Dual". What do you refer to with "splash screen"? You mean u-boot splash screen? In that case please note that: - on UDOO Quad/Dual it is already in the 2015.10 branch (as you already noticed) - on UDOO Neo it is missing (HDMI init code for u-boot is on master only and not in 2015.04; LVDS support should be checked too).
Hi graugans ! Congratulation for your job ! Do you plan to make a yocto image with qt5 layer ? Otherwise, do you plan to make a tutorial to buid a yocto image (git repository with udoo layers) ?
Hi @modjo , sorry for the late reply. I alread wrote a response but this was eaten by taptalk .... Anyway, I plan to write some tutorial. but had not found time to do so . The qt5 thingy should be pretty straight forward with meta-qt5 In case of any questions pleas do not hesitate to ask.
Hi graugans, i'm very insterested by your work ! Currently i'm building a yocto image with qt5.3 for my seco A62 (seco give a guideline to do that). if i understand, your layer work on udoo quad and neo with the same build ? On neo, do you have the accelerometer, gyro ... working ? I suppose you have the A9 gpio working (by linux) but for the commnucation with the M4 copro, do you have the time to test that ? If you would, i can test to build an image with your layer and let you know if it's working ? Just said me the bbconf (machine) you use and if the have some particulars instructions ...
The new layer https://github.com/graugans/meta-udoo have two machine configurations one udooqdl for quad and dual version of the UDOO Board and the udooneo configuration. By selecting udooqdl you can build an image which runs on quad and dual. But this image is not compatible with the UDOO Neo. I'll write some documentation about setup and tuning the layers. Gesendet von meinem Nexus 4 mit Tapatalk
I've updated to top-level post which now addresses the new meta-udoo layer. This is not yet finished yet and needs some polishing but could be a starter...
Hi graugans, i have init my repo, download the bsp and setup the environement. Now i'm on your step "Fixing layers". You said to modify build/conf/local.conf. Do it need to erase the original file and replace it by the line you gives or append it ? I try with the second option and obtain this errors : Code: osboxes@osboxes:~/udoo-community-bsp/build$ MACHINE=udooneo bitbake udoo-image-full-cmdline ERROR: Unable to parse /home/osboxes/udoo-community-bsp/sources/poky/bitbake/lib/bb/parse/parse_py/ConfHandler.py Traceback (most recent call last): File "/home/osboxes/udoo-community-bsp/sources/poky/bitbake/lib/bb/parse/parse_py/ConfHandler.py", line 188, in feeder(lineno=24, s='--- fsl-udoo-community-bsp.orig/build/conf/bblayers.conf', fn='/home/osboxes/udoo-community-bsp/build/conf/local.conf', statements=[<bb.parse.ast.DataNode object at 0x1312ad0>, <bb.parse.ast.DataNode object at 0x1312b10>, <bb.parse.ast.DataNode object at 0x1312b50>, <bb.parse.ast.DataNode object at 0x1312bd0>, <bb.parse.ast.DataNode object at 0x1312c50>, <bb.parse.ast.DataNode object at 0x1312c90>, <bb.parse.ast.DataNode object at 0x1312cd0>, <bb.parse.ast.DataNode object at 0x1312d10>, <bb.parse.ast.DataNode object at 0x1312d50>, <bb.parse.ast.DataNode object at 0x1312d90>, <bb.parse.ast.DataNode object at 0x1312dd0>, <bb.parse.ast.DataNode object at 0x1312e50>, <bb.parse.ast.DataNode object at 0x1312e90>]): > raise ParseError("unparsed line: '%s'" % s, fn, lineno); ParseError: ParseError at /home/osboxes/udoo-community-bsp/build/conf/local.conf:24: unparsed line: '--- fsl-udoo-community-bsp.orig/build/conf/bblayers.conf' Could you help please ?
Sorry this is a typo in my tutorial. For the layers it is conf/bblayers.conf I'll fix it when I have access to a PC. Gesendet von meinem Nexus 4 mit Tapatalk
