summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDietmar Eggemann <dietmar.eggemann@arm.com>2012-05-18 13:36:21 +0100
committerDietmar Eggemann <dietmar.eggemann@arm.com>2012-05-23 12:44:36 +0100
commitbe6df40d74877aafe9fb065b88aa667952ac0f65 (patch)
treef83cf310dbc79b7b6df3748cde09a2bfc0779e9d
parent913c5d16f7b899e90a39676a98c165869235d0fb (diff)
downloadswitcher-be6df40d74877aafe9fb065b88aa667952ac0f65.tar.gz
Update release notes and docs subdirectory to v2.4.
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
-rw-r--r--Release_Notes.txt152
-rw-r--r--docs/01-Usage.txt154
-rw-r--r--docs/02-Code-layout.txt72
-rw-r--r--docs/03-Linux-kernel-build.txt22
-rw-r--r--docs/06-Optional-rootfs-build.txt236
-rw-r--r--docs/08-Streamline-and-cluster-switching-howto.txt98
-rw-r--r--docs/09-HVC-calling-conventions.pdfbin0 -> 265463 bytes
-rw-r--r--docs/10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdfbin0 -> 396143 bytes
8 files changed, 546 insertions, 188 deletions
diff --git a/Release_Notes.txt b/Release_Notes.txt
index 8a82c46..3340bde 100644
--- a/Release_Notes.txt
+++ b/Release_Notes.txt
@@ -53,7 +53,7 @@ Release notes
d. Product status
- ARM Virtualizer for Cortex-A15/Cortex-A7 Task Migration v2.3
+ ARM Virtualizer for Cortex-A15/Cortex-A7 Task Migration v2.4
e. Web address
@@ -71,11 +71,11 @@ Release notes
a. Product release status
- v2.3
+ v2.4
- b. ARM Virtualizer software release v2.3
+ b. ARM Virtualizer software release v2.4
- This software release is a v2.3 snapshot of the ARM
+ This software release is a v2.4 snapshot of the ARM
Virtualizer software.
The ARM Virtualizer software is example code that demonstrates
@@ -97,7 +97,7 @@ Release notes
This release contains the following file:
- 1. arm-virtualizer-v2_3-130312.tar.bz2
+ 1. arm-virtualizer-v2_4-170512.tar.bz2
- Contains source code for a basic boot wrapper.
@@ -124,65 +124,99 @@ Release notes
operating system kernel) built for the Cortex-A15 processor
cluster to run un-modified on a Cortex-A7 processor cluster.
- This release does not support execution of software built for the
- Cortex-A7 cluster on the Cortex-A15 cluster.
-
e. New features
- 1. It is possible to hotplug a cpu using the mechanisms provided
- by the Linux 3.x cpu hotplug implementation. Please refer to
- "docs/07-Linux-cpu-hotplug-howto.txt" for details regarding
- how the Virtualizer software and Linux should be configured
- to support cpu hotplug.
+ 1. Context of the registers specified by the v7.1 Debug architecture
+ is saved and restored during a cluster context switch operation
+ using the mandatory CP14 interface instead of the optional memory
+ mapped interface.
- 2. Context of the registers specified by the v7.1 Debug architecture
- is saved and restored during a cluster context switch operation.
+ Please note that it is not possible to set hardware breakpoints on
+ v7.0 of the big.LITTLE FastModels. This functionality is expected
+ to be available in v7.1 of the FastModels.
- 3. Use of inter-processor interrupts for HYP mode communication has
- been made generic. It is possible to use an IPI for a particular
- type of HYP mode operation. Requesting a cluster switch and
- completing a virtual irq migration operation are the two types of
- HYP mode operations that are currently supported.
+ 2. It is possible to use the Cortex-A7 MP4 processor cluster as the
+ boot cluster provided it is also configured as the target cluster.
+ Refer to "docs/01-Usage.txt" for details.
- f. Known issues
+ 3. A new API is used to request services from the Virtualizer using
+ the ARM "HVC #0" instruction. Details of this API are documented
+ in "docs/09-HVC-calling-conventions.pdf".
- 1. This release does not support execution of software
- built for the Cortex-A7 cluster on the Cortex-A15
- cluster.
+ Existing services which have been changed to adhere to the new
+ standard are:
- 2. This release is intended to be built in a Linux development
- environment. Environments other than Linux are not supported.
+ 1. HVC to invoke a cluster switch
+ 2. HVC to read the physical MPIDR coprocessor register
- 3. The cache level chosen through a write to the CSSELR on the
- Cortex-A7 cluster is not migrated to the Cortex-A15 cluster during
- a subsequent migration.
+ New services which have been implemented using the new standard
+ are:
- 4. Differences in the characteristics of the I-Cache between the
- Cortex-A7 and Cortex-A15 are not hidden through the use of
- Virtualization extensions by the Virtualizer.
+ 1. Services to enable use of the PMU with the Virtualizer. Details
+ can be found in:
- 5. Save & Restore of Debug context is done only when the memory mapped
- interface is supported. Doing the same using the cp14 interface is
- currently not supported.
+ "docs/10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdf"
- 6. Save & Restore of Debug context is still being tested.
+ f. Known issues
+
+ 1. This release is intended to be built in a Linux development
+ environment. Environments other than Linux are not supported.
- 7. Bug fix to support migration of virtual interrupts is still being
- tested. [Please see 'v2.2 to v2.3' in Section g.]
+ 2. The v7.0 release of the FastModels does not reset DBGOSDLR.DLK to
+ 0 when a processor is brought out of warm reset. A software
+ workaround has been implemented which clears the DLK field as a part
+ of saving and restoring the context.
- 8. Support for cpu hotplug is still being subject to
- stress tests.
+ 3. Cortex-A15 implements 6 event counters while Cortex-A7 implements 4.
+ The Virtualizer hides this difference by restricting the number of
+ counters visible on Cortex-A15 to 4. Implementing this requires the
+ PMCR.N field to mirror the HDCR.HPMN field. v7.0 of the FastModels
+ are unable to virtualize the PMCR.N field using this method. Hence
+ Counter #5 & #6 should not be used by the payload software. This
+ issue is expected to be fixed in a subsequent release of the
+ FastModels.
g. Issues resolved since last release
1. Bug fixes
- v2.1:
+ v2.3 to v2.4:
- 1. vGIC HYP view interface handling code in (common/vgiclib.c) now
- detects the number of implemented list registers from the vgic
- type register instead of assuming that the maximum (64) will be
- present.
+ 1. It is possible to boot the payload software on the Cortex-A7
+ cluster. This means that software built for Cortex-A7 can be
+ run unmodified on the Cortex-A15 cluster.
+
+ 2. Cortex-A15 has a PIPT I-cache with 64 byte cache lines. Cortex-A7
+ has a VIPT I-cache with 32 byte cache lines. To provide a uniform
+ view of the I-cache topology to the payload software, the
+ Virtualizer exports the Cortex-A7 I-cache topology to Cortex-A15,
+ thus hiding the differences between them.
+
+ 3. The cache level chosen through a write to the CSSELR on the
+ Cortex-A7 cluster is now migrated to the Cortex-A15 cluster during
+ a subsequent migration.
+
+ 4. Support added in v2.3 for migrating virtual interrupts as a part
+ of physical interrupt migration required the following fixes:
+
+ 1. Event for acknowledging transfer of virtual interrupts is
+ now propagated correctly.
+
+ 2. Data structure used for enqueuing a virtual interrupt is
+ reset correctly.
+
+ 5. The pre-built stub image used for synchronous cluster switching
+ now prints out the outbound cluster ID and CPU ID. [See
+ docs/01-Usage.txt for details].
+
+ v2.2 to v2.3:
+
+ 1. When a physical interrupt is migrated from one cpu interface to
+ another on any cluster, it is possible that its virtual interrupt
+ is in a pending state in the HYP view interface list registers.
+ It is now ensured that the virtual interrupt is also migrated by
+ requesting it to be added to the queue of virtual interrupts on
+ the destination cpu interface.
v2.1 to v2.2:
@@ -220,18 +254,16 @@ Release notes
without taking part in CCI based coherency for a
brief period of time.
- v2.2 to v2.3:
+ v2.1:
- 1. When a physical interrupt is migrated from one cpu interface to
- another on any cluster, it is possible that its virtual interrupt
- is in a pending state in the HYP view interface list registers.
- It is now ensured that the virtual interrupt is also migrated by
- requesting it to be added to the queue of virtual interrupts on
- the destination cpu interface.
+ 1. vGIC HYP view interface handling code in (common/vgiclib.c) now
+ detects the number of implemented list registers from the vgic
+ type register instead of assuming that the maximum (64) will be
+ present.
h. Test cases and results
- In accordance with the delivery’s status as example code, testing is
+ In accordance with the delivery's status as example code, testing is
sufficient to prove robustness of the basic implementation but does
not provide full coverage for all use cases.
@@ -274,11 +306,23 @@ Release notes
07-Linux-cpu-hotplug-howto.txt: Instructions & guidelines to
use Linux CPU hotplug.
+ 08-Streamline-and-cluster-switching-howto.txt: Instructions
+ & guidelines to use ARM Streamline tools with the Virtualizer
+ software.
+
+ "09-HVC-calling-conventions.pdf": Describes a set of software
+ conventions for Hyper-calls to be used with the ARM
+ virtualization extensions.
+
+ "10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdf": Describes the
+ Performance Monitor Units on a big.LITTLE system and the interface to
+ these units as provided by the Virtualizer software.
+
4. Tools
a. Tools
- 1. ARM Development Studio 5 - Version 5.8.
+ 1. ARM Development Studio 5 - Version 5.9.
2. Real-Time System Model v7.0.1 (RTSM_VE_Cortex_A15x1_A7x1
and RTSM_VE_Cortex_A15x4_A7x4).
diff --git a/docs/01-Usage.txt b/docs/01-Usage.txt
index 15e4f06..52d6ca7 100644
--- a/docs/01-Usage.txt
+++ b/docs/01-Usage.txt
@@ -12,8 +12,10 @@ Usage
This release is not intended to be used on development
environments other than Linux.
- 2. An installation of the ARM RealView Development Suite. This
- release was built and tested with version 4.1 [Build 514].
+ 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.
@@ -30,53 +32,88 @@ Usage
location then this must be reflected in the first line of
the following file:
- arm-virtualizer-v2_3-130312/bootwrapper/makemap
+ 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_3-130312.tar.bz2
- $ cd arm-virtualizer-v2_3-130312/bootwrapper
+ $ tar -jxf arm-virtualizer-v2_4-170512.tar.bz2
+ $ cd arm-virtualizer-v2_4-170512/bootwrapper
$ make clean && make
- The resulting file is 'img.axf'.
+ 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.
- This image may be loaded and executed on the model debugger
- as explained in section 3 below.
+ Note that the pre-built stub payload software image is located at:
- Note that the pre-built stub kernel image is located at:
+ arm-virtualizer-v2_4-170512/bootwrapper/payload/kernel
- arm-virtualizer-v2_3-130312/bootwrapper/payload/kernel
-
- .. and the placeholder dummy root filesystem image is located
+ .. and an empty placeholder dummy root filesystem image is located
at:
- arm-virtualizer-v2_3-130312/bootwrapper/payload/fsimg
+ 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.
- The Virtualizer software image supports asynchronous switching
- by default. This means that an interrupt causes a cluster
- switch approx. every 12 million cycles. The payload software
- can request the Virtualizer software to invoke a switch
- explicitly. This can be done using the "HVC #1" ARM assembler
- instruction from the payload software. This is the synchronous
- method of switching. The two methods are mutually exclusive.
- The Virtualizer software can be built with support for
- synchronous switching by setting the ASYNC environment variable
- to FALSE prior to building it.
-
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. Usage
+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=<value>"
+
+ 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
@@ -89,13 +126,68 @@ Usage
a. Depending upon whether the MPx1 or MPx4 model is being used,
update the big-little-mp<x>.mxscript file (x is 1 or
- 4 as the case may be) with the absolute
- path to the model and the img.axf file. (Comments in the
- file indicate where the changes have to be made)
+ 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:
- $ <path to modeldebugger> -s <path to big-little-mp<x>.mxscript>
+ $ <modeldebugger path> -s <big-little-mp<x>.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[<cluster id>/<cpu id>]: 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.
+ .
+ .
+ .
+ .
+
+
- The default build simultaneously switches clusters
- every 12 million cycles (appx).
diff --git a/docs/02-Code-layout.txt b/docs/02-Code-layout.txt
index 32a2a9a..4444135 100644
--- a/docs/02-Code-layout.txt
+++ b/docs/02-Code-layout.txt
@@ -145,8 +145,8 @@ B Code layout overview
1. Simple perl script that takes an ELF image of
the Virtualizer, parses through the relevant
sections & adds those sections to the scatter
- file so that a consolidated image can be
- created.
+ file so that a consolidated image can be
+ created.
2. big-little/common
@@ -317,18 +317,15 @@ B Code layout overview
as a trigger to initiate a switchover
asynchronously.
- 2. sync_switchover.c
+ 2. Exports a function [signal_switchover()] which
+ can be used to trigger a async/synchronous
+ switch.
- 1. Contains code to handle an HVC instructions
- executed by the payload software:
+ 3. Implements logic to ensure that only the cpus
+ which have not been hot-plugged are switched
+ to the inbound cluster.
- a. to initiate a synchronous switchover.
- ("HVC #1").
-
- b. to find the id of the cluster on which
- its currently executing. ("HVC #2").
-
- 3. handle_switchover.s
+ 2. handle_switchover.s
1. Contains code to start saving the non-secure
world context and request the secure world to
@@ -362,7 +359,7 @@ B Code layout overview
block will be trapped in the HYP mode.
Accesses to memory mapped peripherals e.g. shared vGIC
- can betrapped into the HYP mode by populating
+ can be trapped into the HYP mode by populating
appropriate entries in the 2nd stage translation tables.
This is how microarchitectural differences between the
two processor sets are resolved.
@@ -380,7 +377,7 @@ B Code layout overview
System Control Block. Once it knows the host cluster id
& whether the software is expected to switch execution
or run in the MP mode (provided at compile time), the
- CPU Can configure itself accordingly.
+ CPU can configure itself accordingly.
The processor cluster for which the payload software has
been built to run on [assumed to be Cortex-A15 for this
@@ -426,6 +423,18 @@ B Code layout overview
handlers exported by the processor on
which the trap has been invoked.
+ 2. It invokes a synchronous cluster switch if the
+ appropriate 'HVC' instruction is issued by the
+ payload software. Please refer to
+ "docs/09-HVC-calling-conventions.pdf" for details
+ of this 'HVC' API.
+
+ 3. It returns the value of the physical MPIDR
+ register if the appropriate 'HVC' instruction
+ is issued by the payload software. Please refer
+ to "docs/09-HVC-calling-conventions.pdf" for
+ details of this 'HVC' API.
+
3. virt_context.c
1. Generic function that saves and restores traps
@@ -456,15 +465,31 @@ B Code layout overview
to the Kingfisher System Control Block. This is
usually done to start a cpu hotplug operation.
+ 8. pmu_trap_handler.c
+
+ 1. Generic function that enables the use of PMU
+ with the Virtualizer software as per the design
+ detailed in:
+
+ 'docs/10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdf'
+
7. include/
Header files specific to the Virtualisor code.
8. cpus/
- Placeholders for any traps that the Cortex-A7 or A15 processor
- cluster might want to setup. No traps need to be setup
- at the moment.
+ Allows implementation of trap handling specific to the
+ Cortex-A7 or A15 processors.
+
+ 1. a15/a15.c
+ 2. a7/a7.c
+
+ 1. The differences between the I-cache topologies of
+ the Cortex-A7 & A15 processors cannot be handled
+ within the existing abstraction of HOST & TARGET
+ clusters. These differences are treated as cpu-
+ specific and handled within these two files.
9. big-little/secure_world
@@ -576,3 +601,16 @@ B Code layout overview
Contains routines to save and restore ARM processor
context.
+
+ 3. v7_c.c
+
+ Contains routines to save and restore a processor's
+ debug subsystem state. State is saved through the
+ cp14 interface for v7.1 of the debug subsystem &
+ through the memory mapped interface for v7.0.
+
+ 4. debug_helpers.s
+ 5. debug_helpers.h
+
+ Helper functions to save and restore the ARM Debug
+ subsystem context.
diff --git a/docs/03-Linux-kernel-build.txt b/docs/03-Linux-kernel-build.txt
index 9252859..7058613 100644
--- a/docs/03-Linux-kernel-build.txt
+++ b/docs/03-Linux-kernel-build.txt
@@ -5,14 +5,13 @@ A suitable Linux kernel image for use with the virtualizer
can be built as follows (GCC toolchain used for these steps is:
CodeSourcery Sourcery G++ Lite 2010.09 v4.5.1)
-$ tar -jxf arm-virtualizer-v2_3-130312.tar.bz2
-$ cd arm-virtualizer-v2_3-130312/bootwrapper
+$ tar -jxf arm-virtualizer-v2_4-170512.tar.bz2
+$ cd arm-virtualizer-v2_4-170512/bootwrapper
$ make clean
$ pushd /tmp
-$ git clone git://linux-arm.org/linux-2.6-lp.git linux-2.6-lp.git
-$ cd linux-2.6-lp.git
-$ git checkout -b a15-hotplug origin/a15-hotplug
-$ yes | make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- vexpress_a15_virt_defconfig
+$ git clone git://linux-arm.org/arm-blm.git arm-blm
+$ cd arm-blm
+$ yes | make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- vexpress_blm_defconfig
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j4
$ popd
$ cp $OLDPWD/arch/arm/boot/Image payload/kernel
@@ -24,10 +23,10 @@ $ make clean && make
.. in the top bootwrapper directory.
This will result in a file called img.axf located at
-arm-virtualizer-v2_3-130312/bootwrapper/img.axf.
+arm-virtualizer-v2_4-170512/bootwrapper/img.axf.
To launch the ARM FastModel with the virtualizer, first modify
-arm-virtualizer-v2_3-130312/bootwrapper/big-little-MP<x>.mxscript
+arm-virtualizer-v2_4-170512/bootwrapper/big-little-MP<x>.mxscript
as usual to fill in paths to the model binary and the img.axf files.
The mxscript file is adequately commented to assist with this.
@@ -44,15 +43,14 @@ string model = "/home/working_dir/models/RTSM_VE_Cortex-A15x4-A7x4";
The path to the img.axf file is specified using the app directive as
follows:
-string app = "arm-virtualizer-v2_3-130312/bootwrapper/img.axf";
+string app = "arm-virtualizer-v2_4-170512/bootwrapper/img.axf";
The model can then be launched using:
-modeldebugger -s arm-virtualizer-v2_3-130312/bootwrapper/big-little-MP<x>.mxscript
+modeldebugger -s arm-virtualizer-v2_4-170512/bootwrapper/big-little-MP<x>.mxscript
Where 'x' is the 1 or 4 respectively in the case of an MP1 model run or an
MP4 model run.
This will result in the Linux kernel console messages appearing the ARM
-FastModel UART emulation window. The virtualizer will switch execution
-between the two clusters at ~12 million instruction intervals.
+FastModel UART emulation window.
diff --git a/docs/06-Optional-rootfs-build.txt b/docs/06-Optional-rootfs-build.txt
index 6dd9d62..913861f 100644
--- a/docs/06-Optional-rootfs-build.txt
+++ b/docs/06-Optional-rootfs-build.txt
@@ -9,114 +9,202 @@ A Introduction
filesystems and this note doesn't cover all possibilities.
The default virtualizer release contains an empty filesystem
- stub located at:
-
- arm-virtualizer-v2_2-160212/bootwrapper/payload/fsimg
+ stub located at "bootwrapper/payload/fsimg"
A build using this stub doesn't contain a functional
filesytem that the Linux kernel image can use. fsimg can be
- replaced with a suitable filesystem image but with the
- following constraints:
+ replaced with a suitable initramfs root filesystem image but
+ with the following constraints:
1. Compressed or uncompressed cpio archives are supported.
- 2. The image size is limited to ~200 MB.
+ 2. The image size is limited to ~200 MB. In the default virtualizer
+ build setup, the filesystem image size is limited to 32 MB.
+
+ In section B. we illustrate a method to create a compressed
+ cpio archive filesystem image that can be used by replacing
+ "bootwrapper/payload/fsimg" file. We will also illustrate
+ what parts of the Virtualizer software need modification to
+ use a cpio archive of size > 32 MB as the root filesystem.
+
+ The size restriction mentioned in A.2 implies that only very 'lean'
+ filesystems such as busybox <http://www.busybox.net/> may be used.
+ While busybox presents a minimal but robust command line environment,
+ quite often a more conventional desktop like environment with window
+ management on top of an X server is required in order to run web
+ browsers etc.
+
+ In section C. we illustrate a method to use a larger (~2GB) filesystem
+ image that can be used with the ARM FastModels MMC emulation. Note that
+ the MMC emulations only supports images that are just under 2GB in size.
+
+ Note that if the MMC route is used, the "bootwrapper/payload/fsimg"
+ filesystem image needs to be replaced by an empty file. This is to
+ prevent Linux from using the cpio archive based initramfs as the root
+ filesystem before it can detect the MMC based root filesystem.
+
+B Building and using a cpio archive as a initramfs root filesystem
+
+ The following steps assume that a pre-built root filesystem is already
+ available in a compressed form in the file rootfs.tar.gz.
+
+ 1. Uncompress the filesystem:
+
+ sudo tar -zxf rootfs.tar.gz
+
+ 2. Ensure that the filesystem contains '/init'. It is used by Linux
+ as the default init process when an initramfs filesystem is used.
+ It can be the actual file or a symlink to another 'init' binary.
+ Alternatively, use the 'rdinit=<absolute path to init application>'
+ e.g. 'rdinit=/sbin/init' to specify which init binary should be
+ used by Linux in the absence of '/init'.
+
+ The kernel command line can be edited in 'bootwrapper/Makefile'. The
+ BOOTARGS variable points to the kernel command line string.
+
+ 3. Create a compressed cpio archive from the uncompressed filesystem:
+
+ pushd binary/boot/filesystem.dir
+ sudo sh -c 'find . | cpio --quiet -H newc -o | gzip -3 -n > ../../../rootfs.cpio.gz'
+ popd
+
+ 4. Copy the compressed cpio archive to "bootwrapper/payload/fsimg"
+
+ 5. If the size of the resulting cpio archive is > 32 MB then follow the
+ steps mentioned below. The following diagram illustrates how the
+ payload software (Linux in this case), initramfs filesystem &
+ Virtualizer images are placed relative to each other in physical memory.
+
+ Base of memory @ $(LOBASE)00000 -> ----------------------
+ | |
+ | |
+ Linux Kernel start @ 0x80008000 -> |--------------------|
+ | |
+ | |
+ | |
+ | |
+ | |
+ | |
+ Filesystem start @ 0x8df00000 -> |--------------------|
+ | |
+ | |
+ | |
+ Virtualizer start @ $(HIBASE)00000 -> |--------------------|
+ | |
+ | |
+ |--------------------|
+
+ a. Increase the size of the FILESYSTEM region in the scatter file
+ template bootwrapper/boot.map.template to be not less than the
+ size of the cpio archive created in step 3. It is set to 32MB
+ (0x2000000) by default.
+
+ b. The variable HIBASE contains the value of the MB where the
+ Virtualizer software (bootwrapper/img.axf) is loaded. Increase
+ its value to prevent any overlap between the memory spaces used
+ by the filesystem and the Virtualizer. An overlap will be flagged
+ as a linker error while building the Virtualizer software.
+
+ HIBASE can be changed as an environment variable at the time of
+ building the Virtualizer software or in each of the following
+ makefiles:
+
+ a. "bootwrapper/Makefile"
+ b. "bootwrapper/big-little/Makefile"
- The size restriction implies that only very 'lean'
- filesystems such as busybox <http://www.busybox.net/> may be
- used. While busybox presents a minimal but robust command
- line environment, quite often a more conventional desktop
- like environment with window management on top of an X
- server is required in order to run web browsers etc.
+ If following the latter approach please ensure that both the
+ makefiles contain the same value of HIBASE. The default value of
+ $(HIBASE) is 0x8ff.
- In this note, we illustrate a method to use a larger (~2GB) filesystem image
- that can be used with the ARM FastModels MMC emulation. Note that the MMC
- emulations only supports images that are just under 2GB in size.
+ The start address of the root filesystem is contained in the
+ variable FSADDR. The default value of $(FSADDR) = 0x8df00000.
- Note that if the MMC route is used, the bootwrapper/payload/fsimg filesystem
- image will be suppressed and ignored.
+ The following equation illustrates the relationship between
+ FSADDR and HIBASE mentioned earlier
- Locating a root filesystem on the MMC emulation allows the Linux kernel to
- access and use this filesystem. This is facilitated by indicating the
- filesystem location to the kernel via the kernel command-line arguments by
- appending 'root=/dev/mmcblk0' (for a single partition MMC image) to the
- argument list.
+ $(FSADDR) + size of FILESYSTEM = $(HIBASE)00000
+ 0x8df00000 + 0x2000000 = 0x8ff00000
- Note that when using this technique, the fsimg file is ignored.
+ c. Increase the kernel parameter value mem=nn[KMG] of the Linux kernel
+ in bootwrapper/Makefile so that Linux is aware that the size of
+ physical memory is enough to include the root filesystem image. The
+ default value is 255M.
-B Building and installing a Linux kernel
+ BOOTARGS=mem=255M ...
- A suitable Linux kernel image for use with the virtualizer
- can be built as follows:
+ The following equation should be used as a reference for determining
+ the amount of physical memory made visible to Linux.
- $ tar -jxf arm-virtualizer-v2_2-160212.tar.bz2
- $ cd arm-virtualizer-v2_2-160212/bootwrapper
- $ make clean
- $ pushd /tmp
- $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/maz/ael-kernel.git ael-kernel.git
- $ cd ael-kernel.git
- $ git checkout -b ael-11.06 origin/ael-11.06
- $ yes | make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- vexpress-new_defconfig
- $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -j4
- $ popd
- $ cp $OLDPWD/arch/arm/boot/Image payload/kernel
+ $(LOBASE)00000 + "size of memory" > $(FSADDR) + size of FILESYSTEM
- Note that the using the vexpress-new_defconfig configuration
- ensures that the kernel is built with MMC support.
+ where $(LOBASE) is start of physical memory in the platform in MB.
+ Its default value is 0x800 which corresponds to the start of physical
+ on the FastModels platform at 0x80000000.
-C Building a suitable root filesystem
+ 7. Build a Linux kernel image for use with the virtualizer by following
+ the steps in "docs/03-Linux-kernel-build.txt".
- A suitable root filesystem can be built using Ubuntu Linux's rootstock utility
- <https://wiki.ubuntu.com/ARM/RootfsFromScratch> as follows:
+ 8. Build the Virtualizer by following the steps in "docs/01-Usage.txt".
- $ sudo apt-get install rootstock
- $ sudo rootstock --fqdn ubuntu --login ubuntu --password ubuntu --imagesize 2040M --seed lxde,gdm --notarball
- $ mv qemu-armel-*.img mmc.img
+ 9. Launch the ARM FastModel by following the steps in "docs/01-Usage.txt".
- Note that the complete filesystem build will take ~30
- minutes. On boot, the username and password is 'ubuntu'.
+C Building and using a root filesystem with ARM FastModels MMC emulation
- The rootstock invocation above will produce a rootfilesystem containing an
- LXDE desktop <http://lxde.org/> that has a firefox browser.
+ 1. Build a Linux kernel image for use with the virtualizer by following
+ the steps in "docs/03-Linux-kernel-build.txt". Please ensure that the
+ kernel is built with MMC support.
-D Modifying the kernel command line to support the MMC image.
+ 2. A suitable root filesystem can be built using the pre-built root
+ filesystem as mentioned under B.
- The virtualizer build system and the mxscripts that are used for launching
- the ARM FastModel require modifications to support the MMC image.
+ a. Create the mmc.dat file.
+ $ dd if=/dev/zero of=mmc.dat bs=1M count=512
- The build system modification is to change the Linux kernel command line
- arguments to make the kernel aware of the location of the root filesystem.
- The command line should contain the string 'root=/dev/mmcblk0'.
+ b. Add /dev/loop<x> as ./mmc.dat and verify which /dev/loop<x> you got.
+ $ sudo losetup -f ./mmc.dat
+ $ sudo losetup -a
- To make this modification, edit the file bootwrapper/Makefile and change the
- BOOTARGS specification on line 42 from:
+ c. Create an ext<2,3,4> filesystem on mmc.dat
+ $ mke2fs -F ./mmc.dat
- BOOTARGS=mem=255M console=ttyAMA0,115200 migration_cost=500
- cachepolicy=writealloc
+ d. Create a mountpoint to mount the image on.
+ $ sudo mkdir /mnt/devel
+ $ sudo mount /dev/loop<x> /mnt/devel
- to
+ e. Extract the contents of 'rootfs.tar.gz' into the image
+ $ sudo tar zxvf rootfs.tar.gz --preserve \
+ --strip-components=3 -C /mnt/devel
- BOOTARGS=root=/dev/mmcblk0 mem=255M console=ttyAMA0,115200
- migration_cost=500 cachepolicy=writealloc
+ g. Unmount the image and detach mmc.dat with the loop device
+ $ sudo umount /mnt/devel
+ $ sudo losetup -d /dev/loop<x>
- The ARM FastModel mxscript modification is to get the FastModel to use the
- mmc.img file created in step C above with the MMC emulation.
+ 3. Modify the kernel command line to support the MMC image. This is done
+ by indicating the filesystem location to the kernel via the kernel
+ command-line arguments. Append 'root=/dev/mmcblk0' (for a single
+ partition MMC image) to the argument list. To make this modification,
+ edit the file bootwrapper/Makefile and change the BOOTARGS
+ specification from:
- To make this modification uncomment the 'string mmcimage=' line (line 42)
- and provide the complete path to the mmc.img file generated in step C above.
+ BOOTARGS=mem=255M console=ttyAMA0,115200 migration_cost=500
+ cachepolicy=writealloc
-E Building the virtualizer
+ to
- $ cd bootwrapper
- $ make clean && make
+ BOOTARGS=root=/dev/mmcblk0 mem=255M console=ttyAMA0,115200
+ migration_cost=500 cachepolicy=writealloc
-F Launching the ARM FastModel
+ 4. Build the Virtualizer by following the steps in "docs/01-Usage.txt".
+ Please ensure that the 'bootwrapper/payload/fsimg' filesystem image
+ is replaced by an empty file.
- $ modeldebugger -s big-little-MP<x>.mxscript
+ 5. The ARM FastModel mxscript needs modification to get the FastModel
+ to use the mmc.img file created in step C above with the MMC emulation.
+ To make this change uncomment the 'string mmcimage=' line and provide
+ the complete path to the mmc.img file generated in step 2 above.
- .. where x is 1 or 4 as the case may be (MP1 build or MP4
- build).
+ 6. Launch the ARM FastModel by following the steps in "docs/01-Usage.txt".
-G Known limitations
+D Known limitations
None.
diff --git a/docs/08-Streamline-and-cluster-switching-howto.txt b/docs/08-Streamline-and-cluster-switching-howto.txt
new file mode 100644
index 0000000..a572a76
--- /dev/null
+++ b/docs/08-Streamline-and-cluster-switching-howto.txt
@@ -0,0 +1,98 @@
+Instructions & guidelines to use Streamline with Cluster Switching
+==================================================================
+
+A Introduction
+
+ This note describes how the Virtualizer software and the Streamline
+ tools should be configured to be able to visualize cluster Switching
+ and PMU counters across switches.
+
+B Guidelines
+
+ Setting up your target
+
+ 1. Setup Gator
+
+ These instructions are specific to the following big.LITTLE Migration
+ target: ARM Linux on Real-Time System Model v7.0.1 with the
+ Virtualizer.
+
+ You have to build the Virtualizer specific gator daemon and the gator
+ driver.
+
+ Follow the instruction in paragraph 'Setting up an ARM Linux target'
+ which you can find in ARM DS-5 Documentation in ARM Streamline >
+ Setting Up Your Target (click Help->Help Contents in your DS-5 Eclipse
+ window).
+
+ Note that the documentation you find there does not cover the
+ big.LITTLE Migration target. You have to consider the following
+ variations:
+
+ * Source code for the Gator driver (gator-driver.tar.gz) and daemon
+ (gator-daemon.tar.gz) are in the extra/gator subdirectory of the
+ Virtualizer release tarball.
+
+ * To build the Gator driver, use the Linux kernel source as well as
+ the configuration file mentioned in docs/03-Linux-kernel-build.txt.
+ The configuration file has all the necessary Kernel configuration
+ options for gator enabled already.
+
+ * The Streamline version in DS-5 V5.9 supports the Real-Time System
+ Model v7.0.1. For this specific model, you get values for the PMU
+ Cycle counter, the Instruction TLB refill counter and the
+ Instructions executed counter. Since an RTSM does not provide
+ accurate cycle and timing information the samples-generated data is
+ still not meaningful. However, it is sufficient to showcase and
+ validate the mechanisms required to use the PMUs with the
+ Virtualizer.
+
+ * A default counter configuration file 'configuration.xml' is provided
+ in the extra/gator subdirectory of the Virtualizer release tarball.
+ Note, that you can always configure counters using DS-5's counters
+ configuration dialog box but the existing configuration.xml already
+ enables all meaningful counters on the Real-Time System Model v7.0.1.
+
+ * Copy gatord, gator.ko and configuration.xml into the same directory
+ of the target file system.
+
+ * Run gatord with the default port 8080 since a corresponding setup is
+ done in the mxscripts for the gatord listening port in user-mode
+ networking:
+ $ ./gatord &
+
+ 2. Setup user-mode networking
+
+ * Invoke the model with the network (string networking) related
+ options depicted in the big-little-mp<x>.mxscript file (x is 1 or 4
+ as the case may be).
+
+ * Configure an IP address on the network interface of the target.
+ There are multiple ways to do it, one would be the following:
+
+ Activate the network interface:
+ $ ifconfig eth0 up
+
+ Invoke DHCP client on the network interface (e.g. udhcpc in
+ Busybox) to obtain an ip address:
+
+ $ IP_ADDR=`udhcpc -i eth0 2>/dev/null | grep "^Lease" |
+ awk '{print $3}'`
+
+ Add the ip address to the network interface:
+
+ $ ifconfig eth0 $IP_ADDR
+
+ Running a Streamline session
+
+ 1. You can now connect from your DS-5 ARM Streamline Data view to the
+ target by providing 'localhost' into the Address field and press the
+ 'Start capture' button.
+
+ 2. Invoke cluster switches. Please follow the instruction in
+ Documentation/cpu-freq/cpufreq-arm-bl.txt in the Linux kernel source
+ mentioned in docs/03-Linux-kernel-build.txt.
+
+ 3. Press the 'Stop' button of the current Capture and evaluate the
+ graphical representation of the PMU counters mentioned above as well
+ as the switching counts.
diff --git a/docs/09-HVC-calling-conventions.pdf b/docs/09-HVC-calling-conventions.pdf
new file mode 100644
index 0000000..25b631c
--- /dev/null
+++ b/docs/09-HVC-calling-conventions.pdf
Binary files differ
diff --git a/docs/10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdf b/docs/10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdf
new file mode 100644
index 0000000..7ddf5b2
--- /dev/null
+++ b/docs/10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdf
Binary files differ