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. . . . .