Merge branch 'master' of https://chacha.ddns.net/gitea/chacha/V2TMUMemTester.git
This commit is contained in:
chacha
439
Readme.md
439
Readme.md
@@ -1,214 +1,227 @@
|
||||
---
|
||||
include_toc: true
|
||||
---
|
||||
# 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 !
|
||||
|
||||
## 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
|
||||
- [ ] Chore (might never be done...)
|
||||
- [ ] use fixed size types (***e.g. FxUINT32 or uint32_t instead of unsigned long***)
|
||||
- [ ] port / test on more modern build system
|
||||
- [ ] port to Windows or DOS
|
||||
- [ ] better Makefile
|
||||
- [ ] Gitea / Jenkins CI
|
||||
- [ ] 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
|
||||
- [ ] better explanation on how memory is accessed
|
||||
- [ ] Other / Ideas
|
||||
- [ ] integration with (or in) 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
|
||||
|
||||
---
|
||||
include_toc: true
|
||||
---
|
||||
# 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 !
|
||||
|
||||
## 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
|
||||
- [ ] autonomous test delivery (.exe or iso)
|
||||
- [ ] Chore (might never be done...)
|
||||
- [ ] use fixed size types (***e.g. FxUINT32 or uint32_t instead of unsigned long***)
|
||||
- [ ] port / test on more modern build system
|
||||
- [ ] port to Windows or DOS
|
||||
- [ ] better Makefile
|
||||
- [X] Gitea / Jenkins CI
|
||||
- [ ] Validation
|
||||
- [ ] test with debian standard glide drivers
|
||||
- [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
|
||||
- [ ] better explanation on how memory is accessed
|
||||
- [ ] Other / Ideas
|
||||
- [ ] integration with (or in) 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
|
||||
|
||||
## Note on driver aspect
|
||||
|
||||
This tool requires access to low level registers / structures that are not exposed from outside Glide drivers.
|
||||
|
||||
For this reason, it is compiled using driver-internal headers.
|
||||
|
||||
The used driver and the requires headers has bee copied here.
|
||||
|
||||
It is possible that this tool will only work with the driver it is build accross.
|
||||
|
||||
## Licence
|
||||
|
||||
**GPL-3.0-or-later**
|
||||
Reference in New Issue
Block a user