Bureaucrats, dave_user, Administrators
8,254
edits
Changes
→bootscript
** Retrieve binary images (i.e. Linux kernel) via TFTP protocol
** Mount the development root file system via NFS protocol. This root file system is physically in the file system of the host machine as depicted [[Deploying_Embedded_Linux_Systems#The_development_environment|here]].
* deployment: the goal of this stage is to configure the target for normal operation, that is out of the development environment. A target root file system - optimized system–optimized in terms of memory footprint - is footprint–is used. This root file system is stored on onto the target's non-volatile memory.
To implement this workflow, the MVM provides
#Building a user application against a specific SDK.
The overall development flow of a user application is depicted in the following image. For example, the last step shown in the diagram is performed by the second the build process #2 of the previous list.
[[File:Yocto_development_flow.png|thumb|center|Typical Yocto-based development flow]]
}}
{{ImportantMessage|text=The process described in this section makes use of tons of source files retrieved from many different online repositories. '''Any issue preventing Yocto to access these repositories–whose URLs are statically specified in the recipe files–may stop the build process'''.
For instance, from time to time these URLs change over the time. Consequently, the build process can't complete successfully because the URL included in the recipes don't match the actual address anymore.
Another problem that may interrupt the procedure is a temporary interruption of the Internet connection. The following example shows an error message reported by Yocto in such a case:
wget: unable to resolve host address 'download.berlios.de'
ERROR: Function failed: Fetcher failure for URL: 'http://download.berlios.de/fetchmail/fetchmail-6.3.26.tar.xz'. Unable to fetch URL from any source.ERROR: Logfile of failure stored in: /home/dvdk/build-fb/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/fetchmail/6.3.26-r0/temp/log.do_fetch.28992ERROR: Task 632 (/home/dvdk/sources/meta-openembedded/meta-networking/recipes-support/fetchmail/fetchmail_6fetchmail_6.3.26.bb, do_fetch) failed with exit code '1'</pre>
}}
===Building user applications against a specific SDK===
About C/C++ application development and debugging, please refer to [[Debugging_with_Eclipse_(MVM)|this page]].
===Misc===
The MVM may include additional files used for other useful purposes. The following sections detail the usage of such files.
====bootscript====
U-Boot provides flexible mechanisms to support different forms of scripting. One of the most used to automate complex actions at start-up is based on the use of script images.
Most of DAVE Embedded Systems' Linux kits provide a ready-to-use microSD card that allows the target to boot in standalone mode. This means that all the required images (U-Boot, Linux kernel, device tree blob, etc.) for a complete boot are stored in the card itself.
This card makes use of a script image to do this. This image is usually a file named <code>boot.scr</code>. U-Boot provided along with DAVE Embedded Systems' Linux kits implements several customizations. One of these is tailored default environment. This environment is defined to execute <code>boot.scr</code> script image on start-up.
[[File: Bootscript_execution.png | 400px]]
This script image is in turn generated from a source file that is stored in the <code>/home/dvdk/<target></code> directory of the MVM and that is named <code>bootscript.txt</code>. For instance, [[Axel_Embedded_Linux_Kit_(XELK)#Binary_images_on_SD_card|this section]] shows how the script image is generated for the XELK kit.
For more details, please refer to the following links:
*https://www.denx.de/wiki/view/DULG/UBootScripts
*https://www.denx.de/wiki/view/DULG/UBootCmdGroupExec
===Related links===
*[[Yocto build system FAQs]]