Degrees Of Freedom: Booting ARM Processors

Any modern computer with an x86 processor, whether it’s Intel or AMD, is a lost cause for software freedom and privacy. We harp on this a lot, but it’s worth repeating that it’s nearly impossible to get free, open-source firmware to run on them thanks to the Intel Management Engine (IME) and the AMD Platform Security Processor (PSP). Without libre firmware there’s no way to trust anything else, even if your operating system is completely open-source.

The IME or PSP have access to memory, storage, and the network stack even if the computer is shut down, and even after the computer boots they run at such a low level that the operating system can’t be aware of what they’re really doing. Luckily, there’s a dark horse in the race in the personal computing world that gives us some hope that one day there will be an x86 competitor that allows their users to have a free firmware that they can trust. ARM processors, which have been steadily increasing their user share for years but are seeing a surge of interest since the recent announcement by Apple, are poised to take over the personal computing world and hopefully allow us some relevant, modern options for those concerned with freedom and privacy. But in the real world of ARM processors the road ahead will decidedly long, windy, and forked.

Even ignoring tedious nitpicks that the distinction between RISC vs CISC is more blurred now than it was “back in the day”, RISC machines like ARM have a natural leg up on the x86 CISC machines built by Intel and AMD. These RISC machines use fewer instructions and perform with much more thermal efficiency than their x86 competitors. They can often be passively cooled, avoiding need to be actively cooled, unlike many AMD/Intel machines that often have noisy or bulky fans. But for me, the most interesting advantage is the ability to run ARM machines without the proprietary firmware present with x86 chips.

Continue reading “Degrees Of Freedom: Booting ARM Processors”

Official Arduboy Upgrade Module Nears Competition

We’ve been big fans of the Arduboy since [Kevin Bates] showed off the first prototype back in 2014. It’s a fantastic platform for making and playing simple games, but there’s certainly room for improvement. One of the most obvious usability issues has always been that the hardware can only hold one game at a time. But thanks to the development of an official add-on, the Arduboy will soon have enough onboard storage to hold hundreds of games

Even the rear silkscreen was a community effort.

The upgrade takes the form of a small flexible PCB that gets soldered to existing test points on the Arduboy. Equipped with a W25Q128 flash chip, the retrofit board provides an additional 16 MB of flash storage to the handheld’s ATmega32u4 microcontroller; enough to hold essentially every game and program ever written for the platform at once.

Of course, wiring an SPI flash chip to the handheld’s MCU is only half the battle. The system also needs to have its bootloader replaced with one that’s aware of this expanded storage. To that end, the upgrade board also contains an ATtiny85 that’s there to handle this process without the need for an external programmer. While this is a luxury the average Hackaday reader could probably do without, it’s a smart move for an upgrade intended for a wider audience.

The upgrade board is currently available for pre-order, but those who know their way around a soldering iron and a USBasp can upgrade their own hardware right now by following along with the technical discussion between [Kevin] and the community in the “Project Falcon” forum. In fact, the particularly astute reader may notice that this official upgrade has its roots in the community-developed Arduboy cartridge we covered last year.

Continue reading “Official Arduboy Upgrade Module Nears Competition”

Boot Your Pi Over USB

Historically, booting a Raspberry Pi required an SD card. However, if you follow [tynick’s] instructions, you can get a Pi 4 to boot from the USB port. Combine it with a small solid state disk drive, and you’ll get great performance, according to his post.

The caveat is this depends on a beta bootloader and, of course, you’ll still have to boot from an SD card at least once to load that bootloader. If you were deploying something serious, you’d probably want to make sure the bootloader is suitable for your needs.

Continue reading “Boot Your Pi Over USB”

Analog Failures On RF Product Cause Production Surprise

A factory is a machine. It takes a fixed set of inputs – circuit boards, plastic enclosures, optimism – and produces a fixed set of outputs in the form of assembled products. Sometimes it is comprised of real machines (see any recent video of a Tesla assembly line) but more often it’s a mixture of mechanical machines and meaty humans working together. Regardless of the exact balance the factory machine is conceived of by a production engineer and goes through the same design, iteration, polish cycle that the rest of the product does (in this sense product development is somewhat fractal). Last year [Michael Ossmann] had a surprise production problem which is both a chilling tale of a nasty hardware bug and a great reminder of how fragile manufacturing can be. It’s a natural fit for this year’s theme of going to production.

Surprise VCC glitching causing CPU reset

The saga begins with [Michael] receiving an urgent message from the factory that an existing product which had been in production for years was failing at such a high rate that they had stopped the production line. There are few worse notes to get from a factory! The issue was apparently “failure to program” and Great Scott Gadgets immediately requested samples from their manufacturer to debug. What follows is a carefully described and very educational debug session from hell, involving reverse engineering ROMs, probing errant voltage rails, and large sample sizes. [Michael] doesn’t give us a sense for how long it took to isolate but given how minute the root cause was we’d bet that it was a long, long time.

