simics> system_cmp0.set-prom-env boot-command "boot disk1 -rv"
simics> system_cmp0.set-prom-env local-mac-address? true
The workaround, already applied to the bagle machine, is to set the workaround_linux_bug attribute to 1 in the fhc0 object.
On real machines there is an on-board SOC controller on one of the SYSIOs, and 'fas' + 'hme' on the other, hiding this bug. But Simics does not model the SOC device.
@conf.kbd.send_pc_codes = 1
Detailed information: The kernel tries to find the TLB entry of the current PC by masking the PC with an 8K page mask (0x1fff). But SILO has mapped the kernel in an 4M page. Since the PC isn't in the first 8K of this page when this happens, the kernel will never find any matching TLB entry and it then panics by running a "ta 5" instruction.
This bug is known to exist in early 2.6 kernels, at least up to 2.6.8. There exists a workaround, but it has to be adapted for each kernel version.
The clock frequency of a simulated processor can be set arbitrarily in Simics. This will not affect the actual speed of simulation, but it will affect the number of instructions that need to be executed for a certain amount of simulated time to pass. If your execution only depends on executing a certain number of instructions, increasing the clock frequency will take the same amount of host time (but a shorter amount of target time). However, if there are time based delays of some kind in the simulation, these will take longer to execute.
At a simulated 1 MHz, one million target instructions will correspond to a simulated second (assuming the simple default timing of one cycle per instruction). At 100 MHz, on the other hand, it will take 100 million target instructions to complete a simulated second. So with a higher clock frequency, less simulated target time is going to pass for a certain period of host execution time.
If Simics is used to emulate an interactive system (especially one with a graphical user interface) it is a good idea to set the clock frequency quite low. Keyboard and mouse inputs events are handled by periodic interrupts in most operating systems, using a higher clock frequency will result in longer delays between invocations of periodic interrupts. Thus, the simulated system will feel slower in its user response, and update the mouse cursor position etc. less frequently. If this is a problem, the best technique for running experiments at a high clock frequency is to first complete the configuration of the machine using a low clock frequency. Save all configuration changes to a disk diff (like when installing operating systems). Then change the configuration to use a higher a clock frequency and reboot the target machine.
Note that for a lightly-loaded machine (for example, working at an interactive prompt on a serial console to an embedded Linux system), Simics will often execute quickly enough at the real target clock frequency that there is no need to artifically lower it.