UEFI On ARM? More Likely Than You Think

Now, Rock 5 ITX+ is no x86 board, sporting an ARM Rockchip RK3588 on its ITX form-factor PCB, but reading this blog post’s headline might as well give you the impression. [Venn] from the [interfacinglinux.com] blog tells us about their journey bringing up UEFI on this board, thanks to the [EDK2-RK3588] project. Why? UEFI is genuinely nice for things like OS switching or system reconfiguration on the fly, and in many aspects, having a system management/configuration interface for your SBC sure beats the “flash microSD card and pray” traditional approach.

In theory, a UEFI binary runs like any other firmware. In theory. For [Venn], the journey wasn’t as smooth, which made it very well worth documenting. There’s maybe not a mountain, but at least a small hill of caveats: having to use a specific HDMI port to see the configuration output, somehow having to flash it onto SPI flash chip specifically (and managing to do that through Gnome file manager of all things), requiring a new enough kernel for GPU hardware acceleration… Yet, it works, it really does.

Worth it? From the looks of it, absolutely. One thing [Venn] points out is, the RK3588 is getting a lot of its features upstreamed, so it’s aiming to become a healthy chip for many a Linux goal. From the blog post comments, we’ve also learned that there’s a RPi UEFI port, even if for a specific CPU revision of the Model 5B, it’s still a nifty thing to know. Want to learn more about UEFI? You can start here or here, and if you want a fun hands-on example, you could very well start by running DOOM.

Build Your Own Glasshole Detector

Connected devices are ubiquitous in our era of wireless chips heavily relying on streaming data to someone else’s servers. This sentence might already start to sound dodgy, and it doesn’t get better when you think about today’s smart glasses, like the ones built by Meta (aka Facebook).

[sh4d0wm45k] doesn’t shy away from fighting fire with fire, and shows you how to build a wireless device detecting Meta’s smart glasses – or any other company’s Bluetooth devices, really, as long as you can match them by the beginning of the Bluetooth MAC address.

[sh4d0wm45k]’s device is a mini light-up sign saying “GLASSHOLE”, that turns bright white as soon as a pair of Meta glasses is detected in the vicinity. Under the hood, a commonly found ESP32 devboard suffices for the task, coupled to two lines of white LEDs on a custom PCB. The code is super simple, sifting through packets flying through the air, and lets you easily contribute with your own OUIs (Organizationally Unique Identifier, first three bytes of a MAC address). It wouldn’t be hard to add such a feature to any device of your own with Arduino code under its hood, or to rewrite it to fit a platform of your choice.

We’ve been talking about smart glasses ever since Google Glass, but recently, with Meta’s offerings, the smart glasses debate has reignited. Due to inherent anti-social aspects of the technology, we can see what’d motivate one to build such a hack. Perhaps, the next thing we’ll see is some sort of spoofed packets shutting off the glasses, making them temporarily inoperable in your presence in a similar way we’ve seen with spamming proximity pairing packets onto iPhones.

Share Your Projects: Imperfectionism

Everyone has a standard for publishing projects, and they can get pretty controversial. We see a lot of people complain about hacks embedded in YouTube videos, social media threads, Discord servers, Facebook posts, IRC channels, different degrees of open-sourcing, licenses, searchability, and monetization. I personally have my own share of frustrations with a number of these factors.

It’s common to believe that hacking as a culture doesn’t thrive until a certain set of conditions is met, and everyone has their own set of conditions in mind. My own dealbreaker, as you might’ve seen, is open-sourcing of code and hardware alike – I think that’s a sufficiently large barrier for hacking being repeatable, and repeatability is a big part of how hacking culture spreads.

This kind of belief is often self-limiting. Many people believe that their code or PCB source file is not a good contribution to hacking culture unless it meets a certain cleanliness or completeness standard. This is understandable, and I do that, too.

Today, I’d like to argue against my own view, and show how imperfect publishing helps build hacking culture despite its imperfections. Let’s talk about open-source in context of 3D printing.

Continue reading “Share Your Projects: Imperfectionism”

Lithium-Ion Batteries: WHY They Demand Respect

This summer, we saw the WHY (What Hackers Yearn) event happen in Netherlands, of course, with a badge to match. Many badges these days embrace the QWERTY computer aesthetic, which I’m personally genuinely happy about. This one used 18650 batteries for power, in a dual parallel cell configuration… Oh snap, that’s my favourite LiIon cell in my favourite configuration, too! Surely, nothing bad could happen?

Whoops. That one almost caught me by surprise, I have to shamefully admit. I just genuinely love 18650 cells, in all glory they bring to hardware hacking, and my excitement must’ve blindsided me. They’re the closest possible entity to a “LiIon battery module”, surprisingly easy to find in most corners of this planet, cheap to acquire in large quantities, easy to interface to your projects, and packing a huge amount of power. It’s a perfect cell for many applications I and many other hackers hold dear.

