Hackaday Links: May 28, 2023

May 28, 2023 by Dan Maloney 20 Comments

The Great Automotive AM Radio War of 2023 rages on, with the news this week that Ford has capitulated, at least for now. You’ll recall that the opening salvo came when the US automaker declared that AM radio was unusable in their EV offerings thanks to interference generated by the motor controller. Rather than fixing the root problem, Ford decided to delete the AM option from their EV infotainment systems, while letting their rolling EMI generators just keep blasting out interference for everyone to enjoy. Lawmakers began rattling their sabers in response, threatening legislation to include AM radio in every vehicle as a matter of public safety. Ford saw the writing on the wall and reversed course, saying that AM is back for at least the 2024 model year, and that vehicles already delivered without it will get a fix via software update.

Continue reading “Hackaday Links: May 28, 2023” →

Adding Variometer Functionality To A GPS

May 25, 2023 by Bryan Cockfield 10 Comments

Flying a glider, or similarly piloting a paraglider or hang glider, can all be pathways into aviation with a lower barrier of entry than powered flight. Sacrificing one’s engine does generate a few complexities, but can be rewarding as the pilot searches for various means of increasing altitude like ridge soaring or thermaling. You’ll need a special instrument called a variometer to know just how much altitude you’re gaining though, like this one which is built into commercially-available handheld GPS units.

These GPS units are normally intended for use on terra firma only, but [Oganisyan] has figured out a clever way to add this flight instrumentation to these units to help when operating a paraglider. An ATmega328 paired with a pressure sensor is added to the inside of the GPS units and communicates with an available serial interface within the units. To complete the modification, a patched firmware must be installed which adds the variometer function to the display. This upgrade is compatible with a handful of GPS units as well such as the BikePilot2+ or Falk Tiger.

For those who already own one of these GPS units, this could be a cost-effective way of obtaining a variometer, especially since commercially-available variometers tailored for this sort of application can cost around $200 to $500. It is an activity sensitive to cost, though, as it offers a much more affordable option for taking to the skies than any powered craft could, with an exception made for this powered paraglider which offers the ability for powered take off and flight extension using electric-powered props.

Thanks to [MartinO] for the tip!

Getting The Most From Fading ThinkPads

April 21, 2023 by Bryan Cockfield 40 Comments

The ThinkPad line of laptops has been widely prized not only by businesses but also by those who appreciate a high standard of hardware quality and repairability. But some think the cracks are starting to form in their reputation, as it seems that new ThinkPads are sacrificing quality for aesthetics and cost. As a result a huge modding scene has popped up around models that are a few years old like [Cal] found out when working on this X230.

At first he only made some cosmetic improvements to the laptop like replacing the worn palm rest, but quickly found himself in a rabbit hole with other upgrades like swapping out the keyboard and battery. The new keyboard is a 7-row X220 keyboard, which required modification of the connector and flashing the embedded controller with a hacked image to change the keyboard map without needing to make changes at the OS level. From there, he decided to replace the lackluster screen with a 1920×1080 matte IPS panel using an adapter board from Nitrocaster, and finished off his upgrades with a customized Coreboot BIOS for improved performance and security.

While Coreboot doesn’t remove all of the binary blobs that a bootloader like libreboot does, the latter is not compatible with more modern machines like this X230. Still, you’ll get many benefits from using Coreboot instead of the stock bootloader. For running Linux on a daily driver laptop, we appreciate all of these updates and expect that [Cal] will get plenty of years of use out of his machine. We’ve definitely seen an active modding scene for ThinkPads that were (at the time) seven years old and still going strong, so we’d expect nothing less for this one.

Stadia Controller’s Two Extra Buttons Get Seen With WebHID

February 13, 2023 by Donald Papp 9 Comments

The Google Stadia game streaming service relied on a proprietary controller. It was a pretty neat piece of hardware that unfortunately looked destined for landfills when Google announced that Stadia would discontinue. Thankfully it’s possible to use them as normal gamepads, and related to that, [Thomas Steiner] has a developer blog post about how to talk to the Stadia controller via WebHID. Continue reading “Stadia Controller’s Two Extra Buttons Get Seen With WebHID” →

Who Is Thinking About Open Source Firmware?

May 14, 2022 by Elliot Williams 23 Comments

Yesterday, we ran a post on NVIDIA’s announcement of open-source drivers for some of its most recent video cards. And Hackaday being huge proponents of open-source software and hardware, you’d think we’d be pouring the champagne. But it’s trickier than that.

Part of the reason that they are able to publish a completely new, open-source driver is that the secrets that they’d like to keep have moved into the firmware. So is the system as a whole more or less open? Yeah, maybe both.

With a more open interface between the hardware and the operating system, the jobs of people porting the drivers to different architectures are going to be easier. Bugs that are in what is now the driver layer should get found and fixed faster. All of the usual open-source arguments apply. But at the same time, the system as a whole isn’t all that much more transparent. The irony about the new NVIDIA drivers is that we’ve been pushing them to be more open for decades, and they’ve responded by pushing their secrets off into firmware.

