daniel5151/ts7200

A high-level emulator for the TS-7200 Single Board Computer, as used in CS 452 - Real-Time Programming at the University of Waterloo

ts7200

A high level emulator for the TS-7200 Single Board Computer, as used in CS 452 - Real Time Operating Systems at the University of Waterloo.

Choo Choo! 🚂

Disclaimer

The primary purpose of this emulator is to enable rapid prototyping and development of the CS 452 kernel without having to literally live in the Trains lab. That said, at the end of the day, you won't be marked on how well your kernel runs in this emulator, you'll be marked on how well your kernel runs on the actual hardware in the trains lab!

We make no guarantees about the accuracy and/or stability of this emulator! Use it at your own risk!

• Instruction timings and hardware access times are waaay off, so any profiling/benchmarking performed in the emulator won't be representative of the real hardware whatsoever!
• Emulated UARTs are can be quite forgiving when it comes to sending / receiving data. Namely, the CTS behavior is not representative of actual hardware.

If you find any bugs, please file an issue! Even better, if you happen to spot and fix a bug yourself, please consider upstreaming any improvements!

Getting Started

ts7200 is written in Rust, and uses the standard Rust package manager (cargo) for building / installation. If you don't have Rust installed, you can install it via rustup.

You can install ts7200 to your $PATH by running the following command:

cargo install --path .

Alternatively, if you simply want to try-out the emulator, you can build and run it without adding it to you $PATH:

cargo run --release -- [FLAGS] [OPTIONS] <kernel-elf>

Run ts7200 --help for information on how to use the emulator.

Make sure to redirect the emulator's stderr to a file / tty!

By default, the emulator puts the tty into "raw" mode (as part of the --uart2 default config). This clashes with the logging info being sent over stderr, and the two end up intertwining and "smearing" across the terminal.

This can be avoided by redirecting ts7200's stderr to a separate tty:

1. open a new terminal window
2. run the tty command to get it's corresponding tty device
3. redirect the output when running ts7200: ts7200 [...] 2> /dev/pts/X

Emulator Enhancements

There are quite a few features present in the emulator which are not available on actual hardware:

• GDB Debugging across context switches!
  • The GDB server is part of the emulator itself (as opposed to running within the emulated hardware), which means it can provide "true" instruction-level step-by-step debugging of your code.
  • To start a debugging session, pass the -g flag to ts7200, and use the GDB command target remote localhost:<port> to connect to the GDB server.
• Emulated devices emit ContractViolation errors if they are accessed "incorrectly", instead of silently-failing as they would on real hardware. Keep an eye on those stderr logs!
  • e.g: Accessing Uninitialized RAM logs a warning to stderr
  • e.g: Trying to enable a timer without giving it an initial value throws a fatal error
• (optional) Add a virtual UART3 device mapped at 0x808e_0000 (using the --hack-uart3-enable flag)
  • When used in conjunction with --hack-nodelay-uart-tx and --hack-uart3=file:/dev/pts/X, a virtual UART3 can be a useful non-intrusive (unlike GDB, which "stops the world") debugging tool!
  • Just Remember: The TS-7200 only has 2 UARTs, and trying to access UART3 on actual hardware will result in undefined behavior! This virtual UART3 is NOT the same UART3 as the one specified in the EP93xx user's guide! UART3 is just a clone of UART2 with different VIC interrupts.

Emulator Quirks

• Instead of zeroing-out RAM, uninitialized RAM is set to the ASCII value corresponding to '-' (i.e: decimal 45, hex 0x2d). This, along with the uninitialized RAM logs, makes it easier to spot any uninitialized memory issues in your code.
• While most keycodes are forwarded directly to the emulated code, Ctrl-C is "hijacked" within ts7200 to early-terminate the emulator. If your Kernel uses Ctrl-C for any functionality, you may need to tweak either ts7200 or your kernel's source.
  • This could be fixed by implemented a "leader-key" system, similar to tmux. PRs welcome!
