As I understand it, and please correct me if I am wrong, the next Raspberry Pi OS Trixie version will support 32-bit userland, so obviously support for 32-bit isn't going away entirely.

But it appears there is an increasing lack of support for 32-bit applications from Raspberry Pi; (削除) Pi Connect screen sharing requires 64-bit, (削除ここまで) Raspberry Pi's Official VS Code Pico Extension installs but doesn't work on 32-bit, rpi-imager is languishing at version 1.8.5 on 32-bit when the latest is 1.9.6. Increasingly Raspberry Pi pre-built asset bundles are available only for 64-bit, not for 32-bit.

Some lack of support may have legitimate technical reasons but lack of 32-bit support in the VS Code Pico Extension appears to be entirely through choice given Pico SDK builds work perfectly well on 32-bit, as do CMake builds under VS Code on 32-bit, and, if one knew what they were doing, it seems it should be possible to have the VS Code Pico Extension support 32-bit.

It's not hard to imagine this situation getting worse rather than better, that we'll see fewer and fewer apps and tools supporting 32-bits. That means 32-bit users will effectively become second-class citizens through being denied use of what 64-bit users will have use of.

I have myself predicted 32-bit will 'die a death of a thousands cuts', rather than be dropped, it will be supported but there will be less and less it can be used for, and maybe we have entered that phase of its life ?

Does Raspberry Pi have a statement of policy on 32-bit, a roadmap for the future of 32-bit ?

Last edited by hippy on Mon Sep 01, 2025 8:43 am, edited 1 time in total.

Can't see 32bit being entirely dropped until after January 2030 given the availbility statements for 1B+, 1A+, zero, and zeroW.

Knowledge, skills, & experience have value. If you expect to profit from someone's you should expect to pay for them.

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

thagrol wrote: ↑

Sun Aug 31, 2025 6:10 pm

Can't see 32bit being entirely dropped until after January 2030 given the availbility statements for 1B+, 1A+, zero, and zeroW.

There are hardware obsolescence dates for 32 bit boards (ranging from January 2026 to January 2030).
These are for those using Pi in production, but I am unaware that there has ever been a guarantee to keep producing 32 bit OS.

There is a 32 bit Bookworm, while the Lite version works the Desktop version is limited.

I have been using some old 32 bit GUI apps (with no 64 bit version) but these run OK on 64 bit (at least on Pi4 or earlier)

Milliways wrote: ↑

Mon Sep 01, 2025 4:49 am

thagrol wrote: ↑

Sun Aug 31, 2025 6:10 pm

Can't see 32bit being entirely dropped until after January 2030 given the availbility statements for 1B+, 1A+, zero, and zeroW.

There are hardware obsolescence dates for 32 bit boards (ranging from January 2026 to January 2030).
These are for those using Pi in production, but I am unaware that there has ever been a guarantee to keep producing 32 bit OS.

True. But dropping support for 32 bit OS while 32 bit only hardware is still in production seems unlikely.

Knowledge, skills, & experience have value. If you expect to profit from someone's you should expect to pay for them.

All advice given is based on my experience. it worked for me, it may not work for you.
Need help? https://github.com/thagrol/Guides

hippy wrote: ↑

Sun Aug 31, 2025 5:17 pm

.. Connect screen sharing requires 64-bit,

??
https://archive.raspberrypi.org/debian/ ... i-connect/
I see the 32bit version there?

hippy wrote: ↑

Sun Aug 31, 2025 5:17 pm

I have myself predicted 32-bit will 'die a death of a thousands cuts', rather than be dropped, it will be supported but there will be less and less it can be used for, and maybe we have entered that phase of its life ?

I think we are already several years in that phase. You can ask RPL, but look around. Debian dropped ARMv6 armhf long time ago, meaning RPL needs to potentially fix many issues that arise from re-compiling. Even with 64-bit it can fail, look at TVheadend example, is not in Debian by the way. And PHP8.4.
Several small programs like Domoticz also dropped ARMv6, BUT they do build 32-bit but that is the still well supported ARMv7 armhf.

if 32-bit for RPi would be standard Debian, you would already now have Trixie. Like for 64-bit it is no issue as many people around the world have been and are using 'Testing' rolling scheme the last 2 years. I have up to 6 ARMv7 armhf 32-bit only SBCs in use (BananaPi-M1, NanoPi-NEO), they just can use standard Debian, only kernel+bootloader is special (out-of-the-box Armbian actually). The companies behind it already long time ago dropped support, it is completely community based.