Secrets that move from software to firmware are still secrets, and even those among us who are the most staunch proponents of open source have closed hardware and firmware paths in our computers. Take the Intel Management Engine, a small computer inside your computer that’s running all the time — even while the computer is “off”. You’d like to audit the code for that? Sorry. And it’s not like it hasn’t had its fair share of security relevant bugs.

And the rabbit hole goes deeper, of course. No modern X86 chips actually run the X86 machine language instructions — instead they have a microcode interpreter that reads the machine language and interprets it to what the chip really speaks. This is tremendously handy because it means that chip vendors can work around silicon bugs by simple pushing out a firmware update. But this also means that your CPU is running a secret firmware layer at core. This layer is of course not without bugs, some of which can have security relevant implications.

This goes double for your smartphone, which is chock-full of multiple processors that work more or less together to get the job done. So while Android users live in a more open environment than their iOS brethren, when you start to look down at the firmware layer, everything is the same. The top layer of the OS is open, but it’s swimming on top of an ocean of binary blobs.

How relevant any of this is to you might depend on what you intend to do with the device. If you’re into open source because you like to hack on software, having open drivers is a fantastic resource. If you’re looking toward openness for the security guarantees it offers, well, you’re out of luck because you still have to trust the firmware blindly. And if you’re into open source because the bugs tend to be found quicker, it’s a mix — while the top level drivers are made more inspectable, other parts of the code are pushed deeper into obscurity. Maybe it’s time to start paying attention to open source firmware?

NVIDIA Releases Drivers With Openness Flavor

May 13, 2022 by Arya Voronova 27 Comments

This year, we’ve already seen sizeable leaks of NVIDIA source code, and a release of open-source drivers for NVIDIA Tegra. It seems NVIDIA decided to amp it up, and just released open-source GPU kernel modules for Linux. The GitHub link named open-gpu-kernel-modules has people rejoicing, and we are already testing the code out, making memes and speculating about the future. This driver is currently claimed to be experimental, only “production-ready” for datacenter cards – but you can already try it out!

The Driver’s Present State

Of course, there’s nuance. This is new code, and unrelated to the well-known proprietary driver. It will only work on cards starting from RTX 2000 and Quadro RTX series (aka Turing and onward). The good news is that performance is comparable to the closed-source driver, even at this point! A peculiarity of this project – a good portion of features that AMD and Intel drivers implement in Linux kernel are, instead, provided by a binary blob from inside the GPU. This blob runs on the GSP, which is a RISC-V core that’s only available on Turing GPUs and younger – hence the series limitation. Now, every GPU loads a piece of firmware, but this one’s hefty!

Barring that, this driver already provides more coherent integration into the Linux kernel, with massive benefits that will only increase going forward. Not everything’s open yet – NVIDIA’s userspace libraries and OpenGL, Vulkan, OpenCL and CUDA drivers remain closed, for now. Same goes for the old NVIDIA proprietary driver that, I’d guess, would be left to rot – fitting, as “leaving to rot” is what that driver has previously done to generations of old but perfectly usable cards. Continue reading “NVIDIA Releases Drivers With Openness Flavor” →

Reverse Engineering The SEGA Mega Drive

January 19, 2022 by Bryan Cockfield 16 Comments

With the widespread adoption of emulators, almost anyone can start playing video games from bygone eras. Some systems are even capable of supporting homebrew games, with several having active communities that are still creating new games even decades later. This ease of programming for non-PC platforms wasn’t always so easy, though. If you wanted to develop games on a now-antique console when it was still relatively new, you had to jump through a lot of hoops. [Tore] shows us how it would have been done with his Sega Mega Drive development kit that he built from scratch.

While [Tore] had an Atari ST, he wanted to do something a little more cutting edge and at the time there was nothing better than the Mega Drive (or the Genesis as it was known in North America). It had a number of features that lent the platform to development, namely the Motorola 68000 chip that was very common for the time and as a result had plenty of documentation available. He still needed to do quite a bit of reverse engineering of the system to get a proper dev board running, though, starting with figuring out how the cartridge system worked. He was able to build a memory bank that functioned as a re-writable game cartridge.

With the hard parts out of the way [Tore] set about building the glue logic, the startup firmware which interfaced with his Atari ST, and then of course wiring it all together. He was eventually able to get far enough along to send programs to the Mega Drive that would allow him to control sprites on a screen with the controller, but unfortunately he was interrupted before he could develop any complete games. The amount of research and work to get this far is incredible, though, and there may be some helpful nuggets for anyone in the homebrew Mega Drive community today. If you don’t want to get this deep into the Mega Drive hardware, though, you can build a cartridge that allows for development on native Sega hardware instead.