Usage
=====
1. Requirements/Pre-requisites
1. A Linux development environment. This release has been
build tested on the following Linux host environments:
1. Linux Ubuntu 10.10
2. Red Hat Enterprise Linux WS release 4 (Nahant Update 4)
This release is not intended to be used on development
environments other than Linux.
2. ARM Development Studio 5 - Version 5.9. This release was built
and tested with ARM RealView Development Suite version 5.0.1
[Build 64] which is included in the above mentioned DS-5
release.
3. An installation of the Perl scripting language. This release
was built and tested with v5.10.1.
4. An installation of the GNU coreutils suite
. This release was
built and tested with v8.5.
2. Build instructions
Note that this release relies on the 'env' utility, which is
a part of the coreutils suite. The 'env' utility is expected
to be located at '/bin/env'. If it is at a different
location then this must be reflected in the first line of
the following file:
arm-virtualizer-v2_4-170512/bootwrapper/makemap
Failure to make this modification will result in a build
failure.
To build the software:
$ tar -jxf arm-virtualizer-v2_4-170512.tar.bz2
$ cd arm-virtualizer-v2_4-170512/bootwrapper
$ make clean && make
The resulting files of interest are 'bootwrapper/img.axf' &
'big-little/wboot.bin'. 'img.axf' is a composite image consisting
of the bootwrapper, Virtualizer, payload software and any
filesystem image (explained below). 'wboot.bin' is simple stub
code to distinguish between a cold and warm reset. It is loaded
at physical address 0x00000000. Both the images are loaded and
executed on the big.LITTLE RTSM as explained in section 4 below.
Note that the pre-built stub payload software image is located at:
arm-virtualizer-v2_4-170512/bootwrapper/payload/kernel
.. and an empty placeholder dummy root filesystem image is located
at:
arm-virtualizer-v2_4-170512/bootwrapper/payload/fsimg
These may be replaced with custom built images such as a
suitably configured linux kernel image and a root filesystem
image.
Look at docs/03-Linux-kernel-build.txt for instructions on
building a suitable Linux kernel.
Look at docs/06-Optional-rootfs-build.txt for optionally
building a complete root filesystem.
3. Build Configurations
1. How a Cluster migration is invoked
The Virtualizer software image provides the ability to switch
execution of the payload software between the two clusters
asynchronously and synchronously.
In the synchronous case the payload software can request the
Virtualizer software to invoke a switch explicitly. This can be
done using the "HVC #0" ARM assembler instruction with the general
purpose register r0 set to the value 0x90000000 from the payload
software. This convention to switch between clusters conforms with
the "docs/HVC Calling Conventions.pdf" document.
In the asynchronous case, the HYP mode architectural timer
interrupt causes a cluster switch approx. every 12 million cycles.
The two methods are mutually exclusive. The Virtualizer software
is built with support for synchronous switching by default. It can
be built with support for asynchronous switching by setting the
ASYNC environment variable to TRUE prior to building it.
2. Supported Boot and Host cluster configurations
The Virtualizer currently does not support configurations where the
Host cluster can also be the cluster which is released from cold reset
(Boot Cluster). It enforces that the Target cluster is also the Boot
cluster. The boot cluster cluster can be configured using the
BOOT_CLUSTER environment variable prior to compilation. Its default
value is 0 (Cortex-A15 Cluster). The default value of the HOST_CLUSTER
is 1 (Cortex-A7 Cluster).
The FastModels parameter:
"coretile.dualclustersystemconfigurationblock.CFG_ACTIVECLUSTER="
needs to be updated as well to ensure that the chosen boot cluster is
brought out of cold reset. Its default value is '1' which corresponds
to the Cortex-A15 cluster. To configure the Cortex-A7 cluster as the
boot cluster, it should be set to '2'. Please refer to Section 4. for
more details.
4. Usage
If the Real-Time System Model v7.0.1 (RTSM_VE_Cortex_A15x1_A7x1
and RTSM_VE_Cortex_A15x4_A7x4) is installed, the resulting
img.axf file may be loaded, executed and debugged on the
model and the associated model debugger.
This model may be obtained from ARM by separate arrangement.
Steps to run the software:
a. Depending upon whether the MPx1 or MPx4 model is being used,
update the big-little-mp.mxscript file (x is 1 or
4 as the case may be) with the absolute path to the model,
the img.axf & wboot.bin files.(Comments in the file indicate
where the changes have to be made)
b. Invoke the modeldebugger and the script file as follows:
$ -s .mxscript path>
c. If the 'img.axf' was built with the default pre-built stub
image, then output similar to below is expected to appear on
RTSM terminal window corresponding to uart0. In each case,
the stub image invokes a synchronous cluster switch using
the HVC API on a randomly selected cpu. A switch is indicated
by the message "CPU[/]: Switching cluster.".
This message is printed by the cpu invoking the cluster switch.
Output for RTSM_VE_Cortex_A15x4_A7x4:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Kicking 3 secondary CPU(s)
Waiting for 3 secondary CPUs
Kernel at 0x80008000
Kernel entry point 0x80008000 (arm)
Secondary start address 80008000
CPU[0/0]: Booted.
CPU[0/1]: Booted.
CPU[0/3]: Booted.
CPU[0/2]: Booted.
You can see the cluster switch taken place in the CLCD window of the Fast Model!
CPU[0/1]: Switching cluster.
CPU[1/3]: Switching cluster.
CPU[0/1]: Switching cluster.
.
.
.
.
Output for RTSM_VE_Cortex_A15x1_A7x1:
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Waiting for 0 secondary CPUs
Kernel at 0x80008000
Kernel entry point 0x80008000 (arm)
Secondary start address 80008000
CPU[0/0]: Booted.
You can see the cluster switch taken place in the CLCD window of the Fast Model!
CPU[0/0]: Switching cluster.
CPU[1/0]: Switching cluster.
CPU[0/0]: Switching cluster.
CPU[1/0]: Switching cluster.
.
.
.
.