Bureaucrats, dave_user, Administrators
8,226
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=This process requires a lot of hardware resources in terms of disk storage, RAM, and processing power. For this reason, it also is recommended to consider the use of a physical machine. For more details on this topic, please refer to the specific documentation of your kit related to the advanced use of Yocto build system.
}}
{{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:
<pre>
ERROR: Fetcher failure: Fetch command failed with exit code 4, output:
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.28992
ERROR: Task 632 (/home/dvdk/sources/meta-openembedded/
meta-networking/recipes-support/fetchmail/fetchmail_
6.3.26.bb, do_fetch) failed with exit code '1'
</pre>
}}
As known, Linux needs a root file system to operate: a root file system must contain everything needed to support the Linux system (applications, settings, data, etc.). The root file system is the file system that is contained on the same partition on which the root directory is located. The Linux kernel, at the end of its startup stage, mounts the root file system on the configured root device and finally launches the <code>/sbin/init</code>, the first user space process and "father" of all the other processes.
MVM includes one (or more) pre-built images. They are located here: <code>/home/dvdk/<target_name>/rfs/<kit_name></code>. Kit specific documentation describes how to build such images.
===Generating the SDK associated with a specific root file system image===For each supported target root file system image, there is an associated SDKcan be generated. The pre-built SDKs included in the MVM are located here: <code>/home/dvdk/<target_name>/sdk</code>. The specific documentation of your kit indicates how to generate the SDKsusing the Yocto build system as well.
===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]]