| 1 | /* |
| 2 | * Copyright 2006 Sun Microsystems, Inc. All rights reserved. |
| 3 | * Use is subject to license terms. |
| 4 | */ |
| 5 | #pragma ident "@(#)README.save_restore 1.2 06/11/15 SMI" |
| 6 | |
| 7 | |
| 8 | Legion Save/Restore Feature |
| 9 | =========================== |
| 10 | |
| 11 | |
| 12 | How to save a memory image from legion: |
| 13 | ======================================= |
| 14 | |
| 15 | 1) bringover and build your legion gate. |
| 16 | |
| 17 | 2) setup your config file as follows : |
| 18 | |
| 19 | // Add this optional directive to your legion config file. |
| 20 | // It should appear before the system directive. |
| 21 | |
| 22 | debug { |
| 23 | save_state { |
| 24 | // The instruction count to initiate a save. If not specified, |
| 25 | // user can initiate a save using ~% on the console or |
| 26 | // using the dbx command 'simsave'. |
| 27 | icount 2383700054; |
| 28 | |
| 29 | // legion is the default format. ie a list of mem.image.n |
| 30 | // files will be produced along with a restore.conf file |
| 31 | // that has the details of where in memory to load each |
| 32 | // memory image. When using the axis format, a |
| 33 | // single text file called mem_image.axis is produced |
| 34 | // which can be loaded into Axis or can be converted back |
| 35 | // into a series of mem.image.n files for use with legion |
| 36 | // (using the mem_conv program in your legion build dir) |
| 37 | format "axis"; |
| 38 | |
| 39 | // When using the axis format, an optional filename can be |
| 40 | // provided. If no filename is given, the default of |
| 41 | // mem_image.axis is used. |
| 42 | filename "mem_image.foo"; |
| 43 | |
| 44 | // For N2, add the following. This will allow dumbreset to |
| 45 | // know to jump to the restore code on AXIS. |
| 46 | patch 0xfff0000200 0x1; |
| 47 | |
| 48 | // For VF, add the following. This will allow standalone reset |
| 49 | // to know to jump to the restore code on AXIS/Palladium. |
| 50 | patch 0xfff0002000 0x1; |
| 51 | } |
| 52 | } |
| 53 | |
| 54 | |
| 55 | // Add this inside the addressmap directive in your config file |
| 56 | // savestate_<proc>.bin can be found in <legion-ws>/src/statesave/<proc> |
| 57 | // Note that for the bigger configs, the memory size needs to be |
| 58 | // increased. eg, for the largest VF config 2n8c8t, you need to have |
| 59 | // device "memory" 0x0 +320k { |
| 60 | |
| 61 | // Save/Restore |
| 62 | device "memory" 0x0 +32k { |
| 63 | load +0x0 "savestate_<proc>.bin"; |
| 64 | } |
| 65 | |
| 66 | // XXX FIXME: There is a bug which means that you need to change |
| 67 | // the size of the memory image that holds the disk |
| 68 | // from 513M to 512M. So edit your config file to |
| 69 | // change it so it looks like this: |
| 70 | |
| 71 | device "memory" 0x1f40000000 +512M { |
| 72 | |
| 73 | |
| 74 | 3) start your simulation |
| 75 | |
| 76 | 4) Initiate a save_state by one of the following: |
| 77 | |
| 78 | 4a) typing ~% (tilde-percent) on the legion console window |
| 79 | (where the OBP/Solaris boot messages appear). A save_state |
| 80 | will be initiated immediately. |
| 81 | |
| 82 | 4b) specifying an instruction count in the debug directive |
| 83 | in your config file. When this instruction count is reached |
| 84 | the simulator will automatically initiate a save_state. |
| 85 | You can still use the ~% even if you specify an icount |
| 86 | in your config file if you want to save_state earlier. |
| 87 | |
| 88 | 4c) Run legion using dbx, set a breakpoint in legion (break) or |
| 89 | in Hypervisor/Guest code (simbreak) at the place where you |
| 90 | want to initiate the save_state. Once dbx stops, you can |
| 91 | initiate the save_state by typing 'simsave' at the dbx |
| 92 | prompt. Use of this feature requires that you pick up the |
| 93 | dbxrc file in the legion gate above and place this in your |
| 94 | run directory as a file called .dbxrc. The dbxrc can be |
| 95 | found at src/procs/sunsparc/debug/dbxrc in the legion gate. |
| 96 | |
| 97 | All of these will result in a file being created with the entire |
| 98 | simulation memory image. This file will be created in the run |
| 99 | directory using the filename that you provided in your config |
| 100 | file(if you picked the AXIS format). |
| 101 | |
| 102 | This is a text file that can be processed back into multiple |
| 103 | binary images that legion can digest. This file can also be |
| 104 | loaded directly into Axis as a memory image. |
| 105 | |
| 106 | NOTE NOTE NOTE: |
| 107 | =============== |
| 108 | For N2/VF, due to an AXIS bug, the SSI region needs to be |
| 109 | located at the top of this text file. The following extra steps |
| 110 | are needed. |
| 111 | grep -n 'Memory from fff0000000 to fff0800000' mem_image.txt |
| 112 | using the line number obtained, do the following. |
| 113 | tail +<line_num> mem_image.txt > mem_image_axis.txt |
| 114 | head -<line_num -1> mem_image.txt >> mem_image_axis.txt |
| 115 | |
| 116 | mem_image_axis.txt is the file you hand over for AXIS testing. |
| 117 | |
| 118 | 5) Loading a memory image back into legion |
| 119 | |
| 120 | 5a) Run the conversion program to convert the text memory image |
| 121 | back into multiple binaries so that legion can load them: |
| 122 | NOTE: the mem_conv tool gets built as part of legion and |
| 123 | can be found in your build directory |
| 124 | |
| 125 | ./mem_conv -i mem_image.axis |
| 126 | |
| 127 | Running this command takes a few minutes depending on |
| 128 | the size of the memory image. |
| 129 | |
| 130 | 5b) Once this command completes, you will now have a bunch of |
| 131 | new files in your current directory: |
| 132 | |
| 133 | // Binary files for each memory segment |
| 134 | mem.image.n files (usually 0-8) |
| 135 | |
| 136 | // Legion config file for loading in these binary memory images |
| 137 | restore.conf |
| 138 | |
| 139 | 5c) You will now need to create a new config file for reloading |
| 140 | the the memory images. This file should look the same as a |
| 141 | regular 1up.conf file, except strip out all the device memory |
| 142 | directives from the addressmap. NOTE: leave in the dumbserial, |
| 143 | dumbtod and piu devices, just make sure you remove all the |
| 144 | memory devices. |
| 145 | |
| 146 | Then, inside the addressmap directive, add the following: |
| 147 | |
| 148 | #include "restore.conf" |
| 149 | |
| 150 | So your addressmap directive should look like this(for Rock). |
| 151 | For N2/VF, leave the piu section in as well. |
| 152 | addressmap { |
| 153 | // console |
| 154 | device "dumbserial" PUART0 +0x50 { |
| 155 | xterm "/pkg/X11/bin/xterm -l -lf guest1.log -geometry 80x35+200+30 -T 'Guest Partition #1 - 1 X Rock strand' -e /net/cpubringup.sfbay/export/bringup/niagara/tools/bin/netcons %s %d &"; |
| 156 | } |
| 157 | device "dumbtod" HVTOD +0x8; |
| 158 | device "dumbserial" HVUART +0x50; |
| 159 | |
| 160 | #include "restore.conf" |
| 161 | } |
| 162 | |
| 163 | 5d) You need to change the reset vector of your 1up.reload config |
| 164 | file to start the processor executing from the restore code |
| 165 | which is at offset 0x20 in the save_restore code. To do this |
| 166 | edit your config file and change the rstv to 0x0; The processor |
| 167 | always adds 0x20 to the reset_vector so this will cause the |
| 168 | restore code at address 0x20 to start the restore process. |
| 169 | NOTE: This step should not be done for VF/N2. The reset vector |
| 170 | will remain at the original value as reset.bin needs to be run |
| 171 | before the restore code. |
| 172 | |
| 173 | 5e) Then start your simulation using this new config file and voila, |
| 174 | you should start executing from the exact point you iniated the |
| 175 | save_state. |
| 176 | |
| 177 | |