The post stands alone as an exemplar for debugging nasty hardware glitches, but we’d like to call attention to the second root cause buried near the end of the post. What stopped the manufacturer wasn’t the hardware problem so much as a process issue which had been exposed. It turned out the bug had always been reproducible in about 3% of units but the factory had never mentioned it. Why? We’d suspect that [Michael]’s guess is correct. The operators who happened to perform the failing step had discovered a workaround years ago and transparently smoothed the failure over. Then there was a staff change and the new operator started flagging the failure instead of fixing it. Arguably this is what should have been happening the entire time, but in this one tiny corner of the process the manufacturing process had been slightly deviated from. For a little more color check out episode #440.2 of the Amp Hour to hear [Chris Gammell] talk about it with [Michael]. It’s a good reminder that a product is only as reliable as the process that builds it, and that process isn’t always as reliable as it seems.

Arduino Leonardo Gets A Lockable Bootloader

Security is something that’s far too often overlooked in embedded devices. One of the main risks is that if the device doesn’t verify the authenticity of incoming firmware updates. [Walter Schreppers] was working on a USB password storage device, so security was paramount. Thus, it was necessary to develop a secure bootloader.

[Walter]’s device was based upon the Arduino Leonardo. Starting with the Caterina bootloader, modifications were made to enable the device to be locked and unlocked for programming. This can be done in a variety of ways, depending on how things are setup. Unlocking can be by using a secret serial string, an onboard jumper, and [Walter] even suspects a SHA1 challenge/response could be used if you were so inclined.

It’s never too soon to start thinking about security in your projects. After all, we must stave off the cyberpunk future in which leather-clad youths flick all your lights on and off before burning your house down in the night by overclocking the water heater. Naturally, we’ve got a primer to get you going in the right direction. Happy hacking!

Show Your Skills With A Bootable CV

It’s a thankless task, searching for a job. You send off your CV, or resume, and it joins a thousand other destined for the round file. What on earth can you do to make your career stand out, and catch the eye of the recruiter?

Your bootable CV isn't eye-catching if the recruiter uses GitHub to view the PDF.
Your bootable CV isn’t eye-catching if the recruiter uses GitHub to view the PDF.

If you are [Pablo Jiménez Mateo], the answer is straightforward enough. Simply combine the document as a PDF with an x86 bootloader, to make a readable document that will also boot an x86 computer system. He can do this relatively easily by prepending the bootloader file to the PDF, as long as the “%PDF” header of the CV remains within the first 1024 bytes it will remain a readable document. Which it does, though as our GitHub screenshot shows, not in all PDF readers.

A bootable PDF is pretty cool and we have to salute his effort in getting it in front of us in the hope of  career boost, but it would be fair to admit that it’s a trick that has been done before. So it’s time to turn attention to the bootloader itself, whose code comes in the form of an extremely well-commented assembly file that loads some sprites and a border to a VGA screen that looks as though it might be the first room in a top-down adventure game. Through the code we can gain an appreciation of just how simple a bootloader can be, and that in itself makes this project worth a second look.

If writing your own bootloader interests you, that’s certainly a subject we’ve covered in the past. It’s possible to make bootable images very small indeed, even down to fitting in a Tweet.

Want To Learn Ethernet? Write Your Own Darn AVR Bootloader!

There’s a school of thought that says that to fully understand something, you need to build it yourself. OK, we’re not sure it’s really a school of thought, but that describes a heck of a lot of projects around these parts.

[Tim] aka [mitxela] wrote kiloboot partly because he wanted an Ethernet-capable Trivial File Transfer Protocol (TFTP) bootloader for an ATMega-powered project, and partly because he wanted to understand the Internet. See, if you’re writing a bootloader, you’ve got a limited amount of space and no device drivers or libraries of any kind to fall back on, so you’re going to learn your topic of choice the hard way.

[Tim]’s writeup of the odyssey of cramming so much into 1,000 bytes of code is fantastic. While explaining the Internet takes significantly more space than the Ethernet-capable bootloader itself, we’d wager that you’ll enjoy the compressed overview of UDP, IP, TFTP, and AVR bootloader wizardry as much as we did. And yes, at the end of the day, you’ve also got an Internet-flashable Arduino, which is just what the doctor ordered if you’re building a simple wired IoT device and you get tired of running down to the basement to upload new firmware.

Oh, and in case you hadn’t noticed, cramming an Ethernet bootloader into 1 kB is amazing.

Speaking of bootloaders, if you’re building an I2C slave device out of an ATtiny85¸ you’ll want to check out this bootloader that runs on the tiny chip.