The Raspberry Pi platform grows more capable and powerful with each iteration. With that said, they’re still not the go-to for high powered computing, and their external interfaces are limited for reasons of cost and scope. Despite this, people like [Jeff Geerling] strive to push the platform to its limits on a regular basis. Unfortunately, [Jeff’s] recent experiments with GPUs hit a hard stop that he’s as yet unable to overcome.
With the release of the new Compute Module 4, the Raspberry Pi ecosystem now has a device that has a PCI-Express 2.0 1x interface as stock. This lead to many questioning whether or not GPUs could be used with the hardware. [Jeff] was determined to find out, buying a pair of older ATI and NVIDIA GPUs to play with.
Immediate results were underwhelming, with no output whatsoever after plugging the modules in. Of course, [Jeff] didn’t expect things to be plug and play, so dug into the kernel messages to find out where the problems lay. The first problem was the Pi’s limited Base Address Space; GPUs need a significant chunk of memory allocated in the BAR to work. With the CM4’s BAR expanded from 64MB to 1GB, the cards appeared to be properly recognised and ARM drivers were able to be installed.
Alas, the story ends for now without success. Both NVIDIA and ATI drivers failed to properly initialise the cards. The latter driver throws an error due to the Raspberry Pi failing to account for the I/O BAR space, a legacy x86 feature, however others suggest the problem may lay elsewhere. While [Jeff] may not have pulled off the feat yet, he got close, and we suspect with a little more work the community will find a solution. Given ARM drivers exist for these GPUs, we’re sure it’s just a matter of time.
For more of a breakdown on the Compute Module 4, check out our comprehensive article. Video after the break.
Continue reading “Trying (And Failing) To Use GPUs With The Compute Module 4”
Minecraft is a game about exploring procedure-generated worlds. Each world is generated from a particular “seed” value, and sharing this seed value allows others to generate the same world in their own game. Recently, the distributed computing project Minecraft@Home set about trying to find the seed value of the world shown in the Minecraft title screen, and have succeeded in their goal.
The amount of work required to complete this task should not be underestimated. 137 users contributed 181 hosts with 231 GPUs to the effort, finding a solution in under 24 hours. The list of contributors to the project is a long one. It appears the method to find the seed involved comparing screenshots from various seed worlds to the original image. This took a lot of reverse engineering in order to calculate the camera FOV and other settings of the original capture, such that the results could be compared accurately. Interestingly, the group found two seeds that can generate the requisite world, suggesting the world generator code has some collisions between seed values.
We’re not sure what’s more astounding, the amount of work that went into the project, or that there’s a distributed computing project tackling advanced Minecraft research. Either way, we’re no strangers to Minecraft hacks around these parts. Video after the break. Continue reading “Finding The Random Seed Of Minecraft’s Title Screen”
On some 2011 Macbook Pro models, there is a tendency for the Radeon GPU to fail. This should mean game over for the computer, but surprisingly salvation is offered by its having not one but two GPUs on board. The Intel processor also has a GPU, and Apple use a pile of logic in an FPGA to switch at will between them. The community have produced fresh FPGA code to revive a dead Mac on its Intel GPU, but at the expense of losing brightness control. [Ayilm1] has brought back the brightness with a clever BGA reworking hack that gains access to a brightness control line present on the Intel BD82HM65 Platform Controller Hub chip but not used in the Macbook.
We’re used to impressive soldering work here at Hackaday, and we’ve seen our share of wiring direct to the balls on an upturned BGA chip. This is a similar idea but at another level, as a section of the top insulation on an in-place BGA is removed to expose the microvia above the ball carrying the required signal. A tiny wire is soldered to the exposed pad and taken to a piece of copper tape stuck down to provide mechanical strength, and a piece of enameled copper wire is run from that to the other side of the PCB where lies its destination. It comes with FPGA code to take advantage of it, but even for non-Macbook owners, it’s an extremely impressive piece of work. It’s not the first fine-soldering Macbook fix we’ve seen, either.
Thanks [lightpink784] for the tip.
The Hackaday community has answered the call and put their computers put to work folding proteins found in the coronavirus. Team_Hack-a-Day ranks #44 in the world so far this month, and I’ve seen us rank as high as #19 on 24-hour leaderboards.
Want to join the fight? Donate some of those computing cycles you’re not using to battling SARS‑CoV‑2. You’re probably not an epidemiologist or a vaccine researcher, but you can make their jobs easier by providing them with the data they need through the Folding@home Project.
As Dan Maloney explained in his excellent article on protein folding, understanding the incredibly complex folding behavior of the proteins in the virus will be key to finding treatments and possibly a vaccine. Folding@home connects countless computers via the internet and is now the largest supercomputer in the world, consisting of over 3.5 million CPUs and over half a million GPUs. The resulting data is freely available to researchers.
Let’s take a look at how easy it is to get up and running, how a GPU can supercharge a setup, and dip into the stats for Team_Hack-a-Day’s effort.
Continue reading “Help Us Throw More Cycles At The Coronavirus Problem”
Another week, another exploit against an air-gapped computer. And this time, the attack is particularly clever and pernicious: turning a GPU into a radio transmitter.
The first part of [Mikhail Davidov] and [Baron Oldenburg]’s article is a review of some of the basics of exploring the RF emissions of computers using software-defined radio (SDR) dongles. Most readers can safely skip ahead a bit to section 9, which gets into the process they used to sniff for potentially compromising RF leaks from an air-gapped test computer. After finding a few weak signals in the gigahertz range and dismissing them as attack vectors due to their limited penetration potential, they settled in on the GPU card, a Radeon Pro WX3100, and specifically on the power management features of its ATI chipset.
With a GPU benchmarking program running, they switched the graphics card shader clock between its two lowest power settings, which produced a strong signal on the SDR waterfall at 428 MHz. They were able to receive this signal up to 50 feet (15 meters) away, perhaps to the annoyance of nearby hams as this is plunk in the middle of the 70-cm band. This is theoretically enough to exfiltrate data, but at a painfully low bitrate. So they improved the exploit by forcing the CPU driver to vary the shader clock frequency in one megahertz steps, allowing them to implement higher throughput encoding schemes. You can hear the change in signal caused by different graphics being displayed in the video below; one doesn’t need much imagination to see how malware could leverage this to exfiltrate pretty much anything on the computer.
It’s a fascinating hack, and hats off to [Davidov] and [Oldenburg] for revealing this weakness. We’ll have to throw this on the pile with all the other side-channel attacks [Samy Kamkar] covered in his 2019 Supercon talk.
Continue reading “GPU Turned Into Radio Transmitter To Defeat Air-Gapped PC”
There was a time when running a program on an array of processors meant that you worked in some high-powered lab somewhere. Now your computer probably has plenty of processors hiding in its GPU and if you have an FPGA, you have everything you need to make something custom. The idea behind TornadoVM is to modify OpenJDK and GraalVM to support running some Java code on parallel architectures supported by OpenCL. The system can utilize multi-core CPUs, GPUs (NVIDIA and AMD), Intel integrated GPUs, and Intel FPGAs.
If you want to try your hand at accelerated Java, there are some docker containers to get you started fast. There’ are also quite a few examples, such as a computer vision application.
Continue reading “Java On GPUs And FPGAs”
A single board computer on a desk is fine for quick demos but for taking it into the wild (or even the rest of the house) you’re going to want a little more safety from debris, ESD, and drops. As SBCs get more useful this becomes an increasingly relevant problem to solve, plus a slick enclosure can be the difference between a nice benchtop hack and something that looks ready to sell as a product. [Chris] (as ProjectSBC) has been working on a series of adaptable cases called the MagClick Case System for the LattePanda Alpha SBC which are definitely worth a look.
The LattePanda Alpha isn’t a run-of-the-mill SBC; it’s essentially the mainboard from a low power ultrabook and contains up to an Intel Core M series processor, 8GB RAM, and 64GB of eMMC. Not to mention an onboard Atmega32u4, WiFi, Gigabit Ethernet, and more. It has more than enough horsepower to be used as an everyday desktop computer or even a light gaming system if you break PCIe out of one the m.2 card slots. But [Chris] realized that such adaptability was becoming a pain as he had to move it from case-to-case as his use needs changed. Thus the MagClick Case System was born.
Continue reading “Magnets Make This Panda Move”