It used to be that to play a console game, you just had to plug in a cartridge or put a CD/DVD in the optical drive. But these days, with modern titles ballooning up to as much as 100 GB, you’ve got no choice but to store them on the system’s internal hard disk drive. While that can lead to some uncomfortable data management decisions, at least it means you don’t have to get up off the couch to switch games anymore.
Which is precisely why the MC2SIO project for the PlayStation 2 is so exciting. As [Tito] explains in his latest Macho Nacho Productions video, this simple adapter lets you connect an SD card up to the console’s Memory Card slots and use that to hold ISOs of your favorite games. With the appropriate homebrew software loaded up, your PS2 becomes a veritable jukebox of classic games.
Sometimes reverse engineering embedded systems can be a right old faff, with you needing to resort to all kinds of tricks such as power glitching in order to poke a tiny hole in the armour, giving you an way in. And, sometimes the door is just plain wide open. This detailed exploration of an off-the-shelf retro arcade machine, is definitely in that second camp, for an unknown reason. [Matthew Alt] of VoidStar Security, took a detailed look into how this unit works, which reads as a great introduction to how embedded Linux is constructed on these minimal systems.
Could this debug serial port be more obvious?
The hardware is the usual bartop cabinet, with dual controls and an LCD display, with just enough inside a metal enclosure to drive the show. Inside this, the main PCB has the expected minimal ARM-based application processor with its supporting circuit. The processor is the Rockchip RK3128, sporting a quad-core ARM Neon and a Mali400 GPU, but the main selling point is the excellent Linux support. You’ll likely see this chip or its relatives powering cheap Android TV boxes, and it’s the core of this nice looking ‘mini PC’ platform from firefly. Maybe something to consider seeing as though Raspberry Pis are currently so hard to come by?
Anyway, we digress a little, [Matthew] breaks it down for us in a very methodical way, first by identifying the main ICs and downloading the appropriate datasheets. Next he moves on to connectors, locating an internal non-user-facing USB micro port, which is definitely going to be of interest. Finally, the rather obvious un-populated 3-pin header is clearly identified as a serial port. This was captured using a Saleae clone, to verify it indeed was a UART interface and measure the baud rate. After doing that, he hooked it into a Raspberry Pi UART and by attaching the standard screen utility to the serial device, lo-and-behold, a boot log and a root prompt! This thing really is barn-door wide-open.
Is that a root prompt you have for me? Oh why yes it is!
Simply by plugging in a USB stick, the entire flash memory was copied over, partitions and all, giving a full backup in case subsequent hacking messed things up. Being based on U-Boot, it was a trivial matter of just keying in ‘Ctrl-C’ at boot time, and he was dropped straight into the U-Boot command line, and all configuration could be easily read out. By using U-Boot to low-level dump the SPI flash to an external USB device, via a RAM copy, he proved he could do the reverse and write the same image back to flash without breaking something, so it was now possible to reverse engineer the software, make changes and write it back. Automation of the process was done using Depthcharge on the Raspberry Pi, which was also good to read about. We will keep an eye on the blog for what he does with it next!
We’ve gotten used to the GPIO-available functions of Raspberry Pi computers remaining largely the same over the years, which is why it might have flown a little bit under the radar: the Raspberry Pi 4 has six SPI controllers, six I2C controllers, and six UARTs – all on its 40-pin header. You can’t make use of all of these at once, but with up to four different connections wired to a single pin you can carve out a pretty powerful combination of peripherals for your next robotics, automation or cat herding project.
The datasheet for these peripherals is pleasant to go through, with all the register maps nicely laid out – even if you don’t plan to work with the register mappings yourself, the maintainers of your preferred hardware enablement libraries will have an easier time! And, of course, these peripherals are present on the Compute Module 4, too. It might feel like such a deluge of interfaces is excessive, however, it lets you achieve some pretty cool stuff that wouldn’t be possible otherwise.
Having multiple I2C interfaces helps deal with various I2C-specific problems, such as address conflicts, throughput issues, and mixing devices that support different maximum speeds, which means you no longer need fancy mux chips to run five low-resolution Melexis thermal camera sensors at once. (Oh, and the I2C clock stretching bug has been fixed!) SPI interfaces are used for devices with high bandwidth, and with a few separate SPI ports, you could run multiple relatively high-resolution displays at once, No-Nixie Nixie clock style.
As for UARTs, the Raspberry Pi’s one-and-a-half UART interface has long been an issue in robotics and home automation applications. With a slew of devices like radio receivers/transmitters, LIDARs and resilient RS485 multi-drop interfaces available in UART form, it’s nice that you no longer have to sacrifice Bluetooth or a debug console to get some fancy sensors wired up to your robot’s brain. You can enable up to six UARTs. Continue reading “Did You Know That The Raspberry Pi 4 Has More SPI, I2C, UART Ports?”→
You could argue that the project to add a round screen to a Raspberry Pi from [YamS1] isn’t strictly necessary. After all, you could use a square display with a mask around it, giving up some screen real estate for aesthetics. However, you’d still have a square shape around the screen and there’s something eye-catching about a small round screen for a watch, an indicator, or — as in this project — a talking head.
The inspiration for the project was a quote from a Google quote about teaching a monkey to recite Shakespeare. A 3D printed monkey with a video head would be hard to do well with a rectangular screen, you have to admit. Possible with a little artistry, we are sure, but the round head effect is hard to beat. Honestly, it looks more like an ape to us, but we aren’t primate experts and we think most people would get the idea.
Imagine you’re sending a piece of hardware to space on a satellite. Unless you’re buddy-buddy with NASA, it’s pretty unlikely you’ll ever be able to head up there and fix something if it goes wrong once it’s launched. Robust design is key, so that even in the event of a failure in one component, the rest of the hardware can keep working.
The example I2C isolation circuit from [Max’s] paper. The SPI implementation is even simpler.[Max Holliday] found himself in this exact situation, running 69 I2C and SPI devices in a single satellite. Thus, he came up with circuits to auto-isolate devices from these buses in the event of an issue. That work is the subject of a research paper now available on the TechRxiv Preprint Server.
The problem is that these simple buses aren’t always the most robust, being vulnerable to single-point failures where one bad part takes down other parts of the bus. [Max] notes that vast numbers of sensors and devices rely on these standards, and it can be difficult or prohibitively expensive to design without them, so a solution was needed.
To fix this, [Max] developed a simple external circuit that could be placed on each node of a I2C or SPI communication bus. In the event of malfunction, that node can be cut off from the bus by this circuit, allowing the rest of the system to go on functioning.
With little more than a few transistors, MOSFETs and passives, you too could protect your buses from malfunctions using these techniques. [Max] did just that on the NASA V-R3x mission which flew successfully in January 2021 if you needed any further confirmation of the value of this technique.
It’s something that won’t bother the home hobbyist building a garage door opener, but it could be of great value to those designing systems that must fail gracefully if they fail at all. Be sure to share your best tips and tricks for robust SPI and I2C buses in the comments below!
With the prevalence of libraries, it has never been easier to communicate with hundreds of different sensors, displays, and submodules. But what is really happening when you type SPI.begin() into the Arduino IDE? In his most recent video, [Ben Eater] explores the Serial Peripheral Interface (SPI) and how it really works.
Most Hackaday readers probably know [Ben] from his breadboard-based computers, such as the 6502 build we featured in 2019. Since then he has been hard at work, adding new and interesting additions to his breadboard computer, as well as diving into different communication protocols to better understand and implement them. For this video, [Ben] set the goal of connecting the BME280, a common pressure, temperature, and humidity sensor with an SPI interface, to his breadboard 6502 computer. Along the way, [Ben] discusses how exactly SPI works, and why there is so much conflicting nomenclature and operations when looking at different SPI devices.
Embedded Linux devices are everywhere these days, and sooner or later, you’re going to want to poke around in one of them. But how? That’s where posts like this one from [Felipe Astroza] come in. While his work is focused on the Foscam C1 security camera, the techniques and tools he outlines here will work on all sorts of gadgets that have a tiny penguin at their core.
Rather than trying to go in through the front door, [Felipe] starts his assault with the nuclear option: removing the SPI MX25L12835F flash chip from the camera’s PCB and dumping its contents with a Raspberry Pi. From there he walks through the use of different tools to determine the partition scheme of the chip and eventually extract passwords and other interesting bits of information from the various file systems within.
Getting ready to remove the flash chip.
That alone would be worth the read, but things really get interesting once [Felipe] discovers the FirmwareUpgrade program. Since the Foscam’s software updates are encrypted, he reasons that reverse engineering this binary would uncover the key and allow for the creation of custom firmware images that can be flashed through the stock interface.
Further investigation with Ghidra and friends identifies an interesting shared library linked to the executable in question, which is then disassembled in an effort to figure out how the key is being obfuscated. We won’t ruin the surprise, but [Felipe] eventually gets what he’s after.
