media.ccc.de
4 HN recommenders · recommended in 7 months, 2017–2024
53:44 · 166K views · Dec 28, 2016
A 33c3 talk by marcan on reverse engineering the PS4 hardware to run Linux with 3D acceleration. It covers how the console differs from a PC and includes a story about tunneling PCIe over RS-232.
Recommended as an approachable, detailed look at console hardware architecture, FreeBSD in the PS4 and console hacking.
9 comments from Hacker News
This is a good watch, it goes into detail on the architecture of the PS4 showing how it differs from a standard x86_64 “PC.” this video The “too long; didn’t watch” summary is that there’s several peripherals, timers, RTC, etc outside of the processor that software will expect to be present (or at least emulated) with specific interfaces. You can implement x86_64 without a lot of this, or redone in a more modern style, but software such as a Linux kernel will have to be patched for it. Typically a modern laptop will have all the legacy peripherals emulated, and the modern peripherals will live alongside them.
The key is on the console (not server side). Historically either they made some silly choices or there was a hardware bug or glitch that let you read out the key that the processor has to be able to access to decrypt the firmware. Search YouTube for fail0verflow and there are some great CCC talks very approachable and understandable about how it was done on other consoles historically. PS4: this video Wii U: [LINK]
While the CPU is indeed x86-64, the architecture of the SoC and the device is rather different so emulation still won't be all that easy. This 33c3 talk gives a lot of fascinating information on how PS4 differs from your run-of-the-mill PC and what kind of issues they hit when trying to run Linux on it: this video
`It's interesting to note that the PS4 OS is also a forked FreeBSD variant as well.` Here's a nice talk at CCC last year which explains some bits of FreeBSD in the PS4. It's mostly about hardware and how to run Linux on it, but FreeBSD gets a nice mention there too. this video
PCIe is also packet-based BTW [1]. The benefit from the custom protocol is being able to run PCIe and DisplayPort (and I guess networking which no one cares about) over the same cable at the same time with dynamic bandwidth allocation. USB-C has alternate modes but they're not as powerful. In theory PCIe alternate mode over USB-C should be possible and it would be much simpler than Thunderbolt but nobody has tried to build it. I imagine the spec doesn't really exist because Intel has been too lazy to properly write it (I wouldn't be surprised if Thunderbolt is basically defined as whatever the original Ridge controller implemented) and it's probably also gross. Adoption seems to be limited by cost, not by secrecy (thinking back to Firewire, it was open but there were very few controller chips for it). [1] Check out PCIe over RS-232: this video