How Raspberry Pi Is Transforming Tech with Eben Upton

Well thank you for having me.

Yeah, it's an increasingly, it's a scarily long story now, I guess, and I've been telling the story for most of the history of Raspberry Pi. I was, let's see, I'm a software engineer, and I grew up in the 1980s in the UK, and like a lot of people who grew up in the 1980s in the UK, I had a home computer, and I became a software engineer by accident, and I enjoyed it, I very much enjoyed it. I've always been interested in the business, I think I've been as interested, I suppose, in the business of technology as in technology itself. I started a games company when I was an undergraduate here in Cambridge, and so yeah, I've always been kind of interested in being a software engineer, been interested in games and graphics, been interested in business. And I got involved in teaching at the university quite a long time ago now, nearly 20 years ago, and really was struck by the disappearance, I guess, of young people over that maybe 10-year period from 1995, 1994-95 when I applied to Cambridge, 96 when I came up, and then 10 years later, that sort of decline, disappearance of people who had that kind of accidental background. Still people who are interested, you know, we never let anyone into Cambridge who wasn't super bright and super interested in computing, but I think we got to a point by maybe 2008 where we were letting in every single applicant who was interested in computers, and that's not a great place for a university like Cambridge, it's a tier-one university, right? If any university shouldn't be struggling to recruit undergraduates, it should be this one. And so I was struck by that, and really Raspberry Pi was my response, the response of several of us, including my wife Liz, our response to this realization that this thing that we really loved, this thing that had been central to our lives, just wasn't there anymore: the programmable home computer. We launched Raspberry Pi in 2012. We sold a huge, we sold 100,000 Raspberry Pis on the first day. We also launched on the 29th of February, which has constrained, we always say it constrains our birthday party choices. We've had three really cracking birthday parties now. And I sold a lot of Raspberry Pis very quickly to enthusiasts originally, but they did then make their way into education, kind of via enthusiasts, a lot of those enthusiasts volunteer or teach or are simply parents. And then, I guess, as you discovered, the platform is also useful for industrial applications, for embedded in industrial applications, and that's kind of the journey we've been on with Raspberry Pi, which is increasingly trying to service those embedded in industrial applications while staying true, I guess, to the original mission, which is around enthusiasts and education, right?

Yeah, yeah. And I mean, that's the story, you know, the surprising story for Raspberry Pi in embedded in particular is that there were lots of companies like yours who were, I guess, to the extent they were making hardware, either they weren't able to start because they had no platform, or they had started and they were running with some platform they built themselves, and so you had these kind of reluctant hardware companies, they were only hardware companies because they needed a venue, but where their differentiation was software. And really, Raspberry Pi has grown in that space by allowing people either never to start making hardware, or to allow people who were making hardware and weren't enjoying it to stop making hardware, at least to stop making the middle bit of the hardware, the compute complex in the hardware. Yeah, because I remember we did look at, I think it was Nvidia had one of the chipsets you could build, but even if you were like a small company, the MOQs were completely unrealistic unless you were like a multinational. It was a complete game changer back in the days, right? Yeah, that's it. I mean, if you're building, even today, if you're building, obviously there comes a scale point where a lot of our thinking at the moment around how we evolve the business, how we develop an offering for people who are at those higher volume points where it starts to become realistic to leave the Raspberry Pi, we talk about people graduating. And you know, we relax, we don't need people to, as long as we have a steady flow in the industrial space, as long as we have a steady flow of new people coming through with new designs, it doesn't necessarily matter to us that some people, it's a source of pride for us, a source of joy that we bootstrap people to a point where they can depart our ecosystem. But I think increasingly, you know, you do get these people once they get out towards maybe 100,000, if you're making 50,000 units a year or something, it's almost never the right thing to do to build your own compute subsystem, you should always outsource. And to the extent people do outsource, we obviously think that we're a good candidate for that. But a lot of the work we do now is about how, when we get those people to get into that 50 to 100,000 unit stage where they make that second make-versus-buy calculation, you win the first make-versus-buy calculation, it's how do we keep people with us? What services, what products, sometimes customized products, we can offer people at that volume scale which give them a reason to stay with us. No, yeah, still not to the million unit range, but out into that 400, 500,000 unit range, right? Yeah.