You can run 32-bit on 64-bit OS in various ways. You need raspbian for RPi0/1 or maybe you get Debian armel (ARMv5). For fun I did, upgraded in-place to trixie (systemd-nspawn) and maybe I will try to boot it on real Pi (0 or/and 3).

RPi-Imager is an external to the OS and local HW tool, same as RPi Connect. If you make yourself dependent on it, you indeed will worry about support etc. Those are just goodies and soft vendor lock-in.

bensimmo wrote: ↑

Mon Sep 01, 2025 6:35 am

hippy wrote: ↑

Sun Aug 31, 2025 5:17 pm

.. Connect screen sharing requires 64-bit,

??
https://archive.raspberrypi.org/debian/ ... i-connect/
I see the 32bit version there?

Maybe I missed an announcement but it was originally stated that "First of all, Raspberry Pi Connect needs your Raspberry Pi to be running a 64-bit distribution of Raspberry Pi OS Bookworm that uses the Wayland window server" and there wasn't even an 'apt install' package for 32-bit.

I recalled Remote Shell Access had been added for 32-bit. I didn't recall that Screen Sharing was added for 32-bit but it seems it was.

I have updated my post but I would still like to know what the policy is. If it's "64-bit may be the first out the gate but 32-bit will follow" that's great. If it's "We may choose not to support 32-bit even if we could" that's not so great.

redvli wrote: ↑

Mon Sep 01, 2025 7:38 am

You can ask RPL, but look around. Debian dropped ARMv6 armhf long time ago, meaning RPL needs to potentially fix many issues that arise from re-compiling.

That is what I am asking; will the policy be to continue supporting 32-bit. Do Raspberry Pi intend to put the effort in to ensure everything works on 32-bit when things can be made to work on 32-bit, or not. And, when it comes to Raspberry Pi provided software, will 32-bit be supported or is it policy to only support 64-bit ?

32bit is really old tech these days, (16bit & 8bit don't get any support either nowadays). ;)

Even the RPi Zero 2W moved to 64bit, so, I think, it will go 64bit only at some time. 8-)

Whether the Kernel developers will drop 32 bit is another matter.... but I believe they will eventually.

We will continue to support 32-bit as long as we produce 32-bit devices. There may be third-party applications that move to 64 bit only - Mathematica for example, and possibly others, but from a kernel point of view and our own code (unless there are technical reasons it will not work), we will continue to support 32-bit.

I need to investigate Pi-connects requirements so will get back on that one.

Software guy, working in the applications team.

Cross-posted with above

KeithMck wrote: ↑

Mon Sep 01, 2025 9:36 am

32bit is really old tech these days

Everything pre-2016 was 32-bit only, and Zero W after that. That appears to amounts to over 8 million Pi sold which are 32-bit only. That may be les than 15% of all Pi sold, and decreasing by the day, but it's still a significant number.

I wouldn't be surprised if Raspberry Pi eventually walk the path of "it's old, throw it away, you need to buy something more modern" as Microsoft and others do, but would like to know where they stand, what the roadmap is, and ideally as early as possible rather than waking up one day to discover support has ended.

Like others I cannot see support for 32-bit being dropped while 32-bit products are still in production. And there should be a period after that while 32-bit OS keep getting updates. But at some point those OS will no longer be supported and won't even get security updates.

At some point it will become "throw it away or keep using an unsupported OS which isn't receiving security updates" which really isn't recommended.

The issue is three-fold - What the future holds for 32-bit Pi and what the strategy should be for using 32-bit on 64-bit capable Pi to allow SD Cards to also be used on 32-bit Pi, or to maintain exact equivalence when both 64-bit and 32-bit Pi are used.

I still buy, use and deploy, 32-bit Pi and I would like to be able to make an informed decision on when that will stop being a sensible thing to do. Likewise in respect of installing a 32-bit OS on a 64-bit capable Pi.

Always worth remembering that our kernel is completely open source, so it's perfectly possible to take it and recompile to 32 bit if you need to. However, we will continue to be releasing the kernel/OS for all our products until at least their (no earlier than) obsolescence dates. (2030 for the 32 bit devices)

Software guy, working in the applications team.

jamesh wrote: ↑

Mon Sep 01, 2025 10:26 am

from a kernel point of view and our own code (unless there are technical reasons it will not work), we will continue to support 32-bit.

So why doesn't the Raspberry Pi VS Code Pico Extension support 32-bit ?

Or perhaps a better or fairer question is whether it will ever support 32-bit and when ?

That's already causing me issues because I installed Bookworm 32-bit so I could re-use my SD Card on 32-bit Pi, can configure SD Cards on my Pi then simply move them to 32-bit Pi.

