I must admit while this cool, what I really want is a standard dirtcheap 8 to 10 inch Android tablet with a hackable OS and a row of gpio pins on it like the raspberry pi. $50 will get you a lot of power and convience today as these things are two a penny due to economies of
Scale. Throw a usb-c video input and output onto it too, so it can use it as a touch screen monitor for my phone too. and I'm sold
It sounds like what you're looking for is the Pocket C.H.I.P. The company went out of business, but I bought one back in the day and it was so fun to hack around with.
I don't think that is akin to an 8 to 10" Android tablet/screen. Then again, I don't see how all the other products are related to the one mentioned here. Except they're all hackable?
If you want a small device to play old games on via an emulator, I can recommend Pocketsprite [1]. You can even assemble one yourself.
FWIW, I'm looking for a small portable screen (1080p, IPS) to combine with my MBP 2015 (via TB2 or HDMI but I also want it to have USB-C for future compatibility).
If just looking for a portable display, there are plenty on amazon. I bought a Chinese brand, magedock, because they had a touch screen 1600p model that was more portable than the others (no battery though).
Yeah, Amazon is such a rain-forest though. There's a plethora of devices there, and I don't trust the reviews. I'd prefer a 14", don't require touchscreen (though if it would cost me 50 EUR, I'd go for it, but not double the price like ThinkVision M14t). Speaking of which I've seen the ThinkVision M14 for 180 EUR, that's a fair price. It has high brightness of 300 nits (better than the Asus one, of which the 16" gets recommended a lot even though its barely readable in sunlight), though reportedly also has coil whine. However, it _only_ supports USB-C. So I would need some kind of adapter I guess. A lot of the Chinese stuff has the adapters included, but even the brandnames just don't make sense. Magedok was out of stock (they didn't have Magedock). Battery I don't care for; I'd just hang a powerbank behind it with velcro.
Specifically, GP’s mention of “with a row of gpio pins on it” is what made me think of the CHIP, and I don’t think there are any tablets that have that.
The esp32-based m5stack Stick-C finger computer seems like a very inexpensive alternative, comes with a built-in bunch of sensors, a small battery and a small display for $11.
> what I really want is a standard dirtcheap 8 to 10 inch Android tablet with a hackable OS and a row of gpio pins
Sadly, most of these points are mutually exclusive. Android tablets are built for the average user who would have neither use for an hackable OS nor for exposed GPIO ports. Adding them would represent an added cost with no returns with respect to the market they're into.
Also, most if not all Android tablets - actually their manufacturers - are hostile to letting techies install their OS of choice, and implement tactics to discourage them, mainly keeping the hardware closed.
To date, the Pinetab seems the best example of a tablet designed from the ground up to be of interest both to users and tinkerers because it encourages to experiment with open operating systems. https://www.pine64.org/pinetab/
I agree this would be cool, and the good news is that systems close to meeting your wishes already exist today.
However, Precursor is more about evidence-based hardware security, and less about features and usability. To better understand the principles behind Precursor's design, please have a look at https://www.crowdsupply.com/sutajio-kosagi/precursor/updates....
The TL;DR is that it's a development platform for applications that strongly require secure and/or trustable hardware.
The platform as usual looks great! I'd ask if you'd consider an addon board, or including an EZR32WG radio chip or similar, as it supports the open source Dash7 radio stack. I'm guessing that being able to tx wirelessly and securely would fit well with the hardware goals.
Wasn't not long ago right here on HN an article of somebody who did a phone from hacking together stuff around Raspberry Pi? Heck, you can even install Android or Windows IoT on a Raspberry Pi, if you don't like Raspberry Pi OS (former Raspbian)
Sounds like a custom PCB, requiring custom assembly, and, worse yet, a custom enclosure. With sub-million quantities, economy of scale isn't exactly there.
But if it's well-marketed to the hobbyists, and software support is adequate, then maybe.
Just like the PinePhone, Librem etc. This is the future for hackable (hardware and software) mobile devices given how locked down the mainstream consumer manufacturers are, and getting worse by the day.
Mid-to-high 5-figure to low 7-figure unit sales (for a 'wildly' successful device like the Raspberry Pi) is what it seems to be looking like for a successful open mobile(-ish) device. As long as the businesses offering them are sized appropriately, it's doable. Just need to be smart about re-using enclosure designs etc and have long production runs to help amortize things like regulatory certifications etc. For hacker devices, they can sell this stuff for several years between major revs and their customers appreciate the longer product/parts availability.
At the risk of wanting this to be something that it's not - what's the reasoning behind not targeting Precursor towards running (embedded) Linux? With a little more RAM it seems like the specs would make it a great fit for Linux, which might allow for a broader ecosystem of use cases?
Is there something I'm missing that means developing a new OS (https://github.com/betrusted-io/xous-core/) works better for Precursor? Keen to understand the rationale, cause I think I'm probably missing something here!
edit: There's a good explanation on the CrowdSupply page - seems like it's in order to make it a more secure platform:
> Simplicity addresses the reality of only having 24 hours in a day. Even though the full source code for the Linux kernel and Firefox is published, nobody has the time to personally review every release for potential security problems; we simply trust that others have done a good job, because we have no other choice. Precursor rolls the clock back to the early 2000’s, when mobile computers were powerful enough to be useful for single tasks, while simple enough that individuals or small teams could build them from scratch. But don’t worry, despite its simplicity, Precursor’s computational capability exceeds that of the Palm Pilot series. It’s more on par with a Nintendo DS: sufficient for core security tasks such as authentication, instant messaging, crypto wallets, and even end-to-end encrypted voice calls.
This is something that worries me about this project. Is the focus more on hackability, or security/inspectability? The messaging is unclear, and this decision looks like a big sacrifice of the former for the latter. I'd maybe be interested in this device but only for the purposes of DIY messing around, I'm nowhere near so worried about security I wouldn't trust the linux kernel.
This project is definitely security-first. That being said, we're defining "hackability" as "empowerment to hack". For example, this is one of the few platforms where you can hack the CPU itself by adding new instructions to it.
If you flash Linux onto a device like this, the constant stream of discovered and fixed Linux security holes is bound to eventually bite you without frequent & robust OTA update regimen that requires staffing. It's not really a "jury's still out" type of question: https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...
(Not that it's an easy with a simpler software stack either of course but you can have a fighting chance at least)
Maybe they'll later do a version where the corner of the PCB that has the wifi radio is notched out and there is a set of horizontal pins to slide in a replacement pcb... so you could replace the wifi radio with LoRa.
Sticking LoRa in this would be awesome, (e.g. https://www.meshtastic.org/), but I can understand why it has wifi.
This scratches a fairly specific itch I've had for quite a while now — portable DIY electronics. At the moment, even if you use something as Lego-like as Adafruit's boards [1], you still need your primary logic board, a separate module to handling charging, a battery pack, a case that holds all of the above in place neatly, and more. Personally I don't find the keyboard to be a very attractive feature of Precursor, but all the rest of this project is super exciting and I can't wait to see them deliver on it.
Personally I just use ESP32 (specifically Lolin D32) in an altoids-type box with a run-of-the-mill small USB power bank taped to the back. Usually with some level shifters and stuff to run the Blinkenlights (FastLED + ws2813).
If that's too ghetto for you, have a look at the M5Stack series. A main unit (ESP32, screen, speaker, TF card reader, in a case with some buttons) costs $35, and the battery module you can stack on is $10. There is even a keyboard and a gameboy-like attachment.
I like the look of the Precursor, but personally the FPGA is a bit off-putting, just because I've never gone down that road.
> if your application does not require a large display and a keyboard, you can simply remove them and replace the bezel with a full-sized circuit board
It's sad to see that. The project is interesting, but making it WiFi only restricted immensely its use. Although it seems obsolete tech, many countries still use 2G GSM phones (my phone is only GSM in fact). Adding a cheap SIM800 chip on a small removable board would turn this into a real phone, and the sales from people who needed GSM would help to cover for further development for the 4/5G version.
You might also like Wio Terminal[1] if you are looking for something with a bit less powerful hardware and no keyboard. Also it's available now and supported by a fairly mature software stack (micropython for esp32)
This looks lovely. I've long been looking for a hackable device in this form factor, albeit more with the intent of running Linux.
One thing I can't find any detail on is the keyboard. Making a keyboard from scratch is well outside of usual low-volume productions and there aren't any readily available parts in this form factor as far as I know. How is the Precursor's one made/sourced?
I'll be writing an article on this in the future, and you're right, the keyboard was a serious pain to build. It's one of the big reasons it took two years to bring the product to this state.
Bunnie (as you seem to be around here) — can the accel/gyro values be read/sampled? They’re listed under the “anti-tamper” category on crowdsupply so I wasn’t sure. Are there some specs on max Gs, sample rate, etc.?
—
I find this device extraordinarily appealing (will definitely be backing). Bunnie is a hardware hacker’s hacker, the project has at least 2 years of development behind it. It will most definitely ship, and work. Ha.
But — I’m specifically excited because this seems like an ideal platform to build whimsical mobile hardware projects.
My dream of a 2000-era electronic organizer with a “retro” (non touch) display, with physical keyboard, and battery, and programmable/hackable and fully open... this is truly a dream come true.
Why couldn’t this become the democratizing mobile Arduino-like hobbyist “base”?
I’m extra, extra excited about it!
(And dream of adding LTE and making a retro minimal... phone OS/“app”? Fast email + wikipedia clients??)
The TL;DR is that the accelerometer is integrated so that it's in the "always on" untrusted domain, so to access it from the main FPGA "SoC" you have to go through the system controller FPGA ("EC" as we call it). The idea is for it to be available in power down states for anti-tamper, hence the extra layer of complication.
> "Why couldn’t this become the democratizing mobile Arduino-like hobbyist “base”?"
Well, for one thing, the XC7S50 FPGA costs over $50 just for the chip. This device is going to be much more expensive than an Arduino or even a Raspberry Pi.
I do hope that the form factor, “polish” — how much of a finished product the Precursor is, and the possibility of programming/extending it can serve as an inspiration/starting point for future hobbyist mobile tech.
I know that it’s a very heterogeneous mix, but just to note some contemporary devices that evoke “similar” feelings: Panic’s Playdate [0] and the recently crowdfunded Flipper Zero [1].
Maybe all of these remind me in some ways of the Gameboy, electronic organizers from the 2000s [2], pre-smartphone Symbian Nokias [3] (and every qwerty/slide out keyboard device from back then), all of which I grew up with.
But, it also seems like there’s a lot of interest now to create digital experiences that aren’t tied to existing social media platforms, aren’t engineered to simultaneously maximize addiction and profit (through advertisement and the sale of personal data).
Developing towards that future is immensely exciting.
I really dig the slim and professional form factor, a lot of "portable" open-source hardware projects look like a bunch of PCBs stapled together, with wires and connectors hanging out everywhere.
I just learned of "dynamic reconfiguration", where a running device configures and commits additional logic units to a temporary task.
Is that possible, in principle, in a Spartan 7?
It is easy to believe that you would need to pre-generate bitstreams for each configuation, and could only swap them in verbatim, not generate them on-the-fly, but downloading from a library, perhaps with parameterized choices, could increase flexibility.
Most current FPGAs offer the option to have one configuration select a different bitstream in the configuration memory and have that replace itself. That allows a simple menu configuration to let the user select between several actual configurations. Or it allows over the air updates.
In the specific case of Xilinx FPGAs there was a feature introduced in the original Virtex called "partial configuration". This has been present in all its products for the last 20 years. It allows a design to be broken into parts such that one part may be replaced even while the rest of the FPGA continues to work normally. This is pretty hard to use and the interface between the part being swapped and the rest of the circuit is rather tricky, so it has been use more for cool demos than actual products.
It is possible to have the equivalent to this with non Xilinx FPGAs by having several smaller ones connected to each other on a board. Then dynamic reconfiguration of one can happen while the others continue to work normally.
The iCE40UP5K is not the main processor. It's the embedded controller. Think of it as a power management coprocessor that takes care of things like managing the battery while the main CPU is asleep. It is packed to the gills, but the iCE40UP5K is low enough power to remain on and not drain the battery for several days.
The main CPU is a Spartan7 XC7S50, which has plenty of space for things like crypto accelerator cores beyond the primary RISC-V CPU.
What I think would be most interesting is whatever primitives are needed to build fancy cryptosystems which are resistant to EMI/DPA sidechannels.
Plain TLS stuff as the sibling comment suggests is entirely uninteresting to me-- a boring software implementation is more than fast enough even on a 100MHz device to accomplish whatever that 100MHz device is going to accomplish. (I assume bunnie's Betrusted soc will be faster than 100MHz too).
But what you can't do from general software is get something which is extremely robust against EMI and power sidechannels.
Similarly, while plain ECDH/etc. will be more than fast enough even in software for 99% of applications you'd want to run on a small device like this, various zero knoweldge proofs and other fancy constructions may still be painfully slow (as they're often noticably slow on desktops).
Unfortunately the ed25519 curve is probably not really the best choice there for a primitive to optimize due to the cofactor being an extraordinary nuisance for other applications outside of plain signatures and key agreement. ... but group choices for ZKPs are by-far not a settled question.
> Unfortunately the ed25519 curve is probably not really the best choice there for a primitive to optimize due to the cofactor being an extraordinary nuisance for other applications outside of plain signatures and key agreement.
Luckily you can use an optimized ed25519 to implement ristretto255, which solves this problem :)
Interesting project but it seems like the schematics require proprietary and extremely expensive software to look at. Certainly beyond hobbyist reach.
Why not develop with open source tools like Kicad? Kicad these days is mature enough to handle a project of this scale easily.
I remember there was a similar attempt years ago (probably between 5 to 10 years ago). I forgot the name of the startup but they were trying to build a non-phone mobile device that's programmable. I actually applied for beta testing and got one for free, but they ended up going out of business. I remember the color was ruby-ish. Can't remember the name. Anyone know what this was?
no the project I'm talking about looked similar to this one but a bit shorter vertically, and the one I owned had a dark pink (or ruby) color. Had the same blackberry type keyboard too. It was a startup, and they shut down eventually.
The XC7S50 is a Spartan7, which is supported by Vivado's WebPack edition (free but with many non-FOSS parts) as well as the FOSS SymbiFlow toolchain (I can't figure out which Place-and-Route tool that targets Xilinx 7-series parts they're using from the docs, but they imply one is at least vaguely usable) too.
The iCE40UP5K will work with any IceStorm-based FOSS toolchain (including SymbiFlow) as well as Lattice's free first party Radiant tool (and I think also the older IceCube2 toolchain).
It's a little odd that they're different vendor parts / on different 1st party toolchains, but it does look like you could program everything through the FOSS tools, albeit probably missing a few features (Last I looked a couple of the special purpose blocks in both the Xilinx 7-series and the UltraPlus were not fully understood by the FOSS stuff; that may have changed).
I've been meaning to try Radiant, I teach some classes on top fo Vivado + Artix7 FPGA dev boards, and it's so much less awful than ISE (Xilinx's old toolchain) I'm still pleased with, but there are some nice, affordable iCE40-UltraPlus boards coming on the market, and if Radiant is less of a hassle (Vivado is a 25GB install and not _entirely_ beginner-friendly) I'd consider retooling.
The Spartan 3/3E/6 lines are legacy parts (and hence stuck on ISE for programming, so you don't want them). The Spartan 7 parts were a late addition (not shipping until 2017) to the 7th gen line for the low end; they use the 7th gen blocks and tooling, but are "cost optimized" and lack the fancy transceivers and such - though irritatingly the cost and resources of the Artix and Spartan parts have a lot of overlap; Spartan7 parts run from about $15-140 in single, Artix7 parts from about $25-430.
Seriously cool. Love the attention to detail. I’ll definitely back whatever funding campaign is launched for this, I’ve got the perfect project in mind for a portable secure controller.
It’d be a pretty gargantuan task to backdoor the FPGA silicon itself. You’d have to have compromised Xilinx’s software and had some idea of what signals you want to tap. Kinda interesting to think about... I suppose that’s were open source tools for FPGAs would be nice.
The image? Sure, could easily be backdoored, but that’s what open source is for; auditability.
Edit: FPGA silicon is kinda backdoored by definition thanks to JTAG configurability/readability. (Barring cases where keys are used.) So I think the really interesting thing would be addition of nefarious logic by the design tools.
Well, yes, but in the past this type of device would be floated as an attempt to fight state-level actors. And... it can't do that. That's all I'm pointing out.
Either the silicon, the synthesis software, or both could be compromised. Per leaked documents usually what gets attacked is random number generation, but there are more avenues I am sure.
You can usually turn off JTAG, but having JTAG or other debug interface not be permanently disabled is actually an exploit class.
This is the likely target for NSA. Intercepting supply chains for stock parts inside of China is not their specialty. Further, to bother with custom hardware would require substantial resources and time to develop before even getting it deployed. Nobody is going to do that. Bunnie's compiler just changed checksum...
To fight such an attack, the output of deterministic builds running on geographically dispersed systems with disparate stacks (physical, cloud, newly purchased, multiple OSs, etc.) may be compared before release.
The protected body of software should also include the firmware upload utilities.
Another attack, given the open source nature of the device, could be distributing cheap, compromised units broadly after the fact to ensure they are widely adopted.
>Intercepting supply chains for stock parts inside of China is not [the NSA's] specialty
>Another attack, given the open source nature of the device, could be distributing cheap, compromised units broadly after the fact to ensure they are widely adopted.
I like thinking about high-level threat models as much as the next guy, but these two statements seem to be at odds. Unless by "compromised units" you don't mean what I think you mean.
First was referring to supply chain interdiction for third party fabricators attempting to produce non-compromised units. Second was referring to active fabrication and distribution of compromised units to unsuspecting consumers.
Oh, ok. So its the difference between opening the box to put in a wayward chip, versus starting a factory who makes units with the wayward chip to begin with. Fair enough.
interestingly, bunnie's previous take has been that fabbing your own silicon is likely less secure than using an fpga due to supply chain security
if your asic if compromised in tranist, it's a total game over. if your fpga is compromised in transit, the attacker has to have some knowledge of target bitstream
it has been argued that by making it easy for end users to rearrange the bitstream, an fpga can be more secure than an asic
I looked through the link and that does not seem to be what he says. He is just talking about how much verification you need to do, like I am trying to do.
It is shortsighted to view making your own ASIC as less secure. The supply chain weaknesses exist whether or not you make your own hardware. Making your own hardware can potentially limit your exposure to systemic baked in vulnerabilities. Additionally, after-manufacture exploits (as in the NSA interdiction of Cisco router shipments) are easier for mass produced goods.
There are likely edge cases involving small, easier to bribe manufacturers, but I'm not sure you can make broad generalizations on that possibility alone.
Calling it an "edge case" dismisses the fact that Facebook/Apple/Google are never going to make the kind of openly verifiably secure device without a colossal shift in the market. We're not going to see mass produced goods that target the same market as Precursor, so all there is in this space is "small, easier to bribe manufacturers".
It's great that Facebook/Apple/Google can securely manufacture devices, with a supply chain thats verifiable by them, but externally, TouchID's security amounts to "we're Apple, trust us". That's not good enough for the target market for Precursor.
>That's not good enough for the target market for Precursor.
I know? Your two points are really disjoint.
>so all there is in this space is "small, easier to bribe manufacturers".
I think the amount of people who will willingly take money for nefarious purposes is smaller than you think. I would worry more about misguided cooperation with law enforcement. See, for example, the case of the Russian trying to bribe a Tesla employee to install malware. There may be factors like the belief of the employee that the breach attempt would be caught, but it would be very easy to pass the employees actions off as a mistake.
My real point is that between large manufacturers that are likely to have moles or cooperate with law enforcement and smaller manufacturers that are less likely to have moles but may be easier to compromise in general, it's probably about even between them, maybe siding with smaller manufacturers depending on what you have available.
In any case you have trust issues with either one, so I don't see why pointing out "Trust us is not enough" is topical.
With a smaller manufacturer you are more likely to get in to see their facilities and can build a personal relationship. With a larger one that is likely impossible.
The article actually posted to this HN thread contradicts that or at least would imply a change of stance:
> We are also using the FPGA in Precursor to validate our SoC design, which will eventually give us the confidence we need to tape out a full-custom Betrusted ASIC, thereby lowering production costs while raising the bar on hardware security.
There is no change of stance, but there is a subtlety. The hair to split here is that between "security" and "trustability".
I'm defining "security" to include the ability of a device to keep a secret after it's been verified and provisioned. This is also known as "tamper resistance".
I'm defining "trustability" as the ability of one to draw the conclusion that the device in front of you is in fact the device you think it is. It's an essential pre-requisite for security, but it is not identical to "tamper resistance", which is probably what more people expect when they hear the word "security" (that is, security sounds more like a bullet proof vault than a correctly constructed system).
From the trustability standpoint, even a sophisticated technologist will typically have no evidence-based reason to trust any given chip, because they likely have no tools on hand that can verify its correct construction without simultaneously destroying the chip. For example, not many people have a ptychographic x-ray system at home.
On the other hand, you may have some reason to trust an FPGA, because with the tools in your home you can craft your own bitstreams and designs that incorporate countermeasures to potential exploits buried in the FPGA. It tips the balance of power from a "hands up I surrender" situation to a cat-and-mouse game. Furthermore, there is a limit to how deep the rabbit hole can go, because with sufficient countermeasures the circuitry required to backdoor the design without detection becomes larger than can fit within the raw size of the FPGA's silicon.
Thus, an FPGA is "more trustable" than an ASIC in the sense that there is any direct evidence-based reason at all for trusting it.
However, an FPGA is not necessarily more tamper-resistant than an ASIC. If your adversary has full physical possession of your device and has no regard to leaving it intact, then they have a number of venues to attack both the FPGA and the ASIC.
What this statement implies is that a properly designed ASIC will generally raise the bar on how hard it is to extract secrets compared to an FPGA, assuming an adversary with direct physical access to the device and no regard to evidence of tampering with the device.
More importantly, however, the ASIC will be cheaper. That is really the main point of that statement.
Wow, its so cool to hear words that resonate. My own thoughts on trust-ability also run to minimalism, but, in an attempt to reach something even better than cat-and-mouse, also goes the measurement of power draw. There is a nice sharing of concerns here, since most users want their devices to run a long time, and it also happens to be the case that power draw scales with computation, and subversion of the kind you're talking about requires computation, and hence power-draw. So if you have a baseline quiescent draw, you can measure your application(s), and anything above that is a possible threat.
Another area that I've been thinking about, but I see you haven't written about here, is the issue of boot and IO. I would love to see IO systems greatly simplified, to the point where input devices are designed to just write measurement to memory on power on, and stop on power off. In the same way, devices periodically check a fixed memory region for something to write. If the input memory region was large enough, this would be a perfect opportunity for a poor-man's circular buffer of arbitrary size, which has lots of applications. Indeed, you could have explicitly zero copy use of input if you could guarantee that your process completes before the buffer is overwritten, which you can guarantee by just making it really big (or carefully tuning if you're memory constrained).
The goal of all of this is to embrace the modern era of computing which is NOT memory constrained at all, and to build computers that function more closely to their Platonic ideals. A system like yours seems to get the closest I've seen to this goal, modulo a few things mentioned above.
There's a small-scale IC fabrication system under development. It costs $5-30M, fits in an office, and can manufacture 0.5-inch wafers with CMOS and MEMS. The company provides training and rents out time on the machines.
While writing this comment, I discovered that there's a website selling new old stock? Can't vouch for its authenticity, but you should go for it! https://shop.pocketchip.co/collections/frontpage/products/po...
If you want a small device to play old games on via an emulator, I can recommend Pocketsprite [1]. You can even assemble one yourself.
FWIW, I'm looking for a small portable screen (1080p, IPS) to combine with my MBP 2015 (via TB2 or HDMI but I also want it to have USB-C for future compatibility).
[1] https://pocketsprite.com
https://www.google.com/search?q=m5stack+stick+c
Sadly, most of these points are mutually exclusive. Android tablets are built for the average user who would have neither use for an hackable OS nor for exposed GPIO ports. Adding them would represent an added cost with no returns with respect to the market they're into. Also, most if not all Android tablets - actually their manufacturers - are hostile to letting techies install their OS of choice, and implement tactics to discourage them, mainly keeping the hardware closed. To date, the Pinetab seems the best example of a tablet designed from the ground up to be of interest both to users and tinkerers because it encourages to experiment with open operating systems. https://www.pine64.org/pinetab/
https://hackaday.io/project/164845-dlt-one-a-damn-linux-tabl...
However, Precursor is more about evidence-based hardware security, and less about features and usability. To better understand the principles behind Precursor's design, please have a look at https://www.crowdsupply.com/sutajio-kosagi/precursor/updates....
The TL;DR is that it's a development platform for applications that strongly require secure and/or trustable hardware.
https://www.kickstarter.com/projects/745629624/cutiepi-raspb...
But if it's well-marketed to the hobbyists, and software support is adequate, then maybe.
Mid-to-high 5-figure to low 7-figure unit sales (for a 'wildly' successful device like the Raspberry Pi) is what it seems to be looking like for a successful open mobile(-ish) device. As long as the businesses offering them are sized appropriately, it's doable. Just need to be smart about re-using enclosure designs etc and have long production runs to help amortize things like regulatory certifications etc. For hacker devices, they can sell this stuff for several years between major revs and their customers appreciate the longer product/parts availability.
Is there something I'm missing that means developing a new OS (https://github.com/betrusted-io/xous-core/) works better for Precursor? Keen to understand the rationale, cause I think I'm probably missing something here!
edit: There's a good explanation on the CrowdSupply page - seems like it's in order to make it a more secure platform:
> Simplicity addresses the reality of only having 24 hours in a day. Even though the full source code for the Linux kernel and Firefox is published, nobody has the time to personally review every release for potential security problems; we simply trust that others have done a good job, because we have no other choice. Precursor rolls the clock back to the early 2000’s, when mobile computers were powerful enough to be useful for single tasks, while simple enough that individuals or small teams could build them from scratch. But don’t worry, despite its simplicity, Precursor’s computational capability exceeds that of the Palm Pilot series. It’s more on par with a Nintendo DS: sufficient for core security tasks such as authentication, instant messaging, crypto wallets, and even end-to-end encrypted voice calls.
(Not that it's an easy with a simpler software stack either of course but you can have a fighting chance at least)
This formfactor, combined with a LoRa transceiver would be epic as an off-grid or fallback comms device.
I get fuzzy cyberpunk feelings imagining it.
Bunnie's projects are always intriguing. I'm still amazed by the investigation into sd card controller chips.
Sticking LoRa in this would be awesome, (e.g. https://www.meshtastic.org/), but I can understand why it has wifi.
Definite cyberdeck potential
[1] https://www.adafruit.com/
If that's too ghetto for you, have a look at the M5Stack series. A main unit (ESP32, screen, speaker, TF card reader, in a case with some buttons) costs $35, and the battery module you can stack on is $10. There is even a keyboard and a gameboy-like attachment.
I like the look of the Precursor, but personally the FPGA is a bit off-putting, just because I've never gone down that road.
> if your application does not require a large display and a keyboard, you can simply remove them and replace the bezel with a full-sized circuit board
Just the other day I found out about WiPhone: https://www.kickstarter.com/projects/2103809433/wiphone-a-ph...
The project appears to be in a "limbo" state.
[1] https://www.seeedstudio.com/Wio-Terminal-p-4509.html
One thing I can't find any detail on is the keyboard. Making a keyboard from scratch is well outside of usual low-volume productions and there aren't any readily available parts in this form factor as far as I know. How is the Precursor's one made/sourced?
I'm using a Blackberry keyboard for my project, but that's obviously not scalable.
—
I find this device extraordinarily appealing (will definitely be backing). Bunnie is a hardware hacker’s hacker, the project has at least 2 years of development behind it. It will most definitely ship, and work. Ha.
But — I’m specifically excited because this seems like an ideal platform to build whimsical mobile hardware projects.
My dream of a 2000-era electronic organizer with a “retro” (non touch) display, with physical keyboard, and battery, and programmable/hackable and fully open... this is truly a dream come true.
Why couldn’t this become the democratizing mobile Arduino-like hobbyist “base”?
I’m extra, extra excited about it!
(And dream of adding LTE and making a retro minimal... phone OS/“app”? Fast email + wikipedia clients??)
The accelerometer is the LSM6DS3, I'll refer you directly to the manufacturer's website: https://www.st.com/en/mems-and-sensors/lsm6ds3.html
You can find out more about how it's integrated at https://github.com/betrusted-io/betrusted-hardware/blob/mast... (note: this is a "DVT" schematic, bugs were found, they are currently being fixed, but they aren't related to the accelerometer).
The TL;DR is that the accelerometer is integrated so that it's in the "always on" untrusted domain, so to access it from the main FPGA "SoC" you have to go through the system controller FPGA ("EC" as we call it). The idea is for it to be available in power down states for anti-tamper, hence the extra layer of complication.
Talking to it requires a call to the EC via the "COM" bus (https://github.com/betrusted-io/betrusted-soc/blob/master/fw...). The EC driver itself is based on the C-native library provided by STM and translated into Rust bindings. It's a little gross: https://github.com/betrusted-io/betrusted-ec/blob/master/sw/...
Hope that helps.
Well, for one thing, the XC7S50 FPGA costs over $50 just for the chip. This device is going to be much more expensive than an Arduino or even a Raspberry Pi.
I do hope that the form factor, “polish” — how much of a finished product the Precursor is, and the possibility of programming/extending it can serve as an inspiration/starting point for future hobbyist mobile tech.
I know that it’s a very heterogeneous mix, but just to note some contemporary devices that evoke “similar” feelings: Panic’s Playdate [0] and the recently crowdfunded Flipper Zero [1].
Maybe all of these remind me in some ways of the Gameboy, electronic organizers from the 2000s [2], pre-smartphone Symbian Nokias [3] (and every qwerty/slide out keyboard device from back then), all of which I grew up with.
But, it also seems like there’s a lot of interest now to create digital experiences that aren’t tied to existing social media platforms, aren’t engineered to simultaneously maximize addiction and profit (through advertisement and the sale of personal data).
Developing towards that future is immensely exciting.
0 - https://play.date/
1 - https://www.kickstarter.com/projects/flipper-devices/flipper...
2 - https://en.m.wikipedia.org/wiki/Electronic_organizer
3 - https://www.pcmag.com/news/the-10-best-symbian-phones-ever
Is that possible, in principle, in a Spartan 7?
It is easy to believe that you would need to pre-generate bitstreams for each configuation, and could only swap them in verbatim, not generate them on-the-fly, but downloading from a library, perhaps with parameterized choices, could increase flexibility.
In the specific case of Xilinx FPGAs there was a feature introduced in the original Virtex called "partial configuration". This has been present in all its products for the last 20 years. It allows a design to be broken into parts such that one part may be replaced even while the rest of the FPGA continues to work normally. This is pretty hard to use and the interface between the part being swapped and the rest of the circuit is rather tricky, so it has been use more for cool demos than actual products.
It is possible to have the equivalent to this with non Xilinx FPGAs by having several smaller ones connected to each other on a board. Then dynamic reconfiguration of one can happen while the others continue to work normally.
* Would it increase the complexity a lot to provide a linux-capable SoC as an additional chip? (OK, this could be a daughter board)
* "iCE40UP5K SG48, 98% utilized" <- isn't it a bit restrictive to start with such a low room for growth?
The main CPU is a Spartan7 XC7S50, which has plenty of space for things like crypto accelerator cores beyond the primary RISC-V CPU.
Plain TLS stuff as the sibling comment suggests is entirely uninteresting to me-- a boring software implementation is more than fast enough even on a 100MHz device to accomplish whatever that 100MHz device is going to accomplish. (I assume bunnie's Betrusted soc will be faster than 100MHz too).
But what you can't do from general software is get something which is extremely robust against EMI and power sidechannels.
Similarly, while plain ECDH/etc. will be more than fast enough even in software for 99% of applications you'd want to run on a small device like this, various zero knoweldge proofs and other fancy constructions may still be painfully slow (as they're often noticably slow on desktops).
Unfortunately the ed25519 curve is probably not really the best choice there for a primitive to optimize due to the cofactor being an extraordinary nuisance for other applications outside of plain signatures and key agreement. ... but group choices for ZKPs are by-far not a settled question.
Luckily you can use an optimized ed25519 to implement ristretto255, which solves this problem :)
https://pyra-handheld.com/boards/pages/pyra/
> enclosure’s length and thickness are are parameterized.
The iCE40UP5K will work with any IceStorm-based FOSS toolchain (including SymbiFlow) as well as Lattice's free first party Radiant tool (and I think also the older IceCube2 toolchain).
It's a little odd that they're different vendor parts / on different 1st party toolchains, but it does look like you could program everything through the FOSS tools, albeit probably missing a few features (Last I looked a couple of the special purpose blocks in both the Xilinx 7-series and the UltraPlus were not fully understood by the FOSS stuff; that may have changed).
I've been meaning to try Radiant, I teach some classes on top fo Vivado + Artix7 FPGA dev boards, and it's so much less awful than ISE (Xilinx's old toolchain) I'm still pleased with, but there are some nice, affordable iCE40-UltraPlus boards coming on the market, and if Radiant is less of a hassle (Vivado is a 25GB install and not _entirely_ beginner-friendly) I'd consider retooling.
The image? Sure, could easily be backdoored, but that’s what open source is for; auditability.
Edit: FPGA silicon is kinda backdoored by definition thanks to JTAG configurability/readability. (Barring cases where keys are used.) So I think the really interesting thing would be addition of nefarious logic by the design tools.
Either the silicon, the synthesis software, or both could be compromised. Per leaked documents usually what gets attacked is random number generation, but there are more avenues I am sure.
You can usually turn off JTAG, but having JTAG or other debug interface not be permanently disabled is actually an exploit class.
To fight such an attack, the output of deterministic builds running on geographically dispersed systems with disparate stacks (physical, cloud, newly purchased, multiple OSs, etc.) may be compared before release.
The protected body of software should also include the firmware upload utilities.
Another attack, given the open source nature of the device, could be distributing cheap, compromised units broadly after the fact to ensure they are widely adopted.
>Another attack, given the open source nature of the device, could be distributing cheap, compromised units broadly after the fact to ensure they are widely adopted.
I like thinking about high-level threat models as much as the next guy, but these two statements seem to be at odds. Unless by "compromised units" you don't mean what I think you mean.
But I do not know if the Xilinx reversing effort supports the Xilinx chip. That project is in a much earlier state of development.
And I do have to wonder if an ecp5 (supported by trellis project) wouldn't have been able to do the job.
How deep do you want to go down the rabbit hole? Are you capable of fabbing your own silicon?
if your asic if compromised in tranist, it's a total game over. if your fpga is compromised in transit, the attacker has to have some knowledge of target bitstream
it has been argued that by making it easy for end users to rearrange the bitstream, an fpga can be more secure than an asic
https://www.bunniestudios.com/blog/?p=5706
It is shortsighted to view making your own ASIC as less secure. The supply chain weaknesses exist whether or not you make your own hardware. Making your own hardware can potentially limit your exposure to systemic baked in vulnerabilities. Additionally, after-manufacture exploits (as in the NSA interdiction of Cisco router shipments) are easier for mass produced goods.
There are likely edge cases involving small, easier to bribe manufacturers, but I'm not sure you can make broad generalizations on that possibility alone.
It's great that Facebook/Apple/Google can securely manufacture devices, with a supply chain thats verifiable by them, but externally, TouchID's security amounts to "we're Apple, trust us". That's not good enough for the target market for Precursor.
I know? Your two points are really disjoint.
>so all there is in this space is "small, easier to bribe manufacturers".
I think the amount of people who will willingly take money for nefarious purposes is smaller than you think. I would worry more about misguided cooperation with law enforcement. See, for example, the case of the Russian trying to bribe a Tesla employee to install malware. There may be factors like the belief of the employee that the breach attempt would be caught, but it would be very easy to pass the employees actions off as a mistake.
My real point is that between large manufacturers that are likely to have moles or cooperate with law enforcement and smaller manufacturers that are less likely to have moles but may be easier to compromise in general, it's probably about even between them, maybe siding with smaller manufacturers depending on what you have available.
In any case you have trust issues with either one, so I don't see why pointing out "Trust us is not enough" is topical.
With a smaller manufacturer you are more likely to get in to see their facilities and can build a personal relationship. With a larger one that is likely impossible.
> We are also using the FPGA in Precursor to validate our SoC design, which will eventually give us the confidence we need to tape out a full-custom Betrusted ASIC, thereby lowering production costs while raising the bar on hardware security.
I'm defining "security" to include the ability of a device to keep a secret after it's been verified and provisioned. This is also known as "tamper resistance".
I'm defining "trustability" as the ability of one to draw the conclusion that the device in front of you is in fact the device you think it is. It's an essential pre-requisite for security, but it is not identical to "tamper resistance", which is probably what more people expect when they hear the word "security" (that is, security sounds more like a bullet proof vault than a correctly constructed system).
From the trustability standpoint, even a sophisticated technologist will typically have no evidence-based reason to trust any given chip, because they likely have no tools on hand that can verify its correct construction without simultaneously destroying the chip. For example, not many people have a ptychographic x-ray system at home.
On the other hand, you may have some reason to trust an FPGA, because with the tools in your home you can craft your own bitstreams and designs that incorporate countermeasures to potential exploits buried in the FPGA. It tips the balance of power from a "hands up I surrender" situation to a cat-and-mouse game. Furthermore, there is a limit to how deep the rabbit hole can go, because with sufficient countermeasures the circuitry required to backdoor the design without detection becomes larger than can fit within the raw size of the FPGA's silicon.
Thus, an FPGA is "more trustable" than an ASIC in the sense that there is any direct evidence-based reason at all for trusting it.
However, an FPGA is not necessarily more tamper-resistant than an ASIC. If your adversary has full physical possession of your device and has no regard to leaving it intact, then they have a number of venues to attack both the FPGA and the ASIC.
What this statement implies is that a properly designed ASIC will generally raise the bar on how hard it is to extract secrets compared to an FPGA, assuming an adversary with direct physical access to the device and no regard to evidence of tampering with the device.
More importantly, however, the ASIC will be cheaper. That is really the main point of that statement.
Another area that I've been thinking about, but I see you haven't written about here, is the issue of boot and IO. I would love to see IO systems greatly simplified, to the point where input devices are designed to just write measurement to memory on power on, and stop on power off. In the same way, devices periodically check a fixed memory region for something to write. If the input memory region was large enough, this would be a perfect opportunity for a poor-man's circular buffer of arbitrary size, which has lots of applications. Indeed, you could have explicitly zero copy use of input if you could guarantee that your process completes before the buffer is overwritten, which you can guarantee by just making it really big (or carefully tuning if you're memory constrained).
The goal of all of this is to embrace the modern era of computing which is NOT memory constrained at all, and to build computers that function more closely to their Platonic ideals. A system like yours seems to get the closest I've seen to this goal, modulo a few things mentioned above.
Cheers, and good luck (from a backer).
https://www.yokogawa.com/yjp/solutions/solutions/minimal-fab...
HN post: https://news.ycombinator.com/item?id=24540562