Sadly, the 18650 cells were a bad choice for the WHY badge, for multiple reasons at once. If you’re considering building a 18650-based project, or even a product, let me show you what exactly made these cells a bad fit, and how you might be able to work around those limitations on your own journey. There’s plenty of technical factors, but I will tell you about the social factors, because these create the real dealbreaker here. Continue reading “Lithium-Ion Batteries: WHY They Demand Respect”

Screenshot of the email received: Hi there, Upon a thorough review by our Risk Control Team, we are sorry to inform you that, your account access will be permanently disabled on December 13th, 2025 due to compliance policy requirements. Before this date, you may: 1) Complete any existing orders. 2) Pickup components from your parts inventory. 3) Withdraw your remaining account balance (JLC Balance) 4) Back up your historical Gerber Files or any other information. Please note that after December 13th, 2025, your account will be permanently locked and cannot be reopened. Best Regards, The JLCPCB Risk Control Team

JLCPCB Locking Accounts, Mentions “Risky IP Addresses, Activities”

In the past week, a few forum and Reddit threads have popped up, with people stating that JLCPCB has emailed them with a notice, saying their accounts are set up for terminations after an assessment by JLCPCB’s “Risk Control Team”. Reasons given are vague, the terminations are non-appealable, and if you’re planning a JLCPCB order sometime soon, it can certainly come as a surprise. From the looks of it, the accounts restricted do not appear to be tied to any specific country – and not even from the same “kind” of countries.

As quite a few people have observed, the JLCPCB reasoning resembles a compliance action way more than it resembles any sort of internal policy. A few days ago, JLCPCB has released a statement on their blog, claiming that a “history of risky IP addresses and risky activities” would be grounds for a termination, and mentioning “compliance” in ways that would hint at external legal pressures.

By now, quickly checking around Reddit and some other places, we’ve counted at least ten people affected so far – most of them have received emails about account closures, but at least one person has reported a denial when attempting to place an order, instead of getting an email ahead of time. The latter hints that there’s a number of people not yet notified about their account getting terminated, and the amount of people actually affected might very well be a fair bit larger than we can see.

Continue reading “JLCPCB Locking Accounts, Mentions “Risky IP Addresses, Activities””

FreeCAD Foray: Good Practices

Last time, we built a case for a PCB that handles 100 W of USB-C power, an old project that I’ve long been aiming to revive. It went well, and I’d like to believe you that the article will give you a much-needed easy-to-grasp FreeCAD introduction, Matrix knowledge upload style, having you designing stuff in no time.

Apart from my firm belief in the power of open-source software, I also do believe in social responsibilities, and I think I have a responsibility to teach you some decent FreeCAD design practices I’ve learned along the way. Some of them are going to protect your behind from mistakes, and some of them will do that while also making your project way easier to work with, for you and others.

You might not think the last part about “others” matters, but for a start, it matters in the ideal world that we’re collectively striving towards, and also, let’s be real, things like documentation are half intended for external contributors, half for you a year later. So, here’s the first FreeCAD tip that will unquestionably protect you while helping whoever else might work with the model later.

Okay, we’re all hackers, so I’ll start with zero-th FreeCAD tip – press Ctrl+S often. That’ll help a ton. Thankfully, FreeCAD’s autorecovery system has made big leaps, and it’s pretty great in case FreeCAD does crash, but the less you have to recover, the better. Now, onto the first tip.

Continue reading “FreeCAD Foray: Good Practices”

FreeCAD Foray: From Brick To Shell

Over a year ago, we took a look at importing a .step file of a KiCad PCB into FreeCAD, then placing a sketch and extruding it. It was a small step, but I know it’s enough for most of you all, and that brings me joy. Today, we continue building a case for that PCB – the delay is because I stopped my USB-C work for a fair bit, and lost interest in the case accordingly, but I’m reviving it now.

Since then, FreeCAD has seen its v 1.0 release come to fruition, in particular getting a fair bit of work done to alleviate one of major problems for CAD packages, the “topological naming problem”; we will talk about it later on. The good news is, none of my tutorial appears to have been invalidated by version 1.0 changes. Another good news: since version 1.0, FreeCAD has definitely become a fair bit more stable, and that’s not even including some much-needed major features.

High time to pick the work back up, then! Let’s take a look at what’s in store for today: finishing the case in just a few more extrusions, explaining a few FreeCAD failure modes you might encounter, and giving some advice on how to make FreeCAD for you with minimum effort from your side.

Continue reading “FreeCAD Foray: From Brick To Shell”