Yeah, and that sort of feeling that there is both a source of demand there, a source of, but also a source of supply of knowledge. But one of the advantages Raspberry Pi has locked into, I guess, is if you are selling one or two orders of magnitude more product than the next largest product in your class, all of the, if a customer has a problem with the platform, generally somebody else has had the same problem in the past and either they figured out how to fix it or we figured out how to fix it for them, and so you've got that virtuous cycle. Absolutely, absolutely. And I think that was a big part of it. I think it's definitely true that a lot of bug fixes were found on the forum and whatnot, but also I think in the early days, a lot of people like myself were on the waitlist and they finally got this device and they were like, 'And now what?' and they were looking for a use case. Yeah, you know, there was a lot of those first 100,000 units. Yeah, there's always been a kind of meme knocking around that Raspberry Pis always end up in drawers, and I kind of have this, there is this wonderful alternative: you know, we sold 60 million Raspberry Pis now, you know, those drawers have got to be pretty full by now. So it isn't true that Raspberry Pis end up in drawers, but I think it is the case that a lot of people do buy them and then, as you say, think, 'Yeah, what do I do? This is obviously a cool thing, this is a thing I have to have in my life, but why, what do I do?' And you see people turn up on Reddit, 'I've got a Raspberry Pi, what do I do? Give me a project.' And so that's another thing where you have this huge supply. I think even the strap line for the subreddit says something like 'Not just Kodi and Magic Mirrors' because Kodi and Magic Mirrors are the kind of projects that people get pointed to when they buy out of the box.

Well, I mean, look, to some extent the whole thing is surprising. I think that's the first thing to emphasize: the whole thing is surprising, right? Because remember, we're trying to get 200 applicants to computer science, you're trying to get 300 applicants to computer science, so you're thinking, well, a thousand units in the hands of the right thousand kids, you get a 10-to-1 success rate, you get your extra 100 kids. So anything done with a Raspberry Pi that isn't some very structured, Cambridge-centric, possibly open day-centric farming of these things out to people is still in the back of my mind strange and unnatural to me. In terms of the sort of things that people do, I think there's a whole strand of 'make a pro business' this idea that people buy Raspberry Pis to build their own personal passion projects, and then they go on social media and they talk about their passion project, and suddenly they realize that there's a market for this. So I think that kind of, you know, we talk about ESG, talk about what's the social good that Raspberry Pi does, and of course the foundation is a huge part of that. We've returned about $50 million to the, the thing I run is Raspberry Pi Limited, the trading company, the thing that does the engineering and sells the product. The Raspberry Pi Foundation is my shareholder, and so I give money to the foundation to do its work. We've returned $50 million to the foundation, so there's a huge amount of good ESG social benefit from the work they do. And of course, we also think that there's a social benefit when we sell a Raspberry Pi to a child. But it's that, I actually really believe that that social benefit of helping people start companies, whether it's enabling you guys, or if it's just somebody who makes a personal passion project, sticks it on Twitter, and then sells a couple hundred units, uses Kickstarter to fund a couple hundred units for people, those are all life-changing experiences. They can change the vector of somebody's life.

So I do love those. I mean, the individual kind of funny ones, I mean recently obviously a lot of LLMs. I saw a wonderful Llama 3, the 8 billion coefficient Llama 3, running at about two tokens per second on a Pi 5. So I think what's nice is, you know, you saw as soon as the Llama stuff leaked last year, you saw people running original Llama on a Pi 4, and there you were getting a token every seven or eight seconds. And so what you've seen is this big jump in performance, say 3x or more jump in performance between Pi 4 and Pi 5, and that's plugged into this inevitable trend that always happens to models, where people discover that you can make more heavily quantized versions of models, you can make sparser models, smaller models, more heavily quantized models, and get really pretty good performance. So those two things got put together to a point where you can now on a Raspberry Pi 5 have a plausible conversation with a Llama LLM. So I like that way that Raspberry Pi has always tracked what's cool. You know, there was a huge amount of retro gaming happened on Raspberry Pi when Nintendo were making those little mini NES. When it's LLMs, when it was CNNs, when it was image processing, when AI, remember two years ago AI was the big thing? Yeah, right, that was AI. It changes every year. People always talk to me like, 'You should put an AI accelerator into a Raspberry Pi.' Like, yeah, but which AI? I mean, it takes five years to go from chip concept to shipping Raspberry Pi. Yeah, the 2712 which is in Pi 5, 2712 was in flight when COVID got loose, right? It was in development when COVID hit. So yeah, these are hugely long projects. And that's really only, you think of the Transformer paper from 2017 or 2018, so in practice Transformers were maybe a year old at the point where we started that chip. So there is always that change, but you see Raspberry Pi tracking what's cool, and that's wonderful.

