A Dedicated GPU For Your Favorite SBC

May 5, 2023 by Bryan Cockfield 35 Comments

The Raspberry Pi is famous for its low cost, versatile and open Linux environment, and plentiful I/O, making it a perfect device not only for its originally-intended educational purposes but for basically every hobbyist from gardeners to roboticists to amateur radio operators. Most builds tend to make use of the GPIO pins which allow easy connections to various peripherals and sensors, but the Pi also supports PCI devices which means that, in theory, it could use a GPU in much the same way that a modern computer would. After plenty of testing and development, [Jeff Geerling] brings us this custom graphics card interface for the Raspberry Pi.

The testing for all of these graphics cards has been done with a Pi Compute Module 4 and the end result is an interface device which looks much like a graphics card itself. It splits the PCI bus out onto a more familiar x16 slot connector and adds physical connections for power, USB, and Ethernet. When plugged into the carrier board, the Compute Module can be attached to any of a number of graphics cards, including the latest and highest-end of Nvidia and AMD offerings.

Perhaps unsurprisingly, though, the 4090 and 7900 cards don’t work with the Raspberry Pi. This is partially due to the 32-bit limitations of the Pi and other memory mapping issues, but even after attempting some workarounds Nvidia’s cards aren’t open-source enough to test properly (although the card is recognized by the Pi) and AMD’s drivers crash the system even after compiling a custom kernel. [Jeff] did find an Nvidia card that worked, although it requires using the USB interface and second-hand cards are selling for around $3000 USD. For a more economical choice there are some other graphics cards that he was eventually able to get working, albeit not with perfect performance, including some of the ones we’ve seen him test already.

Continue reading “A Dedicated GPU For Your Favorite SBC” →

35C3: Safe And Secure Drivers In High-Level Languages

December 31, 2018 by Sven Gregori 12 Comments

Writing device drivers is always a good start for a journey into the Linux kernel code. Of course, the kernel is a highly complex piece of software, and if you mess up your code properly, you might take down the entire system with you. User-space drivers on the other hand might not look as good on your CV, but they can help to work around some of the dangers and complexity of the kernel space. Plus, you don’t necessarily have to limit yourself to C to write them, especially if you are concerned about the usual C pitfalls and the security issues they can lead to.

With that in mind, [Paul Emmerich] is researching the concept of Linux user-space drivers for Intel’s 10Gbit network cards using other high-level languages, and recruits his students to write their final theses about the implementation details of as many languages as possible.

At last year’s 34c3, [Paul] already demonstrated the basics of writing such a user-space network driver for Linux, which serves now as reference implementation for his students. We won’t see Bash or JavaScript here, but we will see a brief summary of what it generally means to develop user-space drivers in C#, Swift, OCaml, or Haskell, along a more detailed insight from [Sebastian Voit] and [Simon Ellmann] about Go and Rust. A collection of each language’s implementation can be found on GitHub.

Since some of these languages bring their own memory handling and perform unpredictable garbage collection, performance and latency are two big topics to cover here. But then, the general concept is language-independent, so even if nothing in the world could ever make you give up on C, you might at least take away some new ideas for driver development.
Continue reading “35C3: Safe And Secure Drivers In High-Level Languages” →

Make The Surface Dial Do More Things, Such As MIDI

September 4, 2018 by Lewin Day 6 Comments

The Surface Dial is a $100+ rotary control. You can turn it, and it’ll make some basic stuff happen on your Microsoft Surface. It’s silver and sleek and elegant but fundamentally, it just works via emulated keyboard shortcuts. This doesn’t really do much for translating analog rotational motion into digital feedback in a nice way, so [SaveTheHuman5] created Elephant to fix this issue.

As standard, there are two ways to work with the Surface Dial as an end-user. The easiest way is to use existing utilities to map dial actions to shortcut keys. However, for interfacing with knobs and sliders in user interfaces, this is clunky. Instead, [SaveTheHuman5] drilled down and created their own utility using the Surface Dial API provided by Microsoft. This allows raw data to be captured from the dial and processed into whatever interactions your heart desires – as long as you’ve got the coding muscles to do it!

