> But his mention of "if we release an updatable chip" sounds... concerning? It sounds like he is focusing on people being able to audit the code they're shippi

> But his mention of "if we release an updatable chip" sounds... concerning? It sounds like he is focusing on people being able to audit the code they're shipping rather than ship their own applications. Perhaps he could clarify what "non-updatable" means for the normal SKU? This is driven by the paying customer (not the end user: but the entity actually writing checks with lots of zeroes on it and taking in truckloads of chips). It is a fact that the biggest, highest volume paying customers to date for SEs would assume that such chips could only be updated through means that the customer controls. Thus, a business manager doing volume-driven research to craft a chip specification for such a market would reasonably conclude this is a mandatory checkbox for generating volume orders. The flip side is the assumption that nobody in their right mind would pay for a chip that could be fully wiped and/or updated by end users. And to a first order, the conclusion is correct: I can't think of anyone who would write a check big enough to fill distribution channels with such a SKU. Keep in mind that chips are run by the wafer, and things don't get interesting until you run about 25 wafers in a single lot, so you're looking for someone to underwrite the cost for upwards of 100k devices until a sustainable market for such fully updateable chips materializes. This is where the "obviousness" of an open source approach comes crashing into the reality of market-driven hardware economics. It seems pretty obvious to people like you and me that we should have fully updateable SKUs that can be wiped and provisioned by end users. But there's a chicken-and-egg problem of building the hardware, so that OSS developers can write the software stack, then hopefully getting adoption by volume businesses; but volume business wouldn't adopt until the hardware was cheap enough and the software stable enough. The angle I'm hoping to exploit is that because the chips are done with no OTP and only ReRAM, we can release a fully-open and updateable SKU as a late-binding wafer sort option. So instead of having to buy a whole lot of wafers, we can split out a portion of a larger run as the "open source developer's" SKU, at a volume that could be underwritten with say, a crowdfunding campaign. Thus, you'd have the same design, fabricated using the same masks and literally on the same wafer, but based on how some ReRAM bits are configured in the factory, one will accept updates, and the other will not. It's a compromise, but that's the angle I'm trying to work, at the very least. And until someone is willing to step in with a few million bucks to make the demands of other paying customers irrelevant, it's maybe the only practical approach I can see at the moment to break the chicken and egg cycle. I think the team is on-board with the approach, but there's a lot of technical details to work out, which is why there is an "if" qualification. For example, if you totally wipe all the ReRAM, but you need some extant code to write ReRAM in the first place, you again have a chicken and egg problem. This problem is solvable at wafer sort using probe pads that can put the initial code in place to allow bootstrapping, but how to extend this to a convenient user-accessible solution is an open problem. This is particularly troublesome for SKUs that are destined to be packaged in minimal packages, e.g. an 8-pin SO package or a smart card format, where you simply lack the pins to expose a provisioning port. This is also, unfortunately, where all the volume is. It could be that the open source SKU simply comes in a package with more pins and we burn precious I/O to expose something like a permanent JTAG interface. Muxing over the JTAG pins to other I/O can also help mitigate the challenge, but it adds complexity and verification/shipment risk if the mux circuit is defective, and again, a hardware bug costs millions of dollars in this scenario so no decision can be considered "trivial". Nobody wins if I try to force some clever provisioning solution that turns out to be broken (also keep in mind that smart card I/O is weird and fussy, it's not a generic CMOS I/O cell). Also keep in mind that creating a version with a larger package could be a non-starter if we don't also have demand from a "paying" customer to fund the R&D and supply chain to push out that package format. Chip packages aren't free, and also come with substantial up-front costs and high minimum volume requirements.