209 lines
6.7 KiB
Markdown
209 lines
6.7 KiB
Markdown
# Voodoo 2 (TMU) MemTest
|
|
|
|
## Introduction
|
|
|
|
This tool is an attempt to assist troubleshooting Voodoo² TMU's issues.
|
|
|
|
TMU system can be very hard to fix because there are so many connexions.
|
|
|
|
I developped this small tookit because at the time, one of my Voodoo2 was starting to have glitches and I could not figure out what was wrong.
|
|
|
|
I also had a 2nd one that I bought faulty and was struggling to repair.
|
|
|
|
Witchery was just out but did not support testing TMU memory.
|
|
|
|
So I found it funny to write a piece of code that tries to move data from CPU to TMU and vice-versa.
|
|
|
|
I found that the original 3DFX driver was actually doing a subset of what was needed, just to detect 8MB/12MB (and 4MB ?) Voodoo2 (Voodoo FX ?) boards.
|
|
|
|
That was the starting point, and after a lot of trials and error, I managed to transmit data to/from everywhere.
|
|
|
|
Note that this is a hoby project, done mostly for fun because buying another Voodoo2 would probably be cheaper than the time invested ... :).
|
|
|
|
As this is an open-source tool, feel free to Fork, Raise Tickets or to send Pull-Requests !
|
|
|
|
## Table of Content
|
|
|
|
[[_TOC_]]
|
|
|
|
## Requirements
|
|
|
|
To build this tool you need GNU Make, GCC and Glide 2.x SDK.
|
|
|
|
Requirement to run this tools depends on the build platform and options.
|
|
|
|
If you are using the binary I am sharing here, then you need a 32bit Linux System with :
|
|
|
|
- a Kernel >= 2.6.24
|
|
|
|
- glibc >= 2.3.6
|
|
|
|
- working Glide 2.x drivers
|
|
|
|
- a pentium 3 (or better) micro-code compatible CPU
|
|
|
|
|
|
|
|
As a reference, the development & validation environement was :
|
|
|
|
- Debian Linux Etch (4.0) i386
|
|
|
|
- Debian official 2.6.24 Kernel recompiled with pentium III options
|
|
|
|
- my own build of (updated) glide drivers.
|
|
|
|
## Status
|
|
|
|
Here is the [hopefully updated] project status.
|
|
|
|
- [ ] Implementation
|
|
- [X] test data (bit move)
|
|
- [X] test data (random pattern)
|
|
- [X] test address
|
|
- [ ] test data (huge block)
|
|
- [ ] test draw triangle shape (no texture)
|
|
- [ ] CLI options
|
|
- [ ] help
|
|
- [ ] single test run
|
|
- [ ] output failure results to file (TSV)
|
|
- [ ] log level
|
|
- [ ] log to file
|
|
- [ ] fault analysis
|
|
- [ ] Validation
|
|
- [X] working Voodoo2
|
|
- [X] working Voodoo2 SLI
|
|
- [ ] any RAM ICs
|
|
- [ ] DQx
|
|
- [X] short
|
|
- [ ] force 0
|
|
- [ ] force 1
|
|
- [ ] floating
|
|
- [ ] addresses
|
|
- [X] short
|
|
- [ ] force 0
|
|
- [ ] force 1
|
|
- [ ] floating
|
|
- [ ] RAS
|
|
- [ ] short
|
|
- [ ] force 0
|
|
- [ ] force 1
|
|
- [ ] floating
|
|
- [ ] CAS
|
|
- [ ] short
|
|
- [ ] force 0
|
|
- [ ] force 1
|
|
- [ ] floating
|
|
- [ ] WE
|
|
- [ ] short
|
|
- [ ] force 0
|
|
- [ ] force 1
|
|
- [ ] floating
|
|
- [ ] 1MB TMU test (faulty)
|
|
- [ ] 2MB TMU test (= 8MB Voodoo2)
|
|
- [ ] 4MB TMU test (= 12MB Voodoo2)
|
|
- [ ] TMU0 or TMU1 only*
|
|
- [ ] FBI to TMU1 fault
|
|
- [ ] FBI to TMU0 fault
|
|
- [ ] TMU1 to TMU0 fault
|
|
- [ ] TMU0 to FBI fault
|
|
- [ ] Documentation
|
|
- [ ] CLI help
|
|
- [ ] short youtube video
|
|
- [ ] Other
|
|
- [ ] Integration with Witchery ?
|
|
|
|
## TMU0 Memory test
|
|
|
|
Here is a simplified data flow diagram:
|
|
|
|
```
|
|
┌────────────┐ 3 ┌───────────┐
|
|
│ ┼─────► │
|
|
│ TMU0 │ │ TMU0 RAM │
|
|
│ ◄─────┼ │
|
|
└──▲───────┬─┘ └───────────┘
|
|
│ │ 4
|
|
│ │
|
|
2 │ │ 5
|
|
│ │
|
|
│ │
|
|
┌──┼───────▼─┐ 6 ┌───────────┐
|
|
│ ┼─────► │
|
|
│ FBI │ │ FBI RAM │
|
|
│ ◄─────┼ │
|
|
└──▲───────┬─┘ 7 └───────────┘
|
|
│ │
|
|
│ │
|
|
1 │ │ 7
|
|
│ │
|
|
│ │
|
|
┌──┼───────▼─┐
|
|
│ │
|
|
│ CPU │
|
|
│ │
|
|
└────────────┘
|
|
```
|
|
|
|
1. CPU configures texture base address and sends data to the FBI
|
|
2. The FBI streams the texture to TMU0
|
|
3. TMU0 writes the texture into his private memory
|
|
4. The CPU sends a request to TMU0 (through the FBI) to render a triangle using this texture (double the size triangle)
|
|
5. TMU0 streams the rendered pixels to the FBI
|
|
6. The FBI writes the pixel to the frame buffer
|
|
7. The CPU requests the pixels using the Linear Frame Buffer access
|
|
8. The CPU can compare the rendered value with the original texture
|
|
|
|
## TMU1 Memory test
|
|
|
|
Here is a simplified data flow diagram:
|
|
|
|
```
|
|
┌────────────┐
|
|
│ │
|
|
│ TMU1 RAM │
|
|
│ │
|
|
└──▲──────┬──┘
|
|
│ │
|
|
3 │ 4 ┼
|
|
│ │
|
|
┌──┼──────▼──┐ 5 ┌────────────┐
|
|
│ │ │ │
|
|
│ TMU1 ┼──────► TMU0 │
|
|
│ │ │ │
|
|
└── ──▲──────┘ └─────┬──────┘
|
|
│ │
|
|
2 │ 6 │
|
|
│ │
|
|
┌─────┼────────────────── ▼──────┐ 7 ┌───────────┐
|
|
│ ┼─────► │
|
|
│ FBI │ │ FBI RAM │
|
|
│ ◄─────┼ │
|
|
└──▲───────┬─────────────────────┘ 8 └───────────┘
|
|
│ │
|
|
1 │ │ 9
|
|
│ │
|
|
┌──┼───────▼─┐
|
|
│ │
|
|
│ CPU │
|
|
│ │
|
|
└────────────┘
|
|
```
|
|
|
|
0. CPU configures TM0 to simply passthrough incoming TMU1's pixel stream without modifications
|
|
1. CPU configures texture base address and sends data to the FBI
|
|
2. The FBI streams the texture to TMU1
|
|
3. TMU1 writes the texture into his private memory
|
|
4. The CPU sends a request to TMU1 (through the FBI) to render a triangle using this texture (double the size triangle)
|
|
5. TMU1 streams the rendered pixels to TMU0
|
|
6. TMU0 streams the rendered pixels to the FBI
|
|
7. The FBI writes the pixel to the frame buffer
|
|
8. The CPU requests the pixels using the Linear Frame Buffer access
|
|
9. The CPU can compare the rendered value with the original texture
|
|
|
|
## Accessing different memory regions
|
|
|
|
TBD
|
|
|
|
## Licence
|
|
|
|
**GPL-3.0-or-later** |