NVIDIA Releases Drivers With Openness Flavor

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”

Section from the ESP8266 datasheet, showing maximum input voltage as 3.6V, but not mentioning ESD diodes to VCC and only talking about a snap-back circuit set to 6V.

Is ESP8266 5 V Tolerant? This Curve Tracer Says Yes!

Some people state that ESP8266 is tolerant of 5 V logic levels on its GPIOs, while others vehemently disagree, pointing at the datasheet-stated 3.6 V maximum. Datasheets aren’t source code for compiling the chip, however, and aren’t universally correct and complete either. [Avian] decided to dig deeper into the claims, conduct an experiment with an actual ESP8266 chip, then share the results for all of us.

For the experiment, he used a curve tracer – a device capable of producing a wide range of voltages and measuring the current being consumed, then plotting the voltage-to-current relationship. This helps characterize all sorts of variables, from diode breakdown voltages to transistor characteristics. The curve tracer he uses is a capable and professional-looking DIY build of his, and arguably, deserves a separate write-up!

The reasoning behind [Avian]’s experiment is simple – if the pin, set to an input, starts consuming a higher amount of current at a certain voltage threshold, then there’s gotta be some chip-internal structure, intended or unintended, that would be damaged at this voltage. Curve tracer in hand, he set up an ESP-01 module to set a GPIO to input, and started increasing the voltage.

A curve tracer output graph, showing that there's no noticeable increase of current consumed across the range of 0V to 6.6V - current increasing from 0.2mA to 0.4mA in that range

The tests have shown that, while there’s a reverse biased ESD diode from GPIO pins to ground, there don’t seem to be diodes from the GPIO pin to the VCC rail – and those are the primary concern for 5 V tolerance. There does seem to be something functionally akin to a 6 V Zener diode internally, which should clamp the voltage before it gets too way high for the chip to handle. None of that should be a problem for 5 V compatibility, and it seems fair to interpret this as a confirmation of 5 V tolerance until someone shows otherwise.

[Avian] didn’t want to destroy an ESP8266, so the experiment was conducted with a 1 K series resistor between the curve tracer and the input – which might have biased the results a bit. On the other hand, adding series resistors in front of your inputs is an overall underappreciated practice, 5 V or otherwise. He also points out that, while the pins don’t seem to be adversely impacted by the higher input voltage, the bootloader might set some of them to 3.3 V outputs on boot-up, shorting your 5 V source to your 3.3 V rail — worth keeping in mind!

[Avian]’s research journeys are fun to follow, and we recommend you check his blog out; last time, we covered his research of an innocent-looking 3.5 mm jack hiding a devious audio compensation circuit. Since we first covered the ESP8266 in 2014, we’ve been researching all the things it’s really capable of, and we brought up the topic of GPIO 5 V compatibility way back in 2016 – it’s reassuring to finally put this question to rest!

We thank [Adrian] for sharing this with us!

A vape pen, broken into parts, all laid out on a cutting mat

2022 Hackaday Prize: Disposable Vape Pens Turned Project Parts

Disposable vape pens, a sub-genre of electronic cigarettes, have been a fad for a few years now – they’re small self-contained devices with a rechargeable battery and some vape liquid inside. As the battery discharges and the liquid runs out, the entire vape pen is typically thrown out. [Dimitar] wants to change that, however, and teaches us how to reuse as much of the vape pen as possible — as yet another underappreciated source for parts we can use in our projects.

In an extensive worklog, he breaks down and documents a vape pen’s inner workings, coupled with a video we’ve placed below the break showing ways to disassemble them. In these, he shows how we can reuse the casing and the plastic parts, should any of us be interested in a project that happens to fit the e-cig form factor. Attention is paid to the sensor that triggers the evaporation — it may look like a microphone, but is actually a purpose-built pressure-sensor with a high-side switch! He tears into one of these in a separate video, showing how to reuse it as a capacitive touch controller. He also aiming to assemble a small database of related resources on GitHub, currently, hosting the files for the protection circuit he developed as part of his recommendations for safely reusing vape pen Li-ion batteries.

[Dimitar]’s journey is ongoing, and we can’t wait to see some fun uses for these components that he will certainly stumble upon on his way! For instance, here’s a hacker using an e-cig battery to power a pair of RGB LED-adorned sunglasses, replacing the AAAA battery they originally came with. We’ve seen hackers make guides on reusing each and every part of microwave ovens, printers and laptops, and we ourselves have talked about reusing ATX power supplies and computer mice.

Continue reading “2022 Hackaday Prize: Disposable Vape Pens Turned Project Parts”

Photo of the spectrophotometer in question, with a screenshot of the decoding software on the right

Exporting Data From Old Gear Through LCD Sniffing

[Jure Spiler] was at a flea market and got himself a spectrophotometer — a device that measures absorbance and transmittance of light at different wavelengths. This particular model seems to be about 25 years old, and it’s controlled by a built-in keyboard and uses a graphical LCD to display collected data. That might have been acceptable when it was made, but it wasn’t enough for [Jure]. Since he wanted to plot the spectrophotometry data and be able to save it into a CSV file, hacking ensued.

He decided to tap into the the display communication lines. This 128×64 graphical display, PC-1206B, uses a 8-bit interface, so with a 16-channel logic analyzer, he could see the data being sent to the display. He even wrote decoder software – taking CSV files from the logic analyzer and using primitive optical recognition on the decoded pixels to determine the digits being shown, and drawing a nice wavelength to absorbance graph. From there, he set out to make a standalone device sniffing the data bus and creating a stream of data he could send to a computer for storage and processing.