The Elephant software allows the knob to be used in two distinct modes – mouse capture, and MIDI. Mouse capture allows one to use a regular mouse to select UI objects, such as knobs in a music application, and then turn the Surface Dial to adjust the control. Anyone that’s struggled with tiny emulated rotary controls on a VST synth before would instantly know the value of this. In MIDI mode, however, the knob simply presents itself as a MIDI device outputting commands directly which would be more useful in performance environments in particular.

Overall, it’s a tidy hack of an otherwise quite limited piece of hardware – the only thing we’d like to see is more detail on how it was done. If you’ve got a good idea on how this could work, throw it down in the comments. And, if your thirst for rotary controls is still not satiated, check out this media controller. Video after the break.

Continue reading “Make The Surface Dial Do More Things, Such As MIDI” →

34C3: Roll Your Own Network Driver In Four Simple Steps

January 1, 2018 by Christian Trapp 7 Comments

Writing your own drivers is a special discipline. Drivers on the one hand work closely with external hardware and at the same time are deeply ingrained into the operating system. That’s two kinds of specialization in one problem. In recent years a lot of dedicated networking hardware is being replaced by software. [Paul Emmerich] is a researcher who works on improving the performance of these systems.

Making software act like network hardware requires drivers that can swiftly handle a lot of small packets, something that the standard APIs where not designed for. In his talk at this year’s Chaos Commnication Congress [Paul] dissects the different approaches to writing this special flavor of drivers and explains the shortcomings of each.

Continue reading “34C3: Roll Your Own Network Driver In Four Simple Steps” →

Rasperry Pi: Now Mostly Open Source

October 24, 2012 by Brian Benchoff 70 Comments

If you’ve been following the developments of building Android, Chromium, and other OSes for the Raspberry Pi, you’ll come across a common theme. The drivers for the Raspi’s chip are closed source and protected by Broadcom with an NDA. This limits the ability of devs to take on projects that involve messing around deep inside the CPU.

Today, this is no longer the case. The CPU on the Raspberry Pi is now the first ARM-based system with fully functional, vendor-provided drivers.

Previously, the drivers for OpenGL ES, OpenMax, and other goodies inside the ARM chip have been closed source, available only to the Raspberry Pi foundation and those willing to sign a non-disclosure agreement with Broadcom. With this release, the drivers are open source, allowing the devs behind the Android, Chromium, Haiku, *BSD, and the RISC OS to dig deep into the Broadcom drivers and get their projects working.

The new files are available in the Raspberry Pi git, just waiting for devs to take a look at it.

An Appeal To Microsoft To Consider The Hackers

June 7, 2012 by Mike Szczys 105 Comments

[PT] is climbing up on his soapbox again to make an appeal to Microsoft. We think his editorial is well-aimed; appealing for better support for hobby electronics in Windows 8.

This is of course not strictly a hobby electronics feature request, but deals with how a lot of USB devices are treated by the upcoming operating system. Specifically the Communications Device Class, which is a protocol used by most hobby projects (and boards like the Arduino) that take advantage of the Universal Serial Bus. The way communications are handled by OSX and Linux makes this a snap, but not with Windows 7. [Phil] post specifics about how the former two operating systems handle these communications, and how Windows 8 could be tweaked to fall in line with them.

It means not installing drivers. Drivers…. for a USB device. Think about that for a while and then ask yourself which decade Windows 8 is being developed in. Thanks for pointing this out [PT]. We often get spoiled using a Linux box and don’t realize the hassles sometimes found on other systems.

Grinding Down Your Computer To Just 8.5 Watts

February 8, 2011 by Mike Szczys 24 Comments

What can you do to make sure your system is running as efficiently as possible? Take a page out of [Mux’s] book, who went to great lengths to measure and adjust his system for ultimate efficiency (translated). What he ended up with is 8.5 Watts of consumption at idle and about 50 Watts under load. Luckily he posted a six-part series with all of the details.

Some of the changes he made were in software, like reducing voltage to certain hardware by adjusting BIOS settings, and installing display drivers that put the screen into the proper sleep mode. Others were hardware changes like swapping out the power supply with a hacked PicoPSU and removing unnecessary parts from the motherboard like the MAX232 com-port chip. Looks like we need to audit our always-on MythTV box and see if we can apply any of these power-saving techniques.

[Thanks Gijs]