dave_user, Administrators
5,138
edits
Changes
→Related documents and additional resources
{{Applies To Bora}}
{{Applies To BoraX}}
{{AppliesToBORA_AN}}
{{AppliesToBORA_Xpress_AN}}
{{InfoBoxBottom}}
{{WarningMessage|text=This application note was validated against specific versions of the kit only. It may not work with other versions. Supported versions are listed in the ''History'' section.}}
== History ==
Updated for BELK 2.0.0 release
|-
|12.70.0
|September 2015
|[[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|3.0.0]]
|Migration to BELK 3.0.0<br>Added support for BoraX
|-
|}
== Introduction ==
This application note describes how to build the software components required to set up asymmetric multi-processing (AMP for short) configuration required to run Linux OS on the first Cortex-A9 core (also denoted as core #0) and FreeRTOS on the second Cortex-A9 core (also denoted as core #1) of the Zynq SOC.
Asymmetric Multiprocessing (AMP) allows a multiprocessor/multicore system to run multiple Operating Systems (OS) that are independent of each other. In other words, each CPU has its own private memory space, which contains the OS and the applications that are to run on that CPU. In addition, there can be some shared memory space that is used for multiprocessor communication. This is contrasted with Symmetric Multiprocessing (SMP), in which one OS runs on multiple CPUs using a public shared memory space. Thanks to AMP, developers can use open-source Linux and FreeRTOS operating systems and the RPMsg Inter Processor Communication (IPC) framework between the Zynq's two high-performance ARM® Cortex™-A9 processors to quickly implement applications that need to deliver deterministic, real-time responsiveness for markets such as automotive, industrial and others with similar requirements. For further information, please refer to this [http://www.wiki.xilinx.com/Multi-OS+Support+%28AMP+%26+Hypervisor%29 link].
Two different examples are here provided. The first one – HelloWorld – shows basic functionalities while the second – RPMsg-based application – exploits more sophisticated techniques to handle inter-processors communication and synchronization. This latter configuration is based on RPMsg mechanism as described in Xilinx document UG978 (v2013.04, April 22, 2013).
A notable application where AMP configuration has been leveraged is described [[BRX-WP002:_Non-intrusive_continuous_multi-gigabit_transceivers_link_monitoring|here]]. PDF version of this Application Note can be downloaded [httphttps://www.dave.eu/siteslinks/defaultp/files/files/an-belk-001-amp-linux-freertos.pdf j1KrvnU3fd8PeCvX here].
==AMP on Bora==
* Vivado® Design Suite version 2013.3 with Xilinx SDK (Webpack license is minimum requirements)
* Python 2.7.x (C:\Python27 must be the installation directory on Windows)
* TBD [[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|Bora Embedded Linux Kit version 2.0.0]] (BELK for short). Please refer to BELK Quick Start Guide for further details) version 2.0.0]].* BORA FreeRTOS repository (please refer to section TBD[[#Importing the FreeRTOS repository into the SDK]]).
===Building the software components===
====Vivado project====
export PROJ_DIR=$(pwd)/../bora-build-YYYYMMDD-nobk
</pre>
Configure Vivado settings (1){{efn|In a 32 bit system, Vivado settings are configured with the following command <code>/opt/Xilinx/Vivado/2013.3/settings32.sh</code>.}}:
<pre>
. /opt/Xilinx/Vivado/2013.3/settings64.sh
</pre>
Launch Vivado with <code>build_project</code> script (2){{efn|Passing the <code>-tclargs "-bitstream"</code> parameters allows for automatic building of the FPGA bitstream.}}:
<pre>
vivado -mode tcl -source build_project.tcl -notrace -tclargs "-bitstream"
</pre>
====FSBL====
Once the Vivado project build is completed, the hardware configuration can be exported starting the SDK to build the FSBL. From the SDK GUI:
* JP17.4 – UART0_TX
* JP17.6 – UART0_RX
Please follow the steps listed below to build a HelloWorld application that prints a message on UART0 (via EMIO) on FreeRTOS running on Bora core #21.
* From the SDK GUI, create e new application project:
[[File:AN-BELK-001_01.jpg|600px|thumb|center]]
Once the build process is completed, the executable file in .elf format will be generated (we suggest to name it freertos). Creating the .bin file is <u>not required</u>.
* Project name: <code>RPMsg_freeRTOS</code>* Hardware Platform: <code>hw_platform_0</code>* Processor: <code>ps7_cortexa9_1</code>* OS Plaftorm: <code>freertos_zynq</code>* Language: <code>C</code>* Board Support Package: <code>Create New</code>* Type: <code>FreeRTOS Latency AMP</code>To run this example, Linux kernel (1) {{efn|The kernel branch must be <code>bora</code>.}} must be rebuilt too {{efn|It is assumed that the development environment is already set up as described [[Build_system_(2BELK)|here]].}}. First of all copy the freertos executable file in .elf format (<code>freertos</code>) into the directory firmware of Linux kernel tree (3){{efn|The name of the binary file copied into the firmware directory must be <code>freertos</code>.}}. Then configure the kernel using <code>bora_amp_defconfig</code> as configuration file and enter the following command line, that changes the default load address of kernel and launches the building of both the kernel image and the modules:
<pre>
bash# make UIMAGE_LOADADDR=0x10008000 uImage modules
For further details on kernel modules, please refer to this [http://tldp.org/HOWTO/Module-HOWTO/ link].
===Linux Device Tree===
The Flattened Device Tree (FDT) is a data structure for describing the hardware in a system (for further information, please refer to http://elinux.org/Device_Tree). Both Example #1 and Example #2 requires some modifications to the standard Bora device tree (to initialiaze UART0 port and to properly initialize the RPMsg infrastructure, respectively). Please use the kernel branch <code>bora</code>, that already includes the aforementioned patches (for further details, please refer to the <code>arch/arm/boot/dts/bora.dts</code> file and commit descriptions on the Linux git repository). For detailed instructions on how to build the Linux kernel and the Device Tree, please refer to the [[Bora_Embedded_Linux_Kit_(BELK)#BELK_software_components|BELK Quick Start Guide TBD]].
===Running the demo applications===
====Example #1: HelloWorld application====
This section describes how to run freeRTOS HelloWorld example application on BORA using AMP (Linux + FreeRTOS). Plese follow the steps listed below:
* Place all the binary files into the host tftp directory:
** Kernel {{efn|The kernel must be built with the <code>UIMAGE_LOADADDR 0x8000</code> option. Please refer to [[Building_Linux_kernel_(1BELK)|this page]] for more details.}}: <code>uImage</code>** Device Tree: <code>bora.dtb</code>** First stage bootloader: <code>bora_FSBL.bin</code>** FPGA bitstream: <code>bora_design_wrapper.bin</code>** FreeRTOS application: <code>helloworld_freeRTOS.bin</code>
* Start the Bora system
* From the U-Boot shell, update the FSBL with the following commands:
</pre>
* Reset the board to reboot with the new FSBL
* Add the following U-Boot environment variables (2):
<pre>
setenv addcons 'setenv bootargs ${bootargs} console=${console},115200n8 cma=16M debug maxcpus=${nr_cpus}'
setenv fpga_file BELK/bora_design_wrapper.bin
</pre>
<pre>
run net_nfs
</pre>
====Example #2: RPMsg-based application====
As stated before, this example shows a more sophisticated approach that allows for:
* using a standardized communication channel between the two cores(RPMsg)
* exploiting a standardized mechanism to load the firmware of second core.
This approach determines a different initialization process with respect to example #1. In this case the initialization sequence is:
#linux kernel boots, enabling and using both cores
#RPMsg and virtio drivers (compiled as modules) are loaded
#core #1 is released
#FreeRTOS binary image is loaded
#core #1 is started.
In other words, boot process of core #1 is under the control of the Linux o.s. In principle this allows a dynamic use of the core #1 that can be allocated for FreeRTOS application only when it is actually needed.
The example performs IRQ latency measurements on FreeRTOS side by using a hardware timer. These measures are collected by the counterpart application running on Linux side and shown on console. Plese follow the steps listed below:
* Place all the binary files into the host tftp directory:
** KernelLinux kernel: <code>uImage</code>** Device Tree: <code>bora.dtb</code>** First stage bootloader: <code>bora_FSBL.bin</code>** FPGA bitstream: <code>bora_design_wrapper.bin</code>** FreeRTOS application: <code>freertos</code>
* Start the Bora system
* From the U-Boot shell, update the FSBL with the following commands:
</pre>
* Reset the board to reboot with the new FSBL
* Add the following U-Boot environment variables (1) (2please note that, when using the RPMsg mechanism, it's not required to set the <code>maxcpus=${nr_cpus}</code> variable):
<pre>
setenv addcons 'setenv bootargs ${bootargs} console=${console},115200n8 cma=16M debug'
setenv fpga_file BELK/bora_design_wrapper.bin
</pre>
**:this a brief description of these variables***:<code>program_fpga</code>: Loads FPGA binary from TFTP and programs the bitstream ***:<code>load_freertos</code>: Loads freertos application binary from TFTP and writes application start address for core #1* Boot the system running the following command: <code>run net_nfs</code>
When booting, the Linux kernel will print out the following message to indicate it has been relocated to address 0x10000000:
</pre>
Linux kernel will print these messages, informing that the communication between the two cores has been established:
<pre>
[ 17.966158] NET: Registered protocol family 41
[ 18.036698] CPU1: shutdown
[ 18.124417] virtio_rpmsg_bus virtio0: creating channel rpmsg-timer-statistic addr 0x50
[ 18.151586] rpmsg_freertos_statistic rpmsg0: new channel: 0x400 -> 0x50!
</pre>
Then run the <code>latencystat</code> application as shown below. The typical output will look like this:
<pre>
</pre>
==Advanced debugging techniques for AMP Linux+FreeRTOS configuration==
===Introduction===
===Prerequisites===
* LA-3500 Power Debug USB3 or LA-7705 Power Debug Ethernet or LA-7699 PowerDebug II* LA-7843 JTAG Debugger for Cortex-A/-R* LA-7960X License for Multicore Debugging* TRACE32 PowerView for ARM (Release: Feb 2013, Software Version: R.2013.02.000045901)* Optional: LA-7970X Trace License for ARM (Debug Cable)
For a general introduction to debug features provided by TRACE32 tools, please refer to:
===TRACE32 configuration===
In AMP configuration, each core runs a unique code, already fixed at compile time. The CPU interoperates with other processing units, exchanging data through dedicated channels (for example, shared memory buffers or peripheral units). Lauterbach supports these architectures with different TRACE32 instances, each one connected to a single core, in “core view” ''core view'' configuration where debug focus is on single processor.
However, as the cores do not work independently but perform the application task together and in parallel, it is possible to start and stop all the cores simultaneously. This is the only way to test the interaction between the cores and to monitor and control the entire application. Moreover, as each core run a separate part of the application, the majority of the symbol and debug information is assigned exclusively to the corresponding core.
In the following paragraphs, the basic TRACE32 multicore configuration for a single device will be introduced. For more details, please refer to “ICD ''ICD Debugger User's Guide” Guide'' (<code>debugger_user.pdf</code>).
====Multicore configuration====
For the configuration of TRACE32 application, reference scripts are provided from Lauterbach. The first GUI must be started manually and must register itself to share a common JTAG handler with other TRACE32 applications. This is done setting the option <code>CORE= </code> in the configuration file (default file name: <code>config.t32</code>).<pre>
PBI= ; within config file of first core
USB
CORE=1
</pre>
or:
<pre>
PBI= ; within config file of first core
NET
PACKLEN=1024
CORE=1
</pre>
Nevertheless, the setting to define which core is addressed, actually is done later on.
====Multicore synchronization====
To use the start/stop synchronization between different core debuggers, the <code>INTERCOM </code> port settings are necessary. This is done assigning predefined port numbers in the configuration file to each TRACE32 application (option <code>PORT=</code>).<pre>
IC=NETASSIST ; within config file of first core
PORT=20001
IC=NETASSIST ; within config file of second core
PORT=20002
</pre>
===Startup scripts===
In order to use a generic configuration file for each TRACE32 instance, there is the possibility to use just one generic template file for all cores. The particular settings are passed as parameter. This is shown in the reference script:
<pre>
amp_start_core0.bat
</pre>
which refers to the configuration file:
<pre>
amp_config.t32
</pre>
The batch file starts automatically this startup script:
<pre>
amp_demo.cmm
</pre>
After booting the first TRACE32 GUI, the second GUI will be started automatically by the startup script. See the reference script:
<pre>
amp_demo_start_core1.cmm
</pre>
For more details about PRACTICE batch language, please refer to:
====PRACTICE macros for multiple TRACE32====
The startup script, started automatically at the first TRACE32 application, is fully able to configure the whole debug system, providing PRACTICE commands both to the current instance of TRACE32 application, and to the second instance. It’s also possible to deliver the same PRACTICE command to both instances with a single command line. The command redirection is possible using the INTERCOM feature. Typically some PRACTICE macros can be defined for this purpose.
<pre>
&core0="" ;only to improve readability
&core1="intercom localhost:&intercomport_core1"
&core1 ¶m
RETURN
</pre>
In this way, all CPU-specific configuration commands can be performed in the same way for each TRACE32 application, or distinguishing between different configurations. For example:
<pre>
&both SYStem.RESet
</pre>
or:
<pre>
&core0 SYStem.CPU ZYNQ-7000CORE0
&core1 SYStem.CPU ZYNQ-7000CORE1
</pre>
====The SYnch command====
The synchronization between different TRACE32 applications is done by SYnch command group, which allows the following purposes:
* to establish a start/stop synchronization between the cores controlled by different TRACE32 instances;* to allow concurrent assembler single steps between the cores controlled by different TRACE32 instances;* to allow synchronous system mode changes between the cores controlled by different TRACE32 instances.
[[File:AN-BELK-001_10.png|600px|thumb|center]]
The SYnch settings are reported below:
* <code>Connect</code>** Establish a connection to the debugger attached to the defined communication port(s). Several debuggers ports can be specified, separated by space.* <code>MasterGo ON</code>** If the program execution is started, the program execution for all other processors which have SlaveGo ON is also started.* <code>MasterBrk ON</code>** If the program execution is stopped, the program execution for all other debuggers which have SlaveBrk ON is also stopped.* <code>MasterStep ON</code>** If an asm single step is executed, all processors which have SlaveStep ON will also asm single step.* <code>MasterSystemMode ON</code>** Invite other TRACE32 instances to perform system mode changes synchronously. System mode changes are typically performed by the commands SYStem.Mode <mode>* <code>SlaveGo ON</code>** The program execution is started, if a processor with MasterGo ON starts its program execution.* <code>SlaveBrk ON</code>** The program execution is stopped, if a processor with MasterBrk ON stops its program execution.* <code>SlaveStep ON</code>** A asm single step is performed, if a processor with MasterStep On performs an asm single step.* <code>SlaveSystemMode ON</code>** Synchronize with system mode changes in connected TRACE32 instances.
A summary of SYnch configuration is provided with command TargetSystem, which also allows to easily and rapidly modify the SYnch mode options.
Moreover the TargetSystem command provides a general overview of the whole multicore configuration and of the current state.
<pre>
TargetSystem DEFault Title SYnch.All InterComPort /Global
</pre>
There is a time delay between reaction of different cores. The reaction time of the slave core depends on the technical realisation of the synchronization. If no specific configuration is performed, the synchronization is done by software (eg: the master debugger informs the slave debugger via socket communication on the host about specified events). On the other side, if the on-chip Cross Trigger Interface is configured, the synchronization takes place directly on the processor. This is a faster solution and the time delay between reaction of different cores becomes around 0-10ns.
The CTI interface for chip Zynq is configured with the following commands. If CTI is configured, TRACE32 will use the faster solution for the synchronization.
<pre>
&core0 SYStem.CONFIG.CTI.Base 0x80098000
&core0 SYStem.CONFIG.CTI.Config CORTEXV1
&core1 SYStem.CONFIG.CTI.Base 0x80099000
&core1 SYStem.CONFIG.CTI.Config CORTEXV1
</pre>
===Setting up the Linux debug configuration===
The symbolic information is useful for HLL debugging, or setting breakpoints, stepping through the code, viewing variables, and many other aspects of debugging. The compiler must be configured in order to generate debug symbols. The vmlinux file for the running kernel must be available, in order to load the kernel debug symbols.
No instrumentation is needed in the kernel source code for debugging with Lauterbach, but it’s it's important that the vmlinux file is generated from the same kernel build as the zImage or uImage running on the system.The Data.LOAD command is used to load the kernel symbols, and the <code>sYmbol.SourcePATH </code> command can be used, if necessary, to define additional search directories for the source files. The <code>Data.LOAD </code> command for vmlinux is applied to &core0, so that symbol information is not shared with the other TRACE32 application.[[File:AN-BELK-001_12.jpgpng|600px|thumb|center]]
Specific options must be configured to avoid automatic Break of TRACE32 debugger, in case any of the following events happens due to normal Linux operations.
<pre>
TrOnchip.Set UNDEF OFF ; may be used by Linux for FPU detection
TrOnchip.Set DABORT OFF ; used by Linux for page miss!
TrOnchip.Set PABORT OFF ; used by Linux for page miss!
</pre>
In the following paragraphs, the basic TRACE32 Linux configuration will be introduced. For more details, please refer to:
TRACE32 kernel awareness technology makes debugger aware of the OS running in the target system. Debug is significantly simplified, as the user can immediately access all the components of the OS and the application. The Executable and Linkable Format (ELF) binaries, created at kernel build time, are used also by Linux awareness.
The Linux kernel awareness is configured with the commands:
<pre>
; loads Linux awareness
&core0 TASK.CONFIG ~~/demo/arm/kernel/linux/linux-3.x/linux3.t32
; loads Linux menu
&core0 MENU.ReProgram ~~/demo/arm/kernel/linux/linux-3.x/linux.men
</pre>
The Linux kernel awareness is loaded into the first TRACE32 application, and will not affect the second one.
The Linux menu file (<code>linux.men</code>) includes many useful menu items developed for the TRACE32 GUI to ease Linux debugging.
In Linux embedded, the Lauterbach debuggers provide a very tight integration with the RTOS. The kernel awareness supports Linux MMU format and is able to handle virtual memory addressing.
<pre>
MMU.FORMAT LINUX swapper_pg_dir 0xc0000000--0xc1ffffff 0x00000000
TRANSlation.Create 0xc0000000--0xc1ffffff 0x00000000
TRANSlation.TableWalk ON
TRANSlation.ON
</pre>where the virtual address range is the virtual-to-physical kernel address mapping, according with results of command <code>MMU.List KernelPageTable</code>, executed when the kernel is up and running.In the command <code>TRANSlation.COMMON</code>, the virtual address[[File:AN-BELK-001_13.jpg|600px|thumb|center]]range has been extended below the kernel start address, because kernel objects are loaded in this memory range.4[[File:AN-BELK-001_13.5.3 png|600px|thumb|center]] ==== Debugging of kernel modules====
The Linux kernel can be compiled to allow linking of additional modules at runtime (kernel objects). The Lauterbach debuggers also support kernel modules debugging, starting from the initialization function.
[[File:AN-BELK-001_14.jpgpng|600px|thumb|center]]
====Debugging of user processes, threads, shared objects====
User process debugging is also available, starting from the very beginning of the process. If the process loads shared objects, they are loaded in the process address space when the related instructions are executed for the first time (demand paging).
In general, the same techniques used for debugging kernel code, such as setting breakpoints, stepping through code, watching variables, and viewing memory contents, can be performed in the same way for processes and tasks.
Virtual address spaces are distinguished in TRACE32 using the concept of spaceID, which is enabled with the option:
<pre>
SYStem.Option MMUspaces ON
</pre>
The memory addressing is extended using the lower 16 bit of the process PID, allowing in this way to distinguish between equal virtual addresses for different processes.
[[File:AN-BELK-001_15.jpgpng|600px|thumb|center]]===Setting up the FreeRTOS debug configuration===A similar kernel awareness concept as Linux, is provided by Lauterbach for many other RTOS. Among the others, also FreeRTOS is supported with the following awareness configuration.<pre>; load FreeRTOS awareness&core1 TASK.CONFIG ~~/demo/arm/kernel/freertos/freertos.t32; load FreeRTOS menu&core1 MENU.ReProgram~~/demo/arm/kernel/freertos/freertos.men</pre>The FreeRTOS kernel awareness is loaded into the second TRACE32 application, and will not affect the first one.As of symbol information it’s enough to load the proper symbol file, redirecting the <code>Data.LOAD</code> command to <code>&core1</code>. In this way, the second TRACE32 application will have visibility of FreeRTOS HLL debug info.The FreeRTOS menu file (<code>freertos.men</code>) includes useful menu items developed for the TRACE32 GUI to ease FreeRTOS debugging. For more details, please refer to ''RTOS debugger for FreeRTOS'' manual (<code>rtos_freertos.pdf</code>).===Onchip trace===The Zynq chip implements the ETB (Embedded Trace Buffer), a CoreSight hardware component providing on-chip trace functionality. The ETB stores program-flow trace information on-chip at high rates and at 32-bit data width. The data can be read out via JTAG, when the trace recording has ended.This trace method is enabled in TRACE32 with the following commands, respectively performed on each GUIs of AMP configuration:<pre>Trace.METHOD Onchip ; select the ETB as source ; for the trace information</pre>The TRACE32 menu item ''Trace ? Configuration'' allows a full control of configuration, initialization and listing of trace information.The trace, recorded for each core by each AMP TRACE32 GUI, can be synchronized using the XTRACK feature of TRACE32. In this way, an easy comparison is possible of program flow of each core at the same time.The XTRACK feature is enabled with the following commands:<pre>&core0 Synch.XTRACK localhost:&intercomport_core1&core1 Synch.XTRACK localhost:&intercomport_core0</pre>Each trace window will follow the time / record synchronization of other trace windows, if the option <code>/Track</code> is used.The following images show Linux onchip trace XTRACKED vs FreeRTOS onchip trace:[[File:AN-BELK-001_16.png|600px|thumb|center]][[File:AN-BELK-001_17.png|600px|thumb|center]]For further details, please refer to ''Training Real-time Trace'' manual (<code>training_trace.pdf</code>).===Summary view===In the pictures below, all the concepts previously discussed are shown as a summary global view of TRACE32 debugger, respectively for Zynq core 0 running a Linux kernel, and Zynq core 1 running a FreeRTOS based application.[[File:AN-BELK-001_17.png|600px|thumb|center|Linux at Zynq core 0]][[File:AN-BELK-001_18.png|600px|thumb|center|FreeRTOS at Zynq core 1]]===Lauterbach References===This chapter has been written by Lauterbach italian branch office. Contact information: Lauterbach SRL Via Enzo Ferrieri 12 20153 Milan (Italy) Tel. +39 02 45490282 Email info_it@lauterbach.it Web www.lauterbach.it
== Related documents and additional resources ==
|-
|Bora Hardware Manual
|http[https://www.dave.eu/siteslinks/defaultp/files/files/bora-hm.pdf856kxHzE3c5Y5Y05 BORA HM]
|-
|BoraEVB page on DAVE Embedded Systems Developers Wiki
|Xilinx UG978
|http://www.xilinx.com/support/documentation/sw_manuals/petalinux2013_04/ug978-petalinux-zynq-amp.pdf
|-
|Unsupervised AMP
|https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842203/Unsupervised+AMP
|-
|}
==Appendixes==
===U-Boot environment===
The following is the U-Boot environment that can be printed using the print command (please note these are examples and that the actual variables may differ for different U-Boot settings), for both the FreeRTOS applications described in this application note.
====Example #1: HelloWorld application====
<pre>
addcons=setenv bootargs ${bootargs} console=${console},115200n8 cma=16M debug maxcpus=${nr_cpus}
addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gateway}:${netmask}:${hostname}:${ethdev}
addmem=setenv bootargs ${bootargs} mem=1008M
baudrate=115200
bootdelay=3
bootfile=bora/uImage
console=ttyPS0
dt_base=0x005C0000
ethact=Gem.e000b000
ethaddr=00:0a:35:00:01:22
ethdev=eth0
fdt_high=0x1F000000
fileaddr=0
filesize=2f0ed0
fpga_base=0x00180000
fpga_file=belk/free_rtos/bora_design_wrapper.bin
freertos_addr=0x3F000000
freertos_file=bora/belk/free_rtos/helloworld_freertos.bin
fsbl_base=0x40000
ftd_file=bora/bora.dtb
gateway=192.168.0.254
header_base=0
hostname=bora
ipaddr=192.168.0.209
jtagboot=echo TFTPing Linux to RAM...;tftp 0x8000 zImage;tftp 0x1000000 devicetree.dtb;tftp 0x800000 ramdisk8M.image.gz;go 0x8000
kernel_size=0x140000
load=tftp ${loadaddr} bora/u-boot.bin
load_dt=tftp ${loadaddr} bora/bora.dtb
load_fpga=tftp ${loadaddr} bora/${fpga_file}
load_freertos=tftp ${freertos_addr} ${freertos_file};mw.l 0xFFFFFFF0 ${freertos_addr}
load_fsbl=tftp ${loadaddr} bora/belk/free_rtos/bora_FSBL.bin
load_h=tftp ${loadaddr} bora/boot_header-1.1.0
loadaddr=0x08000000
loadaddr_ftd=0x01000000
loadaddr_kern=0x0
loadk=tftp ${loadaddr_kern} ${bootfile};tftp ${loadaddr_ftd} ${ftd_file}
modeboot=qspiboot
net_nfs=run program_fpga; run load_freertos; run loadk nfsargs addip addcons addmem; bootm ${loadaddr_kern} - ${loadaddr_ftd}
netmask=255.255.255.0
nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
nr_cpus=1
program_fpga=run load_fpga;fpga load 0 ${loadaddr} 0x${filesize}
qspiboot=sf probe 0 0 0;sf read 0x8000 0x100000 0x2c0000;sf read 0x1000000 0x3c0000 0x40000;sf read 0x800000 0x400000 0x800000;go 0x8000
ramdisk_size=0x200000
rootpath=/home/shared/devel/dave/bora-DBRx/sw/linux/rfs/BELK/ubuntu_12.04
sdboot=echo Copying Linux from SD to RAM...;mmcinfo;fatload mmc 0 0x8000 zImage;fatload mmc 0 0x1000000 devicetree.dtb;fatload mmc 0 0x800000 ramdisk8M.image.gz;go 0x8000
serverip=192.168.0.23
stderr=serial
stdin=serial
stdout=serial
u-boot_base=0x80000
update=sf probe 0 0 0;sf erase ${u-boot_base} 0x80000;sf write ${loadaddr} ${u-boot_base} 0x80000
update_dt=sf probe 0 0 0;sf erase ${dt_base} 0x40000;sf write ${loadaddr} ${dt_base} 0x40000
update_fpga=sf probe 0 0 0;sf erase ${fpga_base} 0x440000;sf write ${loadaddr} ${fpga_base} 0x440000
update_fsbl=sf probe 0 0 0;sf erase ${fsbl_base} 0x40000;sf write ${loadaddr} ${fsbl_base} 0x40000
update_fsbl_nand=run load_fsbl; nand erase 0x40000 0x40000; nand write ${loadaddr} 0x40000 0x40000
update_h=sf probe 0 0 0;sf erase ${header_base} 0x40000;sf write ${loadaddr} ${header_base} 0x40000
</pre>
====Example #2: RPMsg-based application====
<pre>
addcons=setenv bootargs ${bootargs} console=${console},115200n8 cma=16M debug
addip=setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gateway}:${netmask}:${hostname}:${ethdev}
addmem=setenv bootargs ${bootargs} mem=496M
baudrate=115200
bootdelay=3
bootfile=bora/uImage
console=ttyPS0
dt_base=0x005C0000
ethact=Gem.e000b000
ethaddr=00:0a:35:00:01:22
ethdev=eth0
fdt_high=0x1F000000
fileaddr=0
filesize=2f0ed0
fpga_base=0x00180000
fpga_file=belk/free_rtos/bora_design_wrapper.bin
freertos_addr=0x3F000000
freertos_file=bora/belk/free_rtos/helloworld_freertos.bin
fsbl_base=0x40000
ftd_file=bora/bora.dtb
gateway=192.168.0.254
header_base=0
hostname=bora
ipaddr=192.168.0.209
jtagboot=echo TFTPing Linux to RAM...;tftp 0x8000 zImage;tftp 0x1000000 devicetree.dtb;tftp 0x800000 ramdisk8M.image.gz;go 0x8000
kernel_size=0x140000
load=tftp ${loadaddr} bora/u-boot.bin
load_dt=tftp ${loadaddr} bora/bora.dtb
load_fpga=tftp ${loadaddr} bora/${fpga_file}
load_freertos=tftp ${freertos_addr} ${freertos_file};mw.l 0xFFFFFFF0 ${freertos_addr}
load_fsbl=tftp ${loadaddr} bora/belk/free_rtos/bora_FSBL.bin
load_h=tftp ${loadaddr} bora/boot_header-1.1.0
loadaddr=0x08000000
loadaddr_ftd=0x01000000
loadaddr_kern=0x0
loadk=tftp ${loadaddr_kern} ${bootfile};tftp ${loadaddr_ftd} ${ftd_file}
modeboot=qspiboot
net_nfs=run program_fpga; run loadk nfsargs addip addcons addmem; bootm ${loadaddr_kern} - ${loadaddr_ftd}
netmask=255.255.255.0
nfsargs=setenv bootargs root=/dev/nfs rw nfsroot=${serverip}:${rootpath}
nr_cpus=1
program_fpga=run load_fpga;fpga load 0 ${loadaddr} 0x${filesize}
qspiboot=sf probe 0 0 0;sf read 0x8000 0x100000 0x2c0000;sf read 0x1000000 0x3c0000 0x40000;sf read 0x800000 0x400000 0x800000;go 0x8000
ramdisk_size=0x200000
rootpath=/home/shared/devel/dave/bora-DBRx/sw/linux/rfs/BELK/ubuntu_12.04
sdboot=echo Copying Linux from SD to RAM...;mmcinfo;fatload mmc 0 0x8000 zImage;fatload mmc 0 0x1000000 devicetree.dtb;fatload mmc 0 0x800000 ramdisk8M.image.gz;go 0x8000
serverip=192.168.0.23
stderr=serial
stdin=serial
stdout=serial
u-boot_base=0x80000
update=sf probe 0 0 0;sf erase ${u-boot_base} 0x80000;sf write ${loadaddr} ${u-boot_base} 0x80000
update_dt=sf probe 0 0 0;sf erase ${dt_base} 0x40000;sf write ${loadaddr} ${dt_base} 0x40000
update_fpga=sf probe 0 0 0;sf erase ${fpga_base} 0x440000;sf write ${loadaddr} ${fpga_base} 0x440000
update_fsbl=sf probe 0 0 0;sf erase ${fsbl_base} 0x40000;sf write ${loadaddr} ${fsbl_base} 0x40000
update_fsbl_nand=run load_fsbl; nand erase 0x40000 0x40000; nand write ${loadaddr} 0x40000 0x40000
update_h=sf probe 0 0 0;sf erase ${header_base} 0x40000;sf write ${loadaddr} ${header_base} 0x40000
</pre>
-----
{{notelist}}