Yeah, I think it's good to emphasize it happened to everybody. There was occasionally you would meet somebody who seemed to believe that it only happened to Raspberry Pi. I remember sitting there reading some of these comments online on a day where I had got, we were re-roofing the little barn, large shed at the back of my yard, and the only way of being able to get wood batons to build the roof structure or to build the tiles would mount on to was to go down to the roofing yard at 6 a.m. and buy these from a junior employee, because he knew that as soon as his supervisor turned up, his supervisor would say no, you can't buy those roof batons because we need those for our roofing stuff. So you literally could not buy wood, and wood grows on trees. So this was an omnipresent crisis, and unfortunately semiconductors were particularly affected. You know, these pictures of huge car parks at Volkswagen where they were building, they had the one engine management computer and they put it into a car, build a car, put it into the car, drive into the parking lot, take it out of the car, bring it back in, put it in the next car, drive that car into the parking lot, and you have these vast supplies of cars waiting for engine management systems. So yeah, it hit us for almost exactly 24 months from March of 2021 through to April of 2023, those were the bad months for chip supply. And in terms of the peak impact on end users, that was in the second half of 2022, early 2023. It really was the darkest before dawn.

We did a million, if you think we in a good year we'll do seven or eight million units, we did a million units in the first four months of last year, so an annualized rate of three million units. So it really was, and then suddenly April, May last year, it just turned on like a light switch. Chip supply turned on in April, finished goods supply turned on in May, and it was like a light switch going on. But it was brutal. And of course we had to make difficult allocation decisions. We have OEMs like yourselves who have invested in the platform and who have made a choice. You're not a huge company. When people talk about having had to prioritize OEM customers, people think we're talking about IBM or something. And we do have some genuinely huge OEM customers, hundreds of thousands of units a year, but the majority of customers are a little bit smaller than that. They don't have infinite agility because often their solution is very entwined with the capability of our hardware. So we had to make those difficult decisions to prioritize OEMs, to work more closely with OEMs to understand demand, because of course everyone is incentivized to hoard in a difficult situation, like toilet paper in 2020. But most people understand that if you can win their trust, and when someone comes to you and says I need 10,000 Raspberry Pis, and you say well how many do you really need today? We'll do 50 today and 50 next week. And what we were able to do by building this sales organization in anticipation of selling a lot of Raspberry Pis from 2020 onwards, actually what we ended up doing was using that organization in an anti-sales mode to intensively manage customer relationships, win OEM trust, and then use that to put people on a drip feed. And there was that dream that if we got a chip, because we were throttled by upstream silicon supply, if we got a chip then we wanted to get it onto one of our products, into a customer's hands, an OEM customer's hands, into an OEM customer product, and into their end customers' hands as quickly as possible. So you're trying to discover all of the pools. The way we got through this was we went out and tried to discover where all the pools were, not just of upstream components for us or downstream finished goods, but us as an upstream component for our customers and their downstream finished goods, and said let's just take all of those buffers, let's just lean them out, because there's one to two million units probably in all those buffers. Let's just lean those buffers out. And if you think we probably had a deficiency of 3 million units across the crisis, in so far as we were able to find one to two million units through that kind of activity, it really did help mitigate the impact. Yeah, for everyone. And I think definitely the sales organization has improved a lot, at least for my experience, it has become a lot better. Our relationship has definitely improved a lot as well. It was a bit more chaotic before, and now it's more structured, so that's a good thing on our end. I mean, they're an amazing team, and generally mostly very young people in that team. It's probably the youngest average, we do have a few pretty senior people, but they're mostly very young, incredibly bright people. I think we've always been pretty good at finding engineering talent here, but I think what Mike has been able to do is he's really found this very rich seam of very intelligent, very capable, very motivated young people to staff that.

No, I think that was the right call from a moral perspective. I think look, it was horrible. But as I say, people think you're talking about IBM, and you're not. You guys are big, and you guys are very big by the standards of our OEM customer base. We have a lot of people who just need 50 Raspberry Pis a year, and they put them into some product which sells for a few thousand dollars, and that gets them a few hundred thousand dollars of revenue, and that pays to keep the lights on, pays the mortgage. And if they don't get the 50 units, they go bust. And it was really hard for me to turn people like that away. Yeah, and I think that is correct in the sense that if you can't deploy your Kodi at home, nothing much is going to change, whereas there are people's livelihoods depending on this in a lot of these ISVs. I mean, there was an observation that many of, and this is why I think the vast majority of our fan base, our enthusiast base, did understand the difficulty of the decision and the inherently short-term nature of the problem.

And so people were prepared to dig into their existing stocks, because that's the other big pool of inventory. If we talk about them going in drawers, they don't go to drawers, but many of them go into projects. And one of the things that drove the surprising success of Raspberry Pi, I think, was people putting Raspberry Pis, so cost-effective that you could put it into a project, and then when you were finished, you'd leave it in the project and buy another Pi rather than scavenging it out of the project. And that did mean that there was a lot of inventory. And so there was quite a thing I observed quite a lot on Reddit was people talking about their attrition rate, people talking about, you know, we did our best to communicate to people and give them an idea of, and I think it did go on for six to nine months more than I think when we first communicated to people. I gave people an idea in mid-2022, and it was in the end over in the second quarter of 2023. But you saw people talk, looking at what we were saying and looking at the rate at which they owned Raspberry Pis and the rate at which they were destroying Raspberry Pis by sticking 12 volts on them, and saying, 'Look, this is the end of the road for me. I think I will exhaust my stash in 15 months' time. Please be back in stock in 15 months' time.' And so look, it was a horrible situation. It is not something that, it's one of those things where you make the least bad decision. They're all bad decisions, and you try, that's the right lens, you try to make the least bad decision and you can sleep at night because you think, 'Well, actually, was there a better thing I could have done today?' But it was a once in a lifetime, probably once in an industry. There have been cycles, I remember when you couldn't buy MLCCs in 2017, you couldn't buy caps, the cap vendors were swaggering into your building, 'Do you want to buy some of my precious 100n caps?' So there were always cycles, but I think this is a super cycle, this one is as bad as it's ever been since the invention of solid-state electronics. So it's quite something to come through it at all. For us and for our OEM customers and for our enthusiasts and for the educational mission, survival is victory. And we survived, and we got Raspberry Pi 5 out at the end of it. That was the one thing I am proud of. There's not a lot to feel unproud of. The thing I feel actually proud of is that the team here kept doing engineering all the way through the painful, well, in parallel with doing availability engineering where you're, oh, it's not just the big silicon, occasionally a 10-cent thing would go out of stock and you have to work around it. So in parallel with doing the availability engineering, they did the big stuff as well. And that was, you know, so we're six months out of the most brutal shortage, and we launched Pi 5, which was amazing, right? And it was just the best day.

Yeah, we're really unusual. You have a lot of companies that start offshore as they go to volume, and actually I think that's modestly insane. Generally what happens, at least with a low to medium touch product like Raspberry Pi, in terms of amount of human fettling required to get it out the door, once you reach a certain volume you can justify massive investments in automation. And once it's a fully automated process, it doesn't matter where the robots are. They can be at home, as long as the electricity is fairly cheap, which is not always nailed on in Britain, but as long as the electricity is fairly cheap, then it doesn't really matter where the robots are. And we started reshoring in 2012, quite a labor-intensive process at that point but with a little bit of automation, to South Wales. And then by 2018, 2019, almost entirely reshored. Obviously hugely valuable for us during COVID because if you lose access to your factory, what are you going to do? You can't go to your factory for three years, or you have to stay in a quarantine hotel for a month in order to go visit the factory and in a quarantine hotel for a month when they get back. So that was very valuable to us. The big benefit is the design for manufacturability feedback that you get by building locally. When the factory is four hours away in the car and they speak the same language as you, it's a huge difference versus a 12-hour plane flight and a translator. So that's the reason why Raspberry Pi is so cost-effective. It's a low price product, and that low price is underpinned by a low cost structure, and that low cost structure is underpinned by going into the factory every month and saying, 'Hey guys, what do you hate about our product? What sucks about making our product? What's taking time? What's leading to rework? What's leading to scrap? What can we change about our product to remove those things?' And we continue to do it, and there are real surprises. We continue to find opportunities to do that. We found a packaging change that we haven't deployed yet. Roger Thornton, who runs our application engineering team and compliance team, found a packaging change that will save us $300,000 a year, five cents a unit something like that on most of our products, just in the last few months. So yeah, we continue to find these efficiencies, and being able to have a good conversation with your manufacturing partner is a really important part of that.

Yeah, so the cardboard box is probably made in the UK. For the Pi 400, the plastics are made in the UK, the plastic bases are made. We do a lot of injection molding here. It turns out, again, a little bit like electronics, light industry is the thing that Britain's really good at. So we do our injection molding in the UK, we do our PCB manufacturer, we do our PCB assembly. The PCBs themselves, the actual substrate, is manufactured in China. Most of the semiconductors are either manufactured in Taiwan for logic, or either Korea, South Korea, or North America for DRAM. Electromechanical is mostly connectors, PCB, mostly China, mostly PRC. Plies of Cambodia interestingly, so Kotech build our, you know, absolutely massive facility in the middle of nowhere in Cambodia. So yeah, it's quite a, although final assembly is UK, there isn't the upstream supply chain here to sustain much more than cardboard box manufacturing. Because I think that's what people don't really understand about electronics. A lot of people outside the industry, I guess, in electronics manufacturing, you can't make these components in Europe or in the UK, it's just impossible. There isn't a possibility to do that. Semiconductors are particularly challenging. We do semiconductors, so we of course make our own chips now, right? So that's the big change in the last few years. We've gone from being purely a consumer of other people's silicon, albeit often silicon that we've been deeply involved in design in one way or another, to being a silicon manufacturer ourselves. And that's fun. So we fab those with TSMC in Hsinchu in Taiwan. We package them either in Taiwan or some of our lower cost products, the microcontroller products, actually packaged in EPO in Peninsula Malaysia, which is great for me actually because Liz's family is from very near EPO. And yeah, that's kind of fun. So I haven't actually been to the packaging plant, so that's on my list of things I would like to go and do fairly soon.

No, I, the kind of ticker, we have a signage-focused Wayland demo which is kind of 3D and video and a ticker and a 2D ticker at 60 fps, just like how you, a little bit, I mean you're familiar with the history of this, that's right. So yeah, broadly speaking, the history of multimedia in particular on Raspberry Pi is that we used to use a bunch of Broadcom proprietary interfaces for driving the multimedia subsystem. And so that meant video decode, camera processing, video encode and decode, camera processing, 3D, and display composition. And broadly those APIs were OpenMAX, I mean okay, some of these are standards-based. OpenMAX for example is standards-based. So OpenMAX or MMAL, which is kind of a simplified OpenMAX for video codec and camera. Dispmanx for display composition, and OpenGL ES but a kind of a remoted OpenGL ES. The interesting thing about OpenGL is that it is very amenable to being effectively serialized across a FIFO, and so what we would do is we'd run the OpenGL subsystem, run the state machine inside the VPU, so the closed-source blob, this thing is called 'the blob' sometimes on a Pi. I could talk at length about fear of the blob. And I think often people who are afraid of the blob imagine that their PC is a lot less blob-full than it actually is. You do have a management engine with the blob on your PC, and you don't know what the source code of that is. I had an episode with the coreboot guys talking about BIOSes just a few episodes ago, and yeah, that's a good example of a blob that you have no idea what's in it. How can I be safe on my x86 PC when there is this piece of closed-source code that I don't understand? Anyway, sorry. There is a blob, and this is a single state, which is a big VPU program, a big closed-source proprietary VPU program, which provides the device-side element of all of these APIs which are basically serialized and piped over a subsystem called VCHI from Linux host land, from a bunch of Linux host libraries through the kernel across to the VPU. So everything in a Pi 1 in 2012 is kind of done by remote control. HDMI mode negotiation, I mean it makes for a very nice platform actually, particularly for people who want to do bare-metal programming, because the thing comes up with a framebuffer. By the time the ARM is out of reset, it's already negotiated the display mode for the television. Which is great in a lot of ways when you've got a little processor, you've got an ARM11 in there, it's quite nice not to have to worry about that. And TV service and Dispmanx and some of these other APIs provide you a way of renegotiating if you want to renegotiate. And all is well, but all is very proprietary and non-standard.

So the direction of travel really has been, as you say, towards a standards-based approach. So rather than, probably trying to get them in the right order, probably the earliest of these is the move to Mesa for driving the 3D. Anholt joined Broadcom, worked for me at Broadcom for a while, and did some of the early work on this. Igalia now maintains and progresses the OpenGL and Vulkan Mesa stack for us, which is kind of fun. And then you have the move to KMS for controlling display output. As you say, Video for Linux for stateless V4L for controlling codecs, even the legacy codec H.264, modern codecs from Pi 4 onwards there's a H.265 codec which is a modern codec developed at Raspberry Pi that was designed to be driven from the ARM from the get-go. So you have this gradual depletion of the stock of things that are inside the blob, controlled from inside the blob, to the point where on Raspberry Pi 5, really it's only clocks, power, and reset. And everyone needs that. All decent, all sensible, you know, I believe a bunch of Intel chips actually have ARM cores in them now that do microcontroller cores that do this stuff. So yeah, everyone has, large chips don't tend to come out of reset with the big core being the first thing that comes out of reset. Almost always you have some management processor of some sort that comes out of reset first and gets the world ready, sort of a John the Baptist processor. It doesn't come to such a sticky end, but it will set up the DRAM, fetch a next-stage bootloader. It probably won't negotiate HDMI mode for you, that's probably a bit excessive. But so really, that's what the VPU has been beaten down to. It's still present, it's a very antique piece of hardware, it's still present in 2712 in the Pi 5 chipset, but it's been relegated to this microcontroller-type world where it sets up DRAM, loads the second-stage bootloader, and then sits there providing clocking services, monitoring the temperature of the chip and reducing clocks if things get too hot, those kind of slightly safety-critical processes that you don't necessarily want to, you want those processes to continue to happen even if the OS crashes, even if the big OS goes away. It's a kind of watchdog world.

Know your world consists a lot of it consists of HTML5, so a lot of what we do is about making the browser run well. But to the extent that you have custom players, often you'll be putting together some 2D content, some 3D content, and some video content into a single window. Where historically we would have made a DirectX example to show you how to do that, the example I saw the other day that I need to make sure you have your hands on is the same thing but using the modern Wayland compositor.

We think we even had the Pi One running in frame buffer at 60 FPS with transitions and video. That was one of the reasons why engagements like ours were the foundation of embedded and industrial use of Raspberry Pi. Because Raspberry Pi One has a 700 MHz ARM11, it has a very limited CPU, but the multimedia performance has always been great. As long as you can avoid touching the pixels, if you can have the pixels just zoom straight through from the codec onto the display, you can get incredible results. In fact, one of the things you'll see from us over the next six months or so is a really concerted effort to move desktop composition in the Wayland universe on Pi One to a hardware-accelerated world. A distinctive thing about us is that we continue to sell old products. We sold 50,000 Raspberry Pi 1s last year, which is kind of fun. We also continue to support the modern software stack on older devices and care about delivering performance uplift. We sold between five and ten million units of Pi 1, well over 20 million units of Pi 3. Those are still in the field, not in drawers, not in landfill. We continue to care about eking more performance out of those devices over time. We pushed the EOL date for Pi 3 to 2030; it was set at 2026. It's a workhorse. We still sell a million plus units a year. We're nearly five years after we launched Pi 4, and we're still selling huge numbers of the predecessor product. It just didn't feel right to do a forced transition of people from that world they're happy with up to Pi 4 and Pi 5.

Well, I would say the eMMC with a slot is just an SD card. There isn't a thing that makes eMMC intrinsically better than an SD card. I think that... I would contradict that based on my experience. The biggest failure point on the Raspberry Pi is the SD card by an order of magnitude. We've tried the most expensive, within reason, SD cards on the market, and they will break after two or three years of proper usage, whereas you do not see that with some kind of proper flash storage or eMMC in my experience. That's interesting. I genuinely think we've had these conversations a number of times. I would certainly say that point about expensive is definitely the wrong direction. The best SD cards are the ones they sell a lot of, not the ones that cost a lot. Industrial SD cards are... I would not avoid them totally like the plague, but they are often... What do we look for in SD cards? We look for power cycle volume. We have a test rig. A bad SD card from our point of view is one that is not resilient to unplanned power outages. I think it is genuinely true that there are a lot more people who make eMMC thinking about industrial, so they are thinking about power outage. It is probably fairly rare for someone in the business of shipping eMMC to die when you cut power. The problem with unplanned power outages is you have your flash, your NAND, and then the FTL, the flash translation layer, which turns that fairly rubbish storage into a block device. The problem is some state in the system manages that mapping, and the FTL internal state can become terminally broken if the power goes out during certain operations. You'll see these cards that are not just corrupt, but destroyed, no longer a block device. That's the FTL failing. It's generally not running out of wear; it's the FTL exploding.

If you're in the eMMC business, you generally have to take that seriously. You can sell an awful lot of SD cards to people who want them for cameras or phones, where unplanned power outages don't happen. The FTL is not stressed. So we have a qualification program for SD cards. We take about 32 Pi 4s in a rack, put SD cards into all of them, set each one building the Linux kernel in a loop, and then randomly pull the power with a relay. A torture test across this array is hundreds of thousands of unplanned power cycle events over about a month. If a single card dies, it doesn't pass. Cards have gotten better over time. A random card from a Chinese second- or third-tier vendor five years ago would die in the first hour. Now, equivalent cards from equivalent vendors survive all the way through. Sandisk cards have generally done well. We used to use these certificates; you can find them on the product information portal at pip.raspberrypi.com. There's a whole section of certificates for a pretty broad range of vendors. My general feeling is there are more terrible SD cards than eMMC, but a good SD card, and price is not the right metric, can be as good as eMMC because there's no technological reason it shouldn't be. It's a decision to be bad. That said, I do have some sympathy for the fact that we help customers not have to make a decision. For compute module, we provide a service: don't think about flash, we'll think about flash. Also, vibration is a concern. People are leery of using SD cards in high-vibration environments. So people migrate to compute module at points that feel economically suboptimal. It's more work to integrate a compute module, so people do it at higher volumes, but they go early. So I think at some point there will be soldered-down eMMC on a big Pi. I think there's a reasonable chance that might come to one of the more modern platforms in the next couple of years.

We used to have a wonderful relationship with Western Digital, actually. It was kind of fun when they combined forces. It is encouraging to see other people coming up on the rails, though. But it's that power cut torture test. You can have the best card in the world with the best random read and write ops and great streaming performance, and it will just die after an hour in the rig. You have to go back to these people who sent you a card, and they're like 'Can we get a certificate for this card?' and I'm like 'This card is so bad. You use it in an industrial context, it won't last a week, because unplanned power cycling is a feature of the industrial world.'

We're still big believers in SD cards, particularly the higher performance modes available in modern cards. I would love to be able to ship SD Express, and that hasn't really rocked up yet. But even the high-speed classic modes, the HS400 modes, the A2 class cards, you're really... There's always that feeling that the NVMe the whole Raspberry Pi system is designed to not require NVMe. The nice thing about Raspberry Pi 5 is you can plug an M.2 drive into it. There will shortly be a first-party accessory to let you do that, but there are currently a number of third-party accessories that we love. But really, the whole Raspberry Pi world has been designed to not require NVMe. The operating system is tuned to be lightweight enough that it runs very acceptably from even a modest SD card. As SD card performance has come up with faster bus speeds or with command queuing, which is actually a lot of the benefit of NVMe over classic SD card, it's about the ability to queue commands to hide latency in accessing the flash array. Now that has come to SD cards, it goes a long way towards closing that gap.

I would have to look. Because that was the absolute killer of SD cards in the early days, swap enabled and it just completely wore down and trashed the card. It depends. I think it's one of these things that... Particularly, a modern high-end Raspberry Pi has 8 gigabytes of memory, the same amount as this laptop. Back in the days of 256 MB Raspberry Pi ones, there is an argument that there is a pool of writable memory that gets written and never looked at again. The rationale was that it's helpful to have somewhere to stash that to eke out some percent of additional functionally available RAM by allowing the page cache to push those very low read utilization pages out to storage. The problem is how do you ensure it only does that and doesn't start opportunistically pushing other things out, which then has that thrashing effect. I mostly care about it because performance just craters. In an industrial environment, you need to get that turned off. It's less salient than it used to be. I can see why we did it. Of course, everybody had that flirtation with Zswap. That was a really sad thing that we weren't able to articulate a benefit to Zswap.

It's the old RAM doubler world. Anyone old enough to remember the very... we have protected mode now in Windows 3.1, we can double your RAM by compressing it. It was slightly depressing to discover that it's really hard. We didn't not try this, but on one gig devices, there's a pool of less frequently accessed data. Perhaps the right thing to do rather than writing it to persistent storage is to compress it and stash it in RAM. Then perhaps there's a slightly larger pool of stuff more frequently accessed that should also be compressed. But we were never able to come up with a convincing configuration of that subsystem that didn't make some use cases materially worse. So we left it turned off. There were users who swore by it and used to get Raspbian out of the box and immediately turn Zswap on, but it was very use-case dependent. That's fair enough.

I would love it to be. Why? Well, I guess the concept of open hardware is very compelling from a security and supply chain perspective. I think the challenge you have though is that it won't be open hardware. No performant RISC-V... the architecture is open. What does RISC-V have going for it? You can implement RISC-V and you won't get sued. There's no convincing demonstration that there is any protected IP in the instruction set itself. That's really compelling because it creates a different community. All of these instruction set architectures create a community of innovation. x86, Intel and AMD, create a community where you can go buy a chip at particular performance points. They are basically just chips, historically not much more than the CPU and memory controller. But you could build a system around that as a hardware integrator. Then ARM, licensable CPU cores and architectures, provide a different community. You interact with that architecture through a level of indirection. You buy silicon from licensees who have the ability to build more sophisticated systems. There's an obligation to pay money to ARM, who extracts money and provides services like regulation. They regulate what can be claimed to be ARM compatible. You can't just take an ARM core and add a bunch of instructions. They also provide access to a pool of readily licensable cores. Some people, like Apple, buy an architecture license to make their own core. Raspberry Pi has always been built on the other model: license one of a pool of synthesizable cores from ARM. That's a different shaped ecosystem of innovation. Then RISC-V creates a new model where there is less value extraction at the architectural level. There's still generally value extraction at the core level. But for the first time, you have the ability to write your own core and a large pool of reasonable quality freely available cores. So no extraction at the architecture level, potentially no extraction at the microarchitecture level. Plus you can add your own instructions. Downsides for a software user: you can no longer rely on 'it says RISC-V on the tin, therefore it's exactly like this.' It may have more instructions that you rely on and then discover another core doesn't have them. It's a much less orderly universe. Also, the supply of licensable cores is not great compared to ARM, and the decent cores are not free. They are closed and no more or less secure than an ARM core.

Absolutely. The A76, which is in Pi 5, is not 200 engineer years? I don't know the number. From conversations I've had, for a mid-A7x class core, it's 200 engineer years. You have a few hundred people working on it, and it's not from a standing start because you have the previous core to build on. These are huge investments. The fascinating thing about the ARM world is how cheap it is to buy IP. You can get access to that for not huge sums of money and then go do your innovation, build your silicon, start selling boards. It's not an expensive place to play. So it's very hard to say you're going to spend $100 million from a standing start. RISC-V startups are raising hundreds of millions of dollars. For us, we'd have to go raise it from investors or not give the money to the foundation. If we made the money ourselves, we'd have to not give it to the charity. That would be a $100 million service to humankind at the expense of a charity that educates kids. I guess the argument for it is when it's kids who would be getting the money otherwise, then it's not a business.

You absolutely could imagine some cartel of consumers... Coordination is the problem that capitalism solves. The distributed attack on problems is what the price mechanism does. It's been incredible. Look around, everything behind you was built by that. But it can't solve all problems. This is one that has historically been extremely challenging: collective action to move from a hill climb. Capitalism is a hill climber. What you're articulating makes a huge amount of sense: globally more optimal place where all of us who use CPUs club together around some architecture, contribute money, and agree to make a Cortex A76 except it's RISC-V, document it IP clean, and then put it on GitHub. Then the next year's core becomes much easier. But you need IP certainty. One thing you buy from ARM or a commercial RISC-V core vendor is IP certainty, a contract that says this is mine to license to you. If we all get together and produce not just a core but collateral demonstrating it's clean, and put it on GitHub, then things will be wonderful. But it's never been the case. The open-source hardware world has never had the vibrant nature of the open-source software world. The open-source chip world is that on steroids, plus $10 million tapeouts on modern process nodes. It's hugely challenging. But I'm in agreement. The question is whether there is a market-based... the crazy philanthropist who rocks up and says 'I'm just going to solve this problem for all mankind' is a potential. It sometimes happens. It appears to be happening to malaria vaccine, another place where capitalism hasn't provided a mechanism for collective action other than one guy getting rich selling operating systems and deciding he's going to solve a problem. Long answer: I really care about this. I know Raspberry Pi 6 is not going to be RISC-V based because there are no cores that are good enough that you could license, and the software isn't mature. We're a member of the RISC-V foundation. I hope I've articulated lots of positives about the RISC-V world. That's not to say you might see some deeper involvement from us, but the idea that it will be feasible to procure an A76 successor core for Raspberry Pi 6 sometime before the end of the decade, and be confident that the core is competitive in all dimensions technical and financial versus some ARM core, and that the software ecosystem will be mature, I don't think is realistic.

That's probably the big hope for RISC-V in the big core space, that one of the hyperscalers, probably Google, might be able to articulate a business model for a disruptive open documented ultra-high performance RISC-V core. If a surprise comes from anywhere, I think it will be from a hyperscaler. I'm not sure it's Meta, but some of them have a strategic interest in driving commoditization in the core and architecture purchasing space.

Well, I did once build a GPU. Yes, video call. There was a handful of us in Brookham in Cambridge, including James Adams, who is our Hardware CTO now. We do have previous, although I think building a Vulkan-capable GPU... we built an OpenGL ES 2 class GPU, which was the one I was most deeply involved with. OpenGL ES 2 is actually very simple. I think building a quality Vulkan-capable GPU, we have a quality Vulkan-capable GPU in VideoCore 6, VideoCore 7, which is in Pi 5. But a little bit like the ARM cores, they are built on the shoulders of giants. A ground-up Vulkan competitive GPU is another 100 engineer years program. So yeah, I guess we're not going to see pure open hardware anytime soon.

That's it. I wish... look, don't get me wrong. It's a fickle beast, capitalism. It's fascinating. It's Iain Banks, isn't it? He talks about how the market economy gutters like a flickering candle while the planned economy lazes. It's true. We surround it. Capitalism like democracy is the worst system apart from all the alternatives. We are surrounded by its products and live in unimaginable luxury. But there is a huge fraction of the state space of the world that is inaccessible to market mechanism. You kind of weep for it.

I say this every now and then. I had a BBC Micro when I was a kid. I got into it at school and bought a very secondhand one. I used to go to a computer club in my town in Ilkley. I used to box up my BBC Micro in its porridge box and my black and white 14-inch telly, and every other Friday night a chap called Alan Drew would rock up in his people carrier and take me to computer club, bring me back at 9:30. When I got a bit older, we would go to the pub. He's not sadly with us anymore, but I wouldn't have got where I got if it hadn't been for Alan and a few other people like him, often teachers but volunteers as well, who paid attention to me, gave me a physical place to go and an audience for the things I did. They gave me as a 10-year-old kid a way into this community that we're all part of very early. People should go be Alan Drew. Go be Alan Drew to some little 11-year-old squit who is probably as annoying as I was. Just put up with them, answer their questions, talk to them like they are worth something even before they are. It's good to do good at scale, give money to charity, and build things like Raspberry Pi, which is a business that Liz and I dreamt of all those years ago. But try to do something at the individual scale as well, because it makes a difference and it will make your life better and someone else's life better. That's the thing you should watch out for. Don't watch out for things from the Raspberry Pi Foundation. The Raspberry Pi Foundation is doing amazing stuff, Raspberry Pi Limited is doing amazing stuff, making great products and changing the world. But we can all do as well.

Awesome, thank you very much indeed. Cheers, bye.