Two months after its surprise reveal at the 2019 East Coast RepRap Festival, the Prusa Mini has started shipping out to the first wave of early adopters. True to form, with the hardware now officially released to the public, the company has begun the process of releasing the design as open source. In their GitHub repository, owners can already find the KiCad files for the new “Buddy” control board and STLs for the machine’s printable parts.
But even so, not everyone feels that Prusa Research has made the Mini as “open” as its predecessors. Some concerned owners have pointed out that according to the documentation for the Buddy board, they’ll need to physically snap off a section of the PCB so they can flash custom firmware images via Device Firmware Upgrade (DFU) mode. Once this piece of the board has been broken off, which the documentation refers to as the Appendix, Prusa Research will no longer honor any warranty claims for the electronic components of the printer.
For the hardcore tinkerers out there, this news may come as something of a shock. Previous Prusa printers have enjoyed a fairly active firmware development community, and indeed, features that started out as user-developed modifications eventually made their way into the official upstream firmware. What’s more, certain hardware modifications require firmware tweaks to complete.
Prusa Research explains their stance by saying that there’s no way the company can verify the safety of community developed firmware builds. If thermal runaway protections have been disabled or otherwise compromised, the results could be disastrous. We’ve already seen it happen with other printers, so it’s hard to fault them for being cautious here. The company is also quick to point out that the installation of an unofficial firmware has always invalidated the printer’s warranty; physically breaking the board on the Mini is simply meant as a way to ensure the user understands they’re about to leave the beaten path.
How much support is a manufacturer obligated to provide to a user who’s modified their hardware? It’s of course an issue we’ve covered many times before. But here the situation is rather unique, as the user is being told they have to literally break a piece off of their device to unlock certain advanced functionality. If Prusa wanted to prevent users from running alternate firmware entirely they could have done so (or at least tried to), but instead they’ve created a scenario that forces the prospective tinkerer to either back down or fully commit.
So how did Prusa integrate this unusual feature into their brand new 32-bit control board? Perhaps more importantly, how is this going to impact those who want to hack their printers? Let’s find out.
A Tale of Two Grounds
Looking at pictures of the assembled Buddy board, it’s not immediately obvious how the so-called Appendix works. It’s just a small piece of the PCB with no components on either side, there aren’t even any obvious traces running through it. But with a quick look at those aforementioned KiCad design files, we can put the pieces together.
As we can see, there’s a trace on one of the internal copper layers that loops through the Appendix. One side is connected to ground, and the other to the BOOT0 pin on the STM32F407VGT6 MCU. Consulting the datasheet for the chip, we can see that holding BOOT0 low like this disables DFU mode. So that explains why it has to go.
But the documentation says that to enable DFU mode you need to bring the BOOT0 pin high, and breaking the Appendix only leaves it floating. That’s where the second trace comes in. This one runs from BOOT0 to the center pin of a nearby three pin header. With pins for ground and 3.3 V on either side, a jumper can be used to switch BOOT0 between low and high. The Appendix is essentially a “safety” that prevents this jumper from having any effect.
The attentive reader may be wondering what would happen if you moved the jumper over to 3.3 V with the Appendix intact. It looks like Prusa considered this possibility, as the circuit diagram actually shows a 4.7K resistor between the header and BOOT0 pin to avoid a dead short.
Prusa Developer Program
While we’re certainly approaching the point where the average 3D printer owner is no different than the sort of person who owns a drill press or a table saw, a good chunk of them still spend as much time tweaking and modifying their machine as they do actually printing with it. So it’s little surprise that the possibility of firmware hacking being off the table has lead to some backlash.
But if there’s anyone who understands the desire to hack, modify, and improve 3D printers, it’s Josef Průša. The very real dangers of unchecked firmware modification forced him to act, as much to protect his customers as his brand, but he’s made it clear that the intent was never to block the more technically inclined users from getting their hands dirty.
In a recent blog post, Josef explained the company’s plan to introduce a “Developer Program” that is aimed specifically at those who want to get involved in unofficial firmware development:
Also, we plan to launch a community developer program in the upcoming months. You’ll get extra resources from us and in case you break something during development, you will get new parts (no matter whether you broke the “appendix” on the mainboard). We’ll publish more information soon, so stay tuned!
Such a program sounds like it would address essentially all of the concerns currently being voiced by users, though undoubtedly some will resent needing to register themselves as “developers” if all they want to do is modify a few lines of code in their printer’s firmware. It’s also unclear if a cost will be associated with this program, but it’s somewhat difficult to believe that the company will completely foot the bill for expanded customer support and access to replacement parts.
The End-Hacker License Agreement
Hacker-friendly companies like Prusa Research are in a difficult position. On one hand, they don’t want to do anything that prevents more technical users from modifying their products. But at the same time, it’s unreasonable to expect a manufacturer to replace hardware that was damaged while the user was performing unsanctioned modifications. As hackers, we need to acknowledge that there’s a certain level of personal responsibility that comes with the territory.
At the end of the day, the introduction of the Appendix should be seen as a net positive for the hacking community. It provides a clear line in the sand for anyone who wants to explore their hardware, and ensures both parties clearly understand the paradigm shift that happens when the user decides to take matters into their own hands. The fact that it even exists shows the hardware was not designed to restrict the user’s rights, but rather to acknowledge and respect them.
With any luck, the next time a manufacturer does something like this they’ll put “REMOVE BEFORE HACK” right on the silkscreen.
No comments:
Post a Comment