To maintain equivalence I am not using the VS Code Pico Extension on Windows, which means I am missing out on what it offers, but more significantly I am unable to help others who are using that.

I could upgrade to Bookworm 64-bit but that's more effort than I desire and Trixie is on the horizon. Whether I should upgrade to Trixie 64-bit or stay with 32-bit is a question I am trying to figure out.

If the Raspberry Pi VS Code Pico Extension is going to remain 64-bit only then choosing Trixie 64-bit would be the better choice to make, even if that will create some issues for me. If it is going to support 32-bit within some reasonable time frame then things would be a whole lot easier. I would already be using it if it did support 32-bit.

Hippy
https://www.raspberrypi.com/news/raspbe ... r-devices/
For shell access, I think desktop 'came' when they all defaulted to Wayland, which is what was stopping it even though you could install it since the above post (v1.2) But not found that yet, it'll be in an OS release update.

hippy wrote: ↑

Mon Sep 01, 2025 11:06 am

jamesh wrote: ↑

Mon Sep 01, 2025 10:26 am

from a kernel point of view and our own code (unless there are technical reasons it will not work), we will continue to support 32-bit.

So why doesn't the Raspberry Pi VS Code Pico Extension support 32-bit ?

Or perhaps a better or fairer question is whether it will ever support 32-bit and when ?

That's already causing me issues because I installed Bookworm 32-bit so I could re-use my SD Card on 32-bit Pi, can configure SD Cards on my Pi then simply move them to 32-bit Pi.

To maintain equivalence I am not using the VS Code Pico Extension on Windows, which means I am missing out on what it offers, but more significantly I am unable to help others who are using that.

I could upgrade to Bookworm 64-bit but that's more effort than I desire and Trixie is on the horizon. Whether I should upgrade to Trixie 64-bit or stay with 32-bit is a question I am trying to figure out.

If the Raspberry Pi VS Code Pico Extension is going to remain 64-bit only then choosing Trixie 64-bit would be the better choice to make, even if that will create some issues for me. If it is going to support 32-bit within some reasonable time frame then things would be a whole lot easier. I would already be using it if it did support 32-bit.

The Pico extension is made up of a number of third party extensions, so if one of those is not available for 32 bit then it will not work. It would not be possible to replicate the functionality using homegrown code, so we are limited in what we can do here. There might be bits that would work in 32 bit.

I suspect you are one of the only people (if not THE only) for whom this is causing an issue. VSCode works much better on the latest Pis and the latest Pis work better in 64-bit mode, so for development work, a Pi 5, NVME and 64-bit OS would be my recommendation. There's no real need to stick with 64-bit on a development machine, or to move the SD card to a lower performance device that only supports 32 bit. That would be a very unusual use case.

Software guy, working in the applications team.

jamesh wrote: ↑

Mon Sep 01, 2025 4:19 pm

The Pico extension is made up of a number of third party extensions, so if one of those is not available for 32 bit then it will not work. It would not be possible to replicate the functionality using homegrown code, so we are limited in what we can do here. There might be bits that would work in 32 bit.

I cannot see anything which does not or would not work in 32-bit. It is absolutely fine when building using CMake Tools and using a set-up which seems to have the same third-party extensions.

Most extensions are universal, are Javascript and similar and are executed by and within VS Code itself. It's only when VS Code has to shell out and run something on the host that platform and architecture comes into it. If you need to do a compilation that will shell out and run the compiler on the host.

The VS Code Pico Extension works on 64-bit because it installs and calls the 64-bit compiler. It could likewise call the 32-bit compiler we have which we know works but doesn't because it has chosen not to support 32-bit

The other reason it doesn't work is because the CPU options are specifically "x64" and "arm64" which doesn't include "arm". With that added I used to be able to build the extension and run most of it. I could probably have got it all to work if I were more familiar with the code and 'node.js'.

The latest version appears more tricky to build but I think I might be able to get there or be able to call on others to help with that. It would of course be much easier if 32-bit were simply officially supported.

jamesh wrote: ↑

Mon Sep 01, 2025 4:19 pm

VSCode works much better on the latest Pis and the latest Pis work better in 64-bit mode, so for development work, a Pi 5, NVME and 64-bit OS would be my recommendation.

If you would like to post me a Pi 5 kit and an NVMe add-on, I'll be happy to send you a thank you note and let everyone know how I get on.

Much as I would prefer to use VS Code with the Pico Extension instead of CMake Tools I can't justify spending 120ドル+ just to do that.