Hardware · 14 min read · updated August 2026
Identifying Xbox 360 motherboard revisions without guessing
Most “what board is this?” threads still start with a photo of a closed Slim. That is the wrong first question. Chassis generation gets you in the neighborhood. The NAND package, HDMI port, RF board, and Southbridge family tell you whether RGH3 is even on the table, whether you are holding a Corona 4GB, or whether the only 2026 path is Bad Update on dashboard 17559.
Start from the outside, then confirm inside
Phat Falcons and Jaspers still hide under original white or black shells. Xenon and Zephyr are the oldest living-room bricks: no HDMI on Xenon, early HDMI on Zephyr, and a different RGH conversation than a 2011 Trinity. Jasper is the last Phat a lot of techs still like: HDMI, better GPU luck than Xenon, and RGH3 or older glitch methods depending on the exact flavor (Jasper 16MB, Jasper 256MB, or the rare big-block layouts people still argue about in J-Runner).
Trinity Slims (2010) have HDMI, a 16MB NAND, and are the poster child for clean RGH3. Coronas share the Slim shell but the board is a different animal: Hynix or Samsung NAND, different POST, and a 4GB SKU that is not interchangeable in software with the 16MB cousin. Waitsburg and Stingray show up in late Slim / early E discussions; treat them as Corona-family unless silkscreen and NAND say otherwise. Winchester — including most Xbox 360 E units — looks like a late Slim until you read the board. If you are hunting persistent RGH work, Winchester is the stop sign.
Microsoft reused shells. I have seen Trinity stickers on Corona boards and the reverse. Believe the silicon. Open the RF shield, look at the NAND package, and only then open J-Runner with Extras or PicoFlasher.
Revision chart I actually use
| Board | Typical shell | Persistent glitch | Bad Update 17559 | Notes |
|---|---|---|---|---|
| Xenon / Zephyr | Phat | Specialist RGH / EXT_CLK territory | Yes, if on 17559 | HDMI-less Xenon is its own repair desk |
| Falcon | Phat | RGH family | Yes | Still common in lots |
| Jasper | Phat HDMI | RGH3 / RGH1.2 | Yes | 16MB vs larger NAND SKUs |
| Trinity | Slim 2010 | RGH3 favorite | Yes | 16MB NAND, clean HDMI |
| Corona 16MB | Slim | RGH3 with correct wiring | Yes | Do not flash 4GB images |
| Corona 4GB | Slim 4GB SKU | RGH3 + 4GB dump workflow | Yes | eMMC; PicoFlasher fork required |
| Winchester | Late Slim / E | None public | Yes | Software exploit only |
Visual tells I trust
- Trinity: 16MB NAND, no 4GB eMMC module, Slim HDMI layout, RGH3-friendly.
- Corona 16MB: similar Slim, different NAND footprint, RGH3-friendly with the right POST/CPU_RST wiring.
- Corona 4GB: extra eMMC, dump workflow changes, easy to mis-ID if you only look at the Wi-Fi module.
- Jasper: last “easy” Phat for many techs; confirm 16MB versus the SKUs that confuse xeBuild.
- Winchester: missing the glitch-friendly points people expect from Corona; E-model faceplate is a hint, not proof.
HDMI sparkles on Corona are usually the analog/HDMI encoder path, not a “bad dump.” Do not diagnose picture noise as a NAND problem until the board ID is done. Likewise, a console that runs XeXMenu after Bad Update is not proof you identified a Trinity. Bad Update does not care which board you have as long as the dashboard is 17559 and the Rock Band Blitz path is intact.
Winchester is not a failed RGH3, it is a different product
I still open Winchester units when a customer insists, then I send the console back unmodified for glitch work. There is no honest Ace V3, Coolrunner, Matrix, or RGH3 diagram I will put my name on for Winchester. The 2024–2026 answer for those boxes is the grimdoomer Bad Update hypervisor exploit, usually paired with XeUnshackle or FreeMyXe so Dashlaunch-like patches exist for the session. That is homebrew. It is not a persistent xeBuild NAND. Do not promise Aurora-on-cold-boot the way you would on a Trinity RGH3.
Why this matters before you flash anything
Wrong board identification is how people write a Trinity ECC to a Corona and then spend a weekend blaming J-Runner with Extras. Identify, dump with PicoFlasher or xFlasher, then decide method: RGH3, leftover RGH1.2 on a chip, JTAG/R-JTOP on ancient kernels, or Bad Update only. Timing files, Glitch2 versus Glitch2m, eFuse virtualization, and kv.bin placement all come later. If you skip identification, every later step is folklore — including CPU key reads from XeLL Reloaded that never appear because you wrote the wrong first 50 blocks.
Next: how Corona 4GB dumps differ, including SPI PicoFlasher forks and where the KeyVault lives after you pull the image. Then the comparison every 2026 search wants: Bad Update 1.3 versus RGH3.