• GDB Debugging "breaks" in the presence of Timer interrupts
  • Trying to step to the next instruction will most-likely result in GDB jumping to the IRQ handler instead
  • This can be worked-around by avoiding the n and s GDB commands when debugging code with IRQs, and instead setting specific breakpoints via b to "step" through the code.
  • Note: It should be possible to fix this by artificially disabling interrupts when single-stepping in the GDB implementation. A PR to implement this functionality would be much appreciated!

Project Status

At the moment, the majority of devices critical for running basic CS 452 kernels have been implemented and tested. That said, there are plenty of devices that could still be added and/or improved further. PRs are more than welcome!

NOTE: This is a non-exhaustive list of the project's status. There are also a plethora of TODOs, FIXMEs, XXXs, and stubs littered throughout the codebase, which provide an informal overview of subtle bits of missing and/or flat out wrong functionality.

• Core features
  • HLE boot (emulating CS 452's Redboot configuration)
    • ELF file parsing
    • Initializes devices / key memory locations with hardware-validated values
  • Debugging with GDB
• Devices
  • UARTs - Implemented, but too forgiving!
    • Real UART hardware can be quite finicky, especially when interacting with the Marklin train controller. Things that work fine on the emulator may not work on actual hardware!
    • RX/TX Flags
    • CTS flag (inaccurate: always set to 1 whenever UART isn't transmitting)
    • All "important" registers (for CS 452)
    • Interrupts
  • Timers - Totally Accurate!
    • Note: Timer 4, the 47 bit debug timer, is not currently implemented.
    • All Documented Register Functionality
    • Interrupts
  • VIC - Mostly Accurate
    • Asserts and Clears Interrupts
    • Correct daisy-chaining behavior
    • Vectored Interrupt Support (caution: not very well tested)
    • Reading from the VectAddr register doesn't actually mask out interrupts until you write to it
    • Protection bit can be accessed from any mode (not just privileged modes)
  • System Controller (Syscon) - Only the Important Parts
    • Note: Lot of stuff in the Syscon isn't relevant to CS 452, and will be left unimplemented
    • Correct handling of SW Locked Registers
    • Low Power Halt
    • Low Power Standby
    • The two 32bit scratch registers (just for fun lol)
  • RTC
  • Co-Processor Functionality
    • Note: arm7tdmi-rs doesn't currently expose a configurable coprocessor interface. Instead, any coprocessor operations are simply logged, and treated as no-ops. Until arm7tdmi-rs adds support for custom coprocessors, the following devices cannot be emulated correctly:
    • MMU
    • Caches
    • MaverickCrunch Co-Processor (i.e: math coprocessor)

Non-Goals

• LLE emulation of all TS-7200 hardware (e.g: to support "cold boots" directly into Redboot)
  • Most of the devices on the board aren't used by the CS 452 kernel, so emulating / stubbing them out just to get Redboot working isn't a great use of our time.
• Totally Accurate CPU performance
  • The emulated CPU runs as fast as the host system lets it, so performance will vary based on which machine you run the emulator on.
  • Note: Timers are implemented using the system clock, and will do the Right Thing no matter how fast the host system is.
• Train emulation
  • You mean you want me to write a physics simulator for virtual trains? Hahahaha, yeah... no.
  • Update: Looks like someone else was crazy enough to actually attempt doing this! Check out the MarklinSim project!
    • You may need to use the --hack-inf-uart-rx flag to get this working, depending on how you're querying CTS in your kernel.

ts7200's Issues

Implement 40-bit debug timer (Timer4)

Timer 4 is the 40 bit debug timer (as described under section 18.1.3). It's similar to Timers 1-3, albeit without as much "customization" options.

It should be fairly easy to implement:

• Modify the current timer device to use a internal u64 counter for time-keeping
• Create a "wrapper" device which masks masks out any timer registers unavailable on Timer 4
• Update the Ts7200Bus structure + memory map with the new device

Implement RTC

The RTC device is described under section 20 in the ep93xx user guide.

A simple implementation might be to synchronize the RTCData register to the host machine's clock. A fancier implementation would add the ability to set the time as well (via RTCLoad). The RTC is also capable of generating interrupts, so there may have to be some plumbing there as well.

It's likely the device would take a similar approach to the timer device, where registers are lazilly updated when read / written to, while a background thread is responsible for generating interrupts.

Program throws exception for simple program

Hi there, very cool project! Seeing some issues when trying to test this with a simple program. Program is as follows:

int main(void) { return 0; }

I am compiling this using the TS7200 cross compiler provided by TS here: https://files.embeddedarm.com/ts-arm-sbc/ts-7200-linux/cross-toolchains/crosstool-linux-gcc-4.0.1-glibc-2.3.5.tar.bz2

When running cargo run --release <binary> I see:

 DEBUG ts7200::sys::ts7200 > Setting PC to 0x0000855c
 DEBUG ts7200::sys::ts7200 > loading section ".interp" into memory from [0x000080f4..0x00008107]
 DEBUG ts7200::sys::ts7200 > loading section ".note.ABI-tag" into memory from [0x00008108..0x00008128]
 DEBUG ts7200::sys::ts7200 > loading section ".hash" into memory from [0x00008128..0x000081dc]
 DEBUG ts7200::sys::ts7200 > loading section ".dynsym" into memory from [0x000081dc..0x0000837c]
 DEBUG ts7200::sys::ts7200 > loading section ".dynstr" into memory from [0x0000837c..0x0000848e]
 DEBUG ts7200::sys::ts7200 > loading section ".gnu.version" into memory from [0x0000848e..0x000084c2]
 DEBUG ts7200::sys::ts7200 > loading section ".gnu.version_r" into memory from [0x000084c4..0x000084e4]
 DEBUG ts7200::sys::ts7200 > loading section ".rel.dyn" into memory from [0x000084e4..0x0000850c]
 DEBUG ts7200::sys::ts7200 > loading section ".rel.plt" into memory from [0x0000850c..0x0000851c]
 DEBUG ts7200::sys::ts7200 > loading section ".init" into memory from [0x0000851c..0x00008530]
 DEBUG ts7200::sys::ts7200 > loading section ".plt" into memory from [0x00008530..0x0000855c]
 DEBUG ts7200::sys::ts7200 > loading section ".text" into memory from [0x0000855c..0x00008780]
 DEBUG ts7200::sys::ts7200 > loading section ".fini" into memory from [0x00008780..0x0000878c]
 DEBUG ts7200::sys::ts7200 > loading section ".rodata" into memory from [0x0000878c..0x00008790]
 DEBUG ts7200::sys::ts7200 > loading section ".eh_frame" into memory from [0x00008790..0x00008794]
 DEBUG ts7200::sys::ts7200 > loading section ".ctors" into memory from [0x00010794..0x0001079c]
 DEBUG ts7200::sys::ts7200 > loading section ".dtors" into memory from [0x0001079c..0x000107a4]
 DEBUG ts7200::sys::ts7200 > loading section ".jcr" into memory from [0x000107a4..0x000107a8]
 DEBUG ts7200::sys::ts7200 > loading section ".dynamic" into memory from [0x000107a8..0x00010870]
 DEBUG ts7200::sys::ts7200 > loading section ".got" into memory from [0x00010870..0x00010898]
 DEBUG ts7200::sys::ts7200 > loading section ".data" into memory from [0x00010898..0x000108a4]
 WARN  ts7200::sys::ts7200 > [pc 0x00008568][addr 0x01fdcf34][Ram > <data>] r32 from uninitialized RAM
 WARN  ts7200::sys::ts7200 > [pc 0x2d2d2d2d][addr 0x00000020][Ram > <data>] r32 from uninitialized RAM
 ERROR ts7200              > Fatal Error! Caused by: FatalMemException {
    addr: 0x2d2d2d2c,
    in_mem_space_of: "<unmapped>",
    reason: Unexpected,
}
 ERROR ts7200              > Dumping system state to sysdump.log
Error: "Fatal Error!"

Do you have any ideas as to why this might be happening? Is this a bug, or some mistake I have made in setting up?

Launch GDB session on Fatal Error

Instead of immediately bailing when a fatal error occurs, it would be nice to launch a GDB server which can be used to inspect the current CPU and Memory state at the time of the crash.

This should be an optional feature (i.e: toggled via a CLI flag), as bailing immediately leads to faster iteration times when developing new code (as opposed to debugging existing code).