diff options
| -rw-r--r-- | Release_Notes.txt | 152 | ||||
| -rw-r--r-- | docs/01-Usage.txt | 154 | ||||
| -rw-r--r-- | docs/02-Code-layout.txt | 72 | ||||
| -rw-r--r-- | docs/03-Linux-kernel-build.txt | 22 | ||||
| -rw-r--r-- | docs/06-Optional-rootfs-build.txt | 236 | ||||
| -rw-r--r-- | docs/08-Streamline-and-cluster-switching-howto.txt | 98 | ||||
| -rw-r--r-- | docs/09-HVC-calling-conventions.pdf | bin | 0 -> 265463 bytes | |||
| -rw-r--r-- | docs/10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdf | bin | 0 -> 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 Binary files differnew file mode 100644 index 0000000..25b631c --- /dev/null +++ b/docs/09-HVC-calling-conventions.pdf 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 Binary files differnew file mode 100644 index 0000000..7ddf5b2 --- /dev/null +++ b/docs/10-ARM-Virtualizer-support-for-debug-and-the-PMU.pdf |