[Jure] stumbled into a roadblock, however, when he tried to use an Arduino for this task. Even using a sped-up GPIO library (as opposed to notoriously inefficient digitalRead), he couldn’t get a readout frequency higher than 80 KHz – with the required IO readout rate deemed as 1 MHz, something else would be called for. We do wonder if something like RP2040 with its PIO machinery would be better for making such captures.

At that point, however, he found out that there’s undocumented serial output on one of the pins of the spectrophotometer’s expansion port, and is currently investigating that, having shelved the LCD sniffing direction. Nevertheless, this serves as yet another example for us, for those times when an LCD connection is all that we can make use of.

We’ve seen hackers sniff LCD interfaces to get data from reflow ovens, take screenshots from Game Boys and even equip them with HDMI and VGA ports afterwards. With a skill like this, you can even give a new life to a vintage calculator with a decayed display! Got an LCD-equipped device but unsure about which specific controller it uses? We’ve talked about that!

Continue reading “Exporting Data From Old Gear Through LCD Sniffing”

The TPM module that Viktor designed, inserted into the motherboard

TPM Module Too Expensive? DIY Your Own Easily!

Since Windows 11 has announced its TPM module requirement, the prices for previously abundant and underappreciated TPM add-on boards for PC motherboards have skyrocketed. We’ve been getting chips and soldering them onto boards of our own design, instead – and [viktor]’s project is one more example of that. [Viktor] has checked online marketplace listings for a TPM module for his Gigabyte AORUS GAMING 3 motherboard, and found out they started at around 150EUR – which is almost as much as the motherboard itself costs. So, as any self-respecting hacker, he went the DIY way, and it went with hardly a hitch.

Following the schematic from the datasheet, he quickly made a simple KiCad layout, matching it to the pinout from his motherboard’s user manual, then ordered the boards from PCBWay and SLB9665 chips from eBay. After both arrived, [viktor] assembled the boards, and found one small mistake – he designed a module for 2.54mm pin headers, but his motherboard had 2.0mm headers. He wired up a small adapter to make his assembled V1.0 boards work, and Windows 11 installed without any TPM complaints. He shows that he’s designed a new, V1.1 version with an updated connector, too, and published its (untested but should work) design files for us on GitHub. These modules can vary, by manufacturer and motherboard series, but with each module published, a bunch of hackers can save money – and get a weekend project virtually guaranteed to work out.

Regardless of whether the goal of running Windows 11 is ultimately worthwhile, it has been achieved. With scalpers preying on people who just want to use their hardware with a new OS, rolling your own TPM PCB is a very attractive solution! Last time we covered a DIY TPM module for ASrock server motherboards, we had a vivid discussion in the comments, and if you’re looking to create your own TPM board, you could do worse than checking them out for advice and insights!

Four jumper wires with white heatshrink on them, labelled VCC, SCL, SDA and GND

The Connector Zoo: I2C Ecosystems

I2C is a wonderful interface. With four wires and only two GPIOs, you can connect a whole lot of sensors and devices – in parallel, at that! You will see I2C used basically everywhere, in every phone, laptop, desktop, and any device with more than a few ICs inside of it – and most microcontrollers have I2C support baked into their hardware. As a result, there’s a myriad of interesting and useful devices you can use I2C with. Occasionally, maker-facing companies create plug-and-play interfaces for the I2C device breakouts they produce, with standardized pinouts and connectors.

Following a standard pinout is way better than inventing your own, and your experience with inconsistent pin header pinouts on generic I2C modules from China will surely reflect that. Wouldn’t it be wonderful if you could just plug a single I2C-carrying connector into an MPU9050, MLX90614 or HMC5883L breakout you bought for a few dollars, as opposed to the usual hurdle of looking at the module’s silkscreen, soldering pin headers onto it and carefully arranging female headers onto the correct pins?

As with any standard, when it comes to I2C-on-a-connector conventions, you would correctly guess that there’s more than one, and they all have their pros and cons. There aren’t quite fifteen, but there’s definitely six-and-a-half! They’re mostly inter-compatible, and making use of them means that you can access some pretty powerful peripherals easily. Let’s start with the two ecosystems that only have minor differences, and that you’ll encounter the most! Continue reading “The Connector Zoo: I2C Ecosystems”

The microcontroller described in the article, on the PCB taken out of the kettle

Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle

[aleaksah] got himself a Mi Smart Kettle Pro, a kettle with Bluetooth connectivity, and a smartphone app to go with it. Despite all the smarts, it couldn’t be turned on remotely. Energized with his vision of an ideal smart home where he can turn the kettle on in the morning right as he wakes up, he set out to right this injustice. (Russian, translated) First, he tore the kettle down, intending to dump the firmware, modify it, and flash it back. Sounds simple enough — where’s the catch?

This kettle is built around the QN9022 controller, from the fairly open QN902X family of chips. QN9022 requires an external SPI flash chip for code, as opposed to its siblings QN9020 and QN9021 which have internal flash akin to ESP8285. You’d think dumping the firmware would just be a matter of reading that flash, but the firmware is encrypted at rest, with a key unique to each MCU and stored internally. As microcontroller reads the flash chip contents, they’re decrypted transparently before being executed. So, some other way had to be found, involving the MCU itself as the only entity with access to the decryption key.

Continue reading “Dumping Encrypted-At-Rest Firmware Of Xiaomi Smart Kettle”