Back to the index

Experimenting with GXemul

• Hello world
• Experimental devices

Hello world:

• Build and install a cross-compiler for your chosen target, e.g. mips64-unknown-elf. GCC is usually a good compiler choice, because it is portable and in wide-spread use. (Other compilers should work too.)

• Compile the Hello World demo program for your chosen target, and run it in the emulator.

The Hello World demo program is included in the GXemul source code distribution, in the demos/hello/ subdirectory. The README files in the demo directories have several examples of how the demo programs can be built.

Once you have tried running the Hello World program from the command line, e.g.

	gxemul -E testmips hello_mips

• -t, to show a function call trace,
• -i, to show instruction disassembly (for each executed instruction),
• and finally -V to start the emulator in a "paused" state.

If you start the emulator in the paused state, or if you press CTRL-C during normal execution, you will end up with a GXemul> prompt. This is the built-in debugger.

Using the built-in debugger, you can single step (s), show the current contents of the emulated registers (r), turn on/off the function call trace mode (trace), or continue at full speed (c). Typing quit exits the emulator.

Hopefully this is enough to get you inspired. :-)

Experimental devices:

The test machines (testmips, testppc, etc) have the following experimental devices:

(*) Note: If the emulated architecture has the capability to write 64-bit words atomically, then writing to offset 0x0000 of the disk device should be enough to set the offset. For 32-bit architectures, the lowest 32 bits of the disk offset should first be written to the register at offset 0x0000, and the top 32 bits should then be written to the register at offset 0x0008.

The include files for the test machine devices are found in src/include/testmachine/.

While these devices may resemble real-world hardware, they are intentionally made simpler to use. (An exception is the framebuffer; some machines actually have simple linear framebuffers like this.)

If the physical address is 0x10000000, then for MIPS that means that it can be accessed at virtual address 0xffffffffb0000000. (Actually it can be accessed at 0xffffffff90000000 too, but devices should usually be accessed in a non-cached manner.)

When using the ARM or PPC test machines, the addresses are 0x10000000, 0x11000000 etc., so no need to add any virtual displacement.

The mp, disk, and ether devices are agnostic when it comes to word-length. For example, when reading offset 0x0000 of the mp device, you may use any kind of read (an 8-bit read will work just as well as a 64-bit read, although the value will be truncated to 8 bits in the first case). You can not, however, read one byte from 0x0000 and one from 0x0001, and combine the result. The read from 0x0001 will be invalid.

The cons device should be accessed using 8-bit reads and writes. Doing a getchar() (ie reading from offset 0x00) returns 0 if no character was available. Whenever a character is available, the cons device' interrupt is asserted. When there are no more available characters, the interrupt is deasserted. (Remember that the interrupt has to be unmasked to be able to actually cause an interrupt.)

IPIs (inter-processor interrupts) are controlled by the mp device. Whenever an IPI is "sent" from a source to one or more target CPUs, the interrupt is asserted on the target CPUs, and the IPI number is added last in the IPI queue for each of the target CPUs. It is then up to those CPUs to individually read from offset 0x00c0, to figure out what kind of IPI it was.

Interrupt mappings are as follows: