This method configures the Raspberry Pi [Zero] in “gadget” mode, creating a private link that appears as a wired Ethernet connection over a USB cable. The Pi’s address will never change, either as it is also a DHCP server for the iPad. As an added bonus, the same cable powers the Pi, creating a setup as simple as plugging the Pi into your iPad and waiting for it to appear .. you have a full-blown Linux computer working in tandem with your iPad and the iPad acting as a directly-connected console that is also providing power.
The Pi Zero is a full SoC which naturally runs Linux. Any Linux SoC with USB (so basically all of them) could use used in the same way.
This article is about the RP2350's microcontroller cores. It doesn't even have an MMU, so running Linux on it is much more interesting. It's not as capable as the normal Linux we run on bigger boards, but it's still interesting.
I used to do the same thing with a full RPi4. I’m pretty sure that was the first non-pi zero that worked in gadget mode.
I was trying to make an attached Linux machine for my iPad instead of using a cloud VM. It was pretty effective, but at the time the ARM distributions were difficult to run what I wanted. Now, however, it would be significantly better.
Going in the other direction: recent Intel laptops with Thunderbolt should support USB gadget mode. In theory, this would allow a Linux laptop to emulate keyboard and mouse input to an iPad Mini portrait sidecar, with seamless kb/mouse context switching onto USB, as the cursor moved into the configured virtual viewport of the iPad "monitor".
Similar to synergy/barrier/input-leap, but using USB gadget mode instead of local network, since iOS wouldn't allow installation of non-Apple keyboard-mouse remoting software, https://github.com/input-leap/input-leap
Any non RP2xxx pi can be used like that. Unrelated to this post at all? I only fall back to that when there is no interwebs, otherwise connecting over ssh to a normal server is far more productive.
I carry around an pwnagotchi[1], it serves not only as a cute little paper display, but also a battery powered Linux box.
Can do everything you wanna do, in a cute little box attached to a backpack.
My battery lasts about 3 hours, but its easy to juice it up if we go hiking and need a common filesystem up some mountain somewhere, know what I’m saying ..
(PS - the pwnatotchi part is just an app you can disable if you just want your Linux box to be a Linux box, but it sure is a fun little toy also ..)
It can be used to mirror content for offline viewing, e.g. share sheet sends URL to iOS shortcut, which uses SSH to send yt-dlp or wget archive command line to Linux sidecar, which has microSD storage (more capacity, lower cost/GB). Linux can host WebDAV/CalDAV and SFTP content for iPad apps and media players.
I feel there is a gap between MCU and modern CPU, and also between the software running on top of them. The missing piece is a mid-size computer with:
- A processor, single or multi-core, with computing power like 20 years ago, but modern fabrication process. Maybe without MMU for simplicity.
- RAM between 100MB~1GB and DDR2/3 bandwidth.
- An OS designed and implemented for this type of hardware rather than tailored Linux.
I don't think you can use it for working or your daily entertainment, so I guess not a good business to attract interests.
I found some of these boards in a box last year and was unable to do anything with them… Intel has thoroughly erased all documentation and SDKs from the internet. If anyone has those artifacts, please push to archive.org
For all intents and purposes, the fist raspberry pi is pretty much that, except maybe the tailored OS. Although I'm not sure what would even fit between a fully featured rtos and a trimmed down linux.
also on 3 8 pin chips. I listened to interview with him and he decided to wait 10 years to give competition a chance then try to do it on raw transistors or vaccuum tubes
You'd better be, we have certain expectations from you now /s
But more seriously... I don't think that Linux has ever been booted on a non-monolithic CPU (I wanted to say 'discrete cpu' first, but there's some PDP-11s with 4 chip CPUs)
one could argue that 4004 is it. It does not really do memory ops at all. all decoding for memory ops happens inside the memory chips. but yeah - not non-monolithic enough
I'd really like to see a pi zero 3 that runs on RISC-V, it might be the kick in the pants RISC-V needs to go "mainstream" at least in the public view. People know raspberry pi, nobody outside the RISC-V scene really cares or even knows about MILK-V
This one runs Linux on the ARM cores rather than the RISC-V cores in the same package, so it's apples and oranges, but still pretty neat for something that comes essentially with a companion MCU and is in the same form factor:
In embedded systems it's very common to have a bigger SoC and a satellite MCU to handle e.g. network comm and power lifecycle. I've still not really tried out my Milk-V Duo, but it's interesting to get a combo like this in a hobbyist board form factor.
They also claim desktop-class performance for this RISC-V-based miniITX board, it's a bit weird though since it doesn't claim RVA23 compliance:
I'm building Fostrom (https://fostrom.io), an IoT Cloud Platform. We have Device SDKs to simplify integrating devices, powered by a small Device Agent written in Rust.
I wanted to support RISC-V boards too, so I went with the Milk-V Duo S as the test device. I have managed to get Tailscale working, and our Device SDK works too, with the bundled Python.
The experience of using the Milk-V Duo is definitely not as straightforward as the Pi Zero, but it does work, and is easily available in most places, unlike some of their other products. The Linux distro they provide is quite barebones, and I wasn't able to get Debian working. The docs for the device are pretty decent. I hope we get better support for Debian/Alpine/Arch for these kinds of boards soon.
I wish I could buy RP2350 with the ARM cores being hard-fused disabled, "cheaper" since no ARM royalties would have to be paid.
That said, I wonder how much they did improve their hazard3 design, because we all know the future is no PI locked ARM cores. I wonder if they are sharing part of the design of other open source RISC-V cores.
If those efforts are kept significant, the future is looking good and better there. Hopefully, all that will be a success (=latest silicon process, ultra-performant RISC-V implementation in mobile/embedded/desktop/server).
The Hazard 3 is basically a hobby project of Luke Wren, a Raspberry Pi Employee. He's contiuing to evolve it further, but I don't think it's ready for a full replacement of the Cortex-M yet, especially in regards to the Security Features.
The source code is all from Luke Wren and I don't think other cores use the source code directly, but improvements to test harnesses or general implementation patterns as well as better software support help other cores: https://github.com/Wren6991/Hazard3
For the SoCs I would expect to see an off-the-shelf Risc-V core (certainly no Hazard3 as the main CPU), but we'll see.
The Hazard3 in the Pico 2 are bigger, more capable cores than the Cortex-M0 in the first Pico, and therefore in general faster at the same clock for compiled code.
You're supposed to be able to just recompile most Pico projects to use them as long as there is no ARM assembly in it.
They are only inferior to the ARM Cortex-M33 cores in the Pico 2.
I know the "basically" is probably doing a bunch of heavy lifting, but dang, that's still awesome to think about. I didn't know hardware development was at the point where a hobby project CPU, apparently mostly developed by one guy, can realistically end up in a mass produced product like that.
I am curious to know which RISC-V design they'll go for in this SOC.
M. Wren getting real hard experience on RISC-V is going only to help RP to select and audit more seriously any RISC-V design which would make its way in their SOCs.
I just don't want to contribute to arm IP racketering (and we have mpeg and hdmi to take into account too with avX and eDP/DP).
You can probably already get that if you order a somewhat significant amount of chips directly from Raspberry Pi. They seem to already have everything required for it, it's literally just setting a bit differently during factory programming.
But I'm assuming you're talking about for consumer use, in which case my question is why? There is absolutely no way you're ever benefiting from them spinning up an extra SKU with significantly less volume (most people want the ARM cores).
Even if they decide to eat the costs for the benefit of consumers, at most the chip would be what, 15 cents cheaper? I really struggle to see how that's a meaningful difference for hobbyist use.
I don't even know what would be the point of such device, and if there really is a market for it for tech companies. I would say yes?
As a consumer, all I want if a very minimal "phone", with wifi, touch screen, battery, but no 4g or mobile networking, and linux on it. Just the cheapest, smallest, wifi, battery-powered, touchscreen LCD device that could exist that can run executables.
People are going to say "but just buy a cheap phone", but I cannot really run custom software on those, I can't expect to install a custom system image, and generally even cheap phones CPU SOC are way way too powerful. Open source phones are generally crazy expensive and very powerful, and I am not going to buy those.
With the range of hardware that exist out there, I think such device could cost about 60 euros, and it would be more interesting than a RPI.
The RPI is an amazing product, but it lacks an all integrated consumer device with an actual screen and battery. Of course I can already build one with a compute module etc, but it's not really portable and not designed around a flat battery.
Making a thing made, shipped and delivered at 60 euros each on credit cards is HARD. 600 is easier. 60m consider it done. I wouldn't want to even make and sell, idk, a lens cap for a camera, at that price, without first owning couple factories running at healthy levels of utilization. Maaaaybe if my customers would be happy with a 3D printed artisanal version of it. But even then it'll technically be delivered at a slight loss.
They don’t make cellphones, they make little computers. Hypothetically you could probably use an Arduino or an esp32 to make a cellphone, but you wouldn’t say those organizations lack an all-integrated consumer device, right? They just aren’t in that business.
First, note that what's on that article is not an Raspberry Pi, it's a Raspberry Pi Pico.
I'm not sure about what you want. You don't want a phone, so you want... A tablet, maybe? Or a Raspberry Pi 3/4/5 with a touch screen? Do you want a small screen? Big? Keyboard/Keypad? Touch only?
You can buy touchscreen enclosures for the various pi models. If you want to put in the effort to make your own PCB you could really slim it down by using a pi compute module
Linux on Pi Zero can be used as a sidecar for iPads.
https://schwarztech.net/articles/my-ipads-raspberry-pi-sidec...
The Pi Zero is a full SoC which naturally runs Linux. Any Linux SoC with USB (so basically all of them) could use used in the same way.
This article is about the RP2350's microcontroller cores. It doesn't even have an MMU, so running Linux on it is much more interesting. It's not as capable as the normal Linux we run on bigger boards, but it's still interesting.
Could Linux on RP2350 cores work with iPad via Pi Zero form factor, with microSD storage to supplement iPad?
https://www.cnx-software.com/2025/07/08/rp2350-pizero-rp2350...
Cool, but any SBC that runs Linux and has a USB port that supports gadget mode can do this. Either way, what does this have to do with the article?
I used to do the same thing with a full RPi4. I’m pretty sure that was the first non-pi zero that worked in gadget mode.
I was trying to make an attached Linux machine for my iPad instead of using a cloud VM. It was pretty effective, but at the time the ARM distributions were difficult to run what I wanted. Now, however, it would be significantly better.
Going in the other direction: recent Intel laptops with Thunderbolt should support USB gadget mode. In theory, this would allow a Linux laptop to emulate keyboard and mouse input to an iPad Mini portrait sidecar, with seamless kb/mouse context switching onto USB, as the cursor moved into the configured virtual viewport of the iPad "monitor".
Similar to synergy/barrier/input-leap, but using USB gadget mode instead of local network, since iOS wouldn't allow installation of non-Apple keyboard-mouse remoting software, https://github.com/input-leap/input-leap
Any non RP2xxx pi can be used like that. Unrelated to this post at all? I only fall back to that when there is no interwebs, otherwise connecting over ssh to a normal server is far more productive.
I carry around an pwnagotchi[1], it serves not only as a cute little paper display, but also a battery powered Linux box.
Can do everything you wanna do, in a cute little box attached to a backpack.
My battery lasts about 3 hours, but its easy to juice it up if we go hiking and need a common filesystem up some mountain somewhere, know what I’m saying ..
(PS - the pwnatotchi part is just an app you can disable if you just want your Linux box to be a Linux box, but it sure is a fun little toy also ..)
[1] - https://www.thingiverse.com/search?q=pwnagotchi
Thanks for linking this, I would not have expected this usage (more from the iPad side being locked down) and it has inspired some thought.
It can be used to mirror content for offline viewing, e.g. share sheet sends URL to iOS shortcut, which uses SSH to send yt-dlp or wget archive command line to Linux sidecar, which has microSD storage (more capacity, lower cost/GB). Linux can host WebDAV/CalDAV and SFTP content for iPad apps and media players.
This is a really good way to side step certain kinds of Apple MFI. "I'm not a custom super widget?! I'm an ethernet adapter!!"
Gotta get Pi Zero 2, way stronger hardware
side note: I wish it had more ram so you could mount it in VS Code vs. developing through SSH
Oh running Linux on a MCU without MMU.
I feel there is a gap between MCU and modern CPU, and also between the software running on top of them. The missing piece is a mid-size computer with: - A processor, single or multi-core, with computing power like 20 years ago, but modern fabrication process. Maybe without MMU for simplicity. - RAM between 100MB~1GB and DDR2/3 bandwidth. - An OS designed and implemented for this type of hardware rather than tailored Linux.
I don't think you can use it for working or your daily entertainment, so I guess not a good business to attract interests.
That was Intel Quark. It was too expensive for the “big microcontroller” use case and too power hungry for the “small Linux” use case.
The marketing was confusing, I’m not sure Intel even knew what it was for, except to show investors they had an IoT play.
https://en.wikipedia.org/wiki/Intel_Quark
I found some of these boards in a box last year and was unable to do anything with them… Intel has thoroughly erased all documentation and SDKs from the internet. If anyone has those artifacts, please push to archive.org
Making 20 y/o CPU with today's process? It is cool but yeah not really a wise business decision.
For all intents and purposes, the fist raspberry pi is pretty much that, except maybe the tailored OS. Although I'm not sure what would even fit between a fully featured rtos and a trimmed down linux.
after https://dmitry.gr/?r=05.Projects&proj=35.%20Linux4004 nothing's really impressive when it comes to making it run linux, doubly so that it runs just normal Debian userspace
That is too practical. For ultimate HN bait it needs to include Rust deployed (over QUIC) as WASM on RISC-V.
But the CPU needs to be build in Minecraft.
Rust and QUIC are bloated, but I'll take WASM and RISC-V
What about Commodore where it took 7 hrs to boot (video YT)
Edit: oh damn this one is even worse 8.4 days ha
Is that the same Dmitry that got the linux kernal to run on an atmega?
also on 3 8 pin chips. I listened to interview with him and he decided to wait 10 years to give competition a chance then try to do it on raw transistors or vaccuum tubes
Has anyone run linux on thermionic valves yet?
I’m on it
You'd better be, we have certain expectations from you now /s
But more seriously... I don't think that Linux has ever been booted on a non-monolithic CPU (I wanted to say 'discrete cpu' first, but there's some PDP-11s with 4 chip CPUs)
one could argue that 4004 is it. It does not really do memory ops at all. all decoding for memory ops happens inside the memory chips. but yeah - not non-monolithic enough
Linux in PDF was impressive in a different way
Running native vs running under emulation is a complete different beast
Any turning machine can boot Linux under emulation
turing machines are far superior to 4004 to, normal machines don't have infinite memory for example
...Linux nommu, and the system busses of these platforms, won't get the complete environment that Dmitry wants, unfortunately.
I'd really like to see a pi zero 3 that runs on RISC-V, it might be the kick in the pants RISC-V needs to go "mainstream" at least in the public view. People know raspberry pi, nobody outside the RISC-V scene really cares or even knows about MILK-V
RISC-V needs an inexpensive, performant part for it to be used in the consumer space.
The fastest available RISC-V consumer chip is orders of magnitude slower than a Raspberry Pi 5. Example: https://browser.geekbench.com/v6/cpu/compare/15998376?baseli...
It would probably make more sense to target something like this https://www.hackster.io/news/andrew-bunnie-huang-prepares-th... with linux, has MMU and more RAM.
This one runs Linux on the ARM cores rather than the RISC-V cores in the same package, so it's apples and oranges, but still pretty neat for something that comes essentially with a companion MCU and is in the same form factor:
https://milkv.io/duo
In embedded systems it's very common to have a bigger SoC and a satellite MCU to handle e.g. network comm and power lifecycle. I've still not really tried out my Milk-V Duo, but it's interesting to get a combo like this in a hobbyist board form factor.
They also claim desktop-class performance for this RISC-V-based miniITX board, it's a bit weird though since it doesn't claim RVA23 compliance:
https://milkv.io/titan
I'm building Fostrom (https://fostrom.io), an IoT Cloud Platform. We have Device SDKs to simplify integrating devices, powered by a small Device Agent written in Rust.
I wanted to support RISC-V boards too, so I went with the Milk-V Duo S as the test device. I have managed to get Tailscale working, and our Device SDK works too, with the bundled Python.
The experience of using the Milk-V Duo is definitely not as straightforward as the Pi Zero, but it does work, and is easily available in most places, unlike some of their other products. The Linux distro they provide is quite barebones, and I wasn't able to get Debian working. The docs for the device are pretty decent. I hope we get better support for Debian/Alpine/Arch for these kinds of boards soon.
Availability is a major factor in projects like this.
Alternatively the RP2350 can also run Fuzix
Buildroot is awesome and deserves more love
So we've got a truly free OS; how free is this implementation of RISC-V?
Honest question, I don't follow much on the hardware front.
It's an open source core design [0], so pretty open.
[0] https://github.com/Wren6991/Hazard3
I wish I could buy RP2350 with the ARM cores being hard-fused disabled, "cheaper" since no ARM royalties would have to be paid.
That said, I wonder how much they did improve their hazard3 design, because we all know the future is no PI locked ARM cores. I wonder if they are sharing part of the design of other open source RISC-V cores.
If those efforts are kept significant, the future is looking good and better there. Hopefully, all that will be a success (=latest silicon process, ultra-performant RISC-V implementation in mobile/embedded/desktop/server).
The Hazard 3 is basically a hobby project of Luke Wren, a Raspberry Pi Employee. He's contiuing to evolve it further, but I don't think it's ready for a full replacement of the Cortex-M yet, especially in regards to the Security Features.
The source code is all from Luke Wren and I don't think other cores use the source code directly, but improvements to test harnesses or general implementation patterns as well as better software support help other cores: https://github.com/Wren6991/Hazard3
For the SoCs I would expect to see an off-the-shelf Risc-V core (certainly no Hazard3 as the main CPU), but we'll see.
The Hazard3 in the Pico 2 are bigger, more capable cores than the Cortex-M0 in the first Pico, and therefore in general faster at the same clock for compiled code.
You're supposed to be able to just recompile most Pico projects to use them as long as there is no ARM assembly in it.
They are only inferior to the ARM Cortex-M33 cores in the Pico 2.
So they come inferior in the only place it matters, gotcha
I know the "basically" is probably doing a bunch of heavy lifting, but dang, that's still awesome to think about. I didn't know hardware development was at the point where a hobby project CPU, apparently mostly developed by one guy, can realistically end up in a mass produced product like that.
Quick edit: sounds like "basically" wasn't doing that much heavy lifting after all, wow https://www.raspberrypi.com/news/risc-v-on-raspberry-pi-pico...
linux started as a hobby project...
I am curious to know which RISC-V design they'll go for in this SOC.
M. Wren getting real hard experience on RISC-V is going only to help RP to select and audit more seriously any RISC-V design which would make its way in their SOCs.
I just don't want to contribute to arm IP racketering (and we have mpeg and hdmi to take into account too with avX and eDP/DP).
You can probably already get that if you order a somewhat significant amount of chips directly from Raspberry Pi. They seem to already have everything required for it, it's literally just setting a bit differently during factory programming.
But I'm assuming you're talking about for consumer use, in which case my question is why? There is absolutely no way you're ever benefiting from them spinning up an extra SKU with significantly less volume (most people want the ARM cores).
Even if they decide to eat the costs for the benefit of consumers, at most the chip would be what, 15 cents cheaper? I really struggle to see how that's a meaningful difference for hobbyist use.
>> I wish I could buy RP2350 with the ARM cores being hard-fused disabled, "cheaper" since no ARM royalties would have to be paid.
Better yet, put 4 RISC-V cores on there!
I don't even know what would be the point of such device, and if there really is a market for it for tech companies. I would say yes?
As a consumer, all I want if a very minimal "phone", with wifi, touch screen, battery, but no 4g or mobile networking, and linux on it. Just the cheapest, smallest, wifi, battery-powered, touchscreen LCD device that could exist that can run executables.
People are going to say "but just buy a cheap phone", but I cannot really run custom software on those, I can't expect to install a custom system image, and generally even cheap phones CPU SOC are way way too powerful. Open source phones are generally crazy expensive and very powerful, and I am not going to buy those.
With the range of hardware that exist out there, I think such device could cost about 60 euros, and it would be more interesting than a RPI.
The RPI is an amazing product, but it lacks an all integrated consumer device with an actual screen and battery. Of course I can already build one with a compute module etc, but it's not really portable and not designed around a flat battery.
> I think such device could cost about 60 euros
Making a thing made, shipped and delivered at 60 euros each on credit cards is HARD. 600 is easier. 60m consider it done. I wouldn't want to even make and sell, idk, a lens cap for a camera, at that price, without first owning couple factories running at healthy levels of utilization. Maaaaybe if my customers would be happy with a 3D printed artisanal version of it. But even then it'll technically be delivered at a slight loss.
They don’t make cellphones, they make little computers. Hypothetically you could probably use an Arduino or an esp32 to make a cellphone, but you wouldn’t say those organizations lack an all-integrated consumer device, right? They just aren’t in that business.
First, note that what's on that article is not an Raspberry Pi, it's a Raspberry Pi Pico.
I'm not sure about what you want. You don't want a phone, so you want... A tablet, maybe? Or a Raspberry Pi 3/4/5 with a touch screen? Do you want a small screen? Big? Keyboard/Keypad? Touch only?
You can buy touchscreen enclosures for the various pi models. If you want to put in the effort to make your own PCB you could really slim it down by using a pi compute module